How I got the Bug Bounty for Mega.co.nz XSS

I noticed quite early in my digging that Mega had hijacked the alert-function. You could see that by typing javascript:alert(/XSS/) into the address field when you’re visiting Mega.co.nz. The confirm and prompt-functions are not affected. I also noticed that the download behaviour depending on browser were quite different. In Chrome, the download happened automatically, but in Safari, a flash-segment was visible with a “Save File”-link.

When going through their source code, I started to check if I could inject flashparams into this flash file called downloader.swf to simulate a download. I found a nice tool called JP ActionScript Decompiler that made it possible for me to examine the source code of the SWF-file. I was not able find anything insecure with the file though. However, as I was searching for what flashparams that was being used for this SWF I saw another include that took my attention:

Cool, a SWF getting the filename and saving it into your clipboard. I downloaded the SWF and opened it with ASDec. I immediately saw a ExternalInterface.call inside the constructor:

And behold, it sent the flashparam called “id” directly back to the function clipboardcopyready. I created a local testfile simulating the initiation of the OneClipboard.swf:

It worked, I got the variable back to the JS-function. Great! I started googling on how to inject code directly to the SWF without modifying any JS-function. I found an article by Soroush Dalili explaining the ExternalInterface.call() JavaScript Injection. An input to the ExternalInterface.call with a try-catch could actually trigger your own Javascript if the function that was being called did not exist.

If you’re curious about what could be done with this vulnerability, you should check out our post how to: exploit an XSS.

Anyway, I moved on to Mega’s blog to find where I should report this, a blog entry had recently been written explaining all the different levels of injections that they had, and what had been found during this week, and I noticed this:

So.. Another SWF issue had already been reported, on a SWF called ZeroClipboard.swf, almost the same as the one I found. As my injection still worked, it looked like Mega had replaced their old third-party solution for the clipboard saver with a self-written one, that had the same vulnerability.

At 10:16 PM GMT+1 I sent the report to mega.

Then I moved on to try the vulnerability on other browsers. Suddenly it stopped working, so I went back to Safari and tried it. It didn’t work anymore. The file was removed. So I sent Mega another email to Mega 10:53 telling them that the vulnerability was gone. 5 minutes later I got this:

Nice, Mega fixed it in just 35 minutes! That was the fastest fix I have ever seen and a really nice bounty for my findings. Later that night they also replaced the SWF with a fixed one, removing the id being sent back over to the JS-function. Quite impressive I must say.

Two days later, after some buzz around Mega’s Bug Bounty Program and after Adam Crouchley made an interview with me, Kim actually wrote to me on Twitter: