Introduction

In recent years, F5’s BIG-IP made big news as new vulnerabilities were uncovered, which were seen in massive exploitation campaigns like integrating this vulnerability in Mirai’s botnet. Hundreds of vulnerabilities were found in F5’s BIG-IP & BIG-IQ in the last couple of years. One of the critical vulnerabilities reported so far is an Authentication bypass vulnerability in iControl REST (a web services-enabled open API for management and configuration of F5 platforms) of F5’s BIG-IP resulting in remote code execution. This vulnerability was discovered and patched in the first week of May 2022 with a CVSS score of 9.8 and tagged as CVE-2022-1388.

Affected versions and patched versions of BIG-IP are listed in table  below  :

CISA (Cybersecurity and Infrastructure Security Agency) and MS-ISAC (Multi-State Information Sharing & Analysis Center) released an alert to warn public and private enterprises to secure their critical infrastructure as there is ongoing exploitation due to the ease of exploitation and availability of PoC in the public domain. CISA warns that this vulnerability could be used in massive exploitation campaigns as we have seen in the past with other F5 vulnerabilities.

 

About BIG-IP

Before we dive into the vulnerability, let’s learn a few things about the product. BIG-IP is just a fancy product name to describe a bundled network infrastructure product. F5 BIG IP mainly includes custom hardware and software like TMOS (Traffic Management Operating System) and is bundled with a software suite with many modules bundled together. It offers a pay-per-use license model for the modules one avail.

Although it is mainly used for load balancing in major corporations across the globe, it does offer API management, application security etc. For the purpose of understanding the vulnerability, we’d be using BIG-IP VE (Virtual Edition) which offers intelligent traffic management, optimization and app security but from a VM.

 

 

BIG-IP products are licensed modules that run on top of F5’s custom Traffic Management Operating System (TMOS). Some of the modules include :

1. BIG-IP DNS
2. IP Intelligence
3. BIG-IQ
4. BIG-IP Local Traffic Manager (LTM)
5. BIG-IP Advanced Firewall Manager (AFM)
6. BIG-IP Access Policy Manager (APM)
7. Advanced Web Application Firewall (WAF) and a few others

In the past, we have seen numerous vulnerabilities from F5’s BIG-IP some of which were even included in Mirai botnet’s exploit arsenal and others were exploited in other APT campaigns. Here is one such vulnerability, a remote code execution vulnerability in BIG-IP TMUI (Traffic Management User Interface) CVE-2020-5902 exploited by the Mirai botnet.

 

Vulnerability – CVE-2022-1388

This is an authentication bypass vulnerability in iControl REST of BIG-IP. Using this vulnerability, an adversary can execute arbitrary system commands, and create or delete files once network access is gained to BIG-IP via a management port or via self IP address.

To craft the request, first, we will introduce a token so the request gets forwarded to the backend server ( which is iControl in our case) and  set the Connection header to “X5-Auth-Token”. This indicates that the proxy handler drops the current token and forwards the rest to the next hop. Since we only have two hops (apache and jetty), we send this token to apache so that when forwarded to iControl, the token header is dropped. You can read more about hop-by-hop requests here and more on this in Root Cause Analysis below for a better understanding.

let’s see the Steps to Exploit : 

1. Take a sample POST request and hit at /mgmt/tm/util/bash
2. Set the Authentication header to base64 encoded value of “admin:something”
3. Set Connection header to X5-Auth-Token
4. Set X5-Auth-Token to a random value
5. Set host to localhost (this is for self-IP address, not required for a few versions)

Below is the Working PoC

 

Root cause analysis

Let’s dive into the root cause analysis of iControl REST API. Below is the code to check if the request has X-F5-Auth-Token, this proves that it is authenticated but this entire auth checks process is flawed. Let’s see how

 

 

The above code checks if X-F5-Auth-Token exists or not, if not it calls the completeEvaluatePermission function with NULLin the parameter thus, setting the status to unauthorized. Look at the completeEvaluatePermission function below

 

 

In the above nested if code block in figure 6, the code flow deviates from setting the AuthTokenState if the token is NULL. If it’s not NULL, it has another check to determine the validity of the token.

token.expiratonMicros.longValue() < RestHelper.getNowMicrosUtc()

The ‘expirationMicros’ key in a token is a UNIX timestamp in microseconds of the token (that determines the expiration) and getNowMicrosUtc() gets the current timestamp in microseconds.

 

 

With the second check, it checks the validity of the token and sets X-F5 auth token state.

If we look at the code block outside nested if in figure 6, we’ll find setBasicAuthIdentity() getting called when there is no auth token set.

 

 

Now, the setIdentityFromBasicAuth function decodes the header and sets Identity data solely based on the username and you can see the other parameters as null.

 

The decodeBasicAuth function is our usual base64decode as shown below :

 

setIdentityfromBasicAuth is the initial function that gets called in this entire process, by decoding the auth token and pulling the username and setting Identity data from that request.

 

Now, at this point, the X-F5-Auth-Token is empty and the code moves to setBasicAuthFromIdentity()

 

From the figure 9, the code moves to setBasicAuthFromIdentity if the token is null, which then calls encodeBasicAuth

 

 

SetBasicAuthfromIdentity passes authentication username and NULL password as parameters to encodeBasicAuth.

There are two authentication checks, Apache and iControl API (internal webserver).

We have to provide X-F5-Auth-Token to bypass Apache’s authentication (mod_auth), only if we provide it with a value it then passes that request to iControl to confirm the provided token value.

 

Here, our proxy 1 is where we send a crafted HTTP request, proxy 2 is Apache, Backend is Rest API in iControl and our important header here is X-F5-Auth-Token.

 

If we pass Connection: close, X-F5-Auth-Token, we bypass the Apache check as there is an auth-token involved and when the request is transferred to iControl, the important token header is removed thus triggering iControl REST API to choose the above-discussed code path in fig.6? in achieving remote code execution.

 

Stats

Query : http.title:”BIG-IP&reg;-+Redirect” +”Server”

Here are the exposed BIG-IP servers to the internet and most of which seem to be vulnerable to CVE-2022-1388.

Mitigation

K7 security strongly recommends upgrading the BIG-IP to the latest patched version. If you cannot upgrade it for any reason, you can implement temporary mitigations to restrict access to the iControl REST interface.

 

• Block iControl REST access through the management interface (TMUI)
• Block iControl REST access through the self IP address
• Change port lockdown setting to Allow None
• Modify BIG-IP HTTPd configuration

References

1. https://www.cisa.gov/uscert/ncas/alerts/aa22-138a
2. https://support.f5.com/csp/article/K23605346
3. https://www.trendmicro.com/en_ae/research/20/g/mirai-botnet-attack-iot-devices-via-cve-2020-5902.html
4. https://nathandavison.com/blog/abusing-http-hop-by-hop-request-headers