Lord of the Root Vulnhub Writeup
Lord of the Root is a boot to root style box that offers great opportunities to refine your process and fill in some gaps when your mind-map runs to the end. Here comes the journey.
I start with setting the bash variable IP=192.168.152.129 so I don’t have to remember stuff. This allows me to copy-and-paste from my notes using variables and I don’t have to modify the commands. So I’ll start with ping -c 4 $IP but that returns nothing. So pings must be blocked, need to note that for future commands. Let’s start with an nmap of nmap -sC -sV -oN lotr.nmap -Pn $IP and that returns one port: ssh. I’ll run a bigger nmap of all ports to see outside the top ports: nmap -sC -sV -oN lotr.nmap_full -Pn $IP. That only returns one port: ssh. Well, let’s start a UDP scan while I look at this one TCP port: nmap -sU -oN lotr.nmap_udp $IP.
So looking at the nmap results, the ssh port isn’t providing much. However, looking at the part above, it says “65534 filtered ports” which indicates that the ports are being monitored some how: probably a firewall. I could run a traceroute on it, but I know it is not behind an external firewall: this is probably iptables doing it (or some built-in tool on the box). Looking at searchsploit openssh there aren’t really any that meet this service version that can help us. If we had usernames we could do some validating, but we aren’t even there yet. Time to connect and see what happens!
So I try with ssh logEntry@$IP to see what it gives. Regardless of success or not, the attempted user name for login (along with my IP) will be in the access.log file, so I chose to use logEntry to be in there. In the text, it highlights a phrase with a series of numbers. Hmmm…maybe there is a way around iptables! So following directions I try knock $IP 1 2 3. The only way to see success is to check ports again. nmap -sS -p- -oN lotr_knock.nmap $IP -Pn — max-rate=10000.
Ah, so knocking does work. Looks like we got another port. Let’s investigate that one. curl $IP:1337. So the page is just an image and that is it. Let’s check the image in case we got some hidden stuff in it. curl $IP:1337/images/iwilldoit.jpg -o iwilldoit.jpg. exiftool iwilldoit.jpg. binwalk iwilldoit.jpg. strings iwilldoit.jpg. xxd iwilldoit.jpg. No, don’t see anything buried. If something like steghide was used, it will take some brute forcing. If I find nothing else, I’ll come back to this. I’ll go ahead and run feroxbuster — url http://$IP:1337. This gives a 301 in images and a 403 on server-status. Let’s see what a 404 gives.
It gives another image, but there is a comment in there. Let’s pull it out and see what we get: webpath=$(echo ‘THprM09ETTBOVEl4TUM5cGJtUmxlQzV3YUhBPSBDbG9zZXIh’ | base64 -d | cut -f 1 -d’ ‘ | base64 -d). That gives us a new spot to try: curl $IP:1337/webpath. Now we got a login page. Run the curl command again with a -v and we can see we got a php page and a cookie. Since we have no usernames/passwords (or hints to what they would be), I’ll try admin:admin to see how the page responds. It gives an “invalid”. So we probably have two good options: potential sql injection in the form or brute-forcing usernames/passwords. Let’s try sql injection first. I’ll start with sqlmap -r login.req — batch. It provides nothing with the defaults. I really don’t like brute-forcing unknown usernames (although the theme of the box we could have some educated guesses), so let’s increase our efforts: sqlmap -r login.req — batch — level 5 — random-agent. It says username is injectable and the backend DBMS is MySql. Okay, let’s continue this adventure with sqlmap -r login.req -dbms mysql -dbs -batch and we get back two databases. Might was well pull them both. sqlmap -r login.req -dbms mysql -D mysql -tables -threads=10 -batch and sqlmap -r login.req -dbms mysql -D Webapp -T Users -dump -threads=10 -batch.
So we got a dump and potential usernames and passwords that may work. Let’s try to get a shell: sqlmap -r login.req2 -dbms mysql — os-shell. No, can’t seem to pull off a shell here inside of sqlmap, but worth a shot. Well, let’s try them to see if they work. Let me pull out the users: cat ~/.local/share/sqlmap/output/192.168.152.129/dump/Webapp/Users.csv | awk -F’,’ ‘{print $3":”$2}’ and we’ll need to separate the users and the passwords into their own files. hydra -L users -P pass $IP -s 1337 http-post-form “/978345210/index.php:username=^USER^&password=^PASS^&submit=Login:invalid” -v. And they all work! Kinda makes sense because they are in the database as valid users. However, each login provides the same about of access. No profile page, admin page, etc. Now that I have a valid PHPSESSID, I could do some directory busting again to see what we get. However, before I do that, I’ll check for reuse across services. crackmapexec ssh $IP -u users -p pass — no-bruteforce — continue-on-success gives a success for smeagol!
So, from here we could do it manually or use a tool. I’ll just use a tool to expedite the process. I’ll move linpeas over to the box and run it. From a new terminal I ran: scp ~/kaliOptHome/privilege-escalation-awesome-scripts-suite/releases/linpeas.sh smeagol@$IP:/dev/shm. Then on the ssh shell I ran bash /dev/shm/linpeas.sh | tee linpeas.output. LinPEAS highlights the “95% vectors” in red and yellow: this box has 3 right off the bat. One is a kernel exploit for the old kernel, one is a CVE for polkit which came out in 2021, and the third is a SUID setting on a custom executable. Let’s run through each of them.
The kernel exploit can be overwhelming as this kernel is a bit old and there are a lot of options. Running something simple like searchsploit kernel 3 can be overwhelming and take a lot of time to filter what you want to try. linPeas already has linux exploit suggester built in to provide those vectors. The top items are dirtycow which is popular and easy. If we follow the searchsploit logic, it says 37292 works up to 3.19 which is close. We can try it, but it won’t work. So what is the next kernel exploit up? Well, what is the next one above 3.19 for an ‘overlayfs’? Let’s look at searchsploit overlayfs and you can see the ones above 3.19. I’m going to try 39166 since that is the next highest one. searchsploit -m 39166 moves it to my directory and scp 39166.c smeagol@$IP:/dev/shm moves it to the box.
The CVE is given with the linPeas output, as well as the direct download link. You could use the searchsploit option, but let’s see how this tool helps us out. If we download the link from the linpeas output, we get a zip file. We can copy the whole file over and run it from there. scp CVE.zip smeagol@$IP:/dev/shm.
The third option is way more tricky and involves quite a bit of time. This is a classic buffer overflow option that has to overcome ASLR. Once I built the exploit, I had to do some brute-forcing to have it loop until it lands within my buffer space. If you think you got buffer overflows down, give this one a shot and learn a new technique!
There are more ways to get root on this box, but those were the obvious top 3. Enjoy!