Full Report
Riot Games is a video game creator with many different websites. Because of this, there are many different endpoints that need access to metadata associated with the user. In order to do this, information needs to be shared cross-origin. Back in 2016 (and before) CORS and window.postMessage were spotty at best. What's the solution to this? easyXDM was a JavaScript library that allows for cross-origin calls while using anything that was available - postMessage, Flash LocalConnection or anything else. easyXDM had a producer and consumer model - a producer would export some JavaScript functions that another site could request. In the context of Riot Games, this was pm.html on account.leagueoflegends.com. The functions exported were as follows were get-cookies, set-cookies and send for cross origin request/responses. easyXDM webpages obtain context from a series of query parameters. It should be noted that these are ALL attacker controlled though: xdm_e: The URL to load the page if it's the consumer or the URL of the parent page if it's a producer. xdm_c: The channel to send the messages on. xdm_s: The secret to use to validate between the two parties. xdm_p: The ID of the protocol. This is incredibly scary functionality - so, how is this protected? Both the referrer header on the request and the protocols message origin would have to match an allowlist. The exploitation requires bypassing both of these protections. To bypass the referrer check, they thought about using a link on the league of legends forums. However, they wanted this to be more portable. So, they hunted for open redirect issues on allowlisted sites that were being done via JavaScript (since 301/302s from the server don't set the referrer header). When the xdm_e parameter doesn't match the referer, it will redirect. We can bypass this for an open redirect itself! They found an additional open redirect on another page as well. The origin check is validating that the message is coming from an allowlisted origin. However, when auditing the code of the library, the author noticed that HashTransport works by passing in from data a child iFrame to a parent window via the window.location.hash. But, there's a problem here: how does it know which child or subdomain sent it? It simply uses the xdm_e - which is exactly the bug we need! There's a catch though: if we set the domain to an attacker domain, our page will load but NOT from an allowlisted origin. If we use an allowlisted origin OUR page won't load. The solution? Callback hell with iFrames. At this point, we can make requests but cannot receieve responses - this leaves us with setting cookies and makes arbitrary requests using the cookies. They use this to perform XSS on the site. Overall, interesting bug in a piece of technology that became obsolete. The library maintainers didn't fix the vulnerability becaues this was considered legacy at the time of reporting.
Analysis Summary