Twiggy was another easy box from Proving Grounds. If you’ve read the write-up on Bratarina then Twiggy follows a very similar methodology; by which I mean it’s one step to root by executing a pre-compiled exploit on an unusual port.
Enumeration
As always we start with AutoRecon and check out the nmap.
Looks like we have 4 ports open:
- 22 SSH – This has never been the exploitable port, so I tend to discount it right off the bat when I see it;
- 53 DNS – DNS is often useful for further enumeration and information gathering, but without a domain to use there is not much more we can do with it;
- 80 HTTP – a commonly exploited port, likely hosting a vulnerable web app and worth investigating;
- 8000 HTTP – also a commonly used secondary HTTP port, most likely hosting an exploitable web app.
I start by exploring port 80 and going through the enumeration scripts from AutoRecon but I cannot find anything useful, so I shift my attention to port 8000.
Port 8000
Opening port 8000 in a browser gives the below response:
Googling this output suggests the port is running CherryPy and Saltstack.
A quick Google search for “saltstack exploit” returns this script on Exploit-DB as exploit 48421.
I download a copy of the Exploit-DB script, open it up to find out how it works, and attempt to read some files from Twiggy.
This script lets me read the contents of /etc/passwd, and suggests the server is indeed vulnerable.
Exploit
Looking back at the help menu of the 48421 script I find there is an option to write to the server as well, so I craft my exploit to try and write to the /etc/passwd file.
First I create my own passwd file on my local machine, and copy the contents of the Twiggy passwd file to it. Then I add a line to the bottom with a new account called “pwnd” and give it the password “password” using the openssl command.
Next I run the script with the upload-src and upload-dest flags, and when I get a successful response I try to login with the new account.
The exploit works and I am able to SSH into the box with my new credentials as a root user.
Conclusion
As we can see this box is similar to the Bratarina box from a couple of days ago. The interesting takeaways from this box are to read the output of your exploit scripts carefully, and always check if there is another script you could be using. If I had simply relied on the output of the searchsploit script I would never have cracked this box. Writing to the /etc/passwd file always feels like a crude method of privilege escalation, but it’s always worth trying as a quick and dirty solution.