11 April 2021

Pentesting Fun Stuff

following the cyber security path…



This challenge can be found on VulnHub.com.
It is rated beginner and the goal is to get a root shell and then obtain the flag under /root.
Let’s get started!

I need to know what ports are open.
To do that, I start with a port-scan.

SSH (port 22) and a web-server (port 80).
The OpenSSH version looks a bit out-of-date and the Apache web-server is from around 2012.

Lets start with the web-server first.
The main page has no title and no real content.

To get more information about the web-server, I run Nikto:


It is a security bug in the Unix Bash shell that causes Bash to execute bash commands from environment variables unintentionally.
If this vulnerability is successfully exploited, an attacker can remotely issue commands on the target host, i.e., remote code execution (RCE).
Though Bash is not an Internet-facing service, many network and internet services (for example, web servers) use environment variables for communicating with the server’s OS.

If environment variables are not sanitized before execution, an attacker can send commands through HTTP requests and get them executed by the server’s OS.

To test the server for the vulnerability, I’m going to use the tool cURL and see if I can execute a command.

And I can. Let’s get a reverse shell.

Let’s get some system info:

An old Ubuntu version with an old kernel.
Let’s check searchsploit to see what kind of payloads it has for this type of kernel (this old should give a working kernel exploit).

There are more possibilities according to searchsploit, but these two are more specific for this kernel.

There is a side-note for using these kinds of exploits.
In this case I’m using an VM, where I’m in control of the system.
If the system crashes, there is no problem because I will reboot the system or even roll-back a snapshot if I kill the system.
In a real-life situation you will not have these kinds of control and if you use a kernel exploit, you can crash an entire system.
Most customers won’t appreciate this. So keep this in mind.

But in this case, let’s try the first one.

To get files from my machine to a remote system, I use a Python 3 module called http.server.
With it I can use wget remotely and retrieve the data.
After downloading the file, I compile it with GCC.

Bummer, an error.
In this case the error message is telling me, that the build-time dependency (in this case it is cc1) was not found.
To fix this you should install the appropriate package to the system. But in our case, this is not an option.

Maybe I can compile the program locally and execute it remotely?

Another error. Again bummer.
An assertion statement specifies a condition that you expect to be true at a point in your program.
If that condition is not true, the assertion fails, execution of your program is interrupted, and the Assertion Failed dialog box appears.

Let’s try something else. For the compilation it has requirements which it can not find.
If we adjust $PATH, so the system knows where to look for GCC it maybe solves out problem.
But with what do we adjust our path variable?

Let’s try /usr/lib/gcc/x86_64-linux-gnu/4.6

A check to see if it worked.

Yes it worked. Now why did I do it this way?
Because when looking for an executable, the system checks its PATH environment variable.
This is also handy when you need to fool the system to look at an executable you control if someone made use of a relative path.

Compile it again and run the exploit.

And then it hangs…
Checking the VM we can see why.

It crashed…
After trying the other option mentioned earlier (with no success), I switch to another kernel exploit: Dirty Cow

The steps are the same as before.
Transfer the exploit (got it from Searchsploit), compile it and run it.
Only difference is that this exploit asks for a password and then creates a user with root privs.

From here on out it’s only getting the root.txt flag


The description of this machine was beginner and maybe it wasn’t hard to figure out what the attack vectors were.
But the problem is with kernel exploits that the system can become very unstable.
With a VM you can try over and over again until you nailed it. But in real-life you maybe get one change.

I’m going to try a few more from this creator and hopefully there will be no more kernel exploits.



Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.