I tested different Outlook settings to see if that was the cause of the discrepancy, but had no success, and so the case went cold. I later learned that another researcher reported it too, but neither POC reproduced the bug for the security engineers. I sent them a video of the bug occurring. This was real and I needed them to address it. Unfortunately, the vulnerability didn’t reproduce for the engineering team. Besides, I assumed that it would be pretty easy for the app developers to take my POC and find the problem. And really, I had no experience debugging mobile apps. How could I? I don’t have access to Outlook source code. I sent this to the Microsoft Security Response Center (MSRC) on December 10, 2018.Īt this point I did not know exactly which part of the code caused the bug. It ran an arbitrary external script that stole and exfiltrated private data (although admittedly, with very limited access to email data).
Before disclosing, I created a short Proof of Concept (POC) that demonstrated my vulnerability. This was a big deal, so I needed to let Microsoft know. Weaponized, this can turn into a very nasty piece of malware. An attacker can send you an email and just by you reading it, they could steal the contents of your inbox. This code can do whatever the attacker desires, up to and including stealing information and/or sending data back out. When delivered, the mail client automatically undoes the escaping and the JavaScript runs on the client device. The server escapes that JavaScript and does not see it because it’s within an iframe. This kind of vulnerability could be exploited by an attacker sending an email with JavaScript in it. Not only that, I could send them back out to a remote attacker. My iframe JavaScript had full access to cookies, tokens and even some emails. In Outlook on the Android, there is no such restriction. But in a web browser, JavaScript in an iframe on a separate domain shouldn’t have access to the data in the rest of the page. In a web browser, it’s possible to run JavaScript code by using a URL that starts javascript. However, I was able to circumvent this by using a JavaScript URL in my iframe. With this in mind I tried inserting a script tag instead of an iframe into an email. But if an attacker could gain the ability to run JavaScript in an email, there could be a much more dangerous attack vector.
Even worse, as the iframe was not affected by the block external images setting that prevents tracking pixels and web beacons. This struck me as a problem: the ability to embed an iframe into an email is already a vulnerability.
0 kommentar(er)
