Publisher
Test your enumeration skills on this boot-to-root machine.
Last updated
Was this helpful?
Test your enumeration skills on this boot-to-root machine.
Last updated
Was this helpful?
Let's start with a nmap scan. We find two ports open. Port 22 with SSH and port 80 with an Apache web server.
We start a directory scan using feroxbuster. Here we discover the directory spip.
We do not discover anything on the index page.
In the spip directory, we find a blog created with SPIP, a free and open-source content management system (CMS). SPIP is designed for managing web-based publications and enabling collaborative work.
Examining the source code, we identify that version 4.2.0 is in use. This might be our entry point.
After some research on SPIP 4.2.0, we discover an exploit that allows for remote code execution (RCE) without authentication.
Let's try using the Metasploit framework. We find an RCE exploit for SPIP that was disclosed around the same time as the one on exploitdb. This could be the same exploit.
After we have set the necessary parameters and run the exploit, we get a meterpreter session.
In the session, we can spawn a shell, and we are the user www-data. This user has permission to access the home directory of the user think and read the files there, allowing us to obtain the first flag.
In the home directory of the user think, we find a private SSH key. We copy this key and adjust the permissions accordingly.
After setting the permissions, we use the key to log in to the machine via SSH as the user think. Initially, it seems we now have a more stable shell. However, we quickly notice some restrictions: we can't write in the home directory, other writable directories like /tmp are also inaccessible, and the /opt directory is not readable. It appears our access is more limited than we expected.
During enumeration, we discover a custom binary with the SUID bit set, meaning it executes in the context of the owner, which is root.
We can quickly inspect the binary using strings or cat, which reveals that it only executes a script located at /opt/run_container.sh. Notably, this script is run with bash -p, meaning it executes with root privileges.
The /opt directory should be readable, suggesting another mechanism might be restricting access.
We can read the script located in /opt but cannont not identify any vulnerabilities or entry points for injecting commands or parameters.
It seems like we'll need to bypass our current shell restrictions. One possible approach could involve modifying the contents of run_container.sh.
It appears that AppArmor is imposing restrictions, particularly on the shell ash and programs in /usr/bin and /usr/sbin. The rules deny access to /opt/ and apply a ruleset inherited by /usr/bin/** and /usr/sbin/** which restricts certain operations.
Interestingly, there is a flaw in the AppArmor profile: while /dev/shm/ and /dev/tmp/ have deny rules, they lack the /** wildcard, unlike /tmp/. This allows us to still write to /dev/shm and /var/tmp.
The user's shell, as listed in /etc/passwd, is set to ash.
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'll create a script that copies /bin/bash to /var/tmp and sets the SUID bit. This way, when executed, the script runs with root privileges, allowing us to obtain a root shell.
After running the bash1 binary inside /var/tmp with the tag -p we gain a root shell and find the final flag in /root/root.txt.
