TL:DR 

Patched bugs and vulnerabilities may sometimes rematerialize in later versions of a product. Through regression testing, we identify a case in which a seemingly patched version of PRTG Network Monitor is still vulnerable to an old exploit. Cases like this demonstrate why vulnerability scanning and patch management are not a replacement for defense-in-depth and assumed-breach cybersecurity strategies. 

We responsibly disclosed our finding to the vendor, Paessler. Paessler fixed the vulnerability starting in version 21.2.68. 

Background 

PRTG Network Monitor is a commonly used on-premises software product by Paessler used to monitor devices, applications, network traffic, and other IT infrastructure. Management and monitoring systems are frequently a target of attackers due to their tendency to enjoy privileged access to a variety of systems on the network in the form of either stored credentials, permissive firewall rules, installed remote agents, or other forms of access. In our case, we will be exploring an issue with the PRTG Network Monitor application itself which can lead to a compromise of the underlying operating system. 

CVE-2018-9276 

This CVE, which was originally discovered and reported back in 2018 by a researcher at CodeWatch named Josh Berry, pertains to a feature called Notification Templates.  Notification Templates in PRTG have several interesting features, but the one we will be focusing on is the Notification Method called “Execute Program.” This Notification Method allows for a user to specify an executable file, batch script, or PowerShell script to be executed upon the activation of a specific Sensor state. As we can see from reviewing the Paessler documentation, we can also trigger a Notification Template’s configured Notification Method manually using the “Send test notification” function.  

Unfortunately, we are not able to specify an arbitrary file to be executed and are instead limited to what is present within the PRTG Network Monitor installation subdirectory “\notifications\exe,” which by default only contains one example batch script and one example PowerShell script. 

However, the Notification Method options allow us to pass arbitrary parameters to the executed binary or script file. Additionally, not all characters entered by the user are properly encoded or sanitized by the PRTG web application. This is the vulnerable vector which allows us to achieve OS command injection on the PRTG Network Monitor server. 

According to CVE-2018-9276 (as of 10/26/22), this vulnerability applies to releases of PRTG Network Monitor prior to v18.2.39; however, as we will see, this vulnerability was later reintroduced to the PRTG codebase.  

Exploiting on v20.4.63  

First, let’s log in to our PRTG instance and set up a Notification Template. It’s always nice when the credentials are set to defaults! If not, you may be out of luck, as this vulnerability is the authenticated sort.   

Next, we navigate to Setup > Account Settings > Notification Templates, and then add a new template. Let’s name this guy “icebreaker,” enable the “Execute Program” Notification Method, select the default PowerShell script, and load up the “Parameters” input with a variety of characters we might want to use in a PowerShell payload.

Checking the contents of the configuration file located in the PRTG ProgramData folder, we can see that while single quote and double quote characters are encoded, many others (such as parentheses) are not. This is a good sign and may indicate that we can inject some PowerShell cmdlets.

Let’s do another test to see if we can leverage some of these characters to execute PowerShell code within the script parameters.

We then manually trigger this Notification Template using the “Send test notification” function we noted earlier. Checking the server, we can see that our test file was created successfully! It is worth noting at this point that because the PRTG Network Monitor services run as SYSTEM by default, our PowerShell code is executing in the same context.

Now that we have a way to execute commands on the system, let’s see if we can craft a more interesting payload. First, let’s adjust the Parameters data in our Notification Template so that PowerShell will execute the contents of a remotely hosted file.

Next, we will create a small script to be hosted on our remote attacker machine which we will name “prtg.log.” In this case, we will perform local file system enumeration to see if we can find any interesting files. Using this technique, we don’t need to worry about avoiding characters which are encoded by PRTG.

At this point we will fire up a Python HTTP server on port 80 and manually execute our malicious Notification Template as we did before. As we can see in the web log, we have successfully enumerated local disks as well as files within the Administrator account user profile directories.

Let’s go ahead and exfiltrate that, erm, interesting binary. First, we will need to update our “prtg.log” payload file to send the binary file to our attacker machine via HTTP. Below is the updated code.

Next, we will need a way to handle the PUT requests and save the uploaded files to disk, as this is not something the Python2 SimpleHTTPServer module will do for us out-of-the-box. We quickly put together (or… PUT together) a Python3 script which will handle incoming PUT requests and write uploaded files to disk. With this running, we can now handle the GET requests for our “prtg.log” PowerShell payload file as well as handle PUT requests to save the uploaded files to disk.

Voila! We now have a successful data exfiltration mechanism and can continue to pillage the PRTG server file system to our heart’s content. Of course, if you tire of this and have other services available such as RDP/SMB/WinRM, you can always create yourself a local user account on the PRTG server and use that channel instead.

We responsibly disclosed our finding to Paessler on 9/19/2022, which their team confirmed on 10/14/2022 as a reintroduction of the CVE-2018-9276 vulnerability to the PRTG Network Monitor code. Per their analysis, the additional affected versions include releases after v19.3.52 and before v21.2.68. This fix is noted in the v21.2.68 release notes.

In Summary 

While the v20.4.63 release of PRTG Network Monitor did not contain any significant vulnerabilities according to public vulnerability databases at the time of testing, we covered how regression testing can identify cases in which a previously patched vulnerability rematerializes in a later release of a given product.

Additionally, we worked through identifying escaped and unescaped characters to create a working proof-of-concept payload to exploit the vulnerability. Furthermore, we demonstrated a way to execute code containing properly escaped characters by fetching a remote payload file and demonstrated a way to weaponize this approach in a practical manner to exfiltrate files from the PRTG server operating system.

Give the Icebreaker team a shout to learn more.