Microsoft’s "Crazy Bad” Zero Day

Monday, 15 May 2017 02:31 AM

User Rating: / 1PoorBest

Although not new news Microsoft’s recent Zero Day event which could have had mind numbingly bad consequences. That being said, Microsoft’s response is a great illustration of how the system should work. One must tip one’s hat to the response which has historically, and not just by Microsoft, been poor in general. Briefly, members of Google’s Project Zero team, a team dedicated to rooting out potentially exploitable flaws in products that are used by Google’s clients across the board, discovered a vulnerability in Windows Defender. The vulnerability was deemed rather colorfully as “crazy bad” by Tavis Ormandy, one of the vulnerabilities discoverers.

The Vulnerability

Not only was the vulnerability described as “crazy bad” but it was also deemed by Tavis Ormandy to be “the worst Windows remote code exec [execution flaw] in recent memory.” via his Twitter posts pertaining to the discovery. The Zero Day termed CVE-2017-0290 was discovered by Tavis Ormandy and Natalie Silvanovich in the Microsoft Malware Protection Engine. The engine, known simply as MsMpEng is overprivileged and unsandboxed according to Google’s Project Zero. What is even worse is that the MsMpEng is accessible remotely through other Windows services such as Exchange and the IIS web server.

Due in part to the overprivileged and unsandboxed Javascript interpreter of the engine attackers could attack systems via methods other than email, including instant messaging. The attack could be done by crafting a file directly to the mpengine. This would enable the attacker to succeed without any user interaction with the malicious file as the engine analyses file system activity. This lead the discoverers to conclude after analysis that “So writing controlled contents to anywhere on disk (e.g. caches, temporary internet files, downloads (even unconfirmed downloads), attachments, etc) is enough to access functionality in mpengine” and that “MIME types and file extensions are not relevant to this vulnerability, as MsMpEng uses it’s own content identification system”. As serious as the above sounds, the vulnerability offers an incredible vast attack surface that could include components such as executable packers, cryptors, interpreters, and system emulators that are accessible remotely.

The researchers discovered this by writing a tool to access NScript via the command shell. What occurred was the engine failed to validate message properties from an object before passing through to a runtime state. An attacker could then take advantage of this confusion and pass arbitrary objects to runtime. To make matters worse this vulnerability was declared by the discoverers to be a vulnerability on all modern Windows systems. Meaning that the following are all affected: Microsoft Forefront Endpoint Protection 2010, Microsoft Endpoint Protection, Microsoft Forefront Security for SharePoint Service Pack 3, Microsoft System Center Endpoint Protection, Microsoft Security Essentials, Windows Defender for Windows 7, Windows Defender for Windows 8.1 and RT 8.1, Windows Defender for Windows 10, Windows 10 1511, Windows 10 1607, Windows Server 2016, Windows 10 1703, and Windows Intune Endpoint Protection.

The Redmond Giant Responds

Windows, in what is the industry equivalent of light speed, responded with a patch in less than 72 hours. One cannot overstate how significant this response time is. Using the “responsible disclosure” protocol, Google’s Project Zero confidentially disclosed the vulnerability to Microsoft. According to this protocol, Microsoft would have 90 days to respond. Microsoft’s response was significantly shorter. After the 90 days, the organization which discovered the zero-day flaw can go public with the knowledge. Often this 90-day disclosure is not met further making systems vulnerable. That is why Microsoft’s quick response time is most refreshing. Granted the flaw was incredibly serious in nature but such a response time is unheard of. In fact, it left many experts within the industry most impressed. Tavis Ormandy even went to Twitter to congratulate those in responsible within Microsoft, stating “Still blown away at how quickly @msftsecurity responded to protect users, can't give enough kudos. Amazing.”

In stark contrast, February this year a vulnerability was released into the wild as Microsoft failed to release a patch in three months since been notified. US-CERT confirmed at the time that “a memory corruption bug in the handling of SMB traffic, which may allow a remote, unauthenticated attacker to cause a denial of service on a vulnerable system”. US-CERT continued to say, “Microsoft Windows fails to properly handle traffic from a malicious server. In particular, Windows fails to properly handle a specially-crafted server response that contains too many bytes following the structure defined in the SMB2 TREE_CONNECT Response structure… By connecting to a malicious SMB server, a vulnerable Windows client system may crash (BSOD) in mrxsmb20.sys. We have confirmed the crash with fully-patched Windows 10 and Windows 8.1 client systems, as well as the server equivalents of these platforms, Windows Server 2016 and Windows Server 2012 R2.” It was advised at the time to block outbound SMB connections, TCP ports 139 and 445 and UDP ports 137 and 138 from the local network to the wide area network. Microsoft only corrected the flaw when it released a series of updates close on four months after the discovery. The above illustrates how best practices and protocols are not always followed, leaving the public vulnerable to attack.

Microsoft issued an automatic update which would be rolled out to all affected platforms within 48 hours on May 9. Thus, without many users realizing it the flaw was corrected. Microsoft also made a manual update available almost immediately for those wishing to fix the potential problem faster. It is further advised to admins and other users that they should verify that version 1.1.13704.0 of the engine is running.

Complex programs will also generate bugs, bugs which could be maliciously exploited by hackers, cyber criminals, and for espionage purposes. This is just a reality of our digital age. While Microsoft and other organizations have not been terribly proactive in patching up vulnerabilities in this instance both Microsoft and Project Zero deserve to be congratulated. Working in collaboration and appreciating the seriousness of the bug helped to keep crisis at bay.