Frans Rosén on how he got Bug Bounty for Mega.co.nz XSS

Last week Mega.co.nz released a Bug Bounty Program. Of course I set out to see if I could find something.

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.

Opened up Safari, called this address:

https://mega.co.nz/OneClipboard.swf?id=%5C%22));%7Dcatch(e)%7Balert(document.domain)%7D//

BAM! The injection worked, and my Javascript was executed.

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:

What can I say. Well done to you as well, Kim.