Intro

Information disclosure vulnerabilities are not the most exciting bugs in the business, and some bug hunters don’t even consider them worthy of note. I’m not going to weigh into that debate, but we recently came across such a bug in EventSentry, and I think it was at least worth discussing here as a case study in application security. This is a relatively minor bug – no RCE, no fancy ASLR bypass, this is simply a case where the developers probably thought no one would look there. Actually we discovered two vulnerabilities including a directory traversal – @ruddawg26’s write-up on that can be found here.

Before we get started I would like to point out that NETIKUS.NET ltd, the maker of EventSentry, does appear to take security seriously. There are few public vulnerabilities for EventSentry, and they were really responsive to our report. Both of our findings were patched as of version 3.1.1.90

Background

For those unfamiliar, EventSentry is a Security Information & Event Management (SIEM) solution. To paraphrase from the EventSentry website,

[EventSentry] aggregates and correlate logs, alert engineers in real-time of security issues, provide insight into data through dashboards and easy to use reports and help with a variety of compliance requirements

EventSentry offers the following SIEM-related functionality:

Real-Time Windows Event Log Monitoring with local rule processing

Real-Time Log File Monitoring (with local rule processing)

Complete Log Consolidation (Event Log, Log Files, Syslog, SNMP)

Correlation of various Windows security events

Forensic analysis of collected data through powerful search queries

Secure data transmission to central repository

RBAC to web-based reporting

I only mention these features to highlight that EventSentry has access to a lot of data on the host which means it’s necessary for the agent to run with elevated privileges. Configurations vary, but in general the EventSentry suite consists of a management console, host agent, web reporting, and a back-end database.

The management console is capable of installing and configuring agents, updating configurations, and updating agent software across the network. It’s the configuration updates process that we’re going to focus on.

CVE-2015-2911

To update agents an admin simply makes the desired configuration changes via the management console, and then pushes updates down to the agents. This push action is accomplished by sending a configuration file to each agent. The configuration file is compressed (.zip) and sent over the wire where it’s downloaded to the local installation directory. Once the zip file has been downloaded the agent unzips the file and loads the new configuration file. The EventSentry agent stores nearly all of it’s configuration settings in the Windows registry. To update the agent configuration, the software loads a .reg file with all the new settings. It’s here in this update process that, for a brief instant, information is exposed.

If you watch the install directory, C:\Windows\SysWOW64\EVENTSENTRY, you can actually watch the new configuration file appear during an update. By default a regular user only has READ access to this directory so manipulating the config in flight isn’t likely. From watching this behavior we can see that the programmers needed to know when the config file was ready to be loaded so they used a flag file to indicate the download was complete. This is easily seen in the image below with the appearance of the eventsentry_svc.zip.complete file.

EventSentry agent configuration update

Once the flag file appears the agent unzips the eventsentry_svc.zip file and loads the new eventsentry_svc.reg configuration into the registry. After the new config is loaded the agent then deletes the .reg file because it contains, among other things, cleartext passwords!

Exploitation

As I mentioned above a regular user has READ access to the install directory by default. So all we need to do is copy the eventsentry_svc.zip file before it’s deleted and we have access to all the configuration information that the EventSentry agent uses. There are many ways you can do this, but an easy way is to just use a quick PowerShell script. You can get as fancy as you like with this in practice, but a quick PoC is shown below:

 while(1){  
      $flag = “C:\Windows\SysWOW64\EVENTSENTRY\eventsentry_svc.zip.complete”  
      $file = “C:\Windows\SysWOW64\EVENTSENTRY\eventsentry_svc.zip”  
      if(Test-Path -path $flag){  
           try{  
                cp $file C:\Users\user\Desktop\eventsentry_svc.zip  
                break  
           } catch { “...” }  
      }  
 }

Information Exposure

Searching through the .reg file there is A LOT of information. Included in the config are login credentials for the EventSentry database and any SMTP server the agent uses to send notifications as shown in the screenshots below.

Conclusion

Obviously this only helps in a post-exploitation scenario, and to be perfectly honest it’s unlikely you would use this on a quick penetration test. However, once you have gained access to a system that runs the EventSentry agent why not run a small script in the background just in case the admins push an update? If you get lucky you might have just landed credentials to the EventSentry database or more. Overall, this isn’t a huge vulnerability for EventSentry, but this is the sort of thing a persistent adversary might use to gain access to more information. For the developers reading this – I understand your plight. You have a job to do which is to get a user friendly, working, product to market. Application security is hard, and it’s nearly impossible to think about all the fringe cases that may be exploited, but what choice do we have.

Yes, someone will look there – EventSentry Info Exposure – CVE-2015-2911