PwnLab: Init — Walkthrough

Mr. Robot
InfoSec Adventures
Published in
5 min readOct 1, 2018

Description from Vulnhub:

Welcome to “PwnLab: init”, my first Boot2Root virtual machine. Meant to be easy, I hope you enjoy it and maybe learn something. The purpose of this CTF is to get root and read the flag.

As usual, I started with a simple port scan. This included script scanning, version enumeration on all ports and skipping ping probes, since we know that the machine is online.

I found 3 open ports. On port 80, there was a web server running and I used nikto to enumerate it a little bit. I didn’t found much, except a config.php file that might leak database IDs and passwords.

Of course, we can’t directly access the file so let’s just make a note of it for now. I tried a couple of SQL injection techniques on the login form without luck. Then, I recognized that the site may be vulnerable to LFI (Local File Inclusion). Have you noticed the page PHP parameter? This wasn’t your usual LFI exploitation… I had to do quite a research in order to get a result. Eventually, I found this website: https://diablohorn.com/2010/01/16/interesting-local-file-inclusion-method/ I didn’t have anything to lose, so I decided the mentioned method.

I was using Burp Suite to capture and edit the requests which made this process a whole lot more easier. You can see the Base64 encoded result in the raw response. That’s the content of the config.php file.

Burp Suite has a very handy decoder and I used it to decode the database credentials… You can see the result on the following screenshot.

With this information, I was able to log in to the MySQL database.

The password were Base64 encoded again, so I decoded them…

It was time to log in to the web application and investigate further. I logged in as Kent and tried upload files. I used Burp Suite to capture and edit the requests. I tried a couple of things to bypass upload restrictions but finally I got it. I added the GIF magic bytes to the PHP file and changed the Content-Type along with the extension to make my “picture” more believable.

I have successfully uploaded the file, but I had no way to execute it. This meant that I have to enumerate more and find another vulnerability. I thought, we can read files right? Let’s use that to acquire more information.

I know 2 pages that are present, so I used the LFI vulnerability to read the source code . Decoding the text gives us the following result.

It doesnt’ matter that only the first few lines are shown because only those lines matter the most. There is an include() function call which means there’s another LFI vulnerability that might let us read and execute arbitrary files. I verified it by reading the /etc/passwd file with directory traversal.

The next thing I did was to execute my PHP reverse shell disguised as a GIF image. Using the directory traversal, I simply “moved” up to the web root where the upload is and pasted the path to the file.

Instead of a response, I successfully got a low-privileged reverse shell connection. We are slowly progressing…

I started my enumeration process by checking the previously acquired credentials if they work or not. Mike’s password did not work and Kent’s account wasn’t interesting either. However, Kane had a msgmike binary in his home folder. I ran the executable and got an error message.

Hmmm… Looks like the author of this program tries to run the cat command without providing the full path. This is a bad practice but good for us. I created a file (basically a shell script) named cat in the /tmp directory which runs the Bash program and added it to the beginning of the $PATH environmental variable. This way the system will look for the cat binary in the /tmp directory first and it will execute our shell 😃

I forgot to mention that it was feasible because the SUID bit was set for the group and as you can see Mike is in the mike and kane group.

In Mike’s home directory, there was another executable file that might lead us to root. On the other hand, this one was different. I ran strings on the file and found out that the input gets logged to a text file in the /root directory. The user input is passed to the /bin/echo command and eventually, appended to that messages.txt file. I used command injection (basically command concatenation) to execute a shell after echoing the input. Bash didn’t work, so I resorted to /bin/sh which got me a root shell.

Before You Go

Thank you for taking the time to read my walkthrough. If you found it helpful, please hit the 👏 button 👏 (up to 50x) and share it to help others with similar interest find it! + Feedback is always welcome! 🙏

--

--

Mr. Robot
InfoSec Adventures

Self-taught developer with an interest in Offensive Security. I regularly play on Vulnhub and Hack The Box.