antiworm

IDS is dead, according to Gartner. This subject came up a few weeks ago in a conversation with the CEO of a network management company that works mainly with US Federal clients. He told me, "Federal Agencies have been dropping millions on IDS for years, and it's not doing them any good. They aren't getting any value out of it. My staff thought I was crazy the first time I said this." It's common for security officers, consultants, and staff to think that a lack of management support and a lack of organizational investment is the reason for IDS failure. The other side of the coin is that IDS technology is simply too expensive to operate, and doesn't provide enough ROI. If your car required a full time on-site mechanic to rebuild different parts of the engine and transmission, you couldn't afford to drive, either. One of our clients has an industry leading IDS system. They routinely receive alerts about worm outbreaks on their network from that IDS sys

Two years and dozens of worm variants after the W32.Blaster.worm worm infected millions of machines using an easy to block TFTP callback mechanism, the latest variant of the Zotob family is using the same technique. The W32.Zotob.K worm may spread on some networks more successfully than previous variants, all of which attempt to exploit the MS05-039 buffer overflow defect in Windows systems. Using this technique, a worm author trades complexity in one area of the worm design (the overall transport logic) for simplicity in another (the code which exploits the buffer overflow). Previous variants have connected to the victim computer on port 139 or port 445, where it hopes to find an unpatched software agent listening. Then, a packet is sent containing some things that the victim expects to receive, and some things it does not -- all must be arranged very precisely. This package includes the message which trips the buffer overflow, and the code the attacker seeks to run on the remo

A number of systems administrators have asked me for some nice authoritative PDF and official looking references to support them in discussions with management regarding recovery strategies (see IRC Botnets: The Needle and The Damage Done). Senior managers are not particularly impressed by blogs, you know. Here are a few that I had handy. Note that this guidance is not universal. AntiVirus vendors, in particular, commonly claim that cleanup tools are sufficient recovery in most cases, although lately even a few of them have become more cautious in their claims for their cleanup tools. If you find any other nicely authoritative references on this topic, let me know and I'll add them to this page. The first reference actually surprised me. I was working on a large team in a gargantuan organization, and a client asked a Microsoft Security Consultant if Microsoft recommended re-imaging from worm attacks, and if they in fact practiced this type of recovery for internal problem

Since August 15th, many organizations have been struggling to recover from the onslaught of the various worms exploiting the MS05-039 Universal Plug and Play (UPnP) buffer overflow exploit. Those unfortunate enough to see large numbers of systems hit by one or more worm variants face the usual challenge of recovering the systems. Microsoft and the AntiVirus Vendors are eager to help you recover your systems, with several offering their own custom cleanup tool to eradicate the worms. Victims of this crop of botnets would do well to heed the long standing recommendation of information security experts. Recover your contaminated systems by re-imaging them from pristine media, particularly if they were able to contact the outside world even for a few minutes using an IRC control channel. It's often difficult for non-technical management to weigh the risks involved with any given malware outbreak. This week I've heard this sentiment expressed almost exactly the same way

Microsoft and the AntiVirus Vendors (perhaps a decent name for a band) tend to think of "threat" in terms of the number of machines infected, how many are vulnerable, and certain other primitive measures of damage done by a worm, such as "does it delete data files". By those measures, this worm appears benign. In fact this current crop of worms is far more harmful than some of the most famous worms from a couple years ago. Rather than hitting many millions of machines, these worms hit only a few hundred thousand or a few million perhaps (infestations inside large corporate and government networks are hard to count from the outside, hiding many infected systems.) When the worms are released, they do the most damage in the first few hours. They immediately search the hard drives for interesting files and upload them to remote servers. This damage is done, to the tune of thousands of files and hundreds of MB of data, before you learn which port to block at yo

Many organizations are struggling with containment of worms and botnet invasions this week, as a result of the MS05-039 vulnerability and myriad variant worms exploiting it (Zotob, Spybot, Esbot, Rxbot, bobax, et. al.) Most of these organizations have patch management, firewalls, IDS and AntiVirus systems in place as part of a layered defense. They may suffer dozens or hundreds of compromised systems regardless of these efforts at prevention. The current crop of worms are nearly all bots -- remote controlled software agents that call out of your network to a remote server, looking for instructions from an attacker. Containing the outbreaks can dramatically reduce the cost of the later cleanup. If you have a large network, with a large population of vulnerable machines, and you don't have a containment strategy in place, consider the following tactics. Network Partitioning Consider partitioning your internal network on the ports used by the worm to spread. This worm seem

Zotob reared its slimy head this morning. It exploits a defect in Windows systems (UPnP MS05-039) for which a patch has been available less than a week. Zotob is undoubtedly the first of what will be many Week Zero Worms exploiting this defect -- not quite a Zero Day worm, but close enough to wreck havoc. Every time this happens, the internet discussion forums are flooded with snide comments from smug systems administrators, along these paraphrased lines: "I patched all 652 of my systems this week before the worm hit. Any organization being hit by this worm is incompetent." Well, probably not. These well-run one-man shops do impress with their ability to deploy patches quickly and offer some hope for the rest of the universe. However, the prima donna types that make it happen generally don't really understand the magnitude of the problem in a large corporation with, say, 50,000 TCP/IP devices, mostly running Windows. It's not just a matter of patching 77 time

In several discussions around the net it has been suggested that the author of the Witty Worm must be an insider. I'm not so sure. Although I agree that it's interesting that the worm was pre-populated with a seed target list, and also interesting that some of those hosts were on a military base, I'm not convinced of the conclusions that others have drawn from these facts, namely that the attacker had to be an insider -- either from the product vendor, or from the company who reported the defect. Likewise, the implication that the attack was directed at the US Military doesn't make sense. A few minutes of scanning could have produced a list of 100 vulnerable hosts. The scanning algorithm might have been something like this: google to find likely customers of the company whose product will be exploited, find address blocks likely to be associated with those clients using various DNS tools, scan randomly until you find a vulnerable host, then walk up and down from tha

One of the more interesting security articles of late, Device drivers filled with flaws, threaten security from Security Focus , discusses the potential for device drivers to be exploited, due to many lurking buffer overflow defects. The article discusses Windows and Linux as examples, although presumably any platform which depends upon many 3rd party device drivers could be subject to the same issues. Drivers that listen on a network, such as network card drivers, would of course be vulnerable to remote exploits. People tend to think of device drivers as part of "the system", and the article points out that many if not most of the drivers people use are created by 3rd parties, not by the vendor of the operating system, and typically not by the core kernel developers. The article mentions that the authors of device drivers tend to have wildly varying skill levels, and that many drivers amongst a sample inspected appear not to be properly reviewed for security implicati

A systems administrator at a University pondered today, "We haven't seen a really big outbreak for a few months, where are the big worms these days, like Sasser and Blaster? Aren't there any big security holes left to exploit?" Oh, yes. Microsoft releases patches about once a month, and at any given time there are usually a few serious defects that are known, not widely patched, and remotely exploitable. So what's the deal? Worm authorship seems to be more about building and maintaining botnets for revenue generating spam networks, and mining for various data like email addresses, account names and passwords, and the like. Giant worm outbreaks that infect millions of machines work against the aims of this organized criminal activity. Widespread outbreaks get the instant attention of company management, systems administrators, and AntiVirus vendors worldwide. Many small outbreaks, exploiting older known defects don't attract so much attention and serve

I noticed one day in a discussion with a client, that something they said resonated with things other clients have said over the years. Literally some dozens of conversations over the years have gone something like this: So, you plan to re-install the worm infected systems from clean media, right? No. We get hit by viruses all the time and nothing really bad has ever happened. We'll just delete the worm files, whack the key from the registry and go back about our business. Do you know what the worm did after it contacted the overseas IRC remote control channel? No. How do you know nothing bad happened? If you're a client and you recognize this conversation, don't feel bad, I'm not quoting you. I've had this same basic conversation with many other clients, you're in good company (I'm not quoting them, either!) Just about every other professional consultant in the information security world that I've ever spoken with has similar "war s