Pikaboo
Gaining Access
Nmap scan:
$ nmap -p- --min-rate 5000 10.129.95.191
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-01 23:10 EDT
Warning: 10.129.95.191 giving up on port because retransmission cap hit (10).
Nmap scan report for 10.129.95.191
Host is up (0.022s latency).
Not shown: 65018 closed tcp ports (conn-refused), 514 filtered tcp ports (no-response)
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open httpAnonymous logins does not work for this site. We can take a look at the HTTP site.
Apache Reverse Proxy
It's a Pokemon based website:
The admin portal requires credentials to access:
We can take a look at the Pokatdex and see that there are entries for each specific creature. Props to the creator for designing these:
When we try to view the entries, we just see this:
The URL visited http://10.129.95.191/pokeapi.php?id=6, which might be relevant later on. I tested LFI and other types of injection, but nothing worked. I took a closer look at the administrator login, and found that if I keyed in wrong credentails, I got a unique error.
For some reason, it was redirecting me to port 81 on the localhost. This means that some type of proxy is being used to forward the traffic to the right destination. It's called a reverse proxy, and looking for exploits for it led me to this:
Based on the PoC, this is a misconfiguration regarding the proxy used for the /admin directory. We can test it out and find that we have bypassed authentication using this method and get a 403 instead.
I tried a gobuster scan on this new URL to see if we can find new files to access, and it seems server-status has been left publicly available.
server-status contains logs for the Apache server for administrators to view and see, and now we can see it too!
There are loads of requests, and it seems that there's an extra directory at admin_staging. We can visit it using http://10.129.95.191/admin../admin_staging/.
Admin Staging
This was a dashboard of some sort.
The URL is http://10.129.95.191/admin../admin_staging/index.php?page=dashboard.php. This could be vulnerable to LFI. I used wfuzz to see what files existed on the page using the LFI wordlist. Ideally, we are looking for some type of configuration files.
It seems that we have found 2 files, and both of which have different lengths, indicating that something actually appeared on the page. When we view the FTP log file using curl, we find a username for FTP
The weird part was that there was no password in sight, so we couldn't do much here.
FTP PHP Injection
Notice that we are able to write to the logs via the username logins, and the page is in PHP. There's a chance that we have to do PHP injection via the username parameter in FTP. This might work because the FTP logs are displayed on the page, whereas the rest of the files aren't.
I logged in with a unique username
Afterwards, I used the LFI to view the logs again, and I got a callback on tcpdump.
Great, we now have RCE. We just need to include a bash reverse shell one-liner. We can use this:
After viewing the page again, we would get a shell as www-data.
We can grab the user flag.
Privilege Escalation
Cron -> FTP Creds -> Perl RCE
I downloaded LinPEAS to the machine and it did the enumeration for me. Within the cronjob section, it found 1:
This was running a bash script as root, and we can view it:
This uses another script csvupdate. It's a Perl script, and it's rather long, but here's the end of it:
It seems to use parse on the CSV. I'm not super great at Perl, so I googled every function used here for vulnerabilities. It appears that open can be used for RCE for some weird reason.
Right, so now we have a potential RCE vector, but we still need to find out how to place files into the FTP server. This means we need top find credentials somewhere. Checking the /opt directory, I found some files:
Within the /config/settings.py, we can find some stuff pertaining to LDAP on this machine.
It seems we have a password and a username. We can also confirm that LDAP is running.
The next step would be to enumerate LDAP via ldapsearch, which happened to be on the machine.
We can find the user password in Base64 here, and when decoded it gives the password _G0tT4_C4tcH'3m_4lL!_
We can't SSH in as the user with this, but we can access the FTP directory and place files.
Now, we need to place a maliciously named CSV file to get RCE via Perl. There were a load of files within the FTP server, so I just used the one that was updated most recently.
Based on the StackOverflow question, we have to name our file | <insert bash command>.csv. In my testing, it seems to reject / characters for some reason. So let's create a payload without all of that using a python3 reverse shell.
Remember to have a backslash behind all spaces and spaces to allow the upload to work. After waiting for a little while, we would get a reverse shell on the specified port.
Rooted!
Last updated