Skip to content
Now Available: Threat Detection, Defense & Remediation using ASM | Read Now
Blog

CVE-2022-1388: F5 BIG-IP iControl REST Vulnerability

Share

May 11, 2022

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&reg;- 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:

When a header field aside from Connection is used to supply control information for or about the current connection, the sender MUST list the corresponding field-name within the Connection header field. A proxy or gateway MUST parse a received Connection header field before a message is forwarded and, for each connection-option in this  field, remove any header field(s) from the message with the same name as the connection-option 

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:

curl -H"Content-Type: application/json" \
  -H "Host: localhost" \
  -H"Connection: X-F5-Auth-Token, keep-alive" \
  -H"X-F5-Auth-Token: 0" \
  -u admin: \
  https://$HOST/mgmt/tm/ltm/pool

If the response is an HTTP 403 status, the device is not vulnerable. Otherwise, administrators should patch immediately.

What can be done?

  • Censys ASM customers have had a risk enabled on their workspaces since May 4, 2022, the date of the vulnerability’s release.
  • F5 BIG-IP users should make sure they are running one of the following patched versions of the software:
    • v17.0.0
    • v16.1.2.2
    • v15.1.5.1
    • v14.1.4.6
    • V13.1.5
  • Refer to https://support.f5.com/csp/article/K23605346 for more information about workarounds and patches.

References

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1388
https://support.f5.com/csp/article/K23605346
https://www.horizon3.ai/f5-icontrol-rest-endpoint-authentication-bypass-technical-deep-dive/

About the Author
Mark Ellzey
Senior Security Researcher All posts by Mark Ellzey
Mark Ellzey is a Senior Security Researcher at Censys. Before his current role, Mark has worked as both a network security engineer and software developer for several internet service providers and financial institutions for over 22 years.
Attack Surface Management Solutions
Learn more