The content of the article
As part of BIG-IP there are different modules that run under the TMOS operating system. One of them – Local Traffic Manager (LTM) – handles application traffic, secures network infrastructure and local load balancing. LTM can be flexibly configured, including through the TMUI (Traffic Management User Interface) web interface. A vulnerability was found in him.
More precisely, I found Mikhail Klyuchnikov from Positive Technologies. The bug exists due to incorrect normalization of the URI when processing requests. An attacker could bypass the Traffic Management User Interface authentication and use system functions that are intended only for the administrator. As a result, the attacker can execute arbitrary commands on the target system from the superuser, which means a complete compromise of the server.
The bug got a number CVE-2020-5902 and 10 out of 10 CVSS criticality points. The vulnerability is present in BIG-IP versions 15.0.0 to 126.96.36.199, 14.1.0 to 188.8.131.52, 13.1.0-184.108.40.206, 12.1.0-220.127.116.11 and 11.6.1-18.104.22.168.
Since the product is commercial, there will be no simple docker container this time. The easiest way to set up a booth is to download a thirty day trial BIG-IP VE (Virtual Edition). This requires an account that you can create on the F5 site… After confirmation, you can go to the downloads section.
We need the latest vulnerable version, which is 22.214.171.124. BIG-IP is distributed in several variants, we are interested in OVA virtual machine image… Before downloading, you will be prompted to choose a convenient mirror.
You can also try using my link to download the image. I can't say how long she will live, but so far she's working fine
After that, we import the downloaded image into our virtualization program. I'll be using VMware, but VirtualBox will do just fine.
After successful import, load the virtual machine. After a while, we see an invitation for authorization.
By default, the password for the superuser is
default (you will be immediately offered to change it). Now you can see the IP address of the virtual machine.
Open your browser and go to this IP. We see the Traffic Management User Interface authorization form.
The stand is ready.
Let's go back to the console. Let's see what kind of web server is listening on port 443.
netstat -lnpe | grep 443
This is an ordinary demon
httpd, but it is obvious that it is used simply as a frontend for proxying requests somewhere further. Let's look among the configuration files for directives
grep -iR ProxyPass /etc/httpd
Found a lot of interesting things in the file
...ProxyPassMatch ^/tmui/(.*.jsp.*)$ ajp://localhost:8009/tmui/$1 retry=5ProxyPassMatch ^/tmui/Control/(.*)$ ajp://localhost:8009/tmui/Control/$1 retry=5ProxyPassMatch ^/tmui/deal/?(.*)$ ajp://localhost:8009/tmui/deal/$1 retry=5ProxyPassMatch ^/tmui/graph/(.*)$ ajp://localhost:8009/tmui/graph/$1 retry=5ProxyPassMatch ^/tmui/service/(.*)$ ajp://localhost:8009/tmui/service/$1 retry=5ProxyPassMatch ^/hsqldb(.*)$ ajp://localhost:8009/tmui/hsqldb$1 retry=5...
Both the name and content of the file suggest that requests are being forwarded to the Tomcat web server over the protocol AJP… I already wrote about it in the article about the vulnerability in Tomcat.
But that's not the problem now. We need to look at how the URI is passed to Tomcat. A big study worth looking at here Orange Tsai on path normalization in various applications, which he presented at Black Hat USA 2018 and DEF CON 26 (PDF). There is a section about Tomcat where the construction
/..;/ is used to exit a directory, bypass some rules and gain access to files with important information. This is possible because the web server accepts the construction
/..;/ as a folder name, and Tomcat interprets it as a relative path – up the tree to the parent directory.
To check if this bug works in our case, let's try to read some file, access to which is normally denied. The list of such can be viewed, for example, in the TMUI config –
Let's try to view it with a simple query.
curl -k "https://192.168.31.140/tmui/dashboard/viewset.jsp" -is
In response, we receive a redirect to the authorization page. Now let's do it using the construction
curl -k "https://192.168.31.140/tmui/login.jsp/..;/dashboard/viewset.jsp" -is
viewset.jsp runs successfully, and the server returns the result.
Now we can read any page and execute servlets that do not check the user session internally.
Let's see what you can dig up in the wilds of TMUI. All the most interesting lies in the directory
/usr/local/www/tmui/WEB-INF/… Servlets themselves are also located here, in compiled form. In this regard, I will need JD-GUI… To make it easier, I advise you to simply archive the directory
/usr/local/www/tmui/WEB-INF/ in ZIP format and open in JD-GUI.
And the list of endpoints, as we have already found out, can be found in the file
/usr/local/www/tmui/WEB-INF/web.xml… There are a lot of them, so here are some of the most interesting ones that were found after the release of the vulnerability to the public.
Continuation is available only to participants
Materials from the latest issues become available separately only two months after publication. To continue reading, you must become a member of the "Xakep.ru" community.
Join the Xakep.ru community!
Membership in the community during the specified period will open you access to ALL Hacker materials, increase your personal cumulative discount and allow you to accumulate a professional Xakep Score!
I am already a member of "Xakep.ru"