Attacks/Breaches
8/14/2013
05:13 PM
Gunter Ollmann
Gunter Ollmann
Commentary
Connect Directly
RSS
E-Mail
50%
50%
Repost This

The Increasing Failure Of Malware Sandboxing

Virtualization limits of sandboxes impede threat detection

The past three years have seen many organizations adopt and deploy in-house dynamic sandboxing technologies tasked to detect and block specific classes of malware. Most advocates of the approach will point to malware samples that were detected via the sandbox, but missed by conventional antivirus signature systems, and seek to justify the investment through these simple metrics.

A well maintained sandbox system - capable of launching a dozen or more virtual systems running a vanilla Microsoft Windows installation - is sufficient enough to detect a high percentage of the mainstream malware in circulation, and is perfectly suited to detecting serial variants generated by popular malware construction kits (assuming that no anti-virtual machine evasion code has been included).

Organizations that have deployed the myriad of commercial malware sandboxing appliances have, after a year of observing their operation, increasingly come to ask two important questions. Are the malware I'm capturing really a threat to my business, and why haven't the number of infected devices I detect weekly gone down?

The answers to both questions are closely related.

Because the sandboxing appliances must operate multiple virtual machines, they are restricted to virtualizing specific operating system images. Some appliances come with a default set of ISO images (typically Windows XP SP3 with a suite of common business applications), while others allow you to run a 32-bit corporate "Gold Image". The latter ISO image type is much preferred, as it more adequately represents an organizations desktop environment.

If your organization has deployed Apple, Android, Linux or other non-Windows legacy devices, or is running 64-bit systems, then it's unlikely that your sandbox is doing anything meaningful against threats that target those operating systems. The same applies to the applications your organization installs (or allows to be installed) on corporate systems. If a malware sample exploits vulnerabilities in a specific piece of software and that software isn't included in the ISO image you're running in your sandbox, then of course it'll pass through undetected.

I'm reminded of Gartner's Hype Cycle and the "trough of disillusionment" after a much hyped technology is finally deployed and reaches an operational status. For years now anti-malware sandbox vendors have been touting the approach as a solution to targeted attacks and APT's yet, with even a basic understanding of how these various sandbox technologies operate, it should be obvious what their detection limits are likely to be.

The sandboxing appliances popularly deployed today are performing well against your average"0-day" malware threat, but capabilities decline dramatically the more targeted an adversary becomes. As such, organizations are much better at stopping the generic non-targeted "Internet threats", but becoming more vulnerable to marginally tuned malware. For example, any piece of malware that requires the user to perform an action at a specific time (before it acts maliciously) is sufficient to evade detection in most cases.

Incident response teams and others tasked with malware investigation within large corporations appreciate the fact that sandboxing approaches are helping to keep the mainstream malware "noise" out of their enterprise networks, but are struggling in their communications to upper management the fact that these recent protection investments have had little effect against espionage and other targeted malware attacks.

Until such time that sandboxing technology can virtualize every hardware platform or device used within an organization, emulate every programming or scripting language present on the desktops or BYOD gadgets that employees chose to bring to work, or execute every version of software application used within a particular business, then you're going to have to keep on investing in technologies and resources capable of detecting and mitigating non-generic Internet threats.

Even if that was possible, malware sandboxing approaches will only capture the threats that come in through the front-door -- not threats that get transported between networks via roaming devices. So, as business operations embrace the cloud, BYOD, VPN dual tunneling, and expand their home-office workforce, centralized sandboxing approaches will rapidly diminish in efficacy -- and malware authors continue to have the upper-hand.

Gunter Ollmann, CTO, IOActive Inc. Gunter Ollmann serves as CTO for IOActive Inc. where he is responsible for the strategic vision of the security services portfolio, driving new research areas and bringing new services to market. With over two decades in the information security arena, Gunter has stared down ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Robertd725
50%
50%
Robertd725,
User Rank: Apprentice
8/27/2013 | 1:22:54 PM
re: The Increasing Failure Of Malware Sandboxing
The point on fixed application stacks is absolutely correct. Extending the point to mobile devices is less. Larger enterprises worry more about sensitive data leakage from mobile devices than mobile devices becoming an attack vector to their wired networks. These are protected by the multiple wired security enforcement points that have been deployed over the years (within the limitations of their signature and fixed stack sandbox based solutions.
DamianoB592
50%
50%
DamianoB592,
User Rank: Apprentice
8/15/2013 | 9:55:38 PM
re: The Increasing Failure Of Malware Sandboxing
I don't fully agree with this phrase "malware sandboxing approaches will only capture the threats that come in through the front-door" - is it a problem of placing the sandbox probe in the right spot or a technological issue? I would rephrase it in "malware sandboxing will only detect mainstream malware", but I wouldn't point at the "placement issue" as the main motivation for failing.
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2011-3154
Published: 2014-04-17
DistUpgrade/DistUpgradeViewKDE.py in Update Manager before 1:0.87.31.1, 1:0.134.x before 1:0.134.11.1, 1:0.142.x before 1:0.142.23.1, 1:0.150.x before 1:0.150.5.1, and 1:0.152.x before 1:0.152.25.5 does not properly create temporary files, which allows local users to obtain the XAUTHORITY file conte...

CVE-2013-2143
Published: 2014-04-17
The users controller in Katello 1.5.0-14 and earlier, and Red Hat Satellite, does not check authorization for the update_roles action, which allows remote authenticated users to gain privileges by setting a user account to an administrator account.

CVE-2014-0036
Published: 2014-04-17
The rbovirt gem before 0.0.24 for Ruby uses the rest-client gem with SSL verification disabled, which allows remote attackers to conduct man-in-the-middle attacks via unspecified vectors.

CVE-2014-0054
Published: 2014-04-17
The Jaxb2RootElementHttpMessageConverter in Spring MVC in Spring Framework before 3.2.8 and 4.0.0 before 4.0.2 does not disable external entity resolution, which allows remote attackers to read arbitrary files, cause a denial of service, and conduct CSRF attacks via crafted XML, aka an XML External ...

CVE-2014-0071
Published: 2014-04-17
PackStack in Red Hat OpenStack 4.0 does not enforce the default security groups when deployed to Neutron, which allows remote attackers to bypass intended access restrictions and make unauthorized connections.

Best of the Web