VulnHub CyberSploit 1 Write-up

みなさん、こんにちは!

Can you break the glass?

I decided to take a break from Hack the box and make my trip to Off-Sec Proving Grounds. Now Off-Sec proving grounds is nothing special, it just has VulnHub machines hosted. One thing is that it is convenient that you don’t have to download and install VMs which in my case is a pain (I have low storage lel). Cyber Sploit was perhaps one of the most easiest boxes I have ever done. I rooted the box in a little under 15 minutes so it was a indeed a nice warm up.

Abstract

One thing which I did not like about the box is that it is too CTFy like. I actually hate boxes like these to be honest. What’s the point if you don’t learn anything? Well you do learn something here if you pay more attaention and play with it after completiting it though. It starts with website recon, I find a weird base64 encoded string in robots.txt directory. looking at the source of the home directory we also get a username. SSHing into the box using those credentials was successful. An Overlayfs exploit exists on the box due to the outdated kernel. We exploit that to get the root shell.

Enumeration

As always we start with the nmap scan:

Only two ports are open; Port 22 running SSH and port 80 running a webservice.

Visiting the webservice, we see:

Nothing to special comes up until we examine the source of the page.

A username is hidden from the view by HTML comments. Now I search for a password.

As a habit, before starting a directory bruteforcing tool, I tend to test some common words like robots.txt, dev and so on.

Here robots.txt worked and we see a weird base64 encrypted string.

Decrypting it, we get:

We get a string “cybersploit{youtube.com/c/cybersploit}”. At first glance it looks like a YouTube channel link but this can be a password.

Exploitation

Not really an exploitation but using the creds obtained earlier — itsskv::cybersploit{youtube.com/c/cybersploit} I ssh in successfully. Honestly did not expect it to be that easy.

Escalation

There are a couple of things to enumerate first before we go to some advanced or custom made technique. First thing I tried is, obviously to see what version of Linux Kernel its running by doing uname -a

It returned saying that it was running a 3.13.0–32-generic Kernel. Searching for a Kernel exploit landed me to some interesting places. This is where things get interesting.

Some Words about Overlayfs Kernel Exploit:

An Overlayfs is basically a file system.

Here is what kernel.org had to say:

An overlay filesystem combines two filesystems - an 'upper' filesystem
and a 'lower' filesystem.  When a name exists in both filesystems, the
object in the 'upper' filesystem is visible while the object in the
'lower' filesystem is either hidden or, in the case of directories,
merged with the 'upper' object.

It would be more correct to refer to an upper and lower 'directory
tree' rather than 'filesystem' as it is quite possible for both
directory trees to be in the same filesystem and there is no
requirement that the root of a filesystem be given for either upper or
lower.

The lower filesystem can be any filesystem supported by Linux and does
not need to be writable.  The lower filesystem can even be another
overlayfs.  The upper filesystem will normally be writable and if it
is it must support the creation of trusted.* extended attributes, and
must provide valid d_type in readdir responses, so NFS is not suitable.

A read-only overlay of two read-only filesystems may use any
filesystem type.

So now that we know what the thing is, lets deep dive into the exploit.

I found a Git Hub repo which contains tons of Kernel Exploits and tried to understand the actual exploit. The exploit uses another property of namespaces that has always seemed like something of a bug: the /proc filesystem provides a route for processes outside of a namespace to “see” inside it. In this case, the overlayfs mounted inside the namespace can be accessed from outside of it by using information on the mounts inside the namespace via /proc/PID/cwd.

Here is my breakdown of the code:

The exploit [C program] works like this:

• New mount and user namespaces are created for the process.
• That process then mounts an overlayfs atop /bin using temporary directories for the overlayfs “upperdir” and “workdir” directories. A writable overlayfs must have both of these directories; upperdir holds the files/directories that have been changed, while workdir is used as a work space to enable atomic overlayfs operations.
• The process inside the namespaces changes its working directory to the overlayfs, thus making it visible outside of the namespaces by way of /proc/PID/cwd.
• The process changes the su binary (in /bin) to be world-writable, but does not change the owner. That results in a new file being created in the upper overlay directory.
• A process outside of the namespaces writes anything it wants to that file without changing the setuid bit (more on that coming).
• The outer process then runs that su with root privileges.

Pretty Awesome right!!

Lets get back to the box and get root now.

Transfer the binary to the box using python module SimpleHTTPServer. Then just execute it: STARBURST STREAM !!!!!!

1337root

Conclusion

Although box was of CTF type, I learnt something new about an exciting Kernel Exploit which is cool. I would like to write my own kernel exploit one day! Anyways, good warm up box, best for beginners.