Update (2018-06-04): CVE-2018-8174 has been added to the Magnitude exploit kit (Source: MDNC).
Update (2018-05-25): CVE-2018-8174 has been added to the RIG exploit kit (Source: MDNC).
Update (2018-05-22): Security researcher Richard Warren mentioned that a fully working IE zero-day (now patched) with payload was uploaded to VirusTotal. We decided to test Malwarebytes against it, since last time we only had a Proof of Concept on our hands. To illustrate in how many different ways we can block this exploit, we turned off several layers of the anti-exploit protection module (not recommended, only for testing purposes). You can see the results in the animation below:
—
In late April, two security companies (Qihoo360 and Kaspersky) independently discovered a zero-day for Internet Explorer (CVE-2018-8174), which was used in targeted attacks for espionage purposes. This marks two years since a zero-day has been found (CVE-2016-0189 being the latest one) in the browser that won’t die, despite efforts from Microsoft to move on to the more modern Edge.
The vulnerability exists in the VBScript engine and how it handles memory objects. It will also affect IE11, even though VBScript is no longer supported by using the compatibility tag for IE10.
The attack came via a Word document making use of OLE autolink objects to retrieve the exploit and shellcode from a remote server. However, it is important to note that it could very well have been executed by visiting a website instead.
Perhaps one of the reasons why it was not used as a drive-by download attack may be because Internet Explorer is no longer the default browser for most people, and therefore the exploitation would never occur. However, by tricking their victims to open an Office document, the attackers can force Internet Explorer to load, thanks in part to the URL moniker “feature.”
Using rtfdump.py, we see the call for an HTTP connection:
python rtfdump.py -s 320 -H CVE-2018-8174.rtf
000014C0: 70 B2 86 8C 53 30 05 43 00 38 30 01 18 68 00 74 p���S0.C.80..h.t 000014D0: 00 74 00 70 00 3A 00 2F 00 2F 00 61 00 75 00 74 .t.p.:././.a.u.t 000014E0: 00 6F 00 73 00 6F 00 75 00 6E 00 64 00 63 00 68 .o.s.o.u.n.d.c.h 000014F0: 00 65 00 63 00 6B 00 65 00 72 00 73 00 2E 00 63 .e.c.k.e.r.s...c 00001500: 00 6F 00 6D 00 2F 00 73 00 32 00 2F 00 73 00 65 .o.m./.s.2./.s.e 00001510: 00 61 00 72 00 63 00 68 00 2E 00 70 00 68 00 70 .a.r.c.h...p.h.p 00001520: 00 3F 00 77 00 68 00 6F 00 3D 00 37 00 00 00 00 .?.w.h.o.=.7....
This remote request will download a VBS script. A Proof of Concept adapted from the blog that was published by Kaspersky can be seen below:
The flaw abused by this vulnerability relates to a reference count that is checked at the beginning of the function but not after, despite the chance of it being incremented along the way. This allows an attacker to execute malicious shellcode and eventually load the malware binary of his choice.
We tested this Use After Free (UAF) vulnerability with the publicly available PoC running Internet Explorer 11 under Windows 10. The browser crashes once it loads the VBS code, but with Malwarebytes, the attack vector is mitigated:
Microsoft has released a patch for this vulnerability, and we strongly advise to apply it, as it is just a matter of time before other threat actors start leveraging this new opportunity in spam or exploit kit campaigns.
We will update this blog if we obtain more information about this vulnerability being used widely, and in particular, if a full working exploit is available.
