XXE Vulnerability in BlackBerry AtHoc (Networked Crisis Communication) Platform
Recently I had the opportunity to test an installation of AtHoc – BlackBerry’s emergency notification system. During the course of the test, I discovered an XML External Entity (XXE) vulnerability in BlackBerry AtHoc 7.6.0 affecting the Delivery Template feature used to customize emergency notification messages and demonstrated how an authenticated attacker could read files off of the underlying server. This is important because an XXE vulnerability poses risks to any organization, but it becomes particularly critical when the potential data is sensitive.
From the AtHoc website: “AtHoc’s comprehensive suite unifies crisis communications within and across organizations, their people, devices, and external entities.” In a nutshell, AtHoc is used to alert and track members of an organization during a crisis event such as an active shooter or terror attack, where effective communication can save lives. The platform is used across a broad swath of industries, including commercial, military, federal, healthcare, state & local, and transportation & airports.
Considering the critical function of this platform and the nature of the industries using it, the impact of this finding could have potentially life-threatening ramifications if used as part of a larger attack. This blog details the vulnerability and my findings.
What is an XXE attack?
In order to understand this particular XXE attack, let’s first define the various components that allow for this vulnerability.
Extensible Markup Language (XML), is a flexible markup language capable of defining instructions for processing itself in a special section called the Document Type Definition (DTD). Within the DTD, “XML entities” can be defined that tell the XML processor to replace certain pieces of text within the document with other values during parsing.
eXtensible Stylesheet Language Transformations (XSLT) is a language for transforming XML documents into other XML documents, or other formats such as HTML for web pages, plain text or XSL Formatting Objects.
An XML External Entity (XXE) attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. This attack may lead to the disclosure of confidential data, denial of service, server side request forgery, port scanning from the perspective of the machine where the parser is located, and other system impacts.
From a high level, we’ll be injecting our malicious XXE attack into a field that accepts XML and XSLT code in an attempt to manipulate the processor into including the contents of an arbitrary server file in the final rendering of our input.
With the definitions out of the way, let’s explain the attack.
- When it comes to XXE, we’re looking for input fields or web requests containing XML that we can attempt to modify. With this in mind, visit the Delivery Templates page of the BlackBerry AtHoc 7.6.0 platform.
- Locate the Template XSLT Layout field containing pre-populated XSLT input. By examining the XSLT and clicking the Preview button on the page, we determine that this field is being used to generate custom appearances for emergency notifications, which in our case is a sample desktop popup. Great! A field responsible for converting XML to HTML (XSLT’s job, remember?) is a perfect target.With our target identified, we can now test for XXE. We do this by injecting different payloads and observing any errors or successes while trying to preview our sample desktop popup. This is a tedious process of trial and error and can be discouraging. Don’t give up! A step in the right direction is first figuring out how to get the parser to parse our XML without errors and produce a blank popup. Once over that hurdle, we can then test common attacks such as local file disclosure, command execution, calling malicious external DTDs, etc. After many attempts, we finally are able to produce an XXE proof of concept, interwoven with the preexisting XSLT (our payload is highlighted in red):
<!DOCTYPE doc [ <!ELEMENT doc ANY > <!ENTITY foo SYSTEM "file:///c:/windows/win.ini"> ]> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:output method="html" /> <xsl:template match="/"> <doc>&foo;</doc> <head></head> <body style="margin: 0; padding: 0;" oncontextmenu="return false;"></body> </xsl:template> </xsl:stylesheet>
- With the payload above placed in the Template XSLT Layout field, we click the Preview button to generate the popup.
- The application parses our payload and opens a popup containing the contents of the server’s Win.ini file we requested.
Note: As mentioned above, it’s common in XXE attacks to attempt command execution or calling malicious external DTDs to launch more sophisticated attacks including Out-Of-Band (OOB) file reads and data exfiltration. I was only able to confirm in-band local file disclosure during the test, however, there are several examples of relevant XXE exploits (XXE in IBM’s MaaS360 Platform; XSLT Processing Security and Server Side Request Forgeries), where the researchers were able to execute commands on the server or to exfiltrate data which provided access to sensitive information as a result of this vulnerability.
Though the demonstration above showed us the content of a sample file generated for testing purposes, in real life this could be used to read any* file on the server that the AtHoc service has permission to read and that an attacker can guess/brute-force or knows the existence of. This could include passwords, server and platform configuration data, etc.
*The caveat being that files containing certain characters, e.g. “&” and “<” will break the rendering process in the attack demonstrated. Consult the exploit references presented above for potential bypass methods.
- XML usage is commonplace and it’s easy to parse incorrectly.
- This vulnerability is hard to test for with automated tools and can be a real pain when testing manually. If it uses XML, give it a few pokes before moving on.
Reporting and Remediation
- November 2, 2018: Vulnerability discovered
- November 14, 2018: Details sent to BlackBerry customer support. Response from BlackBerry acknowledging report
- November 21, 2018: BlackBerry response confirms issue and states that hotfix will be released by December 14th
- December 6, 2018: BlackBerry response states hotfix has been released
- December 18, 2018: Vulnerability report escalated to BlackBerry Security Response Center (BBSIRT) for attribution process
- December 20, 2018: BBSIRT response acknowledges report and assigns case number
- December 21, 2018: BBSIRT states case evaluation will be resumed in second week of January due to holiday absences
- January 10 – February, 12 2019: Emails going back and forth. BBSIRT states case evaluation in progress.
- February 20, 2019: BBSIRT notifies me of intention to file a security advisory and coordinate disclosure
- March 4, 2019: Phone call with BBSIRT. Notifies me CVE-2019-8997 has been reserved and that advisory is expected to be released the next week. BBSIRT informed of my intention to create blog
- March 12, 2019: Security Advisory released. Blog release approved
- March 13, 2019: CVE-2019-8997 updated. Blog published
I want to thank BlackBerry for their diligence and consistent communication during the disclosure process.
- BBSIRT Vulnerability Announcement: https://support.blackberry.com/kb/articleDetail?language=en_US&articleNumber=000047227
- CVE-2019-8997: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-8997
- BlackBerry AtHoc: https://www.athoc.com
- XXE in IBM’s MaaS360 Platform: https://blog.netspi.com/xxe-in-ibms-maas360-platform/
- XML External Entity (XXE) Processing: https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing
- XSLT: https://en.wikipedia.org/wiki/XSLT
- XSLT Processing Security and Server Side Request Forgeries: https://www.owasp.org/images/a/ae/OWASP_Switzerland_Meeting_2015-06-17_XSLT_SSRF_ENG.pdf
- Nolan Kennedy’s Blog: https://www.nolanbkennedy.com/