Abstract
On July 1st, F5 Networks published a security advisory regarding a remote code execution vulnerability (CVE-2020-5902) in the Traffic Management User Interface (TMUI) of its BIG-IP devices. BIG-IP devices are used by many organizations, this vulnerability gives an unauthenticated attacker full access to the device and its underlying operating system.
The vulnerability was discovered by Positive Technologies expert Mikhail Klyuchnikov. Their advisory was published on July 2nd, it does not contain any vulnerability details or exploit steps that can be used to assess the impact of this vulnerability. It does have the highest CVSS score, namely CVSSv3 10.
By default the TMUI web interface is not exposed to the outside world. Nevertheless, Shodan records show 8,444 exposed interfaces. Quickly after verification of this threat in our own LAB we noticed during this weekend that malicious actors started to exploit these vulnerabilities trying to gain access to vulnerable devices. On July 5th, several working exploits have been disclosed by researchers, and even a (work in progress) Metasploit module to make the vulnerability even easier to exploit.
This blog is a summary of what we know about the underlying problem in the code base of this vulnerability and how to validate the issues and the patches.
Root cause
At first we thought that the vulnerability relied in the Java layer (JAR/JSP files and related controllers), however we are almost certain the root cause is related to the difference between how Apache and Tomcat handle the character sequence ..;. In particular, Apache seems to interpret it as a folder name, while Tomcat sees it as a path traverse sequence. Due to this it is possible to bypass an authentication filter in Apache and cause Tomcat to execute an arbitrary TMUI endpoint (without being authenticated). An attacker can create a specially crafted requests that could result in arbitrary remote code execution – depending on which endpoint is called. This vulnerability shows once more that not only the code but also the surrounding web server (modules) and the way these are implemented can result in exploitable conditions.
From our first analysis it seems that F5 has made a quick fix by adding a LocationMatch directive in the Apache configuration.
#Returns 404 error when ..;/ is present anywhere in Request URL.
<LocationMatch ".*\.\.;.*">
Redirect 404 /
</LocationMatch>
Validation
curl --silent --insecure 'https://[ip]/tmui/login.jsp/..;/tmui/util/getTabSet.jsp?tabId=Vulnerable' | grep -q Vulnerable && printf '\033[0;31mVulnerable\n' || printf '\033[0;32mNot Vulnerable\n'
Update July 8th
Researchers have found a bypass for the fix mentioned in the F5 advisory. The bypass abuses the internal F5 HSQL Database Servlet to execute code which requires a different exploit sequence hence resulting in a bypass. Abuse of this new bypass has been reported in the wild. The mitigation advice has been adjusted by F5 and their advisory is updated accordingly. Besides upgrading, all access to the management interface should be denied from the internet. In case access is essential it should be restricted to specific IPs to reduce the attack surface as much as possible. We expect that as long as the root cause is not resolved in the appliance overall code base more updates will follow.
Change log
- July 8th, 2020 – v1.1 – Updated FIX F5 due to bypass reported by researchers and exploited in the wild
- July 6th, 2020 – v1.0 – Initial version