Monday, February 4, 2013
Vulnerability Disclosures in 2012
Monday, January 7, 2013
The Demise of Desktop Antivirus
Are you old enough to remember the demise of the ubiquitous CompuServe and AOL CD’s that used to be attached to every computer magazine you ever brought between the mid-80’s and mid-90’s? If you missed that annoying period of Internet history, maybe you’ll be able to watch the death of desktop antivirus instead.
Just as dial-up subscription portals and proprietary “web browsers” represent a yester-year view of the Internet, desktop antivirus is similarly being confined to the annuls of Internet history. It may still be flapping vigorously like a freshly landed fish, but we all know how those last gasps end.
To be perfectly honest, it’s amazing that desktop antivirus has lasted this long. To be fair though, the product you may have installed on your computer (desktop or laptop) bears little resemblance to the antivirus products of just 3 years ago. Most vendors have even done away from using the “antivirus” term – instead they’ve tried renaming them as “protection suites” and “prevention technology” and throwing in a bunch of additional threat detection engines for good measure.
I have a vision of a hunchbacked Igor working behind the scenes stitching on some new appendage or bolting on an iron plate for reinforcement to the Frankenstein corpse of each antivirus product as he tries to keep it alive for just a little bit longer…
That’s not to say that a lot of effort doesn’t go in to maintaining an antivirus product. However, with the millions upon millions of new threats each month it’s hardly surprising that the technology (and approach) falls further and further behind. Despite that, the researchers and engineers that maintain these products try their best to keep the technology as relevant as possible… and certainly don’t like it when anyone points out the gap between the threat and the capability of desktop antivirus to deal with it.
For example, the New York Times ran a piece on the last day of 2012 titled “Outmaneuvered at Their Own Game, Antivirus Makers Struggle to Adapt” that managed to get many of the antivirus vendors riled up – interestingly enough not because of the claims of the antivirus industry falling behind, but because some of the statistics came from unfair and unscientific tests. In particular there was great annoyance that a security vendor (representing an alternative technology) used VirusTotal coverage as their basis for whether or not new malware could be detected – claiming that initial detection was only 5%.
I’ve discussed the topic of declining desktop antivirus detection rates (and evasion) many, many times in the past. From my own experience, within corporate/enterprise networks, desktop antivirus detection typically hovers at 1-2% for the threats that make it through the various network defenses. For newly minted malware that is designed to target corporate victims, the rate is pretty much 0% and can remain that way for hundreds of days after the malware has been released in to the wild.
You’ll note that I typically differentiate between desktop and network antivirus. The reason for this is because I’m a firm advocate that the battle is already over if the malware makes it down to the host. If you’re going to do anything on the malware prevention side of things, then you need to do it before it gets to the desktop – ideally filtering the threat at the network level, but gateway prevention (e.g. at the mail gateway or proxy server) will be good enough for the bulk of non-targeted Internet threats. Antivirus operations at the desktop are best confined to cleanup, and even then I wouldn’t trust any of the products to be particularly good at that… all too often reimaging of the computer isn’t even enough in the face of malware threats such as TDL.
So, does an antivirus product still have what it takes to earn the real estate it take up on your computer? As a standalone security technology – No, I don’t believe so. If it’s free, never ever bothers me with popups, and I never need to know it’s there, then it’s not worth the effort uninstalling it and I guess it can stay… other than that, I’m inclined to look at other technologies that operate at the network layer or within the cloud; stop what you can before it gets to the desktop. Many of the bloated “improvements” to desktop antivirus products over recent years seem to be analogous to improving the hearing of a soldier so he can more clearly hear the ‘click’ of the mine he’s just stood on as it arms itself.
I’m all in favor of retraining any hunchbacked Igor we may come across. Perhaps he can make artwork out of discarded antivirus DVDs – just as kids did in the 1990’s with AOL CD’s?
-- Gunter Ollmann
Friday, December 21, 2012
How much is a zero-day exploit worth?
There's no simple answer as I discuss the topic in my first blog posting with IOActive. You can find the discussion "Exploits, Curdled Milk and Nukes (Oh my!)" on the IOActive Labs Blog site.
Monday, December 17, 2012
Now at IOActive
The last 3.5 years with Damballa were a wild ride. My first 3 years with the company saw much innovation and cutting-edge technology making its way to the market, but as things slowed down and the business doubled down on the features that make a product more "channel friendly", it was becoming less interesting to me. Don't get me wrong though, the research coming from Damballa Labs still can't be beat, and I hope it makes it the product sometime soon.
So, with that all said, I wanted to get back in to consulting. I love the constant flux of new problems, logistics and cutting-edge technology.
Last week I joined IOActive, Inc., as their CTO.
As some of you may be aware, I've been working with the company for a number of years - including being a member of their Advisory Board. As their CTO my initial focus will be on helping to develop the long-term service strategy - bringing new boutique and cutting-edge services to market to address the latest onslaught of technology threats and preempt many upcoming security problems for large and sophisticated organizations.
IOActive is a fantastic company. It's at the forefront of advanced security consultancy and has been growing at an amazing rate.
So, with all that said, you can now find me at IOActive, and I'd be pleased to offer you my new business card. I'm sure IOActive will be able to help! :-)
Sunday, November 25, 2012
Exploit Development for Fun & Profit
Persistent Threat Detection (on a Budget)
If there’s one simple – high impact – thing you could do to quickly check whether your network has been taken over by a criminal entity, or uncover whether some nefarious character is rummaging through your organizations most sensitive intellectual property out of business hours, what would it be? In a nutshell, I’d look to my DNS logs.
It’s staggering to me how few security teams have gotten wise to regularly interrogating the logs from their recursive DNS servers. In many ways DNS logging can be considered sprinkling flour on the floor to track the footsteps of the culprit who’s been raiding the family fridge. Each step leaves a visible impression of where and how the intruder navigated the kitchen, and their shoe size.
Whenever an electronic intruder employs their tools to navigate your network, tries to connect back to their command and control server, or attempts to automatically update the malicious binaries they've installed upon the system they have control over (or wish to control), those victim devices tend to repeatedly resolve the domain names that that attacker is operating from. Therefore, armed with a list of known bad domain names and/or IP addresses, it’s a trivial task to mine the DNS logs and identify any successful intrusions.
Depending upon how authoritative your “blacklist” of criminal domains is, and how picky you are about the IP destinations that the domain names are resolving to, you can rapidly spot those nefarious shoe impressions in the flour.
One word of caution though, this isn’t a comprehensive technique for detecting persistent threats operating within your network – but it is one of the simplest! It also has the highest impact – particularly if you’re operating on a shoestring budget.
An obvious limitation of DNS log mining is the depth and accuracy of the blacklist you’re matching DNS events to – so you’ll want to ensure that the list you’re using covers the types and classes of threats you’re most interested in detecting. While there are plenty of free blacklists out there, the vast majority of them deal with spam, phishing and drive-by hosts… so you’ll want to invest some time shopping around a little.
Here are a few tips to using DNS as a means of detecting persistent threats (advanced or otherwise):
- Turn DNS logging on! Seriously, do it now… you can read the rest of this blog after you've turned it on.
- Select a bunch of relevant blacklists that contain malicious domains associated with the threats (and criminal actors) you’re most interested in.
- Create a list of IP address ranges for countries, companies or regions that computer systems within your organization shouldn’t be communicating with, and use this as a second-pass filter for spotting other unwanted or likely malicious traffic.
- Scrape your DNS logs frequently – ideally at least once per week.
- If you’re worried about a handful of specific threats (e.g. a criminal operator or state that is likely targeting your organization), scrape your DNS logs for relevant domain names hourly – and alert upon their discovery.
- Even if you’re only scraping you’re DNS logs weekly, don’t throw them away after you’re done. Try to keep your DNS logs for multiple years at least. (Note: DNS logs compress to almost nothing – so they’re not going to take up much space).
- Consider scraping all the older logs (going back up to 5 years) once a month or so. New domains will be added to the blacklists you’re using over time, and new intelligence can shed new insight in to past intrusions. It’ll also help to establish when the intruder first compromised your network when you do find one.
- If your DNS server allows it, turn on logging of “failed” lookups – i.e. NX domain requests. While these events won’t help in your blacklist lookups, they will help identify malware families that make use of domain generation algorithms (DGA) as well as “broken” applications within your network that need some tuning in finding their legitimate destinations.
- DNS log scraping can be conveniently done off-line through simple batch script processing. So the impact on the team responsible for securing the corporate infrastructure is minimal after a nominal development investment.
If you’re not happy with the quality of the blacklist you’ll be able to bring to bear in uncovering the persistent threats likely already operating within your environment, or if it would be helpful to do a “one-off” check of your DNS logs and to help build the internal business case for investing in a more permanent detection solution, let me know.
Point of Sale (POS) and Card Reader Tampering
Over the last two decades POS technology has evolved considerably. Today’s systems are predominantly networked computers capable of not only processing a sale, but also querying inventory, managing customer loyalty programs and even delivering news and mandatory training materials directly to the store employee.
At their heart, these modern POS terminals are often a standard desktop PC adorned with a number of card readers, money drawers and barcode scanners and, as such, are all too often vulnerable to the same threats that affect any other PC around the world. Some all-in-one POS systems incorporate a number of physical safeguards to protect against the everyday insertion or removal of attached peripherals, and to also prevent theft of the equipment – which you rarely see on corporate desktop systems.
In many stores you go to you’ll also encounter a separate card reader (often with a touch-screen and numeric keypad) that’s designed to allow the customer to swipe and complete a credit or debit card transaction by themselves. These card readers are typically owned and managed by the merchant bank that processes the financial transfers for the retailer and, while there are many different types, a handful are more popular than others.
These merchant-supplied card readers typically include any number of logical and physical anti-tampering technologies – most of which are designed to elevate the retailers trust in the reader, and to help protect against semi-sophisticated criminals. There are entire books and engineering courses in anti-tampering technology, but an interesting paper I came across a few years ago will likely be a good primer for hinting at the sophistication of the anti-tampering technologies found in the POS card readers, and the techniques available to organized criminals for defeating them.
Check out “Thinking inside the box: system-level failures of tamper proofing” by the University of Cambridge from 2008. It has a few pretty pictures too.
It should be no surprise that the criminals have access to many of the tools and techniques to alter even the most sophisticated anti-tampering technology. It’s interesting to note that there are online tutorials and walkthroughs on many hacking sites and (more importantly) carding forums. Here is just one example:
If you’re a retailer, what should you be doing to protect yourself from POS (and card reader) tampering? I’m sure there are a number of audit points within the PCI standards that cover this topic but, frankly, it’s so difficult to locate those points and distil them into something immediately actionable I’d recommend the following as a bare minimum:
- Maintaining a list of the POS terminals and card readers within the store – that includes the type, make, model and serial number. This list and terminals should be checked on a daily basis.
- Checking that serial numbers on the terminals match the serial numbers displayed on the terminal screen.
- Checking for signs of terminal and component tampering; and making sure that staff are trained in identifying evidence of physical tampering.
- Checking that stickers and other visual identifiers are unchanged.
- Prohibiting unauthorised people from accessing terminals and any CCTV equipment.
Thursday, September 13, 2012
Nitol and 3322.org Action by Microsoft
Microsoft presented the need to take control of this cluster of malicious domains as a necessary action against the Nitol botnet and to protect and secure the supply chain. While I don't quite understand all of the logic behind this argument (there's just not enough info public at this point in time), at the end of the day Microsoft have managed to remove a thorn from the community's side.
The Nitol botnet is, in general terms, bothersome but not a wide scale threat. Damballa Labs has been tracking the threat for quite some time and, as botnets go, is a rather small and tired affair. If you're a victim of Nitol though, yes, it's a pain-in-the-bum DDOS agent.
The 3322.org angle is much more interesting to me than the Nitol botnet that formed the legal excuse for being able to seize control of the domain.
From a Damballa Labs perspective, we currently track around 70 different botnets that currently leverage 3322.org's DNS infrastructure for C&C resiliency - using a little over 400 different third-level domain names of 3322.org. With a bit of luck I'll have some size information about those botnets later today.
Will the usurping of 3322.org kill these botnets? Unfortunately not. There may be a little disruption, but it's more of an inconvenience for the criminals behind each of them. Most of these botnets make use of multiple C&C domain names distributed over multiple DNS providers. Botnet operators are only too aware of domain takedown orders from law enforcement, so they add a few layers of resilience to their C&C infrastructure to protect against that kind of disruption.
Take Nitol for example - it employs multiple domains from several free dynamic DNS providers, including other four-digit .ORG domain services such as 6600.org, 7766.org, 2288.org and 8866.org.
Interestingly enough, the (former) owners of 3322.org are providing new support advice to their inconvenienced customers in how to bypass this interuption by Microsoft:
