Tara Seals | Threatpost.com »
A malicious website or malicious ad can trigger an exploit for the IE zero-day bug, opening the door for data theft and code execution, new analysis notes.
New details have emerged about an unpatched security vulnerability in Microsoft’s Internet Explorer that was recently used in a complex campaign against security researchers. A fresh analysis from 0patch offers further insight into where the bug exists and how it can be triggered in real-world attacks — notably, by just visiting a website.
In early February, cybersecurity researchers at South Korean consultancy ENKI identified a zero-day exploit that it said was used in the researcher attack. The vulnerability in question exists in Microsoft Internet Explorer, and at the time of writing remains unpatched, though Microsoft said it was looking into the bug report.
The attack on researchers had come to light a few days earlier. That campaign, detailed by Google’s Threat Analysis Group (TAG), involved hackers likely linked to North Korea who carried out an elaborate social-engineering effort to set up trusted relationships with security firms. The end goal was infecting these organizations’ systems with custom backdoor malware.
The effort included attackers going so far as to set up their own research blog, multiple Twitter profiles and other social-media accounts in order to look like legitimate security researchers themselves who were looking to “collaborate.”
At the time, TAG noted that it couldn’t determine the mechanism of compromise, and it asked for help from the greater security community.
Microsoft IE Zero-Day Discovered
ENKI heeded that call. It was one of the targeted firms, and when the attackers sent researchers there an MHTML file, under the guise of helping with security research, the firm discovered an embedded malicious exploit for a previously unknown flaw.
Delivering the exploit in an MHTML file does ensure recipients would open it in Internet Explorer, which is registered to open this file type, according to researchers at 0patch, which released an additional analysis of the bug on Thursday.
“While this delivery method required recipients to confirm a security warning about executing active content, the exploit could be delivered without such warning if the victim visited a malicious web site with Internet Explorer,” according to the posting.
Microsoft has acknowledged ENKI’s report and issued a short statement: “Microsoft has a customer commitment to investigate reported security issues and we will provide updates for impacted devices as soon as possible.”
Microsoft didn’t immediately respond to a request for an update from Threatpost. No CVE has yet been assigned.
More Technical Details Come to Light
In breaking down ENKI’s (non-public) proof-of-concept (PoC) exploit, researchers at 0patch were able to uncover more details on the bug.
ENKI’s original analysis did offer some insight on this front:
“Due to the double-free bug, alloc1 and alloc2 functions use different types of objects, but they allocate data to the same memory address space, thus obtaining a Type Confusion condition,” the firm explained in early February. “To execute additional attack code, the attacker creates a Fake ArrayBuffer with buffer address 0x0 and size 0x7FFFFFFF, and then creates a DataView object that can read and write the entire user space memory of the process.”
Neither firm has published exploit or PoC code and won’t until the bug is patched. But 0patch researchers did say that the “root of this vulnerability is not new.”
They explained, “it’s about tricking the browser to delete an object that has already been deleted in some unexpected way that existing sanitization checks don’t notice. In this case, it’s about deleting a node value of an HTML Attribute. The trick is to create an attribute, assign it a value that is not a string or a number, but an object (why is this even allowed?) – then when deleting this attribute, said object makes sure that the attribute is deleted before it gets deleted, so to speak.”
Executing Native Code for Spying
Researchers at 0patch also disclosed additional details on how the bug could be weaponized.
They found that simply opening a malicious website would automatically result in native code execution inside Internet Explorer’s render process. The exploit could also be triggered via a benign website hosting a malicious ad, according to the analysis which opens up several avenues of attack.
Internet Explorer’s render process runs by default in Low Integrity mode, which means that the executed code could read any data from the computer and network that the user can access, ultimately sending it to the attackers in the background, according to 0patch.
“An additional vulnerability would be needed to escape the Low-Integrity sandbox and achieve a long-term compromise of the computer,” researchers explained.
The potential impact of an exploit could be significant, researchers cautioned: “While Internet Explorer is not widely used for browsing websites anymore, it is installed on every Windows computer and (a) opens MHT/MHTML files by default, (b) is being used internally in many large organizations, and (c) executes HTML content inside various Windows applications.”
Fixing the Microsoft IE Zero-Day
0patch has issued a free micropatch to plug the security hole ahead of an official fix. It admitted that it took a different approach from what the Microsoft patch will include.
“We decided to break the obscure browser functionality that allows setting an HTML Attribute value to an object,” researchers said. “We assess this functionality to be useful to very few web developers whose apps are supposed to work with Internet Explorer.”
Microsoft on the other hand “will probably fix the way the attribute node is deleted so that it doesn’t actually get deleted while references to it still exist,” according to the post. “We decided that such approach would simply require too much time for us and would introduce an unnecessary risk of breaking something.”
No one has detailed exactly which Windows or Internet Explorer iterations are vulnerable, a possible clue lies in the Windows versions addressed by the micropatch (32bit and 64bit): Windows 7, Windows 10, Windows Server 2008 R2, Windows Server 2016 and 2019.
“When the social-engineering attack against security researchers by malicious actors out of North Korean was reported in late January 2021, it seemed likely there was more to the effort than was currently known or reported,” Saryu Nayyar, CEO at Gurucul, said via email. “The report by ENKI that the attackers were leveraging a zero-day exploit in Internet Explorer reinforces that assumption. As the extent of the attack becomes more evident more of the techniques they used, including more new exploits, will come to light.”
She added, “With what is already known, it is apparent that even the most experienced security researchers need to remain vigilant. While they have a great deal of knowledge and experience, the attackers are well resourced with new exploit vectors and the skill to create very convincing hooks.”
External Link: https://threatpost.com/exploit-details-unpatched-microsoft-bug/164083/