Base
Last updated
Last updated
PHP is one of the most popular back-end languages in the world. It's flexible, cross-platform compatible, cost-efficient and easy to learn. Services like Facebook, Wikipedia, Tumblr, HackTheBox, and Yahoo are built with PHP, not to mention Wordpress and other content management systems. However, PHP can often be misconfigured, which leaves huge vulnerability holes in the system, which cyber criminals could exploit. Ethical Hackers & Penetration testers need to know how PHP works, along with the many varieties of misconfiguration that they can discover. The Base machine teaches us how useful it is to analyze code & how one slight mistake can lead to a fatal vulnerability.
Start with basic nmap scan.
It shows that port 22 and 80 are open. These are showing as SSH and HTTP.
We'll start by visiting the Target IP address URL:
I then checked the source code for the page briefly but nothing popped out. I can always come back to take a more in detailed look if need be.
There is a login button at the top right-hand of the screen that we can click.
This shows the following URL for the page:
I'll check wappalyzer while I'm at it.
By going to just the login URL shown below:
Three files exist in the login directory.
/config.php
/login.php
/login.php.swp
In the context of computing, a swap file with an extension of ".swp" is a temporary file used by some text editors, such as Vi or Vim, to store changes made to a file while it is being edited. When you open a file in Vi or Vim, a hidden ".swp" file is created in the same directory as the original file. This file is used to store changes made to the file while you are editing it. If the editor crashes or if your system loses power, the swap file can be used to recover your unsaved changes when you reopen the file. It is worth noting that the swap file is not a backup of the original file, and should not be relied upon for data recovery in the event of file loss or corruption. It is also important to clean up any leftover swap files after you are done editing a file, as they can take up disk space unnecessarily.
In the case of this question, they are referring to the /login.php.swp
file in the /login
directory.
If we view the source code for the /login/login.php
page it doesn't show any of the backend code.
However, if we download the /login/login.php.swp
file and use strings
to view it, we will get some good information.
The first is possible credentials at the top of the file for root:
The next is the backend php code for validating the user's login:
It looks like strcmp()
is used to compare the input to the known credentials.
The PHP function strcmp()
is used to compare two strings in PHP. It takes two string arguments and returns an integer value that indicates the result of the comparison. The strcmp()
function compares the two strings character by character, starting from the first character of each string. If the two characters being compared are equal, it moves on to the next character in each string. If the characters are different, the function returns a value that indicates which string is "greater" or "less" than the other, based on their respective ASCII values. The return value of strcmp()
is zero if the two strings are equal. If the first string is greater than the second, it returns a positive integer. If the second string is greater than the first, it returns a negative integer.
I first started by trying:
Neither worked so I tried running a gobuster scan to see what other directories were available.
None of these panned out so I next tried another gobuster scan while adding a .php extension to the end of the wordlist words.
We have a couple of other pages I'll try to curl. It doesn't look like any of them work.
None of these are working so instead let's see if we can exploit the php login page since we know the backend code.
Since the code snippet is using the strcmp()
function with ==
to compare the value of the two strings, it should be easy to grab a packet and manipulate it gain access.
For note, you should use ===
which compares values and types.
So let's first capture a packet from burpsuite and send it to the repeater.
Next, let's change the username
and password
parameters and change them to arrays by placing []
at the end of them. Arrays will automatically have a null
value that translates to a value of 0
. Since the code snippet looks for a value of 0
, it should allow login.
See below for how that should be done.
This now gives us access to the /uploads.php page that we previously found in our gobuster scan.
Unfortunately, this still doesn't tell me where the file was uploaded.
I next tried uploading a reverse shell with a php extension to it and trying to capture the response to see if it would tell me where it was uploaded.
Unfortunately, no answer but it did let me upload a .php file without any issues meaning I'm totally going to exploit that later.
So I took a few guesses on what the upload directory could be. I tried /upload
, /uploads
, /uploaded
, /
uploads
, /_upload
, and finally /_uploaded
.
And I got /_uploaded
to work which shows the file I just uploaded. I need to reupload the file though because the one I uploaded doesn't have the correct IP.
I uploaded a new php reverse shell with the correct information.
I then started up a Netcat listener on my host machine.
I then opened up the reverse shell on the /_uploaded
directory and I now have a shell into the target system.
I then stabilized the shell with python by running this command to give me a more interactive shell.
I then checked out the home directory.
It looks like there is another user on the system named john
.
After a lot of browsing through the system, I ended up finding the admin's credentails in the config.php file
The credentials we have are admin:thisisagoodpassword
I next tried a bunch of things that didn't work.
I tried logging into admin over ssh.
I tried switching users with sudo -u, which did not work.
I uploaded linpeas and ran it but didn't find anything.
I explored the system more and didn't find anything.
I ran sudo -l to see what privileges I had.
What I should have done was:
Use the password we got from above.
Or ssh into john's account with that password.
After I ssh into John's account I run the following to see if they have any sudo privileges.
Looks like they have sudo privileges to /usr/bin/find
Run the following to see what options we have with the find command:
It looks like the -exec
flag allows to execute commands with the find command.
Run the following to see the user.txt
f54846c258f3b4612f78a819573d158e
Since we have root privileges with the find command, we can actually find and see files as root. In this case, we are going to look for the root.txt file in the /root directory.
Here is the breakdown of the find command
Sudo --> We can run it as sudo based on what we learned previously
find --> Command to find a file.
/root --> Specify the directory to look for the file.
-name --> Flag to specify the name of the file
root.txt --> Name of the file we are looking for.
-exec --> Flag to specify a command to run on the file we found.
{} --> represents the path of each file found by the find
command,
\; --> ignals the end of the cat
command
This ultimately gives us the root flag.
51709519ea18ab37dd6fc58096bea949
You can also escalate your privileges with the following command from GTFOBins.