Introduction
On May 4th, 2022, F5 released a security advisory that discussed a vulnerability in BIG-IP’s iControl REST system that could allow an attacker to bypass the software’s authentication and execute arbitrary commands. This vulnerability has been assigned CVE-2022-1388 by NIST.
The vulnerable versions of this device are as follows (and can be found on the devices filesystem in “/etc/f5-release”)
- 16.1.0 – 16.1.2
- 15.1.0 – 15.1.5
- 14.1.0 – 14.1.4
- 13.1.0 – 13.1.4
- 12.1.0 – 12.1.6
- 11.6.1 – 11.6.5
These potentially vulnerable devices can be found using a simple Censys search query: (services.http.response.html_title: “BIG-IP®- Redirect”) or services.http.response.html_tags=`<meta name=”description” content=”F5 Networks Configuration Utility.”>`
And at the time of writing, there were just over 3,000 services, and a little over 2,500 hosts/virtual-hosts matching this fingerprint in the Censys database. The majority of these hosts reside in Asia with 38.8% of the total, while Europe is a close second with over 30% of the total.
It has also been reported that this vulnerability is being actively exploited in the wild, so administrators should check their assets, and upgrade immediately.
Technical Summary
The BIG-IP server has several HTTP servers running: An Apache server for frontend operations (listening on a public interface) and several internal backend web servers, including a Jetty server for the iControl REST API. And while the backend services are not publicly accessible, several URI paths are exposed on the frontend server, which are proxied internally by the frontend Apache server with mod_proxy.
When a user authenticates to the frontend Apache server, a custom Apache module called mod_auth_pam is used to validate the incoming credentials. But if the client includes a header named “X-F5-Auth-Token”, the credential validation is deferred to the service handling the request and assumes that the downstream service will do the right thing (and reject invalid X-F5-Auth-Token values).
But the iControl backend service has a rather interesting logical oversight. When a request is sent directly to the service via localhost, and the “X-F5-Auth-Token” is not present, the request is permitted without validation as long as a valid username is found in the Authorization section of the request. The idea (we’re guessing) is that any local request should be inherently trusted, as there was no way for an external client to preclude the X-F5-Auth-Token header (and not include credentials) without being dropped at the frontend via mod_auth_pam.
But what if there was a way to trick mod_proxy into removing the “X-F5-Auth-Token” before sending the request to the local backend service? Let’s look at the HTTP/1.1 specification, RFC7230, under section 6.1 for a hint:
This statement means that any non-standard token values (close/keep-alive, etc.) found in this header are treated as headers-to-remove when acting as a proxy. So, as an example, if a client’s “Connection” header contains the value “close,X-F5-Auth-Token”, an RFC conforming proxy server (like Apache mod_proxy) will remove the X-F5-Auth-Token header from the request before sending it to the backend. And this is precisely how an attacker can bypass the original assumptions made by the backend service.
A simple vulnerability test request can be made to any BIG-IP service using the following curl command:
