How I got the Bug Bounty for XSS


Last week 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 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 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 JavaScript Injection. An input to the 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:;%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.


Author: Frans Rosén