TryHackMe - AgentSudo
hackthebox.eu has a separation between ‘active’ and ‘retired’ machines; it’s against the rules to publish a write-up on an active machine. I’ve only recently started with tryhackme.com, which is a little different. There isn’t a distinction between active and retired machines, and as far as I can tell, there is no policy preventing people writing up their results. Furthermore, this writeup is for a machine that has other existing writeups, so there are no spoilers here.
This is my first writeup of a box I’ve rooted.
I’ve noticed with other writeups that people often include big chunks of nmap output, but I don’t really see the need. My method is usually to run a TCP scan on all ports immediately followed by a detailed scan on the open ports. I usually only run a UDP scan if I’m drawing a blank. I’m only going to include specific details from nmap scanning if it’s really relevant. Otherwise, I’ll just list the open ports and maybe the services.
For this box, the relevant open ports were 21 (FTP), 22 (SSH) and 80 (HTTP). The server was Apache 2.4.29 running on Ubuntu.
When I see an open FTP port on a scan, I usually try an anonymous login. However, this was not permitted on this box.
Visiting the website via Firefox you are greeted with the message:
Dear agents, Use your own codename as user-agent to access the site. From, Agent R
I usually run Burp Suite for these things, in which case changing the
with Repeater is trivial. I must admit I tried lots of different names before discovering the codename was supposed to be a single letter (like the R in Agent R). Anyway, once I found the correct value, the following message appeared:
Attention chris, Do you still remember our deal? Please tell agent J about the stuff ASAP. Also, change your god damn password, is weak! From, Agent R
Since we now had a username and a hint that the password was weak, it was back to the FTP server to try to login as Chris. I used the FTPBruter tool to achieve this (https://GitHackTools.blogspot.com).
You can try this for yourself if you want to know the password. At the FTP site were three files:
- cute-alien.jpg, and
The text file said:
Dear agent J, All these alien like photos are fake! Agent R stored the real picture inside your directory. Your login password is somehow stored in the fake picture. It shouldn’t be a problem for you. From, Agent C
So this provides a clue that we are looking at a steganography challenge. Running binwalk on one of the files produces:
Extracting the files produces an image which isn’t of any further use, and a password protected zipfile.
The zipfile can be cracked using John to obtain the password ‘alien’:
Unzipping the file using the password provides the following message:
Agent C, We need to send the picture to ‘QXJlYTUx’ as soon as possible! By, Agent R
We can decode the base-encoded string in a variety of ways, but from the CLI we can do:
‘Area51’ then becomes the passphrase to unlock hidden content in the other image file that was found in the FTP directory, which can be unlocked with steghide:
Hi james, Glad you find this message. Your login password is hackerrules! Don’t ask me why the password look cheesy, ask agent R who set this password for you. Your buddy, chris
Alternatively, we could skip the entire step of decoding the first zipfile with binwalk > JtR and bruteforce the second file with stegcracker; both methods work.
The new credentials we have (james:hackerrules!) are for SSH, so we can log in to the box and at this point grab the first flag. Now it’s time for the privesc.
The box was designed to allow for exploitation of CVE-2019-14287, a Sudo vulnerability. A description is found here here, but essentially if sudo is passed a User ID of “-1” or its unsigned number “4294967295”, the command will run as root. So the exploit is simply:
At which point you have root privileges and it’s game over.
Running LinEnum.sh produces the following output: [+] We’re a member of the (lxd) group - could possibly misuse these rights! uid=1000(james) gid=1000(james) groups=1000(james),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lxd)
As it turns out, there is an LXD/LXC privesc that the box is also vulnerable to. You can read about it here: https://dominicbreuker.com/post/htb_calamity/, and here is the method in action: