We start with another boot2root machine from Vulnhub. This machine is called Infovore and is misconfigured by the administrators a very known vulnerability that appears in OWASP Top 10. As per the description of the machine, it is supposedly configured by lazy administrators and our job is to exploit innocent-looking PHP functions while capturing all 4 flags on the machine. We start with powering on the virtual machine.
We immediately get an IP address displayed on the screen after booting. We conduct a Nmap scan as usual and enumerate the machine for ports, services, and any other information we can enumerate.
Only to find port 80, an HTTP service running on the machine. It was weird as generally, machines have more than one ports open. However, we press ahead to use Nikto and Dirb in the background, while we visit the webpage and look for further clues on it.
Seems nothing interesting at first, even the source code provides no clue. The title of the page says “Include me…”. As we know it is a PHP based website and we need to exploit PHP functions, could it mean exploiting the PHP Include function? Well, that may be a possibility. Meanwhile, we wait for the results from Dirb and Nikto. Dirb results show an “info.php” webpage which is unique.
Opening the “info.php” page shows us a phpinfo (PHP Information) webpage. We get the version number and wealth of knowledge regarding the PHP version installed.
We check with our Nikto scan result if we can find anything else about the website. The website does give us small hints. However, we require something more concrete to go on for now.
From the bottom results, we find an RFI (Remote File Inclusion) location on the info.php page appending a parameter along with the text file from another website. In RFI vulnerability, it displays the content of the other website page on our machine’s webpage. By this we mean, the external scripts will execute on our website and display as a part of our machine’s webpage. With this, we know that RFI is detected. Similarly, we can try LFI (Local File Inclusion) just like we found RFI. However, the fundamental difference is that LFI includes local files on the machine itself. So, we look in the direction of brute-forcing parameter names as we are unsure which parameter would work.
We send the phpinfo page request to the Burp Intruder tab. We add a “?” (question mark) followed by the “test” parameter and its value “/etc/passwd”. The URL will look like “info.php?test=/etc/passwd”. From the intruder tab, we brute force the “test” parameter where Burp replaces the test parameter for our specified parameters which we will add. Now that the position has been set for the attack, we select an attacker type “Sniper” as we brute-force only one parameter. Next, we need to set the payloads for the attack.
In the Payloads section. We manually add a custom list of parameters that we find from Github: https://github.com/danielmiessler/SecLists/blob/master/Discovery/Web-Content/burp-parameter-names.txt. This list contains a different parameter that we can brute-force and proceed to start the attack.
As we brute-force, we will be focused on the length column. By default, the page length will be the same or few bytes above or below. However, pages with actual value would show a shorter content length as the file size of the local file we are accessing is significantly less or it could append the output along with the actual page. Hence, we will have to then look at the Response tab for the output we are looking for. From the above, we did not find any parameter to work. However, we also gave the main index.php a try as well.
Same Attack and Payloads as before, but with a different URL.
Sorting through the length column for the least file size, we find a parameter “filename” which in its Response tab displays the contents of the file as displayed in the above image output. The next step is to gain a shell using the LFI technique.
So, we found an exploit that requires two conditions to achieve an RCE. Firstly, an LFI and secondly phpinfo. As we have both the conditions, we will now proceed to download the exploit and look at the exploit code.
Upon a further look at the code, we find some parameters to be changed. These parameters are IP address and the Port number for the exploit to run. However, we only change the IP address as required.
Scrolling below we find that the LFI parameter needs to be adjusted as per the parameter we have found while brute-forcing.
The REQ1 variable requires the phpinfo page, hence we change that and the LFIREQ variable to add the parameter filename. Now we save and exit the code and move to the execution of the code. Before execution, we will spawn a NetCat listener on the localhost and the mentioned port in the code.
We now move on to check the parameters to be executed with the exploit and execute it.
Exploit runs without errors and says a shell has been created. Looking back at our other window with NetCat running, we find shell access on the machine.
Since we have a shell, we proceed to enumerate the machine and check for flags or clues.
Straight away we find oldkeys.tar, a compressed archive maybe containing keys. Before proceeding ahead, we use bash –i to break the shell into an interactive shell.
As we search for flags, we find a flag within the HTML folder. A user.txt shows as our first flag.
After looking around, we now proceed to copy the compressed archive to the /tmp folder and extract it. Once extracted, we move on to finding keys public key and private key for the root user.
We can log in using the private key. However, to get root access, we require a password for the root user which we do not have. To get the password using the key, we need to convert the private key to a hash which is generated by using a tool called ssh2john.
We save the key on our machine and move ahead using the ssh2john tool. Once we have the hash, we save it to a file and then pass the hash to the john-the-ripper tool along with a wordlist to be brute-forced against.
Now, we get the password for our hash. We move ahead to change the user to the root account. With the password, we found above.
Now we successfully log into the machine with our credentials. We then check the /root folder as it gives us a root.txt flag.
With two flags down, two more to go, including root access to the machine. As this root user in a docker environment and not an actual root user of the machine.
We also find a .ssh folder and find again the private key and a public key for the user admin. We SSH into the admin user along with the same password and log in to another user account.
We are now the admin user again. We check the user’s folder to find an admin.txt file containing the flag.
To break out the docker environment, we proceed to gtfobins. It shows commands and how they can be used for breaking out of their shell.
We search for the docker and copy-paste the code in our shell.
We now have root access on the machine.
We now move on to successfully finding the last flag along with owning the root access that was achieved.
