Red team engagements always include a plethora of different services and applications, and often they may be services that have not been previously been pentested on their own. When pentesters or other actors encounter situations like these, they can be prime targets to attack. This blog post will detail a similar situation in Jive Software’s Jive-n platform and the discovery of an XML external entity injection (XXE) vulnerability, which resulted in CVE-2018-5758.

Researchers at Rhino Security Labs recently discovered an XML external entity (XXE) injection vulnerability in the employee interactive intranet software know as Jive-n. This vulnerability lies in the “Upload File” functionality of the application. By uploading a Microsoft Word document weaponized with an XXE payload, attackers can read any file on the operating system and request a directory listing for any folder.

This attack is significant because one of the features of Jive-n is the ability to upload and share files among trusted users. For more information on XXE vulnerabilities, refer to our recent post, XXE Zeroday Vulnerability in HP Project, or the OWASP page on XXE.

Jive-n is a product of Jive Software, which is owned by Aurea. It is known as an interactive social intranet software, offering many different features and integrations to assist both employers and their employees. It is offered both as a SaaS product as well as an on-premises/self-hosted application. During the course of our research, we found an active instance of Jive-n, but it was not in active use. We had access to credentials from a phishing campaign, so we were able to login to the app, due to password reuse.

One of the features offered by Jive-n is the ability to upload files to share with other employees. Before an uploaded file is published, the application will attempt to render it and display it through a flash object on the page. After some promising initial tests with normal Microsoft Office documents, we determined this required a deeper look for XXE potential.

The payload used first defined an XML entity with a path to a local file on the operating system, then use an external entity to send an HTTP request to our external server. Our server would reply with a document type definition (DTD) that would then instruct the application server to send the previously defined entity pointing to the local file back to our external server using FTP. This was generated using a program “oxml_xxe” (https://github.com/BuffaloWill/oxml_xxe) and our target was “file:///etc/passwd”.

On our XXE server, written by Rhino Security Labs researchers, we setup  an HTTP listener on port 80 and an FTP listener on port 8080, ready to correctly handle the incoming requests. The DTD that we used was as follows:

Although there didn’t seem to be much recent activity on our target application, we decided to upload a “Hidden” file, as to not expose the word document to all users of the application. One feature of Jive-n is the ability to preview an uploaded file before publishing it. The application does this by using Flash to try and render Microsoft Office documents in the browser after they are uploaded, including Word, Excel, and PowerPoint.

Initially, we uploaded our document and used the “Save Draft” function in the hope that Jive-n would then attempt to render the document. The render step failed, but, Jive-n did display an error message, as well as an option to “View” or “Download” the file.

Typically, this is where one would assume that the XML was parsed, and the payload was executed, but we found that this was not the case. In fact, we didn’t receive a request on our server until we clicked the “View” option in the screenshot above. After clicking it, the payload was executed, and the contents of the file were sent to our XXE server.

In the screenshot above, three events have taken place.

• The content in the blue box is the initial HTTP request that the application server made to our server.
• The content in the green box is the data that our server responded to that request with.
• The content in the orange box is a small portion of the data that was sent to us over the FTP connection.

We also confirmed that by requesting “file:///etc/”, we were able to retrieve a directory listing of the “etc” folder.

Jive-n administrators have the option of implementing an anti-virus for the files that are being uploaded, but this approach has not been tested to see if this would catch our specific payload. It’s possible that the anti-virus would detect an outbound connection being made, an operating system file being read, or that the FTP protocol is being used. With an anti-virus in place and by disabling XML external entities, this attack can be mitigated.

We would like to thank Aurea (the parent company of Jive Software) for their quick and effective triage to fix this issue. We also requested a CVE for the vulnerability, reserving CVE-2018-5758 while the Jive team worked on their mitigation.

1/17/2018 – Rhino Security Labs initiates contact with Aurea.

1/18/2018 – Aurea acknowledges contact and requests details to begin an investigation.

1/18/2018 – Rhino Security Labs fully disclosed the vulnerability to Aurea.

1/19/2018 – Aurea confirms receipt of information and begins to research the vulnerability.

2/9/2018 – Aurea informs Rhino Security Labs of the remediation steps and plans they have in place. We mutually agree on a plan for public                                      disclosure.

Aurea informed us that the latest SaaS version of Jive-n had inadvertently addressed the XXE injection in a separate patch, disabling access to remote DTDs. As a result, every customer using the SaaS version of Jive-n is no longer vulnerable to the exploit, because the XML interpreter being used would no longer process external entities.

For customers using the on-premise version, updating to the latest version of Jive-n (or even just the uploader component) will address the issues listed here.  Separately, Jive security noted that the Jive-n file uploader and Microsoft Office document renderer could both be firewalled to block its access to the remote DTD and prevent this attack.