Microsoft Edge and Internet Explorer Zero-Days Allow Access to Confidential Session Data

by Kassiane Westell

On March 30th, security researcher James Lee disclosed information on two zero-day vulnerabilities present in current versions of Microsoft Edge and Internet Explorer. These vulnerabilities make it possible for confidential information to be shared between websites.

A flaw in the same-origin policy for these web browsers, called an Origin Validation Error (CWE-346), allows JavaScript embedded in a malicious web page to gather information about other web pages the user has visited. If a user visits a malicious page via a Microsoft Edge or Internet Explorer web browser, these vulnerabilities may be used to relay sensitive information about the client’s browser session back to an attacker. Lee has shared a simple proof-of-concept (POC) for each vulnerability.

How same-origin policies work

To illustrate the same-origin policy, visualize a scenario where an attacker wishes to gain access to a client’s banking information. The attacker tricks the user into visiting the site “hxxp://www.attack1.com,” which has JavaScript embedded in a malicious webpage that can supposedly access all the session IDs currently stored in the client’s cache. In particular, this maneuver attempts to expose an online banking session a user is running with “hxxp://www.trustedbank.com”.

A same-origin policy within the client’s browser should prevent the script on “attack1.com” from accessing information from “trustedbank.com” because the bank and the attacker’s webpage have different origins. Thus, the client’s banking information is not exposed to the attacker, and the client remains safe.

Analysis of the attack

Unfortunately, in the case of these vulnerabilities, an attacker can bypass the same-origin policy in Microsoft Edge and Internet Explorer.

Accessing a crafted website with the malicious script provided via a vulnerable browser (Internet Explorer in this case) yields the following result:

Figure 1. Pop-up caused by POC being accessed by client through Internet Explorer.

In this case, a proof-of-concept webpage hosted on “pwning.click” redirects to the search engine “bing.com.” If the same-origin policy in Internet Explorer — the browser being used by the client — was working properly, then the embedded JavaScript would only display information from pwning.click. Shockingly, the pop-up displays information from the search results of bing.com.

The browser is not restricting information about the website redirection properly, and instead allows pwning.click to access information about the client’s activities on other websites. In a malicious attack scenario, the attacker could also receive the information directly. There would be no pop-up and the user would be unaware of any compromise.

The images below show the traffic captures of the POC being accessed by Internet Explorer and Microsoft Edge:

Figure 2. Traffic capture of POC accessed using Internet Explorer, which James Lee made public.

Figure 3. Traffic capture of POC accessed using Microsoft Edge, which James Lee made public.

The line “performance.getEntries(“resource”)[index].name” is the important part of this POC. This line in the embedded JavaScript is accessing the name of the resolved URL of the requested resource through Javascript’s Performance API.

Performance.getEntries(<entryType>) will return a list of PerformanceEntry objects with the attributes seen below in Figure 4. An updated list of valid entryTypes can be found here.

Figure 4. List of PerformanceEntry object fields found here

Note that performance.getEntriesByType(“resource”)[index].name is simply performance.getEntries for Internet Explorer, thus the technical explanation is essentially the same.

The URL in the popup in Figure 1 is not equivalent to the embedded origin, which shows that the attacker has successfully bypassed the same-origin policy in the browser and accessed a resource that should have been restricted.

The attacker now has access to any information stored in the URL, even if it is supposed to be hidden. Examples of vulnerable information that might be stored in the URL include cookies, sessionIDs, usernames, passwords, and OAUTH tokens, either in plaintext or hash form. OAUTH is a way of authorizing third party applications to login to users’ online accounts, and has a history of being abused. Any sensitive information included in the URL of a website could be collected using these vulnerabilities.

Putting these vulnerabilities in perspective, recall the failed attack scenario. If the attacker could bypass this same-origin policy and gain access to confidential information exchanged between user and “trustedbank.com,” the user’s online banking account could be compromised. The attacker would be able to impersonate the client and gain access to the client’s personal information for online authentication, which could have devastating effects.

How to safely browse the web

This vulnerability is potentially very serious, since it can expose aspects of confidential browsing sessions to malicious servers. There is currently no information on when Microsoft will provide a fix for this threat, making this a high-risk scenario for end users. One solution would be to stop using Microsoft Edge and Internet Explorer until the bug is fixed.

The Trend Micro Deep Security platform and Vulnerability Protection can protect user systems from any threats that may target the vulnerability detailed above via the following DPI rules: