Today, in this article we are going to gain the root access of an easy level machine called “Photographer 1” which is available at Vulnhub for penetration testing and you can download it from here. The credit for making this lab goes to v1n1v131r4. So, let’s get started and learn how to successfully root this machine.

Table of Content

Reconnaissance

• Netdiscover to find the machines on our Network
• Nmap to detect open ports

Enumeration

• Enumerating sambashare
• Discovering Koken CMS

Exploitation

• Authenticating and exploiting Koken CMS using a public exploit

Privilege Escalation

• SUID binary set for php7.2

Reconnaissance

 Let’s set up our lab using a NAT network. We will first detect the IP address of the vulnerable machine using netdiscover. The command to be used is:

 

So, the IP address found is 10.0.2.20.

Now, that we have our target machine’s IP let’s go ahead and scan it using nmap. We’ll do this by using the command:

 From the below screenshot, we can see that there are 4 ports open on our target machine which can be further used for the enumeration process.

The discovered ports are 80,139,445 and 8000.

Enumeration

 With ports 139 and 445 open, which are the SMB ports let’s try for the low hanging fruit that is samba share. Usually, in a boot2root, we could attempt a null session and see if we get any information. We’ll use smbclient to find the shares which we can access without creds. The below commands are to be used to find the shares:

Ok!!! So, it seems that we can access sambashare. Let’s go ahead and access that.

We find two files in sambashare by the names mailsent.txt and wordpress.bkp.zip which we’ll download into our machine for further inspection using the get command.

The mailsent.txt file seems to be interesting. Let’s read that and see if there’s anything useful in it for us.

Well, we do have some important information with us. We get two usernames Daisa and Agi.

We can see that Agi is talking about some secret. At this stage, we felt it might be some sort of credentials related clue so, let’s save this information for future use.

Now, that we have the usernames with us let’s go ahead and enumerate port 80. Unfortunately, we couldn’t find anything resourceful there so, we decided to enumerate port 8000 and we were greeted with this:

The server seems to be running Koken CMS. Let’s Google it to search for a public exploit. It seems that we have found one.

https://www.exploit-db.com/exploits/48706

Exploitation

Reading through the exploit, it seems to be an authenticated file upload exploit, which means we need some credentials. Browsing to the admin page of the CMS, we see we need to enter some credentials

After some trial and error, we were still unable to sign-in. Seems to be a roadblock. But wait, we have yet not tried the credentials we got earlier.

If you remember, we had got two usernames earlier Daisa and Agi from the mailsent.txt file. Let’s go ahead and try those usernames.

Great!!! We have successfully logged in using the below credentials:

Now, we are logged in the CMS.

We will now upload our php shell which is already available in Kali. To upload our shell, we’ll follow the steps mentioned in the exploitdb link. We click on “import content” first

Now, we get a prompt to upload our shell as we can see below.

Before uploading our php reverse shell, we need to add a .jpg extension to it in order to bypass extension filtering according to the exploit. Once, we rename it accordingly, we will use burp suite to intercept the imported data and remove the jpg extension and forward the request.

We need to press the forward tab two-three times after making the changes. We immediately get a reverse shell on our netcat listener.

Now, that we have gained the reverse shell we shall first spawn the shell by using the command:

 After spawning our shell we’ll change our directory from home to daisa. Once, we are in dais’s directory we’ll go ahead and open the user.txt file. On opening the file, we found our user flag which is shown in the image below.

Privilege Escalation

 Now, it’s time for that part of the CTF where everyone waits to gain the root access. But, hold on. Let’s go slow and steady. We will first check for any suid binaries using the command:

It seems that php7.2 was set to suid and we can easily escalate our privileges by using php7.2 like this:

We referred to GTFO bins for it. Great!!! Now, that we have root access, are we all ready to get the root flag?

I’m sure everybody is, so let’s go and capture that final flag. Once you are in the root shell simply change your directory to root by using the command:

Now, that we are in the root directory we’ll read the proof.txt file by using the command cat proof.txt Alright, there you go. We now have access to our final flag as shown in the image below.

Author: Arnav Tripathy is cybersecurity enthusiast and blogger. Contact  here 

So Simple is a beginner level vulnerable box created by @roelvb79, with some rabbit holes and good methodologies to easily understand how a pentester has to run public exploits work in OSCP-like VMs.

Table of Content

1. Reconnaissance
   1. Arp-scan to detect system IP
   2. Nmap to detect open ports
   3. Wpscan to enumerate wordpress installation
   4. Bruteforcing a username to gain password
   5. Finding an outdated plugin social warfare
2. Exploitation
   1. Exploiting RCE using social warfare plugin
3. Privilege Escalation
   1. Gaining max’s account using ssh key
   2. Escalating to steven using sudoers file
   3. Escalating to root using sudoers file
4. Snagging the flag

Let’s start

Reconnaissance

To start off, I ran an arp-scan and nmap on the target IP 192.168.56.105 to find out the open ports and services.

There was not much to be seen on the website so I ran a directory enumeration using gobuster to find a wordpress installation on the target

Next obvious step was to enumerate wordpress using wpscan and find any usernames or vulnerable plugins installed.

I found a wp-admin panel and a user “max” and no vulnerable plugin was found during this step.

After exploring alternate options and all the directories there was no lead to find the password for max. Hence, the next most obvious step was to bruteforce max using a given password list.

I used rockyou.txt and wpscan itself to bruteforce the login for user “max”

There we go! I found a suitable credential for wp-admin login: max/opensesame

But, wait a minute, there was also a vulnerable plugin displayed in this step which is weird since it wasn’t visible in the previous enumeration phase. Anyway, I logged in using max:opensesame credentials.

I tried to upload a shell or include a vulnerable code that could somehow help me to gain a reverse shell out of the server but it was in vain. There is no option to install a plugin or code. This hinted me to pivot back to the last step where I found a vulnerable plugin “social warfare.” After a bit of research, I found that the installed version 3.5.0 is vulnerable to an RCE exploit! You can read more about this exploit here.

Exploitation

So, as per the PoC steps, I had to launch our own server with a text file that had a payload and the server would execute it. This is a classic example of RCE. I launched my own python server and created a payload.txt file with the following code in it to check if it is exploitable or not.

Now to run this payload I had to navigate to the following address:

So it was found to be exploitable. Next step is obviously to launch a code that would give us a reverse shell back. Hence I changed the payload.txt with the reverse shell payload of netcat by pentest monkey but it didn’t work for me. Next, I included the reverse bash payload by a pentest monkey which is:

To execute it in a PHP format I had to change the payload to:

On visiting the same URL in the browser and setting up a netcat listener on port 8080 I got a reverse shell!

Privilege Escalation

At this point, the author of the VM had created another rabbit hole which just consumed more time and trolled me.

Eventually, I got back to the basics and tried accessing max’s account to look for insecure permissions given to important files as I should have which lead me to the private ssh key of max having read permission.

I copied this private key in my local system and connected to max’s SSH using this key.

Now we had max’s terminal! I looked for files with SUID permissions, docker images other directories that may escalate the privileges but I found nothing. I looked for any entry in the sudoers file and I found a binary that could run as another user steven.

This binary seemed to run any installed service on the system. Hence, I supplied an argument that could give me steven’s shell.

On accessing sudoers entry for steven I found another script that could run as root without password. But the catch is that that script didn’t exist physically. So I created a directory /opt/tools and a script server-health.sh with the following code:

Snagging the flag

I changed the permissions of this file and then ran the script as root. We got a root shell! I read the congratulatory flag finally!

Author: Harshit Rajpal is an InfoSec researcher and left and right brain thinker. Contact here

Broken 2020 is a beginner level virtual machine created by EuSecinfo. There was no running of public exploits, no rabbit holes in the machine, however, there was a need for custom exploitation and a little bit of common sense.

Table of Content

1. Reconnaissance
   1. Nmap and directory enumeration
   2. Locating a malicious script to gain shell access
2. Exploitation
   1. Writing our own script to gain a reverse shell
3. Post Exploitation
   1. Gaining Alice’s shell by modifying a python script
   2. Understanding the algorithm of the script’s working
4. Snagging the flag
   1. Manipulating a script to read root flag

Let’s start

We detected the IP address of the vulnerable machine and ran nmap scan on it to begin with.

We could only find port 80 open.

We immediately scrolled to the website but didn’t find anything useful over there.

Next obvious step was to run directory enumeration. We used dirb for the purpose and found a directory “/cms”

It looked like an installation page of a CMS. We clicked install.

Upon clicking install, something vague happened and seemed like it was a trap.

Here we could see flag 1 and it is self-explanatory, our website got defaced by that installation of CMS.

However, since the website got defaced, some change in directories, new files, or some payload must have been executed or created. So we ran directory enumeration once more in the “/cms” directory.

A new directory called “/cc/” seemed to have been created by this installation. We head over there to see what had been created. As the page explains itself, it is a malicious script that is used to connect the server to a remote IP with a remote port! That means a ready-made shell. But let’s see what it actually does first by inputting a random IP and port.

Hence, it is searching for some script in the designated IP. Lets actually create a simple python server and see what script it is searching for.

So, it was asking for a shell script with a random system-generated name. So, we created a script with the specified name with a python reverse shellcode in it (Pentest Monkey python reverse shell). Make sure you also launch a netcat reverse listener on port 8888 in a new terminal window.

Upon inputting this python server’s IP and port we see a new status code in the website.

Meanwhile, on our other terminal, we saw a shell was obtained. We traversed to /home/alice directory and read our next flag. There was also a note left there that said that a script log.py was created to clear apache logs.

Upon inspecting log.py we saw that it was clearing out apache logs and creating a log file “clear.log” that was updated every time the machine cleared it.

Here is the catch: upon inspecting clear.log we found that the logs were being cleared after every 1 minute sharp. This could be due to a cron job. Since the script log.py is being run as alice we could gain Alice’s account access if we somehow manage to insert our reverse shellcode in log.py.

Now, log.py is not editable by www-data (the current user) but the directory is writable! So we replaced the log.py file with our own log.py file as below.

1: Create a log.py file in our own system with the code as used before:

2: Launch a python server

3. Rename the existing log.py in the VM’s session to log_new.py

4. Copy log.py using wget command and give execute permissions.

In a new terminal, start a netcat listener on the port specified in the payload. Here, 5555, and wait for a reverse shell.

Surely, we received Alice’s shell. Now we traversed through directories and found a /back directory with the backup folder. There we snagged our third flag!

Now, we saw a note.txt too which had a message saying “Please put the path of the website backup directory in path.txt and bot will do the rest.” That means those three scripts (backup.py, check.py and hack.sh) were doing something using the contents in path.txt.

Upon analyzing the three scripts we understood that the bot (scripts) are picking up the contents in the directory specified in “path.txt” and copying it in the current directory! That solved our purpose since we can just dump the contents of /root directory using this.

Hence, we input /root in path.txt with the command:

Echo “/root” > path.txt

After waiting for about a minute again, we easily saw the contents of the root directory and read the congratulatory flag!

Author: Harshit Rajpal is an InfoSec researcher and left and right brain thinker. Contact here

Today we are going to solve another boot2root challenge called “Sunset: Midnight”.  It’s available at VulnHub for penetration testing and you can download it from here. The credit for making this lab goes to whitecr0wz. Let’s get started and learn how to successfully break it down.

Level: Intermediate

Penetration Testing Methodology

Reconnaissance

• Netdiscover
• Nmap

Enumeration

• Hydra bruteforce MySQL service

Exploiting

• WordPress administrator’s password change
• Modification of code to build a webshell

Privilege Escalation

• Misuse of recycled passwords
• Binary abuse without fixed load path
• Capture the flag

Walkthrough

Reconnaissance

We are looking for the machine with netdiscover

So, let’s start by running map to all ports with OS detection, software versions, scripts and traceroute.

We add the IP address and the “sunset-midnight” host to our “/etc/hosts” as indicated by the creator of the machine in the description.

Enumeration

We access the web service and find a site developed with the CMS WordPress.

We also check that the authentication panel is still on the same path.

Exploiting

We attacked the MySQL service with hydra and the rockyou dictionary. We will get the credentials to access the database.

We created a hash in md5 of the password “123456” (we will use it below).

We connect to the database with the obtained credentials, select the database and consult the table of registered users. We don’t know the password, but it’s not a problem, we’ll change it directly indicating our md5 hash (remember that it corresponds to the password 123456).

Now we have access to the WordPress administration panel. Now we’ll change the “header.php” file (or another file you can call) and insert the web shell’s PHP code (I used PentestMonkey).

Now we will put a netcat to listen to port 4444 and we will execute any section of the web. If all goes well, we’ll get a shell on our Kali.

We run these two sequences to get an interactive shell. Later, we will read the file “wp-config.php” and it shows us a password in md5.

Privilege Escalation (user “jose”)

 

We use the password to authenticate ourselves as the user “jose”.

Privilege Escalation (root)

We check which files we have access to and the binary “/usr/bin/status” catches our attention.

We use strings on it, we see that internally it calls the binary “service” but without indicating the path of origin, this would allow us to create a malicious “service” file and thus be able to change our PATH to execute it.

So let’s put it into practice, we create a file in the “tmp” folder with the name “service”, we introduce the sequence “/bin/sh”, we execute the binary of “/usr/bin/status” and we get a shell as root.

Author: David Utón is Penetration Tester and security auditor for Web applications, perimeter networks, internal and industrial corporate infrastructures, and wireless networks. Contacted on LinkedIn and Twitter.