Complex libraries lead to hidden attack vectors

This is an inspiring story for all bug bounty hunters of how a SSRF vulnerability was discovered in Slack, along with potentially many other web applications, by Brett Buerhaus, Cody Brocious, Sam Erb, and Olivier Beg’s. I will be detailing a more user-friendly version of their detailed “A Tale of Exploitation in Spreadsheet File Conversions,” and all the material I’m presenting is sourced from Brett’s writing. I highly encourage the read for the more technical details.

I will also include the message from Slack regarding the vulnerability for transparency

Slack would like to thank the researchers for their work to increase the security of the open source tool LibreOffice and their responsible disclosure to Slack. The security of file sharing is critically important to Slack and its users, and we worked with the research team to quickly implement a fix within 24 hours of receiving the report. Slack has confirmed that no customer data was accessed using this bug. (source: A Tale of Exploitation in Spreadsheet File Conversions by Brett Buerhaus and co.)

The team started by doing initial reconnaissance by performing a cybersecurity technique called fingerprinting. Fingerprinting is essentially the term used to gather specific information about a system to try to identify what types of programs, services, OS, etc. is being used by that system. Here is a good link to learning more about fingerprinting.

In this case, the team was looking to see what software was being used to process spreadsheets (i.e XLSX files). The following method was used:

You can use this on your applications to see what happens! Additionally, the team noted that if raw PDFs were returned, the metadata included could identify the program used to process. Excel is the well-known Microsoft spreadsheet processor. LibreOffice is a free spreadsheet processor that used to be known as OpenOffice.

Using this process, the team was able to identify that Slack was an application that used LibreOffice… by accident! The team was not initially testing Slack, but through sharing their own files on Slack, they then realized that Slack was also using LibreOffice to process files.

LibreOffice Exploit 1: EPFS and PostScript/GhostScript

The team noticed that LibreOffice handles EPFS files. These files are usually passed on to another program/system called PostScript/GhostScript in order to be interpreted, and there have been several vulnerabilities reported having to do with this file processing, which is often executed automatically. For example, this Github goes over an RCE vulnerability in a certain python library when processing EPFS.

The team was able to develop a successful EPFS payload (link here to the code with specific credits given to Cody Brocious) for local file inclusion. There is some nuance to using this payload that is highlighted Brett’s pieces that makes it such that it doesn’t work each time.

This exploit seems to have worked on some applications, but it did not work on Slack. However, this didn’t stop the team.

LibreOffice Exploit 2: Remote OLE Object xLinking

With further testing, the team determined that LibreOffice documents could be embedded with OLE objects, which stands for Object Linking and Embedding. These objects allow for the smooth transition of data between different applications that support different document types. OLE objects can be extremely dangerous, and the Cybersecurity and Infrastructure Security Agency (CISA) listed OLE vulnerabilities as the most exploited vulnerability between 2016–2019.

According to U.S. Government technical analysis, malicious cyber actors most often exploited vulnerabilities in Microsoft’s Object Linking and Embedding (OLE) technology. OLE allows documents to contain embedded content from other applications such as spreadsheets. After OLE the second-most-reported vulnerable technology was a widespread Web framework known as Apache Struts. (Source: CISA Top 10 Routinely Exploited Vulnerabilities)

The team then developed an initial POC to exploit the OLE. The team had to also do some minor tweaking (details can be found in OG post) in order to fully display the results. This worked and successfully revealed secret keys in Slack!

How was the xlink-href being exploited and why did this work? The team went down several self-described “rabbit holes” to learn about the Python unoconv, or Universal Office Converter. In the PyUNO bridge, which essentially is used to make API calls to the LibreOffice commands, the code would silently update external links when doing conversions. This would essentially update untrusted links allowing for hackers to maliciously change the links to //etc/passwd and then retrieving all of that file’s contents.

For Devs:

Document parsing requires the use of external libraries, which are often large, complex and with many features that can be forgotten about or nuanced to a high degree. Be careful since many of these files can be malicious with so many different attack vectors. Make sure to sandbox this file processing as much as possible to avoid the leaking sensitive information or allowing RCE.

For Hunters:

Don’t give up! This team went through many iterations of their exploits and payloads, and they most likely went through even more than the ones they published about. When one attack vector that was proven to work in other applications failed in Slack, they continued to push on other attack vectors until they got a successful result. What was a key insight for me was that this team was not internally satisfied with simply getting an exploit to work, but also was dedicated to researching the root cause of the exploit. I highly encourage to read their full original post as I gained a lot of insight.