Once upon a time, a CTF was held. There were many ways to solve it, though none knew that one was The Unintended Way. Although, it does sound pretty unconventional and sad that in a CTF where you explore all the paths and explore wild possibilities, one of them was tagged as unintended and thus, invalid.

Without further ado, let’s discover what it was.

The CTF⌗

The CTF was hosted on vulnhub, you were provided with an ova virtualbox image. Boot it, login to a basic user whose credentials were provided. Now, you gotta look through the system to find the flags. They looked something like flagN{...} where N would be the challenge number.

The Forbidden Way⌗

After solving a couple of challenges the intended way, one would notice that you gotta login to a different user account to find out the flag. Let’s verify this assumption by looking at all the users in /etc/passwd

$ tail /etc/passwd
etc_passwd

The names look quite familiar, let’s have a look at the challenge names: challange_names

Interesting. All the names match. So, all we gotta do is access the $HOME of every user. Unsurprisingly, by default, in this VM, there’s no such direct way. What could we do ? Here are a few possibilities:

  • Find a kernel exploit and get root access
  • Find some suid binary and exploit it to get root access
  • Just mount that damn virtual HDD in another OS

We shall look at the last way. Close the current VM, then head over to VM settings and add a bootable Virtual Machine HDD. Here, I’ll be using the one offered by Parrot Sec Here’s how it’ll look. parrot_hdd_insert

Boot the VM again, this time keep hitting F12, you’ll get the boot options: Boot Options

Yes, we’re gonna boot the second Hard Disk. Choose 2 and the Parrot OS boots like a hot cheese slice. Let’s open up a terminal inside our Parrot and look at the connected drives.

$ lsblk
lsblk

Voila! The ubuntu--vg-ubuntu--lv is the volume we want. vg and lv keywords make it quite apparent that it’s an LVM. Let’s mount it.

$ sudo mount /dev/mapper/ubuntu--vg-ubuntu--lv /mnt
mount block device

Mounted successfully. Head over to /mnt/home and let’s simply grep all the files containing the flag format.

$ grep -P 'flag\d{.*}' -r
all flags

There you go! Easy as a cake. The root flag is located at /mnt/root, and you have everything you need.

How could they avoided it ?⌗

In my opinion, there was no need of labeling an unintended way. A simple solution to this would have been to use encrypted LUKS volumes and mounting them on login. Here’s how.

To every problem that relies on trust, encryption is the answer.

References: