Am I I(n)-Control? CVE-2022-1388 Advisory

Background

Last week, F5 disclosed a new critical remote code execution vulnerability in BIG-IP networking devices tracked as CVE-2022-1388. This vulnerability abuses the BIG-IP iControl REST authentication component. A successful exploitation of the vulnerability allows attackers to bypass authentication and execute arbitrary commands on the device. (For the full list of affected versions, please see the official F5 advisory.)

As F5 BIG-IP appliances are popular among enterprises, this vulnerability puts organizations at significant risk as it allows threat actors to gain initial access to networks and from there move laterally in the network. 

The flaw explained

CVE-2022-1388 is a big deal. This is both because of how popular the BIG-IP component is, and because of how trivial it is to exploit. In this section, we’ll discuss this vulnerability in detail, and delve into its root cause.

The flaw exists in the BIG-IP iControl component. iControl is a web services-enabled open API providing granular control over the configuration and management of F5's BIG-IP. The iControl interfaces manage all configuration and management policies of F5’s application delivery platform, and therefore shouldn’t be publicly exposed for any reason.

The iControl REST service runs on a Java application with an exposed Apache server that acts as a reverse proxy to allow “safe” remote communication. 

By design, iControl supports two types of authentication mechanisms:

• Auth-Token authentication using the X-F5-Auth-Token header
• Admin credential authentication using the Authorization header

With the responsibility of the external Apache server, the authentication packets are delivered to the REST-API Service by observing the relevant authentication HTTP headers. In the case that the sent packet contains the X-F5-Auth-Token header, the packet is automatically passed to the REST-API service, at this point without being validated. In the separate case of providing the admin credential authentication in the Authorization header, the credentials are validated in place and refused in case they’re incorrect. Packets without both of the headers are dropped immediately.

The diagram below will help you understand the authentication validation on the Apache side. 

But the authentication validation isn’t done here. The iControl REST Service will continue with the validation that hasn’t been completed on the Apache side. It’ll look to approve the F5 Auth-Token and reject it if it’s wrong. 

Up until now, it sounds like F5 does a good job with the authentication mechanism, as it validates both of the authentication methods, and rejects them if necessary.

However – there can be a case where one of these is true:

• The X-F5-Auth-Token header doesn’t exist in the packet sent to the REST API service and the Host header is set to localhost
• The X-Forwarded-Host is otherwise included in the Connection header. 

When either of these occur, the iControl REST Service will treat the connection as internal, and won’t verify the password in the Authorization header.

In the head example below, we’re simply conducting “admin:axon” as credentials. As you may guess, “axon” isn’t a real password, any string provided to the “admin” user would pass the REST API validation.

The diagram below is a flow of the iControl REST API validation AFTER the Apache authentication below. 

At this point, an attentive reader must be wondering about a very important question: How do we get REST-API validation without the X-F5-Auth-Token header, if the Apache authentication is dropping packets that aren’t included in it? 

And there’s the million dollar question. The answer to that is by deleting hop-by-hop headers. A hop-by-hop header is designed to be processed and consumed by the proxy currently handling the request. When encountering these headers in a request, a compliant proxy should process or act upon whatever these headers are indicating, rather than forwarding them onto the next hop. It can be simply done by adding the related header to the Connection header.

In the Apache validation case, the check for the X-F5-Auth-Token happens before the Connection header. This means we’re bypassing the Apache validation that looks for the X-F5-Auth-Token, and in the case of using localhost as the host header, the REST API service will look for the Authorization header without validating the password. 

The following is a request POC that illustrates this situation:

Am I vulnerable?

The above writeup just confirms the importance of mitigating and assessing your publicly exposed F5 BIG-IP devices.

For convenience, we have written a script that scans for F5 BIG-IP components with exposed iControl REST API. This script was shared with Hunters’ customers earlier this week and searches for devices with an exposed iControl REST API by examining requests to /mgmt/shared/authn/login.

The script is available here: https://gist.github.com/axon-git/2b8c7b06b49b00d8374e79f691577af7 

In addition to that, we highly recommend using the following Shodan query to track potential externally exposed servers associated with your environment: https://www.shodan.io/search?query=http.title%3A%22BIG-IP%26reg%3B-%2BRedirect%22+%2B%22Server%22

Hunt and detect with Team Axon

In order to reliably hunt and detect exploitations, let’s take the lessons learned from above and examine them in the relevant logs.

We know that to reach the internal iControl REST API service, we have to be validated by the exposed Apache server with an HTTP request first. In that case, we will have the relevant visibility in the CDN, WAF, or layer seven FW logs, which will examine inbound HTTP/s traffic in case the server is indeed behind them.

To summarize, these are the requirements needed for exploitation:

• HTTP POST request directly to /mgmt/tm/util/bash, which is the REST interface to execute commands. 
• Authorization header with admin credentials and an empty password (or any desired password)
• X-F5-Auth-Token header containing a random string 
• Connection header with X-F5-Auth-Token in order to remove the header from the internal request to the REST API service.
• Host header set to localhost (127.0.0.1) or alternatively including the X-Forwarded-Host header in the Connection header. 

A successful exploitation can be detected by reviewing the inbound HTTP POST traffic to /mgmt/tm/util/bash URI with a status code of 200, which will be returned only in cases of successful exploitation.

Have you found one of these requests? Then we recommend performing the following investigation flow:

• Have these requests been seen before 2022-05-03 (vulnerability announcement date)? If so, there’s a high chance your organization uses the REST API externally for legitimate reasons. In that case, we highly recommend considering restricting external usage, even if patching has already been implemented.
• Examine the source IP
• Examine the packet headers:
  • Is the Host header set to localhost (127.0.0.1) or X-Forwarded-Host header in the Connection header?
  • Do the X-F5-Auth-Token header and the Authorization header exist simultaneously?
  • Does the Connection header include the X-F5-Auth-Token header?

Going through this list should give you a good idea of whether you’ve been exploited.

Team Axon is actively monitoring the usage of the vulnerability in the threat landscape and can confirm that massive scanning has taken place on /mgmt/tm/util/bash URI – not necessarily with an iNTL knowledge of exposed BIG-IP servers, but by simply scanning servers randomly.

We hope you found this writeup helpful. Subscribe to our blog to stay up-to-date with the latest research findings and Rapid Response campaigns by the Hunters team.