This is TECH_SUPP0RT: 1 from VulnHub.
Background: The machine acts as a server setup by pop-up scammers which is under maintenance.
HTTP, SSH and SMB. Let’s begin with SMB.
We have anonymous login (I use smbclient) and just one file: enter.txt.
So, this implies we have a wordpress installation, and something called subrion which I’ve never heard of. Heading over to CyberChef with our obfuscated credentials and clicking magic gives:
Scam2021 Matching ops: From Base64
So that’s our password for subrion (Scam2021).
Now, this is where I had some trouble. The box came in as a VMDK which I don’t hate but they never tell you which OS it is. Anyway it’s Ubuntu and I set it up, but it was set to NAT. I switched it to Bridged, because that’s how I run my Kali and it started to work but then trying to go to subrion it kept redirecting to a NAT IP address. Bugger; I’ve had this before and it makes it pretty much impossible to continue.
I shut everything down, took a snapshot of my Kali and restarted it in NAT mode, then restarted the box; it worked! This was actually a first for me. But we can continue.
We can login easily; it’s a CMS. I poke around and upload a webshell but it’s only got read and write permission; no execute. Navigating to the file says ‘you can’t do that’ or something along those lines. Now what?
There is an exploit. Reading through the code, it appears that phar files can be executed, but not other types. Rather than running the exploit script I use the GUI to rename my shell from shell.php to shell.phar and then visit http://10.0.2.15/subrion/uploads/shell.phar; success!
We know there is a Wordpress site so I go to /var/www/html/wordpress/ and check wp-config.php for creds:
This can be used to login to mysql, but it’s alse reused for our next user, whose name we get from /etc/passwd:
So; according to GTFOBins we can read and write files with iconv, but there is one catch. The example given for writing files is:
echo "DATA" | iconv -f 8859_1 -t 8859_1 -o "$LFILE"
Where the call to iconv is not the first thing. I usually find with these sudo things that this won’t work; the iconv call needs to be first. Anyway, I can read /etc/shadow and grab the root hash with this; that’s okay but it probably won’t break easily (I don’t try for long). What about SSH? Yes, there is a root SSH key at /root/.ssh/id_rsa and we can read that. However, even though the key is not encrypted, we can’t login with it. Every time I try, I am prompted for a password - presumably something is not right in the server configuration.
Debug mode doesn’t help, and even reading /var/log/auth.log with the iconv trick doesn’t help:
Now what? Well, we can use iconv for a file write by modifying the GTFOBins code a little. I want to add the line:
to /etc/passwd. I make a copy of /etc/passwd to /dev/shm/backup and then append the line in:
printf "root2:WVLY0mgH0RtUI:0:0:root:/root:/bin/bash\n" >> /dev/shm/backup
And then I can use inconv to replace /etc/passwd with the modified version using redirection:
So; a few challenges along the way but we got there in the end. Huzzah!