Bit9

A common theme among some of the companies we've been working with lately has been the acknowledgement that they are already hacked or infected; they just can't prove it.  This theme has been echoed by many of the conferences I’ve attended over the past few years, so maybe it is starting to sink in a little!  Regardless the source, these organizations have a common objective:  they want to locate the malware that is dodging their current defenses.

If you think about it, this is a very daunting task.  Basically the task is to narrow down a list of hundreds-of-thousands or millions of files to a subset that is questionable.  This is not too different from challenges that face other industries, like law enforcement, where they attempt to identify a thief or an organized crime gang among millions of innocent people.  So, using Parity, I’ll demonstrate how it is possible to speed this project on its way.

We’ll be relying on attributes of files that Parity gathers and makes available for reporting.  We’ll also be using some of the reporting and filtering functionality available in the solution.

First, I’ll define three categories of attributes that we’ll use in the analysis: authenticated, reasonable, and unreliable.  Authenticated attributes are either a digital certificate or a hash; attributes that are relatively irrefutable, much like a fingerprint.  Reasonable attributes are ones that are discovered by the operating system or by Parity and are accurate but not by themselves conclusive:  file path, Threat score, or file size.  Unreliable attributes are ones that can easily be spoofed in the file metadata and should not be used for making a decision:  company name, product name, or product version.

With those attributes as our framework, let’s look at some ways to narrow down our population of files.

With the Parity software, we can create baselines of our existing standard images.  I know I used to build my standard images in an offline setup so I had a reasonable degree of certainty that malware didn’t exist in my standard image.  We can then filter out all of the files that are in my baselines, assuming those are known-good files.

Next, I’ll toss out all of the files that are digitally signed.  True, malware could be signed, but I can identify all of the signed files in a different report in Parity and that would be rather trivial to spot.

I’ll also use the reasonable attribute of Threat to toss out all of the clean files.  Threat is a verification on a hash level that Bit9 has an exact copy of that file in our ParityKnowledge repository and it has checked out to be clean by all of the leading Anti-Virus scanners.

Finally, I’ll filter our all of the files larger than 1MB.  Why would I do that?  Well I took a look at over 10 million pieces of malware that we have collected for our knowledgebase, and statistically-speaking, 99% of malware over the past decade has been smaller than 1MB.  I thought that was pretty amazing, but it actually makes sense:  who wants to try and surreptitiously move a 10MB file around a network and onto hundreds of machines?

I can also filter on other reasonable attributes like Trust, file prevalence, and file path to whittle my list down further. 

In my tests, using many of the filters mentioned above, I’ve been able to pare down my population of files by 90% or more.  Does it draw an arrow and pinpoint the advanced threat?  Not at first blush, but thieves aren’t exactly lined up outside the police station volunteering their identity either. It definitely sets me up, however, to do so in a much shorter timeframe with the remaining files!

Check out this new video on YouTube by Brian Heffernan, Bit9 Systems Engineer. He demonstrates how Bit9 Parity Application Whitelisting can be used to stop the "new" DLL hijacking attacks - similar to how Bit9 Parity stops an Advanced Persistent Threat attack.

It may seem passé to be discussing an attack from 2008. Two years is an eternity in the cyberworld. But the incident discussed in a recent New York Times article (see also CNN) was a watershed moment worthy of revisiting.

In 2008, a flash drive was plugged into a laptop on an American military base. It contained the Agent.btz virus, and proceeded to propagate from device to device, machine to machine, planting its tentacles across both secure and non-secure networks within the government. Details of what information or what systems were compromised were never made public, but we know the attack was severe enough to warrant a security brief for the President of the United States. The effort to counter this attack was dubbed Operation Buckshot Yankee.

I was there, working with our government and civilian customers, when the DoD ban of all portable devices went into effect (it was later relaxed, but the initial ban was without exception across all their sub-agencies and contractors). All of the computer systems within the Defense Department were running the latest antivirus software with firewalls, intrusion detection, internet filtering, and advanced policy management settings. Millions, if not billions, of dollars had been spent on IT security. Yet one tiny device, with a payload less than 1MB, went undetected and wreaked havoc. All that money, manpower, and technology, and Uncle Sam was reduced to physically banning the use of USB sticks.

It reminds me of a Dr. Seuss story that I used to read to my kids, Yertle the Turtle. There’s a line in that story, “his burp shook the throne of the king”. One tiny turtle, at the bottom of a stack, caused the entire system to collapse. This flash drive “burp” got the attention of the highest levels of government. It’s as if a light bulb went off in the heads of the top brass, “This really happened? How could our cyber defenses be so ineffective? There has to be a better approach.”

I saw two things happen next. First, the collective recognition within the government that traditional “react-and-respond” security was ineffective against today’s cyber threats. New approaches, like the “proact-and-prevent” paradigm of whitelisting, were needed. Bit9 was already successful within the government sector, but this raised awareness to a new level.

The second thing that happened is, when the global ban of all things removable went out, the world didn’t end. It quickly evolved into more relaxed policies and selective/monitored exceptions, and it’s certainly not the ideal way I would recommend transforming a security posture. But under fire, it was necessary. The posture transformed from “let everything in and then see if it behaves badly” to “block everything until it is verified to be good”. That model has always been the way the government approaches personnel security, but it had not been applied to cyber security. People were so used to the old way of thinking about security that they feared change. This incident and the Operation Buckshot Yankee response showed that approval based protection works.

Whether you’re talking about people, or removable devices, or software, positive security is more effective than negative security.

The Zero-Days Of Summer

Summer is coming to a close and yet another “zero-day” exploit is being reported (See here and  here). It's not really a "zero-day", as it has been known for a long time; it’s more a design “quirk” or flaw in Windows, but the media likes to say zero-day, so I’ll oblige.

This one is going by the names “Binary Planting”, “DLL load hijacking”, and “DLL preloading”. According to ACROS Security, this vulnerability impacts around 200 widely used Windows applications, many of them from Microsoft. Another day, another zero-day, and the anti-malware vendors and Microsoft are forced to react, update malware signatures, and provide security updates.

This one is a little more pernicious because it involves behavior that many applications rely upon. Microsoft does not have a simple patch for this problem. Rather, they have introduced an update that allows you to create registry entries that may thwart such attacks but requires some pretty heavy lifting (i.e. forethought on the part of the system administrator to use properly). What a pain.

What is interesting is that this zero-day, almost by definition, is exactly the type of attack that whitelisting mitigates. We at Bit9 are not changing a thing in reaction to this latest vulnerability because Parity already stops it.

Let's break it down in simple terms. Most Windows applications contain or rely upon dozens of independent files. These files are dynamically loaded when the application runs – hence the term Dynamic-Link Library (DLL). (Note: Acros Security claims the vulnerability can also impact EXE and COM files, but the principle behind the vulnerability is the same.) When a Windows application loads a DLL file, if it doesn’t specify a full path to that file, Windows will search a predefined set of locations. This allows programs to use shared files in the Windows System folder or anywhere in your PATH environment variable, for example, without any heavy lifting. The application simply needs to specify the filename.

If an attacker can place a file with the same name at a search location before the legitimate version of that file, they can get their code to run – with all the elevated privileges that your application has. Essentially, this solves the second of the two key problems that an attacker must overcome: the first is that they must get their program onto your system; the second is they must find a way to launch that code, ideally bypassing any privilege restrictions. As a bonus, they get a level of stealth because you won’t see any “strange” processes running, and if you were to look at the names of the libraries loaded in memory, you likely won’t see anything suspicious.

(Note: The attacker still needs to get their file onto your system at the right location, or trick you into opening a document from a remote location where their malicious library is present. Therefore, it is likely that an effective use of this vulnerability will still involve using other exploits or social engineering as part of the attack.)

This entire problem is non-existent if you are using an advanced whitelisting solution like Parity. Parity only allows files that are approved to load; it doesn’t matter whether they are in the Windows search path or even in the same folder as a legitimate application. It’s really very simple -- even if the application (or executable) is approved, if it tries to load an unknown or unapproved library, it will be stopped.

This exploit is also a great case study on the limitations of blacklisting. Since the attack can take the form of any known filename in any possible location, there is no malware “signature” that can be used to stop it globally. Only once an instance of such an attack is discovered can a signature be reactively made. Anti-malware technologies may be able to stop some of the vectors by which the file is placed, but unless the file is known bad, its simple existence in an unexpected location is not a good enough trait to build a blacklist signature.

It's also worth noting that other reactive technologies, such as HIPS, would be equally ineffective at stopping this type of attack. A HIPS product looks for suspicious or bad network activity. So, by definition, the malware would already have to be loaded into memory and running before HIPS would be able to detect anything. Moreover, most modern attacks remain stealth, dormant or avoid suspicious network activity. They can do a lot of damage without triggering any HIPS-detectable behavior. Lastly, like anti-malware, HIPS technology is only as good as its latest rules, which need to be updated continually in response to known bad activity, bad IP addresses, etc.

If you’re waiting for your AV or HIPS vendor to fully protect you from this one, good luck.

There are still a few days left in summer. We’ll wait and see what zero-days are lurking in the shadows. But while the blacklisting vendors keep chasing their tails reacting to each new exploit, I’m thinking I might sneak in a few more days at the beach.

In my last post, I graphed the introduction of software onto a new system.  In this post, I'll graph the risk that that software poses to an environment.

By introducing an unapproved application, end users seldom realize the risk that change could have to the network.  For example, a single user introducing an alternate web browser onto their computer might have a risk profile that looks like the graph below.  By itself, a single application on a single computer does not pose a huge threat to the network (unless of course that application is malicious in nature, but we will assume for now it is not).

(You can download a larger version here:  http://bit.ly/aXBFnE )

Over time, there may be patches or updates that need to be applied to the application, and because the end user is likely the only one who knows about this application, it is up to them to be responsible for applying these patches or updates.  In an attempt to address the lack of central patching and upgrading, many products now come with self-updating functionality that will either check at runtime or on a set schedule for these files.  Unfortunately, most end users are neither aware of the importance or the urgency with which some of these patches need to be applied.  Therefore, updates get postponed, versions get skipped, and vulnerable applications grow within the network.

Now the graph will move up the risk scale a bit because there is little control over this unknown web browser and there is a level of uncertainty about its patch level.  Depending upon the application that has been installed, the responsiveness of the publisher, and the timeliness of the patches can also bump up the risk level.  For example, Secunia reports that Firefox, a very common alternate browser, had to release patches for 115 vulnerabilities in 2008 (source:  http://bit.ly/cFAA4z ).  Comparatively, Internet Explorer, which IT has a fairly good grasp over patching, suffered from 31 in 2008.

(You can download a larger version here:  http://bit.ly/biXqpK )

This issue is only compounded by the fact that not only will users install an alternate web browser, but also install games, toolbars, media players, peer-to-peer tools, and a plethora of other programs either intentionally or unintentionally.

This final graph shows the compound level of risk that multiple machines introduce when they all have unwanted programs added to them.  It is very easy to see why unauthorized software is almost more of a concern these days than malicious software.

(You can download a larger version here:  http://bit.ly/ddF79Q )

All of these programs expose an organization to increased support costs as unwanted programs conflict with business-related applications, increase re-imaging costs as the easiest and most effective way to eliminate this software from an end user’s computer is to start from scratch, and increases the risk that a computer will be compromised with an attack on a vulnerable application.

Coupled with strong written policies, it is understandable why many organizations are turning towards methods that can apply tighter control around what software end users are able to introduce onto their systems.  Without a reasonable mechanism for attempting to inventory and patch unauthorized software, the best approach for IT is to prevent the introduction of these applications in the first place.

At Bit9, we talk with customers and prospects every day about the risk that unauthorized software introduces into an environment.  Some IT folks have a difficult time presenting to senior management what the actual threat to the environment is of users introducing programs like iTunes, Firefox, or Skype. They are so commonplace that we start to get the impression that they are benign!

I've put together some charts, that could be incorporated into a presentation, to help convey the message that any unmanaged application, especially if IT is unaware that it exists within the environment, is an exposure that should be addressed.

(You can download a larger version here:  http://bit.ly/8YxzqJ )

This graph illustrates the typical introduction of new software onto a freshly imaged system.  The bane to any of us who have ever spent days or weeks creating a pristine base image!  I think the important thing to note is that much of the "software pull" that happens over the lifetime of the computer, happens relatively early.  Within hours or days of a user being issued a system, they have re-introduced their favorite chat programs, music players, screen savers, and more.  Once the user is satisfied with the state of the software, then over the coming months and years, you have blips of software packages getting installed, or a package upgrading to a newer version.

Once new unknown software has been introduced, the attack surface of that system goes up significantly.  My next post will discuss this further.

Today, Bit9 launched a migration program for customers of Cisco Security Agent (CSA) endpoint security solution, which is now scheduled for end of life. See the announcement on the Cisco website here.

Cisco customers that replace their current CSA solution will receive promotional pricing of Bit9 Parity^TM Suite that will be offered until December 31, 2010.  You can get a quote by emailing us at contact@bit9.com or filling out the form here.

This program was created in response to the many inquiries we have already received from customers looking for a replacement solution.  And Bit9 has already replaced CSA in large corporate environments.

Security and IT professionals have historically looked to CSA for:

• -  Zero-day protection against attacks for which no patch or antivirus signature yet exists;
• -  Visibility and control of applications and sensitive data against loss from users and targeted malware; and,
• -  Total security that protects systems even when users are not connected to the corporate network or computers that lack the latest patches or antivirus signatures.

Bit9 Parity offers this and more and is a reliable and proven alternative.

Organizations interested in learning more about Bit9, Inc.'s CSA migration program can visit: www.bit9.com/csamigration, where they can find case studies from companies that have already made the switch, as well as whitepapers and webcasts.

We are hosting an online data breach "roundtable" featuring Bob Russo, general manager of the PCI Council; Rich Baich, the former CISO of ChoicePoint who weathered the historic breach in 2004 and is now a partner at Deloitte and Touche; and Tom Murphy, chief strategy officer at Bit9, Inc.

Topics include the recent data breaches in the news and solutions.

To sign up, go the registration page here.