Charlotte

Gaining Access

Nmap scan:

$ nmap -p- --min-rate 3000 192.168.183.184
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-12 11:46 +08
Nmap scan report for 192.168.183.184
Host is up (0.17s latency).
Not shown: 65529 filtered tcp ports (no-response)
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
111/tcp  open  rpcbind
892/tcp  open  unknown
2049/tcp open  nfs
8000/tcp open  http-alt

NFS was open, so I wanted to enumerate that first.

NFS Files

showmount reveals that there are some files for us to download:

$ showmount -e 192.168.183.184
Export list for 192.168.183.184:
/srv/nfs4/backups *
/srv/nfs4         *

We can mount on this and view the files present:

It seems that there are files containing the source code of a website here. index.js contains some information pertaining to an authentication:

Web Enumeration -> Admin Creds

Port 80 hosted a basic page with a login:

Port 8000 required credentials to view, and its likely that the source code we found in the NFS shares was for the port 8000 website.

I first did a feroxbuster scan on the port 80 website, since we couldn't do anything without the credentials for the port 8000 website.

The README contained some interesting information.

Basically, we are given the nginx configuration files and can see that there are checks on the User-Agent. We can change this to googlebot, and another directory scan finds other directories:

Next, there's a small mention of port 3000 being used as a proxy within the Nginx configurations. Since the User-Agent header value is set to googlebot, the $prerender value would be set to 1. The following is executed:

The $host parameter is user-controlled, and can be altered. Fittingly, attempts to visit the /admin directory are blocked by a WAF:

This can be bypassed by setting the Host header to localhost since the Nginx configuration uses our $host values:

With this, we can login and view the port 8000 service.

Prototype Pollution -> RCE

Now that we have access to this service, we can do some basic source code review. Earlier, we saw that this application uses some libraries and packages. We can find their specific versions within package.json:

The ejs package is vulnerable to RCE using Prototype Pollution, while the merge package is vulnerable to Prototype Pollution.

Logoejs 3.1.6 vulnerabilities | SnykFind detailed information and remediation guidance for vulnerabilities and misconfigurations.
Logomerge 2.1.0 vulnerabilities | SnykFind detailed information and remediation guidance for vulnerabilities and misconfigurations.

The vulnerable function would be the post_status one since it uses the recursive function from merge.

I tried interacting with the application and injecting some other JSON data:

The RCE exploit lies in overwriting outputFunctionName. When researching for how to exploit this, I came across this article:

LogoEJS, Server side template injection RCE (CVE-2022-29078) - writeupEslam Salem blog

We can then exploit it using basic Prototype Pollution:

It didn't work at first, and upon sending a GET request to /reset, it worked!

Privilege Escalation

Cron -> User -> Root

When we view the /etc/crontab file, we can see that the user sebastian is executing a JS file periodically:

Here's the file contents:

It uses a package.js file from /var/www/node, a directory we have write access over as www-data. We can create a package.js file like this:

Then, we can just wait for the shell to execute.

The user is part of the sudo group, and it is trivial to become the root user:

Rooted!

PreviousCattoNextChatty

Last updated