Pelican
Video Tutorial
Please wait for video to load...
Written Walkthrough
FOOTHOLD
Starting off with an nmap scan we get 9 ports open:
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 61 OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
139/tcp open netbios-ssn syn-ack ttl 61 Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp open netbios-ssn syn-ack ttl 61 Samba smbd 4.9.5-Debian (workgroup: WORKGROUP)
631/tcp open ipp syn-ack ttl 61 CUPS 2.2
2181/tcp open zookeeper syn-ack ttl 61 Zookeeper 3.4.6-1569965 (Built on 02/20/2014)
2222/tcp open ssh syn-ack ttl 61 OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
8080/tcp open http syn-ack ttl 61 Jetty 1.0
8081/tcp open http syn-ack ttl 61 nginx 1.14.2
45713/tcp open java-rmi syn-ack ttl 61 Java RMI
As usual I start off with the juicy stuff, the HTTP services on ports 8080 and 8081.
When visiting port 8080 we get a 404 Not found. Doing directory brute forcing against this application doesn’t reveal anything either. I then go to check out port 8081 which actually then redirects us back to port 8080 under the directory /exhibitor/v1/ui/index.html
I have a look around and already this thing seems vulnerable. I search for “Exhibitor for Zookeeper v1.0 exploit” and get an exploit-db finding come up for RCE.
https://www.exploit-db.com/exploits/48654
It explains you can execute commands under the config tab in the “java.env script” field by wrapping the command in $(). The exploit-db gives a proof of concept also.
I changed the IP in the command and setup a netcat listener.
The exploit goes onto say that when the zookeeper application is launched it will execute the command at that point. I have to go back to the “Control Panel” and restart the service.
Once the service has been restarted I instantly get a shell.
PRIVILEGE ESCALATION
I land on the box as a user called charles. I moved into the /tmp directory and ran linpeas (I had to grab it from my local server as curl wasn’t recognised).
linpeas picks out a couple of interesting things.
So we can run gcore with sudo privs as ALL users. Hubba hubba. Okay what does gcore do ? I have a look at GTFObins and there is a section for gcore incudling the sudo priv esc.
Overview
gcore can be used to generate core dumps of running processes. Such files often contains sensitive information such as open files content, cryptographic keys, passwords, etc. This command produces a binary file namedcore.$PID, that is then often filtered with strings to narrow down relevant information.
Sudo
If the binary is allowed to run as superuser bysudo, it does not drop the elevated privileges and may be used to access the file system, escalate or maintain privileged access.
sudo gcore $PID <——–
So it sounds like we need to find a sensitive process that’s running to potentially dump sensitive information. Well we found that root was running a binary called “password-store” before hand.
I then boot up pspy64 and take a look at the process running and find a PID to use with gcore.
Using the password-store PID of 494, I run the following gcore command against this process, which then creates a file in my current directory.
└─$ sudo /usr/bin/gcore 494 
Following what GTFObins said, using the strings command against the created file “core.494” I find something very nice.
I use the following command below to change users to root and enter the password I found above “ClogKingpinInning731”, and I get logged in as root.
└─$ su root