11 April 2021

Pentesting Fun Stuff

following the cyber security path…



At the moment of writing, this is the latest challenge created by the SunCSR Team and hosted on VulnHub.
This challenge is rated ‘Intermediate to Hard’ and has rabbit holes to watch out for.
The goal is to get root shell and obtain the flag under /root.
It is part of a series of challenges ranking from beginner and upwards.
The challenges itself are a mix of CTF-like combined with realistic admin mistakes.
Hopefully this team will create a lot more challenges, but for now let’s enjoy the last one.


As always we start with a port-scan to get a good view on what ports are open and what services are running behind them.

From the scan it looks like there is an FTP-server (port 21), an SSH-server (port 22), several web-servers (ports 80, 7080, 7601 and 8088) and an SMB-server (ports 139 and 445).
The FTP and SSH servers need credentials, so I’ll start with enumerating the web-servers.


For a basic web-server scan, Nikto is a very useful tool.

Starting with port 80:

There is an info.php file and basic authentication in place.
Unlike its predecessors (other challenges from this creator), this one doesn’t have admin:admin credentials.

Next up is port 7080:

port 7601:

This one has some interesting findings.

Hostname = seppuku
The image is that of Jack the Ripper (not very subtle or another rabbit hole?)
A password list and a passwd and shadow file.
The warning  about the rabbit hole and this seems just way too easy, but hey, let’s give it a try.

There are some things that are bothering me.
1. the name of the user is rabbit-hole (I was warned to look out for it)
2. the usernames in passwd and shadow are slightly different (for John to work, I needed to alter it)
3. the found password doesn’t work on anything (this one kills me hahaha)

So, not wasting my time much longer, I discard this option and check what else I have found.

In this folder are two other items that are interesting.
The hostname, being seppuku, and a password list.
Because this means brute-forcing, which I really dislike, I’ll finish the enumeration on the other web-servers first.

Another finding is CKEditor. In the javascript file I can find the version number:

Checking exploit-db it looks like this version has no known vulnerability. Skipping it for now.


And finally port 8088:

By default the browser lands on index.html with this web-server, but if you go manually to index.php, you get something more interesting:

According to the website, Web Console is a web-based application that allows to execute shell commands on a server directly from a browser (web-based SSH).

From the looks of it, there is no clipping level keeping me from a brute-force session (maybe later).

Phase 2

Let’s start with brute-forcing the SSH-server first (if this works, I can skip al other nonsense).

So……..this is a welcome surprise.

Wait, what?

Crap……I’m inside a restricted shell.

When inside a restricted shell, it is wise to do some enumeration first.
Like, what available commands are there?
Which operators work?
What programming languages are available (python, perl, ruby, etc.)?
What commands can you run (sudo)?

Here I used the program chsh to change my shell (easy right?).
In a better restricted environment this probably wouldn’t be an option, but it’s always good to check.

I can make symbolic links from /root to /tmp/.
What else?

And I have a passwd file with just one password.


Just repeat the previous option.
Also……If your shell gives you problems with restrictions (while you have a bash shell), just exit and log back in with SSH.
You will have a good working bash shell.

No .cgi_bin. Another rabbit hole?
Unlike my current user and the previous one, user Tanto has a .ssh folder.

In the beginning of the enumeration, I found a ssh key.
Let’s try and use it on user tanto.

To transfer a file I need a transportation tool…….looks like we have wget at our disposal.
First I start up a python web-server at the location where the SSH key is.

Then I retrieve the key and rename it and changing its permissions (else SSH will begin to scream bloody murder).

And finally log in as user tanto using the key.

<very big sigh>

The previous method won’t work, because I don’t have a password for this user.
Luckily there are numerous other ways to get out of a restricted shell.

Now that I am free to do as I please, it’s time to take a look at the sudo command from user samurai.

Basically it says it will run a file called bin from the folder /home/tanto/.cgi_bin as root.

Let’s create a folder and file so the sudo permission of samurai can exploit it.

Now from another shell with user samurai open:

And there you have it.


This was by far the best challenge out of the series.
It had multiple misleading options and a lot to go through.
As with a lot of pentesting notes are so very important, so you can keep track on what you’re doing.

I really like the fact I needed to link stuff I found in the beginning use at the end the get further.

Really nice work with this challenge.

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.