The VM image can be downloaded from:
This VM is quite interesting as there are a few “test” files left on the web root directory which should not be there. One of the test file contains a Local File Read vulnerability. This is not to be confused with Local File Inclusion (LFI). Local File Read vulnerability DOES NOT execute PHP code inside the file unlike LFI. LFI can be leveraged to gain code execution but not Local File Read vulnerability.
I discovered another way to get a low privilege shell using a LFI vulnerability found in “panel.php”
To login to “panel.php”, I used the credentials obtained from “c.php” to login to PHPMYADMIN and from the “auth” database, the credentials can be seen to be
It is possible to gain PHP code execution by uploading a valid image extension with PHP code in the metadata and using the LFI to launch the image file.
The LFI will load the image file and if it discover any PHP code in it, it will be executed 🙂
As quoted from the VM description
One need to break into VM using web application and from there escalate privileges to gain root access
I decided to focus on the web application as the attack vector.
Running nikto and dirb with common.txt shows the following results…
It appears that there are a few test files in the web root directory. Let’s visit them individually before focusing on the SQLI hint.
The following “add” file appears to do nothing…
Browsing to the “test” file returned that the “file” parameter is empty. Supplying the file parameter with the input “/etc/passwd” does not seems to do anything…
The ‘file’ parameter is definitely not empty! I decided to try the obvious and change the HTTP method to POST instead. Voila! This could be a Local File Inclusion (LFI) vulnerability.
Let’s investigate further.
The login function can be seen by disclosing the source code of index.php. At first glance, it seems that there is no SQL Injection vulnerability. The parameters “um” and “ps” are properly quoted. Single quotes were used and it is not possible to escape out of it due to the str_replace function. I tried launching “sqlmap” against it and no results were obtained.
I decided to continue to disclose all the source code of the files discovered by dirb.
The test file “c.php” revealed the MySQL credentials. I tried to SSH with the same credentials but no to avail.
The following 2 requests revealed the web root directory to be “/var/www/”
File not found.
I decided to look at the “test” file instead to figure out the actual vulnerability that we currently possess.
We have a Local File Read vulnerability instead of LFI. This means that we can’t execute PHP code.
I was stuck on this part for awhile, trying to figure out how can I obtain a shell from this vulnerability. I decided to enumeration more and fired up dirb again.
By default dirb uses common.txt, I decided to try small.txt and big.txt as well.
Nothing useful from small.txt…
big.txt… Voila! PHPMYADMIN!
Now we have more files to go through.
With the Local File Read vulnerability we can potentially disclose sensitive information/credentials used by the PhpMyAdmin for set up.
Since we know the web root directory, we can easily disclose the config file “config.inc.php” used by PHPMYADMIN.
I tried to login using the credentials but to no avail. I decided to try logging in on SSH with the credentials and Voila!
I think this is not the intended way to root the system since the VM descriptions talk about privilege escalation lol.
Now let us go through the LFI way from panel.php
From the “c.php” disclosed we can see that the PHPMYADMIN credentials are
We can login to /phpmy with the credentials. The “auth” database shows the credentials to login to /index.php, which will then route us to “panel.php”.
Looking at “panel.php” source code with our Local File Read vulnerability, we can see that it is vulnerable to LFI. (It is using the include function, not readfile)
From the source code we can see that the str_replace function only applies to $choice parameter. The else condition does not make use of the $choice parameter, instead it uses the “load” parameter. It is possible to do directory traversal with the LFI.
I created a user with an uploaded image. The images are then uploaded to /uploaded_images directory. Out of curiousity, I decided to LFI one of the existing images in the directory, c.JPG.
So the existing c.JPG contains the phpinfo function. This image file could be a test file used by the developer to ensure that this method works and will allow code execution.
Now it is possible to upload an image file with a PHP reverse/bind shell payload into its metadata and use LFI to execute and gain a low privilege shell 🙂
Stay safe people!