CVE-2022-1388 is a critical vulnerability (CVSS 9.8) in the management interface of F5 Networks’ BIG-IP solution that enables an unauthenticated attacker to gain remote code execution on the system through bypassing F5’s iControl REST authentication. The vulnerability was first discovered by F5’s internal product security team and disclosed publicly on May 4, 2022.
What is F5 BIG-IP?
Through a combination of software and hardware, F5 BIG-IP allows the inspection and encryption of traffic passing through a network. It serves as a load balancer, application firewall, and full proxy. F5 BIG-IP is widely adopted and is one of the most commonly exposed services seen across Randori customer attack surfaces. According to F5, BIG-IP is used by 48 of the Fortune 50 and there are more than 16,000 instances of BIG-IP discoverable by Shodan; however, the management interface needed to exploit this vulnerability is rarely internet-facing or publicly exposed.
Is CVE-2022-1388 Exploitable?
Yes. The Randori Attack Team has developed a working exploit and has been able to successfully leverage this vulnerability as part of our offensive security platform. Randori has also released a bash one-liner that can be run to determine if a specific instance of BIG-IP is exploitable.
From our research, the Randori Attack Team is able to confirm F5’s assessment that this vulnerability can be used by an “unauthenticated attacker with network access to the BIG-IP system through the management port and/or self IP addresses to execute arbitrary system commands, create or delete files, or disable services.”
Exploits:-
- https://github.com/bytecaps/CVE-2022-1388-EXP
- https://github.com/sherlocksecurity/CVE-2022-1388_F5_BIG-IP_RCE
- https://github.com/numanturle/CVE-2022-1388
Analysis
The iControl REST API is used to instrument the BIG-IP server, automate tasks, monitor the system, and more. The API is exposed on the management interface and should not be exposed to the Internet.
To understand the root cause of CVE-2022-1388, first the authorization model of the iControl REST interface must be explained. From the iControl API documentation:
“…a user automatically has access to REST resources, but all user [sic] must acquire a token for authentication and include that token in all REST requests. Administrators of a BIG-IP® system can still make REST requests by using basic authentication. As an administrator of a BIG-IP® system, you can use the basic authentication to make iControl REST calls. For users that lack administrator privileges, the user must request a token that can be used to authenticate the user making REST API requests.”
The above defines two modes of authentication: token-based and HTTP Basic. It also highlights that the HTTP Basic mode of authentication is reserved for Administrators, whereas users are relegated to token-based methods.
From an external perspective, connections made to iControl REST over HTTP are handled by a frontend Apache web server on port 443. This server is responsible for routing requests to the appropriate internal services. To reach the iControl REST service, a requested path must begin with /mgmt which will inform Apache to forward the message to an internal Jetty web server listening locally on port 8100.
This Jetty web server will authenticate requests that appear to originate externally and provide a token in the form of an X-F5-Auth-Token header upon success, which must be used in all subsequent communication. If a request is received by the external Apache server with this present, Apache will assume that Jetty will verify the token value and forwards along the header.
From the Jetty server’s perspective, if a request is received without the X-F5-Auth-Token, it is assumed to be administrative and only the username of the HTTP Basic header will be verified to match either admin or root (per Vulnerability Analyst Will Dormann). These are the credentials that were observed to be hardcoded into the application for use to send trusted requests.
CVE-2022-1388 arises out of the combination of the above trust relationships and a small detail in the HTTP specification. The HTTP 1.1 specification is defined in RFC 2616. The specific section of interest for exploiting CVE-2022-1388 is contained within Section 14.10 in the description of the Connection request header:
“HTTP/1.1 proxies MUST parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header field(s) from the message with the same name as the connection-token.”
The above applies to F5 BIG-IP, as the Apache server is acting as a reverse proxy for the backend Jetty application. This allows attackers to remove specific headers from the request that is forwarded between Apache and Jetty by naming them in the Connection header. For example, specifying the following will strip the X-F5-Auth-Token from proxied requests:
Connection: X-F5-Auth-TokenA remote attacker that specifies the above header value while making requests to the external Apache server will be treated as administrative from the perspective of Jetty.
Additionally, the Jetty application tracks the source of requests based on the X-Forwarded-For and X-Forwarded-Host headers. By including X-Forwarded-Host in the Connection header, the X-Forwarded-Host header will also be stripped:
Connection: X-F5-Auth-Token, X-Forwarded-HostThis will blind Jetty to the fact that the request has been forwarded by Apache, and the request will be treated as though it was made from a local perspective.
The mitigation provided by F5 in their initial announcement essentially disallows any value in the Connection header other than “keep-alive” or “close” which effectively addresses the issue in lieu of a patch:
<If \"%{HTTP:connection} =~ /close/i \">RequestHeader set connection close</If><ElseIf \"%{HTTP:connection} =~ /keep-alive/i \">RequestHeader set connection keep-alive</ElseIf><Else>RequestHeader set connection close</Else>The specific interface needed to exploit this vulnerability is rarely publicly exposed, and the risk to most organizations of exploitation by an unauthenticated external actor is low.
How do I know if I’m vulnerable to CVE-2022-1388?
For organizations looking to understand if their F5 BIG-IP instances are vulnerable to exploitation, Randori has released a bash one-liner they can run to determine if a specific instance of BIG-IP is exploitable.
Replace ADDRESS with the host to test:
HOST=ADDRESS; if curl -s https://$HOST/mgmt/tm \--insecure \-H "Authorization: Basic YWRtaW46" \-H "X-F5-Auth-Token: 1" \-H "Connection: X-Forwarded-Host, X-F5-Auth-Token" \-H "Content-Length: 0" | grep -q "\"items\":\["; then printf "\n[*] $HOST is vulnerable\n"; else printf "\n[*] $HOST doesn't appear vulnerable\n"; fiExample Output:$ HOST=192.168.255.2; if curl -s https://$HOST/mgmt/tm --insecure -H "Authorization: Basic YWRtaW46" -H "X-F5-Auth-Token: 1" -H "Connection: X-Forwarded-Host, X-F5-Auth-Token" -H "Content-Length: 0" | grep -q "\"items\":\["; then printf "\n[*] $HOST is vulnerable\n"; else printf "\n[*] $HOST doesn't appear vulnerable\n"; fi[*] 192.168.255.2 is vulnerable$How can I protect myself against CVE-2022-1388?
Randori encourages all organizations running an impacted version of F5 BIG-IP to upgrade to the latest patched version.
If patching the system is not possible, Randori recommends organizations
- Block iControl REST access through the self IP address
- Block iControl REST access through the management interface
- Modify the BIG-IP httpd configuration