As you might have guessed already by the title: I’m not a big fan of web vulnerabilities. Well, actually it is not the fault of the web here, but that I have the feeling the many people are just reporting XSS as if it were super critical. I do fully understand that its consequences can be devastating, but most often they are not. PERIOD.
In this post I want to document an exploit that I discovered during one of my latest pentests. I consider it a great example, that shows that the web can in fact be interesting. By combining several issues it’s often / sometimes / once-in-a-lifetime possible to achieve something really interesting, like a remote code execution. As I can’t discuss the vulnerabilities on the real product (because of legal obligations), I rebuilt the interesting parts myself and pushed them to my race2rce Github repro. So you can try it out yourself it you are curious.
Everything started with the following dirb scan:
As you can see there is a “hidden” directory /Global with directory listing enabled on the target server. Many of the therein identified directories were empty or could only be accessed with valid credentials. However, the folders lic and logviewer were unsecured. Additionally, the file demo.lic could be downloaded.
Let’s start with the folder /Global/logviewer. It’s a simple web page to monitor some kind of log. After selecting one of the listed files, its content is shown. The interesting part is the URL: http://192.168.88.147/Global/logviewer/?file=../logs/fakeapp.1.log. The highlighted parted almost screams for a LFI.
And I was right. By modifying the URL to http://192.168.88.147/Global/logviewer/?file=../../../../../../../../etc/passwd a list of all users was printed.
The big question: Is there anything that is worth reading? Well, let’s check the content of /Global/lic.
It looks like a license viewer where .lic files can be uploaded and checked for validity. By uploading the demo.lic (as previously downloaded) we learn that the license file is not valid (anymore).
The question is, what is this file doing in the background? By abusing the LFI vulnerability we can obtain the underlying source: http://192.168.88.147/Global/logviewer/?file=../lic/index.php
This looks interesting, so let’s analyse the file in detail. In our example here, we can simply use the original file from Github.
The first thing we learn is that there is a magic byte sequence. The file is only processed any further if it starts with “fakeapp”.
After that, the rest of the file is stored with the user provided file name. Because there is no additional path given, the file is saved in the current working directory.
Furthermore, after the license file has been checked it is removed from the server:
Well… this may be vulnerable for a race condition. If we add the magic bytes to any PHP code file, it should be stored in the current working directory with the filename we provide during the upload. If the file is requested at exactly the right time – between it was written to disc and before it is removed – arbitrary PHP commands can be executed. At least that’s the theory.
With that knowledge I started to build a small Python exploit PoC. It uses two threads to abuse the identified race condition. One thread (called writer) tries to upload a malicious PHP license file that can execute arbitrary CLI commands.
The second thread (the main thread) tries to find the right moment to exploit it. The following screenshots shows it in action.
In this blog post I wanted to show that there is more than XSS. Sometimes you have to be creative to find something interesting – like a remote code execution. But please always remember: A vulnerability is only as critical as the data that is exposed on or from the affected system as well as the gained access level.
If you are keen to try it yourself, you can download everything from my race2rce Github repro.