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.
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.
High
Product Vendor |
Product Name |
Affected Version |
Zamzar |
Zamzar API | N/A |
Product Description
The Zamzar API is an online file conversion utility. The project’s official website is Zamzar.com.
One vulnerability was identified within Zamzar API:
SERVER-SIDE REQUEST FORGERY (SSRF)
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.
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.
CVE ID |
Security Risk |
Impact |
Access Vector |
N/A | High | Code execution, Information disclosure | Remote |
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
object in the xlink:href
portion of the file. To demonstrate this issue, an ODT file was generated with a custom text section that requested the content of text:section
:https://ifconfig.me
text:section text:name="string"> <text:section-source xlink:href="https://ifconfig.me" 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
was included with the public IP address in the PDF file, as shown in the figure below:https://ifconfig.me
FIGURE 2 – Response from https://ifconfig.me
This vulnerability was tested further to determine if file URIs were also supported. The
object in the text section was changed to point at the xlink:href
file instead of a URL. The result of that request is shown below:/etc/passwd
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
, 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./var/lib/mlocate/mlocate.db
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.
8240 S. Kyrene Rd.
Suite A113
Tempe, AZ
85284
United States