This post is as much about the penetration testing process and mindset as it is about the vulnerability I discovered in a network monitoring program called PRTG Network Monitor. This vulnerability was discovered and reported to Paessler AG, the company that develops the application. I agreed to wait at least 90 days to disclose the vulnerability, to give the company time to fix it and their customer’s time to apply the patch. The patch was released on April 20, 2018 and the vulnerability was assigned a CVE of CVE-2018-9276. More details on the release can be found here. I finally have time to disclose this issue.

I was performing a penetration test recently and really hadn’t found much on the scoped servers and other systems, so I began reviewing accessible services and applications to target for default/weak credential testing. I was browsing through the available web applications and came across the PRTG network monitoring tool on one of the hosts. I was hopeful, as network monitoring tools are valuable targets that by definition have connectivity to most other systems and can often execute programs as part of their alerting/notification features. I quickly navigated to the documentation for the tool and found the default credentials of “prtgadmin / prtgadmin”:

Lo and behold the credentials worked. I was now pretty excited as network monitoring tools are typically a quick path to full domain compromise. Many network monitoring tools include the capability of running external programs as part of a “notification” as a feature. PRTG is no exception, however; as I quickly found out, it does not allow you to run just any executable or script of your choosing:

The instance that I found did not have any available programs to run outside of two demo scripts. Paessler AG confirmed that this is a security feature. PRTG requires any executables or scripts used in a notification to be uploaded to a specific directory on the server. There are no methods in the web application that can be used to upload a script or executable to use as a notification:

This is where the hacker/penetration tester mindset comes in to play. My initial thought was to move on to the next thing on the test. I had previously searched Exploit-DB and other sources for any vulnerabilities relating to PRTG and did not identify anything useful for the current version. I figured if no one else had reported a bug, then it probably didn’t exist. I began reviewing other potential targets for default/weak credentials. After a few minutes of reviewing other available services, the thought occurred to me that maybe one of the included demo scripts was vulnerable to command injection and no one had tested it out before. I decided it didn’t hurt to try.

PRTG is available to download as a demo for free, so I installed the tool on one of my own systems. One thing I was curious about was what kind of permissions I would have with a default install. If there were a command injection vulnerability, then it would be running under whatever permissions were provided to the application/service. The installation on my server confirmed that by default the PRTG services are running as “Local System”:

This was great news as if the demo scripts were vulnerable to command injection then I would start with elevated access on the server (giving me the ability to add an account to the local “administrators” group, or run Mimikatz, or perform other actions limited to administrators).

I then reviewed the “Demo” batch script, which appeared to be vulnerable to command injection attacks upon first glance, but all attempts to inject commands into this notification option failed. It is assumed that the user input is modified prior to being passed to the script in a way that mitigates command injection for the batch script. The contents of the batch file are provided below:

I then reviewed the “Demo” PowerShell script code, as shown below:

I noted that the argument supplied in the “Parameter” field of the “Notifications” configuration is passed directly into the PowerShell script without any sanitization, resulting in the ability into inject any other PowerShell code. I was hopeful that the application did not modify the input in any way, similar to the batch script.

I discovered the “C:\ProgramData\Paessler\PRTG Network Monitor\PRTG Configuration.dat” file while reviewing the PRTG application and monitoring files to which the application was writing or from which it was reading. The contents appeared to contain all values passed as part of a notification, among other things. I decided to begin testing out what if anything was encoded on my test server. The initial test looked something like the following screenshot:

I saved the test notification and reviewed the results, confirming that some characters were encoded but many useful characters were not:

A quick test confirmed that entering the following value into the “Parameter” field of a new notification, and then running the notification, would result in creation of a local account on the host:

test.txt;net user pentest p3nT3st! /add

 
I now had command execution on the host and had compromised the host in short order.

First of all, kudos to Paessler AG as they implemented a security control around the notifications feature where most network monitoring tools allow you to run any executable you want, and secondly because they were very responsive to my notification and developed a patch within two months of disclosure. Second of all, test all the things. I try to stick to a methodology of testing even the very low probability issues. That mindset and methodology paid off in this case and has in many others. Many times it doesn’t work (because it is low probability after all), but when it does it is absolutely worth it.