Publisher
Test your enumeration skills on this boot-to-root machine. -by josemlwdf
Recon
We start with a Nmap scan and find only two open ports. Port 22 with SSH and port 80 with an Apache web server.
Before we manually enumerate the pages on port 80, we start a directory scan using Gobuster. Here we discover the directory spip, which could be interesting later.
We do not discover anything on the index page for the time being.
But in the spip directory, we discover a blog that was created using SPIP. SPIP is a free, open-source content management system (CMS) designed for managing web-based publications and facilitating collaborative work.
Looking through the source, we find version 4.2.0 in use. We may have our entry point here.
Shell As www-data
After a little research on SPIP 4.2.0, we find an exploit that allows RCE without authentication.
Unfortunately, the manual exploit was unsuccessful. Before we start tinkering around, let's try the Metasploit framework. Here we also find an RCE for SPIP disclosed around the same time as the exploit on exploitdb - this might be the same.
After we have set the necessary parameters and run the exploit, with a little more patience, we get a meterpreter session.
In the session, we can spawn a shell, and we are the user www-data. This user is allowed to enter the home directory of the user think and read the files there, so we get the first flag.
Shell As think
In the home directory of the user think we find a private ssh key. We copy this and adjust the rights.
After we have set the permissions, we can use the key to log in to the machine via ssh as user think. At first glance, we now have a more stable shell. But something is strange; we can't write in the home directory, and otherwise, like /tmp is not writable. The /opt directory is not readable; we are probably a bit more limited than expected.
Shell As root
When enumerating, we find the said custom binary, which has a SUID bit set, so that when executed, it's in the context of the owner root.
We can already get a quick overview with strings or cat to the binary. This will only execute a script in /opt/run_container.sh. The special thing here is that bash -p is used for this, so the script is also executed in the context of root rights.
/opt should actually be readable; another mechanism must apply here.
In fact, we can read the script in /opt, but cannot find an entry point for command or parameter injection.
As mentioned in the short description, we will probably have to get around our current shell restriction. It would then be conceivable to rewrite run_container.sh.
Attempts to escalate privileges using a custom binary are hindered by restricted access to critical system files and directories, necessitating a deeper exploration into the system's security profile to ultimately exploit a loophole that enables the execution of an unconfined bash shell and achieve privilege escalation.
Possible restrictions can arise via AppArmor. We find some rules for the shell ash. Here we see the deny rules for /opt/, among others, which prohibit us from writing here.
Furthermore all programs run in /usr/bin and /usr/sbin are restriced by the rules /usr/bin/** mrix and /usr/sbin/** mrix inherit this rule. To bypass this restriction, we need to run a bash application outside of /usr/bin or /usr/sbin.
In /etc/passwd we see that our user is using the ash shell.
With the following search we find writeable paths, including /var/tmp.
We copy /bin/bash to /var/tmp and run it. We can now access /opt.
Fortunately, we are allowed to write on run_container.sh.
We write a small script that copies the /bin/bash into /var/tmp and sets the SUID bit this time. Because the script is executed in the root context as mentioned at the beginning, the owner also remains root and can thus we are able to obtain a root shell.
After running the bAsh binary inside /var/tmp with the tag -p we gain a root shell and find the final flag in /root/root.txt.
Last updated
