Exploiting a Microsoft Edge Vulnerability to Steal Files

One thing that's often overlooked in new development projects is the knowledge gained from years of small security fixes on the original product. Those experiences with the inner workings will know that your team would probably initially get more wrong than right during the process of developing a new browser today.

The reason for this is that browser security is under constant redevelopment as new hacks arise, since browsers are viewed as one of the richest sources of potential attack surfaces by hackers and security professionals alike. Small security holes that are used to lead to the leakage of user data in browsers have been resolved over the years. Some were more severe than others, but most of them weren't immediately obvious in the first place. It is these security fixes, and the knowledge that comes with it, that may get lost when redesigning a web browser.

That might explain why Microsoft Edge was the only browser I found to be vulnerable to this flaw.

Note: this vulnerability has already been fixed by Microsoft.

Who Is at Risk From This Microsoft Edge Vulnerability?

I've successfully tested my exploit on Microsoft Edge 40.15063.0.0.

How Can You Steal My Local Files?

Let's first think about why I shouldn't be able to steal your local files!

The Same Origin Policy (SOP) would prevent the https://attacker.com from reading the file://C:/your/stuff.txt, for example. The reason is that they have different origins. In order to read data using a JavaScript-issued request, the protocol, the hostname, and the port need to match. However, file URLs are a little special. The file:// protocol and the https:// protocol are obviously different, which is why attacker.com can't read your local files.

But, what if we're dealing with two file URLs? Neither have a hostname or a port, right? They only have the file protocol scheme and a path. This means that the two file URLs would automatically be from the same origin, because:

• The port matches — both have no port
• The hostname matches — there is no hostname on both of them
• The protocol scheme matches — both use the file:// scheme

In other words, if the browser developers wouldn't take the special format of file:// URLs into consideration, it would be possible for me to read the content of any local file, if you simply opened a malicious HTML file saved on your machine!

You might conclude that this is not a very convincing attack vector, perhaps, because you've never downloaded a random HTML file. In addition, Windows might block the file that you just downloaded, since it came from another computer. At least, this was the case when I tested the attack.

Is This a Realistic Threat? Or, Is It a Theoretical Scenario?

Do you think an attacker could somehow convince a potential victim to download an HTML file and execute it?

Due to the existence of another attack vector, it turns out that this is not merely a theoretical scenario. If you can't deliver your HTML file through the browser, why not simply mail it to your victim? In the last few years, we've become all too cognisant of the fact that it can be a verey bad things to open unknown attachments such as .exe files, .js files, and even Word documents. But, HTML files? There is no obvious immediate danger. After all, we request many HTML files in our browsers every day.

I drafted an email from another computer, added the file as an attachment, and, then, opened the attachment in the Mail and Calendar app. Much to my surprise, it worked. I expected that the app, like the Edge browser, would block the attachment. But, this was not the case at all. When I sent the email as an attachment and waited until a user opened it, it would immediately send local files of my choosing to my server, where I could store and read them. There is probably no antivirus program that would recognize my file as malicious, and, I could extract the files over a secure HTTPS connection. This is what makes this attack so stealthy! The Windows Mail and Calendar version is where I tried — my exploit was version 17.8600.40445.0 (this bug was reported too).

But, there are other ways to deliver the file, depending on the target's installed programs.

How Can I Protect My Files?

The only way to protect yourself is to update to the latest versions of the Edge browser and Windows Mail and Calendar applications. And, of course, it's best to never open attachments from unknown senders, even if the extension doesn't initially appear to be malicious.

But, this was a very theoretical post. If you want to see my exploit in action, you can watch my proof of exploit video.

Proof of Concept Video of the Attack

If you think this was a very theoretical post, see my exploit in action in this proof of exploit video.

Code for Exploiting the Edge Vulnerability

Below is also the code that the hacker can use in the HTML file to exploit this Edge vulnerability.

<html>
<head>
<script>
let resultDiv = document.getElementById("result");
    let xhr= new XMLHttpRequest();
    let user = document.location.href.match(/file:\/\/\/C:\/Users\/([a-z0-9\-]*)\//i)[1];
    xhr.open("GET",'file://C:/Users/${user}/Desktop/secret.txt");
    xhr.onreadystatechange = ()=> {
     if(xhr.readyState==4) {
     resultDiv.innerText = xhr.responseText;
     }
    }
    xhr.send();
</script>
</head>
<body>
</body>
<div id="result"></div>
</html>