Introduction

Today we are going to crack this vulnerable machine called Maskcrafter: 1.1. It is created by evdaez. It is a simple Boot to root kind of challenge. We need to get root privilege on the machine and read the root flag to complete the challenge. Overall, it was an intermediate machine to crack.

Download Lab from here.

Penetration Testing Methodology

• Network Scanning
  • Netdiscover
  • Nmap
• Enumeration
  • FTP Anonymous Login
  • Enumerating FTP for hints
  • Enumerating /debug directory
• Exploitation
  • Crafting Payload using msfvenom
  • Exploiting the Command Injection
• Post Exploitation
  • Enumerating MySQL database
  • Extracting cred.zip
  • Logging into SSH
  • Enumerating Sudo Permissions
  • Exploiting Sudo Permissions on custom script
  • Enumerating Sudo Permissions
  • Exploiting Sudo Permissions on socat
• Privilege Escalation
  • Enumerating Sudo Permissions
  • Crafting deb Installation Package using fpm
  • Installing the malicious package using dpkg
• Reading Root Flag

Walkthrough

Network Scanning

To attack any machine, we need to find the IP Address of the machine. This can be done using the netdiscover command. To find the IP Address, we need to co-relate the MAC Address of the machine that can be obtained from the Virtual Machine Configuration Setting.  The IP Address of the machine was found to be 192.168.1.110

Following the netdiscover scan, we need a Nmap scan to get the information about the service running on the virtual machine. An aggressive Nmap scan reveals that 5 services: FTP (21), SSH (22), HTTP (80), RPC (111), NFS (2049).

Enumeration

Let’s start the enumeration stage with the FTP Service. It was clear from the Nmap Scan that FTP allows Anonymous Login. We got inside using it. We listed contents and found the pub directory. Inside the pub directories, we find 3 files. A NOTES.txt file, A zip file by the name of cred.zip, and a php file by the name of rce. Pretty convenient. Let’s download all the files to our local system to take a closer look.

First, let’s check the NOTES.txt file. It said that there is a web directory by the name of /debug. It might contain a strong password. That makes bruteforce out of question. Also, the username is the admin that is confirmed in the note.

We went to take a look at the debug directory. We were greeted with a login panel. We knew the username was admin. We tried the admin as a password as well. We were in. That didn’t seem so hard. It contained the 3 commands that can be selected and executed.

We used BurpSuite to capture the request to analyze how the commands are sent to the command to get executed. We saw that it is a simple parameter with a clear text command.

Exploitation

This meant that we can craft a payload using msfvenom in the Raw format and use it to exploit it to get a session.

We copied the raw payload code and replaced the ifconfig command in the captured request in the Burp Suite as shown in the image below:

Before forwarding the request to the application, we start a netcat listener on the specified port from msfvenom i.e., 1234. After that, we forward the request and we see that we have a session on the target machine. We use the python one-liner to convert the shell into a TTY shell. The shell we have is of www-data user.

Post-Exploitation

We start the enumeration with the /var/www/ directory. We have the debug directory that was mentioned earlier. We see that it contains a php file by the name of db.php. We open it to find the set of credentials for the Database.

We then connect to the database using this set of credentials. After connecting, we list the databases. Among those mydatabase seemed interesting. We enumerated it further to find 2 tables by the name of creds and log in. We first listed all the contents of the creds table to find the zip password cred12345!!

We went back to our local machine and used the credential that we just found to unzip the cred.zip file we got earlier. It contained a cred.txt. It read another set of credentials as shown in the image below.

We use this set of credentials to log in as SSH.

After logging in on the target machine via SSH, we used the Sudo -l command to list all the binaries that have the permission to run with elevated privileges. We found a script by the name whatsmyid.sh. It can be executed by the user evdaeez. We open the file in the nano editor.

We edit it to spawn a bash shell. It is as simple as writing /bin/bash in the script.

We tried to execute the script using the sudo command with u parameter. We see that we have the shell as evdaez. We again run the sudo -l command to check for any more binaries that could lead us to root. We see that socat has permission as user resercherx. Let’s get to resercherx user by exploiting this permission on socat. To do this we have a one-liner that executes socat. It requires a remote host and port. We first define these variables in the session. We define the RHOST variable with the local IP Address of our Kali Linux or attacker machine. Next, we define the RPORT variable with a random port number such as 12345. Then we will execute the socat as the user resercherx and variables that we just declared.

Before executing a one-liner, we start a socat listener to capture the session that might be generated from the target machine. As soon as the one line gets executed, we get a session on our local machine. Then we convert this shell into a TTY shell using the python script. Again, we ran the sudo -l command to check for binaries and their permissions. This time we have the sudo permissions on dpkg. We need to exploit this vulnerability to get root access to the machine.

Privilege Escalation

The dpkg is used to install and manage packages. So, to get a root level shell from dpkg we need to provide it with a package to install. It will be of the malicious kind which can give us a shell. We get to our local machine to do this task. We searched dpkg on GTFOBINS and found a neat way to elevate privileges by dpkg. We need to craft a package using fpm and then that when installed with the help of dpkg it will grant us a root shell. First, we define a variable TF with the mktemp command which will create a temporary directory upon execution. Then we entered the shell invocation command into a shell file in the TF. Finally using the fpm, we crafted the contents of TF into a package. The resultant package was named x_1.0_all.deb. We ran the python script to create an HTTP server and transfer this deb file to the target machine.

Since we don’t have write permissions anywhere in the application, we went into the temp directory and downloaded the deb file using the wget command. Now, all there left is use dpkg with sudo to install the malicious deb file and we have the root shell. We confirm this using the id command. Then we can see that we have the root flag to conclude the machine.

Author: Pavandeep Singh is a Technical Writer, Researcher, and Penetration Tester. Can be Contacted on Twitter and LinkedIn

Today we are going to solve another boot2root challenge called “Tempus: 3“.  It’s available at VulnHub for penetration testing and you can download it from here.

The merit of making this lab is due to @4nqr34z & @theart42. Let’s start and learn how to break it down successfully.

Level: Hard

Penetration Testing Methodology

Reconnaissance

• Netdiscover
• Nmap

Enumeration

• Ghidra

Exploiting

• SSTI (Server Site Template Injection)
• Dump credentials database SQLite
• Malicious Module Processwire (Reverse Shell)

Privilege Escalation

• Backups and abuse OPT Auth Google
• Abuse script created users with arbitrary UID
• Reversing binary and ping binary abuse
• Capture the flag

Walkthrough

Reconnaissance

We are looking for the machine with netdiscover

So, we put the IP address in our “/etc/hosts” file and start by running the map of all the ports with operating system detection, software versions, scripts and traceroute.

Enumeration

We access the web service and start listing versions, code, users…

In the following image, we see 3 users, and the image tells us that we are going to have fun with this machine xD.

We listed an authentication panel, we tried brute force, but it is not possible to access it.

Forcing the application to show some error, we see that it writes what we pass it through the URL.

This reminded me that I might be vulnerable to SSTI (Server Side Template Injection), so let’s do a proof of concept:

Exploiting

Before we will check what type of template you use, if it is “jinja2” it will show the number of times the number we multiply it, otherwise, it will multiply it giving “81“, in this case, it will be “twig“.

As you can see, we are in front of a “jinja2“.

Indeed, it is vulnerable. We are going to try to execute a command to check if it prints it on the screen.

Now we will put a netcat to listen and we will execute the following command to obtain a reverse shell.

We read the file “app.py“, this file contains the “secret_key” (flag nº1) and “pragma key“.

We decode the base64 and find the first flag.

Listing the binaries we have access to, we find “sqlcipher“, if we look for information about “pragma key“, we will find that to dummy the information, we will need the help of this tool.

These will give us the three registered users on the website and another flag.

We decode and get another flag.

We access the 3 users with their respective passwords, we will obtain the same information.

In that string in base64 we will find the flag nº 2.

We decode again.

If we look, both profiles show us the number “37303“. We do an internal port scan with a python script (In google there are many).

We list three open ports, including “37303“.

We do a port forwarding and see that this port corresponds to an OpenSSH.

We repeat the port forwarding, this time with port 443.

We will have access to a new website, we see that it gives us the clue that “Hugh Janus” is the administrator.

We see that the user “Anita” has come up with the great idea, that users can upload files.

We also list access to the administrator panel.

We tried to access with the user “Hugh-janus” but it gives us an error, now we try with the user “admin” and the password of “Hugh“, we will enter without problem to the panel.

We found an upload to upload modules, we downloaded a proof of concept module from the official website.

We unzip, edit the file “Helloworld.module.php” and add to the “else” a reverse shell.

We upload the file and load it.

We put a netcat to listen and edit any page of the CMS. We check our terminal and we will have access to the machine.

Privilege Escalation (user Myrtia)

After an exhaustive enumeration, we find an image in the “backups” folder, the name mentions one of the users of the system.

This is a QR code, we read it and it will give us a temporary code to access a service.

This reminded me of a machine I did recently, so I set up this “OUPAUTH” (possibly Google Authentication) to my cell phone and we connected via SSH.

And also, we check that we can execute the “addcustomer” script with the root user.

We run the script, fill in the data and then check if it is possible to create users.

The following image shows that it is.

At the moment, we don’t find it very useful, besides the script is executed from the root directory and we don’t have access to it.

We continue listing the user’s home files that we have gained access to and read the 4th flag.

 

Privilege Escalation (user Cecil)

We keep listing files and directories, we find a file called “…”, quite suspicious and with a different UID. We do not have access to this file…. But… What if we create a new user and assign this UID?

Let’s give it a try! We create a new user, we assign it suid “1337“, we check that the user has been successfully created by reading the “/etc/passwd“.

We authenticate with the new user, execute our two favourite commands to get an interactive shell and read the file “…”.

We get a private key from OpenSSH.

We are not clear to which user it belongs, so we will try one by one until we manage to connect with the user “cecil“.

Privilege Escalation (root)

According to a clue given by one of its creators, the “ping” binary had to be revised. We opened ghidra and found that the binary opens a shell if the UID and the string “deadbeef” match when executing the “ping” command.

We already have the user equivalent to the UID, we just need to execute the command specifying “deadbeef“.

We execute a ping, the binary will do its checks and will give us a shell as root.

And finally, we will read the last flag.

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.

Today we are going to solve another boot2root challenge called “Insanity: 1“.  It’s available at VulnHub for penetration testing and you can download it from here.

The merit of making this lab is due to Thomas Williams. Let’s start and learn how to break it down successfully.

Level: Hard

Penetration Testing Methodology

Reconnaissance

• Netdiscover
• Nmap

Enumeration

• Dirsearch
• Wireshark

Exploiting

• SQL Injection through e-mails
• Password theft in database
• Weak hash cracking

Privilege Escalation

• Cracking to passwords stored in Firefox
• Capture the flag

Walkthrough

Reconnaissance

We are looking for the machine with netdiscover

So, we put the IP address in our “/etc/hosts” file and start by running the map of all the ports with operating system detection, software versions, scripts and traceroute.

Enumeration

The recognition and enumeration of vulnerable services have been the hardest part of this machine. Since it had many services to which they managed to entangle you, turning out to be all of them (except one) rabbit holes.

Some evidence of these services (rabbit hole):

FTP:

Bludit (From here we will list the user “Otis”.):

phpMyAdmin:

Having seen the above, we will go directly to the correct and vulnerable services. We start with the organization’s web service, a hosting service.

We puzzled with dirsearch and found several directories, but we will focus only on two “/monitoring/” and “/webmail/“.

Well, we used the user “otis” and the password “123456” (I took it out with guessing).

We will enter a panel are monitoring the internal server, we see that we can add new servers.

We insert our IP (it can be another one that is operative) and we see that it marks us “Status: UP“. What does this tell us? Well, the application below is running a ping to our machine to check if it is on.

We use dirsearch again, this time we will fuze the content of “/monitoring/”.

We go through the directories obtained until we reach the directory “/monitoring/class/“.

We access the directory and we find what we already imagined, a “ping.php” file.

We open Wireshark and see that the machine does indeed execute a ping. Do you think the same as me? Of course, we do! A command injection!

Let’s do as usual, a proof of concept.

We wait for it to run, but we see that it does not work (Status: DOWN). We contrast this information with Wireshark and see that it does not move either, so we are in another “rabbit hole“.

Well, nothing, we continue with the other service. Now we have a “SquirrelMail” in version 1.4.22, if you look for exploit you will find that it is vulnerable to remote code execution (RCE), but I already advance you that it will not work either xD.

We use the same credentials, access the “Inbox” and see that emails with errors are arriving. Attention! These emails only appear if the server is “DOWN”.

We read one of them, if we look at it, it is structured in 4 columns… This is something that called my attention a lot, since it seems to be loading this information through a database.

Seeing this, I lost my mind and came up with the crazy idea of launching a payload list of SQL Injection (/usr/share/wfuzz/wordlist/vulns/sql_inj.txt).

Configuration Attack:

Executed attack:

We are checking all the emails that we receive, we find this one that shows “Localhost“, therefore, the site is vulnerable to SQL Injection.

We do another test, this time we list the hostname and version of MariaDB.

Exploiting

We continue to exploit the vulnerability, although this would be faster by posting only 3 photos, I think it is worth seeing all these images, which will help us learn how to exploit SQL injection without any tools.

Obtain user and database:

Obtain all databases:

Obtain all tables:

Obtain all the columns in a table:

Dump users, passwords and emails:

After trying to crack the hashes of the two (hidden) users, it is not possible to obtain it even with JTR, Hascat or other online tools. Everything looks like another “rabbit hole“.

We continue to list and find these two hashes in the “mysql” database.

The 2nd hash does not correspond to that of a MySQL, we use the online tool “hashes.com” and obtain the password in plain text.

We logged in through SSH and great! We are in!

Privilege Escalation (root)

We do an “ls -lna” and see that we have a “Mozilla Firefox” folder, very very rare.

Whenever you see software folders, check it out, because it’s not normal.

We check if the browser has been storing user passwords. How to check this? As simple as listing these 4 files.

If these files exist, it means that they contain passwords and we can use a tool “Firefox_Decrypt” to obtain the passwords in plain.

We download the tool, choose the 2nd option and we will NOT give you a password when you ask for the “Master Password”.

We will get some credentials in the “root” user plane.

We try to authenticate with the user “root” and the password obtained and…. Yes! we are root!

We read the flag and have a good coffee.

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.