Disclaimer: This article was first published on Secure Guest
Original link:www.anquanke.com/post/id/210…
Sorry for being late. In fact, I have been paying attention to this vulnerability since it broke out. However, due to my work and lack of free time, I have not been able to analyze it by myself. None of the articles talked about the principle of this vulnerability seriously, which made me a little curious, so I spent more than a day on the weekend to re-analyze this vulnerability.
This paper mainly records the problems and solutions encountered in the recurrence analysis of this vulnerability, hoping to help you
Environment set up
I thought I had to pay for this product. However, when I went to the official website, I found that BIG-IP could apply for trial use, so I downloaded the VIRTUAL machine of Big-IP to reproduce, which was also convenient for debugging and analysis later.
Go to this page on the official website and select the version you want to download:
Downloads.f5.com/esd/product…
If I remember correctly, I should choose the version marked in red, click in and continue to select the version to download
Because my VIRTUAL machine is vmware Fusion, I choose the first virtual machine image in the picture to download
In vmVare Fusion, go to “file -> Import” and start the big-IP VIRTUAL machine. The user password is root/default. It also seems to change the login password of the Web.
After starting the VIRTUAL machine, you need to configure the IP address. I will not expand here, see the detailed operation
Blog.csdn.net/ice_age1/ar…
This article is very detailed and basically solves all installation problems 8
The login page is displayed at https://VM IP/ in the browser. The default password is admin/admin. If you have changed the password, the password will be the same
Log in and input the license to activate the product. However, failure to activate the product does not affect the reoccurrence of the vulnerability.
Vulnerability emersion
Now that the environment is set up, let’s reproduce the vulnerability first. Only when we reproduce it, do we know how to analyze it
Read the file:
https://192.168.133.128/tmui/login.jsp/.. ; /tmui/locallb/workspace/fileRead.jsp? fileName=/etc/passwd
Execute command:
. ; /tmui/locallb/workspace/tmshCmd.jsp? command=list+auth+user+admin
This command displays information about the user admin who has logged in. If the user admin has not logged in, no information is displayed
I will simply reproduce these two here, and refer to Master JAS502N for other ways of use:
Github.com/jas502n/CVE…
Vulnerability analysis
Learning, in my opinion, a loophole, than just learning the vulnerability of principle, thinking and learning about the author’s mining, and the characteristics of the corresponding application or usage scenarios, such can enrich our knowledge reserves to the greatest extent, so every time I analyze loopholes will probably go to fathom the author is how to excavate the point
There’s a little bit of a twist to the analysis, so you’ll just have to play it by ear
I before analysis, first saw an article on the analysis of the others (this article was later I found that is not correct, completely is I biggest stumbling block in the process of analysis of this loophole, because the error analysis of preconceptions), and then probably see the problem, the article analysis mentioned in the authentication of the cause of the hole is mainly the servlet problem, That is the problem of code implementation, but the article did not mention how the author found this vulnerability, is it really code by code?
In order to better understand the author’s mining ideas, I decided to take a look at the vulnerabilities mentioned in the article and start debugging, just as I was familiar with big-IP first
Because big-ip is integrated into the virtual machine, unlike other applications that provide source code or installation packages, I thought the first thing to do was to pull the code out of the virtual machine. Big-ip is deployed in the virtual machine under /usr/local/www
Here comes the first question:
- Isn’t the default deployment directory of Tomcat under Webappps? Custom web root? And isn’t tomcat’s default HTTPS port 8443?
After my inspection, I found that Tomcat does not have a custom web directory. Then I began to wonder if the application is not deployed under Tomcat.
To find out exactly where the application is deployed, I looked up ports
netstat -anp | grep 443
Big-ip is an Apache + Tomcat architecture. Apache acts as a reverse proxy to forward requests to Tomcat for processing.
Then I checked the HTTPD configuration file and found, sure enough, that the web directory was configured as /usr/local/www, which solved my first question.
Then continue, according to the POC can know that the vulnerability point is in the TMUI directory, so I directly drag the TMUI directory, I wanted to directly deploy to the local debugging, but the moment the code ran I found that I did not have a database ah, debugging P
Now either remote debugging, or to change the local code database address, but thought about it, it seems to directly change the database address may be more troublesome, mainly because I can not find his database configuration file ~
So the curve saved the country, choose remote debugging, but now there is a problem
- Is big-IP in debug mode?
The answer is obvious. Why would someone else package a product for you in debug mode
So I have to manually start the debug mode, because big-IP runs on Tomcat. Isn’t it easy to start tomcat debugging?
As we all know, Tomcat starts debugging by running catalina scripts directly in JPDA mode
catalina.sh jpda start
There is no catalina.sh script in the Tomcat directory on the VM, which leads to the next question
- How does Tomcat start?
Check the process information
ps -ef | grep tomcat
As you can see, here is the most suspicious part, which is probably the script that started Tomcat
I found the script and looked at its contents. Sure enough, it was a Tomcat startup script
The script directly uses Java to run bootstrap to start Tomcat, so I will directly start Java debugging for you. When I was about to modify the script, another problem occurred
- Readonly file system disables writing.
Well, thanks to the Linux course at school, re-mount /usr as writable
mount -o remount w /usr
If you do not know which directory is mounted, you can use cat /proc/mounts to check whether the dtomcat script is mounted. After the dtomcat script is mounted, you can add a line in the following location
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8080
Then save the changes, restart the machine, and check the process information again to find that our Tomcat is running in debug mode. The next step is to configure IDEA and prepare for remote debugging code.
IDEA Remote debugging code configuration method search below, here I set the remote debugging port is 8080
But when I had everything configured and clicked to start debugging, another problem popped up
- Why is idea debugging timeout? Wrong port? Failed to start debug mode on the server?
I check the server and find that port 8080 is in the listening state, indicating that Tomcat is running in debugging mode, that is, the port is filtered by the firewall. I pull up my Nmap and see port 8080 is filtered, but it’s filtered
I felt the problem was getting a little tricky and tried to change the firewall rules of the VIRTUAL machine using iptables
Use the TMOS shell utility to make changes to the system configuration. For more information, see "tmsh help security firewall management-ip-rules"
According to the prompts, it can be seen that the VIRTUAL machine has its own firewall management tool, executed
tmsh help security firewall management-ip-rules
You can view the firewall policy configuration syntax. After executing it, I looked at the English help document on the screen and was lost in thought
Have no way, still get top ah, after a toss and turn over and over again, felt clear his configuration rule
Run the TMSH command on the terminal to enter a new execution environment (which should be dedicated to configuring the VIRTUAL machine) and then run the following commands to enter the management-IP-rules module
Then start adding firewall rules
modify rules add { accept-8080 { destination { ports add { 8080 } } action accept place-before first ip-protocol tcp } }
Then enter quit to exit the TMSH environment. I did not specify ip-protocol when I added the rule at the beginning and kept prompting me
No source or destination port argument allowed for non-port-based protocol (0) on firewall rule
If you are good at English, you can try to translate it. I was wrong several times before I remembered the meaning of No and prohibition.
OK, now the firewall rules are ready, idea end click debugging, see the connection is successful, I directly excited to jump a set of national primary and secondary school third set of broadcast gymnastics
OK, let’s take a look at the web.xml and take a look at the servlet configuration. The analysis article focused on the ControlServlet, so I followed through on the configuration of this servlet
The servlet is then mapped to the following directory
The controlServlet is configured with the load-on-startup property, so the servlet is initialized as soon as Tomcat is started. The servlet overrides the doGet/doPost method. All requests are processed by this servlet. As a Java novice, I have no idea why all requests are processed by this servlet. My only knowledge is that servlet-mapping is configured for specific directories. I thought it was load-on-startup, so I asked my Fellow Java Web developer and he told me that there was no such operation. I didn’t believe him, so I did an experiment and found that there was no such operation. So I fell into thinking about life and society again
- Where exactly is the configuration that allows the servlet to accept all requests?
If you can’t figure it out, you have to do it, so seeing is believing, and I started debugging at the break point of the controlServlet, and I realized that everything was going through the controlServlet, which it wasn’t, but, At this point I was still wondering if there was something wrong with my debugger (because I’ve had breakpoints fail to trigger before), so I’m still not sure if the article was written wrong, since it was written by an authoritative organization.
I have been studying the controlServlet for a long time, but I can’t figure out what the permission verification mechanism in the controlServlet mentioned in that article has to do with this vulnerability, because breakpoints are not triggered
So I rejected the analysis in that article for the time being. I thought, since I knew that the vulnerability was caused by the HTTPD/Tomcat resolution difference (but where the difference was, or why the difference was causing permission bypass, I didn’t know), that since it was a parsing difference, HTTPD releases my request as a normal request, but on the Tomcat side it sees a sensitive request, i.e
We send:
/tmui/login.jsp/.. ; /tmui/locallb/workspace/tmshCmd.jsp
HTTPD see:
/tmui/login.jsp/
Tomcat see:
/tmui/tmui/locallb/workspace/tmshCmd.jsp
I need to know HTTPDD and Tomcat in the handling of url specific differences, to know their differences, first of all, I need to understand how they work together
Through searching, we learned that they set up the connection through mod_proxy module. The specific configuration is described in this article in detail:
www.cnblogs.com/f-ck-need-u…
I found the mod_proxy module configuration file:
As you can see, this is the forwarding rule for the HTTD proxy, and I know that they are communicating through the AJP protocol, so to make sense of their parsing differences, I set a breakpoint on the code related to THE AJP communication
In the debugging process, I found a phenomenon that completely overturned the analysis in the previous article, because the analysis said that the permission verification mechanism of the servlet led to the occurrence of the vulnerability, that is to say, they thought that there was something wrong with the code of the product big-IP, which led to the permission bypass, but I found that, When I directly enter the following directory into the browser and request
/tmui/tmui/locallb/workspace/tmshCmd.jsp
The breakpoint at AJP did not fire, but when I requested /tmui/login.jsp, THE AJP breakpoint did. I initially thought that my debugger had a problem again, so I used tcpdump to catch packets on port 8009 (ajP listening port) of lo network card on the VIRTUAL machine
Request a login. When the JSP
Burp under direct request/tmui/tmui/locallb/workspace/tmshCmd JSP, note that here can’t use the browser to access, because the browser to access will jump directly to the login. The JSP, can affect the result of the experiment
You can see that when accessing a file that requires authorization, the package is not caught, meaning that the request never arrives at tomcat at all, so at this point I realize that it is possible that permission validation is implemented in HTTPD at all, not in the controlServlet as described in the article. Finally, I feel like there is a light at the end of the tunnel
Of course, this is just a guess, and I still need to find some proof, so I go back to the configuration file, find httpd.conf, and see
HTTPD uses PAM authentication, but what’s weird about PAM authentication is that when you access a directory that requires permissions, the browser pops up and asks you to enter a password. /tmui = /tmui = /tmui = /tmui = /tmui = /tmui = /tmui = /tmui = /tmui
I guess it’s probably configured (crap, what else is it?)
But I can’t figure out exactly where the configuration is, and then I continue to surf the Internet to see if I can pick up the answer
Turns out I did find a treasure
Big-ip implements its own PAM authentication module, mod_f5_auth_cookie. So, which sets login.jsp to be accessible without authorization and compares only the first 16 characters
That makes perfect sense.
At this point, the bug principle is in front of you, remember the orange 🍊 blackhat issue?
I.blackhat.com/us-18/Wed-A…
Bb: All of my previous research only proves one thing: permission validation is on the HTTPD side, and I tm directly cracked…
Vulnerability principle
The following details the differences between HTTPD and Tomcat in handling urls
Tomcat supports Path parameters. What are path parameters? We usually pass query parameters of a form like the following:
https://xxx/a.jsp?file=xxx
Parameters are separated from the file by a question mark, while path parameters are separated from the path by a semicolon, as follows:
https://xxx/a.jsp; file=xxx
This feature is true 🐂🍺
Then we look at HTTPD source code, mod_proxy_AJP.c, the code is about ajP communication part
The code will be executed to ap_proxy_canonenc, which is in the proxy_util.c file, followed
As you can see from the comment, semicolons can be part of the HTTP path, so when we request
https://xxx/tmui/login.jsp/.. ; /tmui/locallb/workspace/tmshCmd.jsp
It’s going to pass to Tomcat again, there’s no processing
https://xxx/tmui/login.jsp/.. ; /tmui/locallb/workspace/tmshCmd.jsp
This can be seen through packet capture or debugging
The next step is tomcat, which uses the AJP protocol to handle HTTPD requests. In catalina.jar! / org/apache/catalina/connector/CoyoteAdapter class parsePathParameters path parameters for the processing, Path parameters are removed directly, just as the following for loop removes path param
Then, assign the value to uriBC, and you can see that the value of uriBC is:
UriBC from
/tmui/login.jsp/.. ; /tmui/locallb/workspace/tmshCmd.jsp
Turned out to be
/tmui/login.jsp/.. /tmui/locallb/workspace/tmshCmd.jsp
With a semicolon missing, Tomcat will then normalize the URI
/tmui/tmui/locallb/workspace/tmshCmd.jsp
Then, it is based on the web. In XML configuration to find the URL corresponding to the servlet, and the request to the servlet, / tmui/tmui/locallb/workspace/tmshCmd JSP servlet for corresponding
We then execute the command we passed in at tmshCmd_jsp
This is the end of the process.
other
As you can see, the bug principle is actually pretty simple, except you never know what you’re going to trip over, and NEITHER did I know that I spent hours looking at that article, right
In retrospect, perhaps the bug author dug the hole without looking at the code, stumbled upon a reverse proxy architecture, tested it with such a bypass, and found a bug
Refer to the article
This article analysis is very good, this article about C language decompilation that part of the picture are from it, unfortunately it is I wrote this article just a day before, if had seen this article, would not have taken so many detours, purr
Research.nccgroup.com/2020/07/12/…
