On 3rd July 2020, Twitter was abuzz with news of a high profile vulnerability. F5 had released an advisory about a vulnerability in their platform with a perfect 10 CVSS score – the worst a vulnerability can get. Immersive Labs doesn’t run any F5 appliances, but being quick off the mark with content on new and hard-hitting CVEs is a core part of our service, so it was time to create offensive and defensive labs on these vulnerabilities.
There goes my weekend!
Where to start?
The first place to look for more insight into these threats was the official Security Advisory from F5 themselves. Although it didn’t give much detail, the report told us this was an RCE in the TMUI web application, and provided us with version numbers, patch releases, and some impacts these vulnerabilities might have. They said:
This vulnerability allows for unauthenticated attackers, or authenticated users, with network access to the Configuration Utility, through the BIG-IP management port and/or self IPs, to execute arbitrary system commands, create or delete files, disable services, and/or execute arbitrary Java code. This vulnerability may result in complete system compromise. The BIG-IP system in Appliance mode is also vulnerable. This issue is not exposed on the data plane; only the control plane is affected.
There were no examples of how this could be abused or any proof of concept examples, but it did list a mitigation.
The mitigation
<LocationMatch ".*\.\.;.*">
Redirect 404 /
</LocationMatch>
Note: Several days after this was first published an updated version of the mitigation was released.
Adding this code to your Apache HTTPD configuration would limit the threat from external attackers. Essentially, the mitigation was doing three things here. Firstly, it looked at the URL that had been requested. It checked whether this matches a regular expression, and if so, returned a 404. Now let’s take a closer look at the regular expression.
The ..; is the important bit here. What was it allowing? Initially we thought it could be command injection. After all, this is a Linux OS and the ; character is well known for abusing command injection vulnerabilities. But then why use ..? That’s something commonly seen with path traversal attacks…
Just start playing
With a few questions rattling around and a list of things we already wanted to test, we decided to get going, but we needed a vulnerable version of the appliance. Luckily (for us at least) the official AWS marketplace images were still on a default vulnerable version.
After just a few minutes, we had a vulnerable appliance up and running. After an hour or so of testing, I found a valid path traversal. Bingo! This alone wouldn’t exploit anything, but it did mean I was on the right track. We now needed to find a URL path to call that would give us some sort of code execution.
Methodological approach
Once we had a path traversal, we needed to find a web page or functionality in the application that would let us issue operating system commands. Large applications like this usually have something but are often poorly documented. Navigating to search for anything interesting is a slow approach, but one that had to be done.
With full access to the application and the operating system, we jumped into a shell to take a closer look, and it seemed that the TMUI was a Java application. We lacked the strong Java skills needed to write a full application but knew enough to decompile and read the source to figure out what goes where.
We also used the open source Find Security Bugs tool to run a quick audit on the code. While this would give us some false positives, it did give us an idea of the more obvious issues.
That’s a lot of bugs!
A lot of warnings were thrown up – and that’s just from one of several components. Armed with the report, the mitigation, and easy access to a test environment, it only took a few more hours to identify the vulnerable route and several functions within the application that could be abused to gain access to the underlying operating system.
…and we weren’t the only ones! Around the same time as our discovery, the InfoSec community began to see other researchers publishing details and reports of active exploitation by attackers.
To see our offensive and defensive labs on this critical vulnerability, book a demo.