Pwnlab: Init

Since discovering Vulnhub.com, 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:

Shell

1

2

3

4

5

6

7

8

Nmap scan report for192.168.110.53

Host isup(0.00027slatency).

Notshown:997closed ports

PORT STATE SERVICE

80/tcp open http

111/tcp open rpcbind

3306/tcp open mysql

MAC Address:00:0C:29:38:35:83(VMware)

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:

Shell

1

2

3

4

5

6

7

8

9

Nmap scan report for192.168.110.53

Host isup(0.00011slatency).

Notshown:65531closed ports

PORT STATE SERVICE

80/tcp open http

111/tcp open rpcbind

3306/tcp open mysql

45944/tcp open unknown

MAC Address:00:0C:29:38:35:83(VMware)

Let’s confirm my suspicion:

Shell

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

Nmap scan report for192.168.110.53

Host isup(0.00017slatency).

PORT STATE SERVICE VERSION

80/tcp open http Apache httpd2.4.10((Debian))

|http-methods:

|_Supported Methods:GETHEADPOST OPTIONS

|_http-server-header:Apache/2.4.10(Debian)

|_http-title:PwnLab Intranet Image Hosting

111/tcp open rpcbind2-4(RPC#100000)

|rpcinfo:

|program version port/proto service

|1000002,3,4111/tcp rpcbind

|1000002,3,4111/udp rpcbind

|100024145944/tcp status

|_100024156251/udp status

3306/tcp open mysql MySQL5.5.47-0+deb8u1

|_mysql-info:ERROR:Script execution failed(use-dtodebug)

45944/tcp open status1(RPC#100024)

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:

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:

PHP

1

2

3

4

5

6

7

//Multilingual. Not implemented yet.

//setcookie("lang","en.lang.php");

if(isset($_COOKIE['lang']))

{

include("lang/".$_COOKIE['lang']);

}

// Not implemented yet.

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 127.0.0.1, 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:

Shell

1

2

3

kane@pwnlab:~$./msgmike

./msgmike

cat:/home/mike/msg.txt:No such fileordirectory

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:

Shell

1

2

3

4

5

mike@pwnlab:/home/mike$./msg2root

./msg2root

Message forroot:test

test

test

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.