Oopsie

I start out the same way I would with the same way I would with any other box. I run my nmap scan.

nmap -sC -sV -T4 10.129.163.8

Port 22 & Port 80

Now in our nmap output we can see that we have two ports open, 22 & 80. We can see that 80 has a "Welcome" banner so instead of trying to get into ssh, lets go check out the website running on 80.

Lets start up burp suite as well to proxy any incoming resources from the webpage.

It looks like a website for an automotive group. Now lets see what we got in burp.

Expanding the cdn-cgi asset folder

We can see there is some kind of javascript executing here on a login endpoint. Now what happens if we were to go to this endpoint?

Well it looks like there's an exposed login panel here. We also don't need to provide any authentication credentials because we can login as a guest! So lets go ahead and do that.

Authenticated as a Guest

So in order to fully own this box we are going to need to escalate our privileges somehow, right? We essentially need to find some way into the server to get our flags. Now we can try for some remote code execution endpoints but what immediately stands out to me is the "Uploads" page.

Uploads require super admin privileges

Looks like we don't have the correct permissions to upload....but what if we did? What if there was some kind of endpoint of parameter we could change so that we could trick the application into thinking that we are an admin? "What parameter would be storing our user information?" you may ask. Well now its time to start poking around and checking some other points of interest to see if we can expose some more information out of the application.

So theres two pages that really stand out to me. The "accounts" and "clients" pages.

Just going to the clients page we can see that the URL contains an "orgId" parameter. So naturally we should try to test this for an Insecure Object Reference vulnerability. By just changing the parameter at the top to 3, we can see that we are taken to a page with an empty table and the ID of 3.

If we do 1 we can see that there is an account for "Tafcz".

So the vulnerability is there but it doesn't quite expose enough information that we would be able to compromise this account. So lets pivot over to the account page. If we look at the URL we can see the same thing is present here.

So of course we should test this as well. This time lets test with the 1 first.

Now if we check Burp, we can see that the request also has plaintext cookies that it sets

Changing these cookies manually could grant us access to the administrator account, so we are going to do exactly that. You can do one of two things here. You can intercept the request and set the cookies there or manually edit them in the browser. Its really dealers choice here.

New IP is from me resetting the machine trying to troubleshoot connection issues.

Setting the new cookie changes and then traversing to the uploads page again, confirms that we can also expose a broken authentication vulnerability here, and get access to upload content to the site. Pressing the browse button and examining the "File Type" field, it looks like it accepts all types of files. So now we should try to see if we can upload some kind of shell that we are able to execute from our end. The idea here is that once we have the shell then we can start enumerating the host itself from the command line.

For this I am going to use the PHP reverse shell that comes with Kali, because we are able to execute PHP with this application.

I change the IP and Port parameters to match my Host.

Now all that is left is uploading, starting the netcat listener, and executing our shell. We start our netcat listener on port 4444 and with the command nc -nvlp 4444 and we will upload our shell.

Now we need to find where the file was uploaded. This is where some directory enumeration is required. So my tool of choice is going to be gobuster for this one.

A little hard to read here but you can see in the very last request we got a subdirectory hit for /uploads. If we go the subdomain we don't have access but if we try to access the file uploaded (/uploads/php-reverse-shell.php) then we notice that the site hangs for quite some time. Looking back at our terminal we can see that we have actually gotten the shell.

I took too long to take the screenshot and the web request timed out.

Now we run python3 -c 'import pty;pty.spawn("/bin/bash")' in order to get a more functional shell. Now dude to the nature of PHP, you cant really hide secrets within the code. So now the goal is to enumerate through the source code to see if we can find some plaintext credentials that we can use. If we navigate to the /var/www/html/cdn-cgi/login folder, we can see we have several files here. You can sort through all of the source code for this, but the much easier way is to concatenate all of the files and then pipe that into a grep and look for the word password or varations of the word in order to find these credentials within the files. With a command like cat * | grep -l passw* we can achieve this.