XXE in the era of JSON

How we compromised the web-server of a cyber security startup

This case study is dedicated to an XXE vulnerability we found in a cyber security start up
company during one of many offensive security assessments we performed this year.

Case Study XXE in the era of JSON

The Challenges


What is XXE? 

XXE Injection is a vulnerability that exists in XML files – once the server receives XML content and parse it, it may also parse XML External Entities (XXE), which is very dangerous since those entities may request resources outside the XML content (hence called External Entities).

If we identify this vulnerability, the damage of XXE is devastating as the impact on the application is high. It can lead to several different ways of exploitation such as: 

  • Remote Code Execution    

  •  Local File Inclusion  

  •  Server-Side Request Forgery    

  •  Denial of Service

Is XXE dead in 2022?

Most people think that an XXE vulnerability is a thing of the past. And, like the dinosaurs, it has been extinct from the internet since JSON overtook XML for the reasons above.

Because XXE is supposed to be “extinct”, new developers or developers without a security- oriented mindset might not be aware of the vulnerability’s existence.

So, even though people believe it is extinct, we still see it alive and kicking because XML is still in use. However, since XXE is a powerful vulnerability for attackers to take advantage of, it will not disappear until there is a better way to do what it does.

Finding the XXE and exploitation

The platform offered the ability to extract data from an external connection – such as a DB existing in a remote server.

At this point, things got interesting. After playing with some of the configurations in this feature, we found that the data returned from the external server is, by default, JSON. However, a functionality allows the content received to be in XML format instead of JSON – which immediately opened the door for an XXE Injection.

Our team initialized a server and configured it to send an XML file containing a malicious XXE Injection.

When the customer’s server fetched data from our malicious server, it parsed the XML content with the XXE Injection containing an LFI (Local File Inclusion) on the server’s file system. 

As our customer’s server failed to construct data from the malicious XML content, it sent an error message containing our malicious XML content, thus allowing us to view the file we requested. 

At this juncture, we had written a Python script fetching every file from the client's server, compromising the entire file system– from sensitive files such as those containing cloud tokens and sessions to server configuration files.

The server used Java’s XML parser. “Fortunately,” this parser is also vulnerable to directory listing – a vulnerability that allows an attacker to view the content of directories on the file system.

The outcome?

Full access to the File System.

Following the trend of moving to the cloud, a leading provider of web authentication solutions wanted to offer a SaaS solution in addition to the more mature on-premises one they currently offer. 

Since security-aware organizations (Fortune 500 companies) have implemented the solution, it is validated by security teams all year long, compelling the vendor to maintain a high standard of security in the application and system. However, despite the trust they have in their security posture, the security team wanted to conduct a test to verify that moving to the cloud does not pose new threats that were previously irrelevant. 

Our team detected an XXE vulnerability that only an admin could exploit (In the previously on-premises version). An admin must connect the system to a backend service that responds with an XML format, including an XXE payload. 

When deploying the system on-premises the likelihood and implications of such a scenario are negligible. However, deploying it on the cloud would enable a malicious tenant to take control of the system, deeming the entire solution hackable.

XML has been around for much longer than JSON, and as such, has a well-established ecosystem. It's easy to find tools and libraries for working with XML, and it's well-suited to more complex data structures. However, XML can be verbose and difficult to read, making it less than ideal for smaller projects. 

JSON, on the other hand, is a newer format that is designed to be lightweight and easy to read. One important consideration is security. XML is vulnerable to a type of attack known as XXE.