Pwnlab: Init

Since discovering, I’ve been on a bit of a binge.  I use the excuse that hacking all these VMs is helping me prepare for the OSCP, but really, it’s just loads of fun.

We’re going to start with this VM, Pwnlab: Init, since it’s my most recent success.  As is customary for me, I started out with a quick nmap scan of the network:

Looks like we’ve got our target with a webserver, MySQL, and an rpc client.  A quick scan of all tcp ports on the system reveals an extra port that I suspect is an rpcbind helper:

Let’s confirm my suspicion:

Yep, it’s just an rpc helper.  I tried logging into MySQL with a series of “default” combinations of username and password to no avail, so we’re going to move on to that webserver:


Pretty darn basic.  I check the picture for interesting exif data, any steganography, ran any potential insertion point through sqlmap, tried some basic LFI tests, ran it through the ropes with dirbuster (I found pretty standard php files, along with config.php which returned a blank page), and looked for any easy XSS injection points and then ran it through ZAP to confirm.  I had nothing.

I was stuck on this for days and eventually put it down to complete other VMs (I’ll be doing walkthroughs on these as well.).  When I felt refreshed enough to come back, I started looking into more advanced LFI techniques and came across this:

At this point I was willing to try anything, so I pointed my cannons at config.php………and it worked!


Success!  I opened up the page source and copied the base64 string out of it.  I did the same for index.php, login.php, and upload.php.  I then decoded them all into their respective files on my machine:

In the decoded config.php file we’ve got some MySQL creds!

Awesome!  Let’s try logging into that MySQL server!

We’re in! I see that there’s a Users db, and within it is a table called users.  Looks like we’ve got usernames and passwords (base64 encoded) in this table:

After decoding those passwords, we’re left with the following credentials:

Cool, and it looks like we’re able to log in with each of these users on the site.  Now that we have access to the upload page, let’s take a look at the decoded upload.php from earlier:

The 2 pieces that stood out the most to me are:

  • It requires the uploaded file have a file extension in the whitelist (jpg, jpeg, gif, png).
  • It’s checking that MIME type matches the file uploaded.

After looking at the headers for each file type, I settled on GIF since its header is literally a string at the beginning of the file that says “GIF”.  I grabbed a reverse php shell script from here, inserted the GIF header into it, and renamed the file to php-reverse-shell.gif.  Now let’s see if I can upload this file:


It uploaded!  Checking the /upload directory confirms this.  The next task is getting this shell to actually run.  I ended up getting stuck here for a couple hours just searching for ways to execute, and I eventually went and reviewed the other php files that were decoded earlier.

I found an interesting snippet at the top of the index.html:

Looks like it sets and checks for a ‘lang=’ cookie.  Maybe we can perform some LFI here via the cookie?  Trying the basic LFI test (../../../../../../../etc/passwd)  returned:


Friggin’ sweet!  We can work with this!  I set up a netcat listener and after a few attempts, I set the lang cookie to “../upload/3208fd203ca8fdfa13bc98a4832c1396.gif” (to match what my “gif” uploaded as), and got a shell!


Ok, we’ve got our first shell on this box and we’re running as www-data.  I checked out what ports were open on the machine, and found that port 25 was open on, but it ended up being a dead end.  After looking around for a while, I found a new user “john” and added him to my list.  The next step was to see if I could switch to any other user accounts:


So we’ve got access to kent and kane’s accounts.  Doing a cursory search around kane’s home dir resulted in an executable binary called “msgmike” that had an SUID bit set.  Running the binary resulted in an error:

Hmmm, Ok.  It looks like all this binary does is cat the contents of a file in mike’s directory, so I can assume that this file is set to run as at least mike since I can’t access his directory as kane.  The best way to go about this is with a pretty basic privilege escalation attack.  Since the executed program only knows what’s inside kane’s PATH as a reference to run other binaries (/bin/cat for instance), if we change our path to “.” (meaning that it’s only looking in the current directory), we can create a script called “cat” to launch a new shell:


And we’ve got access to mike’s account now! After checking out mike’s home directory, there’s a new binary called msg2root.  This new binary also has the SUID bit set, and if we’re following the same theme, it’s probably root.  Let’s see what this msg2root does:

It’s spitting back out what we type.  Probably some form of printf()?  Let’s see if it’s sanitizing input:


Nope!  Let’s make quick work of this.  We set our path back to what it was, and get a reverse-shell going for root:



And there we have it!  Root access to the machine and a congrats from the VM creator, Chronicoder.

Until next time skiddies!