worm blog

Worms, Bots and Holy Grails

This post may be long overdue, but I hope it still has value. This post comes out of thinking a lot about the relationship of bots, worms, and the role of Wormblog going forward.

The Worm Problem

The "worm problem" has a couple of facets to it. First and foremost, it's likely that the worm will attempt to propagate so rapidly and so aggressively that it will disrupt normal network operations. Secondly, it can introduce new points of unauthorized access or control in systems that are under your administrative domain. In the wake of Code Red and Nimda, the world woke up and saw the threat that network-aware malware can pose to the Internet's use. Since then, we've seen a dramatic upsurge in interest in worm "solutions" and research. These facets I list above seem to be the main concerns of anyone with an interest in worm research and hoping to apply it to the Internet at large. These are also the concerns that have lead to various commercial worm solutions.

Now that we have a clear problem statement, we can state the goals of worm protection clearly and succinctly. Any solution to "the worm problem" must be able to detect a new piece of autonomously propagating network malware (ie a worm) as fast as possible and be able to selectively identify the traffic caused by it. Optionally, for a real solution, it must enable the operator to selectively kill the malicious agent's traffic. In short, it must identify the worm and stop its propagation before it gets too far. Because network-centric views give you the biggest area of monitoring, and because we often have to think of worms as "zero day" threats (ie using an exploit specifically coded for the worm's use, even if it uses a well known vulnerability), I tend to focus Wormblog on naive, network-centric detection of novel worms.

I've spent a lot of time looking at how to detect worms reliably based on network traffic, and I've even helped implement such a solution in a commercial product (which I'll name in a few minutes). I've gone looking for other such products or techniques that are available, and what I've found is only a few classes of tools to help you detect a worm on the net.

The first, and most common, kind of tool is a host-based agent that relies on signatures, such as a traditional antivirus product. This is probably still the most common method of malware defense, good old desktop AV. In an enterprise setting, this can be a managed solution, so that when new signatures get published they can get pushed out as rapidly as possible to all of the desktop agents. Still, this is a reactive solution.

The second solution, and probably nearly as popular (in terms of coverage) as the first, is network IDS-based detection of malware, usually based on either the exploit payload of a worm or the worm executable's payload. IDS engines like Snort have rulesets for worms, like these Nimda rules, that you can load. But again, they're reactive. Someone has to see the worm to develop a signature.

The third type of detection that is used is commonly referred to as Dark IP or Blackhole monitoring, DarkNet techniques, or a Network Telescope. However, they're all basically the same thing: take some unused address space and have it hit a collector. Run some statistics and some analytics on the data collected and you may be able to detect a worm. You can even use this data for signature generation. Bear in mind that a lot of the Internet is monitored in this way. There isn't a stretch of the net that someone isn't watching.

The type of detection I most favor is based on anomaly detection. For example, a set of hueristics and rules that look for a growing pattern of alerts that can be due to a worm's propagation attempts. Products that apply this sort of analysis include Arbor Networks' Peakflow X, Mazu's Profiler, and Therminator (based on the Lancope engine).

Finally, there's a honeypot-based approach favored by Forescout and their Wormscout product. I haven't seen a lot of this in the field, to be honest, and in most cases a honeypot isn't the most sensible approach to detecting worms quickly. You're relying on the honeypot to selectively see attacks that you may not be able to anticipate (if the exploit or vulnerability isn't know), and to be able to distringuish that from generic background attacks (more on that later). Even then, you still have to honeypot a lot of addresses, either with real or virtual honeypots.

While I tend to focus on a network-centric view of things, I do recognize the value of a combined approach. You can't observe everything from the network, and so host-based approaches will always be needed. You need to capture a sample to analyze, and so a honeypot will be vital. However, I still think that because worms have such a significant network footprint, detecting them by using network traffic and patterns in that traffi cmakes a lot of sense.

The Bot Problem

Now, the bot problem is somewhat different. Because bots usually don't propagate nearly as aggressively as worms have in the past, their threat is not that they'll knock out your network with too much traffic. The big problem is that somewhere, someone else has access to your network and your assets, and that someone is unauthorized. The primary, tractable solution to this problem is quite clear, then: detect bots and block them as fast as possible. Stopping the bots from getting a foothold is a "nice to have", but because they allow for an external party to control the infected machine, most people want to block that communication and then worry about more bots coming online from within their networks.

However, bots will usually rally at some central point for instructions, and that's often how people detect their presence, through monitoring the communications channels. Some people do use IDS signatures for the well known exploits that most bots use, but that's not as unique as looking for a bot's specific actions. There are some Snort signatures to detect bots and their backdoors, but this effort isn't yielding a significant bumper crop of new signatures.

Ultimately, that's still reactive. People have to collect and analyze the bots to identify where they rally (even if it's sped up with sandboxing), and it's still signature-based. The first bot that comes around uses a new exploit will be mised by network signatures. Desktop AV is still the most popular way to detect bots.

The Importance of the Differences

There are a number of key differences between worms and bots, and their associated problems, that have a significant impact on the future of malware detection techniques. These may impact funding choices for future research, and will probably be visible as changes in the literature.

I don't think that anyone disagrees that a proactive solution to the problem is preferred. After all, a shorter gap between malware outbreak and it's detection by customers is still a reactive solution. To that end, I think that I'll keep focusing on naive approaches to malware detection.

Most bots out there are derivatives of common malware families, and why detection isn't based on those common characteristics is beyond me. While I can pick out a Spybot vs an Agobot from within IDA in just a few moments yet most AV engines can't detect a freshly repackaged Spybot is still a mystery to me. Given the pace of bot authorship, and that it wont be slowing down, this sort of lag in detection seems unacceptable to me.

However, I think that the biggest challenge to detecting malware on the network (and using only network traces) comes from the dramatic increase in the amount of background "radiation" on the Internet today compared to 2000 or so. The volume of scans due to infected boxes means that scan alarms on the open Internet are always going off. Most worm detection techniques rely on a clean, "happy" Internet, one where the noise generated by a worm would be unmistakable. Yet, this isn't the case, and rarely do we see people testing their worm detection tools (ie tools that look for TCP RST storms as an indicator of a worm) on the modern, polluted Internet. This is an important aspect of research that needs more attention, especially as many grant-funded worm-detection tools are being completed around this time.

This question, "can your worm detection tool work in the face of a thousand live botnets?" may be moot if the worm problem has really been diminished or gone away. However, naive detection of network threats is still just as important as ever. The good news is that humans will still be needed for the task, and probably more than ever before. And, if you're attracted to grand challenges in computer security, making sense of this mess is a great problem to tackle.

MS06-040 and the Death of the Worm

A couple of years ago, when a vulnerability like the recently disclosed Microsoft Security Bulletin MS06-040: Vulnerability in Server Service Could Allow Remote Code Execution was released, you figured a worm was not far behind. And not just a basic worm, the kind that can infect hundreds of thousands of machines quickly. After all, we've been expecting that to happen given what we saw in the past with MS05-039 (Zotob, which really was a bot), MS04-011 (Sasser) and MS03-039 (Blaster).

But this is 2006, and people recognize that if you were able to get your code onto hundreds of thousands of systems, you should be able to do something with them. And so we have bots like W32.Wargbot taking advantage of that vulnerability. It didn't spread nearly as aggressively as Blaster did, but it showed that we're beyond simple worms, for whatever reason.

During my haitus, I spent some time wondering if Wormblog was even still needed. It's only been a few years, but it seems like worm detection systems are no longer as high pressure as they were in the past. For one, you have a significant amount of background noise from bots scanning for victims. Also, you have a dramatic slowdown in malcode propagation compres to a couple of years ago. Don't be surprised if you see more botnet stuff on here because of such changes. I think that there's still interesting research going on in worms and not just in bots, and I'll keep digging for it.

What the heck?

What the heck? Why did this blog get so quiet all of a sudden?

I'm exhausted, working more than I have in recent years, lots of hours every day and simply hit burnout phase. Wormblog was one of the causualities. I'll be posting again, but right now I'm travelling. Keep your eyes peeled and thanks for your patience.

-- jose

Week in Review: Inqtana redux

It's been a busy week, but on the really interesting malware front, it's been pretty slow, so here are some comments on the Inqtana worm. A lot of hype surrounded it when it was first published a week ago Friday, but it turns out to be mostly hype.

In InqTana Through the eyes of Dr. Frankenstein, a post to the Full Disclosure mailing list, KF breaks down the malware and shows that it's not found in the wild, that it's nothing but a proof of concept sample and crippled to avoid spreading about the lab. While the press jumped on the "OS X malware" bandwagon, it appears to have been premature. Yes, the proof of concept is great, it demonstrates that there's a potential of a threat vector with Bluetooth of personal computers and there's a largely untested field of OS X malware, but the threat is not yet realized. It's some good analysis, although I dispute one of his claims:

"Putting all of that aside I think most people missed the point of this worm and its variants. The main focus was not on the usage of Bluetooth for the exploit medium, or the vulnerability used. The focus should have been on the usage of built in OSX facilities to spread malicious code. OSX contains features, which will certainly aid in the future of malware on OSX."

I think that it's just as important that it's Bluetooth on a personal, general purposes computer that makes it just as interesting as the fact that it's OS X. We've seen a lot of PDA and cellphone malware in 2005 (see the F-Secure weblog archives, it's quite interesting), mainly variants of a few families, and now we can have it on OS X, too.

Interesting times ...

Another interesting tidbot from the past week, it seems that MWCollect and Nepenthes are merging into one codebase. If you haven't looked at these tools to collect Windows malware, you should. They're useful and easy to deploy. It will be good to see efforts combined and the projects strengthen in the coming months.

And finally, another new tool to help network administrators defeat malware infestations. Quarantainenet looks lik a commercial tool to use your network segmentation tools to protect your network if you have untrusted or infected hosts on the net.

Quarantainenet provides network operators with a way of placing users in a quarantined environment, for example in case of a virus or worm infection.

Quarantainenet makes sure a user only retains the limited functionality that is necessary for fixing the problem. The big difference with simply disconnecting a user, is that quarantainenet usually enables the user to solve the problem himself while at the same time improving communication towards the user. The productivity of operators also heavily benefits from this.

If you run a network and have been looking for ways to implement quarantine segments, this may be useful for you.

Botnets and IM Worms

Two news articles caught my attention this morning. The first is a set of interviews that deal with the botnet problem. Both Red Herring and CNN talked to Merrick Furst, a professor of computing and associate dean for undergraduate programs at Georgia Tech's College of Computing. The interviews are similar, but have some nice background material on bots and what's being done with them. You can read Q&A: Bot-Buster Merrick Furst from Red Herring, and Expert: Botnets No. 1 emerging Internet threat from CNN. I think that he's not too far off. The size of some botnets and the flexibility they afford attackers does make them a significant threat. And once they have penetrated an enterprise, they can be used to access systems arbitrarily, exposing documents to theft or destruction. Expect more botnet material in the coming days, and also read the Wormblog archives on botnets.

The second piece reads more like a press release from a company that has a vested interest in selling products to combat IM threats.

The worm, which was reported by FaceTime Communications, targets PCs that have been infected with the lockx.exe or palsp.exe viruses. It can use Internet Relay Chat-enabled malware to connect the client to a server and spread further. In one manifestation, the worm sends a message containing links to everyone on the infected client's buddy list. When the recipients click on the link, they become infected with new variants of the worm and they install creame.exe, which delivers multiple adware payloads.

Source: All the Rage: Worms Turn Against IM, in Security Pipeline, February 1, 2006. I recall looking at this threat, and it's not as bad as it sounds. Almost all major AV companies picked up the bot software as a SpyBot (or related) variant, so it wasn't slipping under the radar, but it does show that IM is fast becoming a method to propagate malware, like email had become about 5 or 6 years ago. We've been tracking this particular angle of the threat, and you can browse the IM worm story archive here at Wormblog for some history.

Nematodes and Blackworm

A couple of comments on recent events.

First up, at the Blackat Federal briefings (recently concluded), Imunity Sec maestro Davie Aitel presented on his Nematode idea again. I saw this at Hack In The Box 2005 (one of the best conferences I've ever been to), and have made comments previously. Dave's been getting some press traction with the idea, and I've been asked to comment. I still stand against the idea of a beneficial worm.

Secondly, the Blackworm has spread and is set to destroy your files this Friday, February 3. Note that a great consortium of people have come together to help notify customers that they are infected. Thanks to the cooperation of the ISP who is hosting the CGI counter to show how many infected hosts there are, various groups in industry and government are working to help prevent a massive problem. The Blackworm is known by many names by various vendors, but it's all the same thing. Note that this is one of the better efforts at this in the past, and unlike some worm outbreaks, this one doesn't consume insane amounts of bandwidth (ie by spewing scan traffic). This is the evolution of security approaches and efforts and represents a good step forward.

Humor: Blog Worm

A piece of humor for everyone ...

Malware for Sale: Comments on some recent efforts

Some thoughts on some of the recent malware distribution projects that have been announced.

The first of these is MD:Pro, who plans to change about 1000 Euros a month for access, which has a number of benefits. It keeps the average people, who may have malicious intentions, from getting arbitrary access. And it also helps fund such a venture, which can be costly. Managing sample submission, a site, etc .. that takes people, and time, and eventually people have to pay their bills.

Another effort is the Offensive Computing effort. Their stated goal is to help people get access to malware who share their intentions, namely learning how it works. This full disclosure for the malware world. From their website, "There is a noticeable lack of public sources of malware and malware analysis available. Those that were available were either for sale or limited to a small number of users. We provide resources such as live copies of malicious software, md5sums to search on and analysis of the malware to the general public." Pretty worthy goals from my perspective (more below), but there's more to it than good intentions.

If you're a malware researcher (or an aspiring one), the key thing to remember about any such malware distribution site is the integrity of the samples. You'll be wasting your time if you don't get real samples to work on. Right now I don't think we're aware of what kinds of integrity controls these malware collections have in place. For a great review of what this means, be sure to read Analysis and Maintenance of a Secure Virus Library, by Vesselin Bontchev, from the VB Conference, 1992. If you remember the 1999 admw0rm incident (which owned the person who executed it before running off to infect anyone ele), you'll know what it means to have a sample do something you didn't expect it to.

Many people in the malware analysis community will tell you that distributing samples so openly and indiscriminately is irresponsible and should be frowned upon. The AV community already has a sample sharing scheme, with everything from very tightly knit groups which require massive amounts of vetting and trust to more loose affiliations. Access to these is granted by personal introductions, and sharing outside of an approved circle is frowned upon for obvious reasons: You don't want the samples to fall into the wrong hands.

With regards to how someone may make use of such a sample, I'm reminded of something Brian C. spoke about recently on the Daily Dave mailing list. Someone asked if you should use your own tools or openly available tools to commit an act (e.g. penetrating a network or a host). Brian brought up a great point: if it's an open tool, they'll have more difficulty in tracing it back to you than if you wrote your own tools for the job. Everyone has a set of tricks they know and use, methods they fall back on, and coding style. This is apparent when you review anyone's work output over the years. If you have access to a malware repository written by others, you can tweak it for your needs.

In a recent story in The Register, John Leyden looks at the pay for your malware access model. It does raise a number of questions as John pints out. This sort of thing isn't new, the for-pay model is not unlike the TippingPoint ZDI program or the iDefense VCP effort: organizations can subscribe to a feed from the underground and stay abreast of things. The broker, in this case the MD:Pro organization, makes a few bucks off of their effort of being the middleman. Clearly large organizations can (and do) penetrate the underground and get their intelligence: vulns, malware, exploits, etc. and it works. There's a growing presence of these sorts of intelligence brokers in the infosec space, but clearly the market can't support them all, and I don't know if MD:Pro will survive, only time will tell.

Years ago when I was starting to evaluate malicious software, I wanted access to malcode repositories so I could understand samples, families, techniques, etc. If you look at any established AV researcher, it's usually the same story: I found some samples, I analyzed them, and I got access to more samples. Then again, the malware (and AV) world is significantly more mature and well staffed by this point. I raided a few sites for peoples' malware stashes, I begged borrowed and stole numerous samples for my worms book, and I am eternally grateful. Now, a few years later, I have so many samples flowing in I have to automate analysis. I can totally see why people who want to learn malware analysis (a fast growing field) want and need lots of samples, I have been there myself.

That said, there's a couple of things I disagree with in this business model. First, it violates a lot of reasonable safeguards and ethical standards developed by the anti-malware and AV community, such as AVIEWS and AVIEN. These safeguards have a place, and while it can be frustrating to not get access when you want to learn and grow in this space, you have to remember that there are a lot of people out there who want malware for themselves for nefarious purposes. You can't be responsible and give it to people with expressly malicious intentions.

Secondly, while it is a broker model, selling samples is another violation of a common AV ethic, namely not to sell samples. It's counter-productive, because you force people you share with to chose when budgets start to run out (no one's budget is endless). And unless it's your intellectual property or you have express licensing terms, it's hard to justify selling it as well.

If you really want to start analyzing malware, check your inbox. So much mail-based malware is moving around, you get a few new samples every day. There's no shortage there. Fire up a free copy of IDAPro (trial copies are available, you just can't save your work), use OllyDbg (free), and read some tutorials on the web. If you're really interested, fire up a honeypot or malware collection tool like MWCollect and Nepenthes on your broadband line and start analyzing the samples you collect.

Happy 2006

First up, a big hearty thank you to all readers, commenters, submitters, and friends of Wormblog for a great 2005. You have helped this year be better than the last and we're building a nice resource. I've been trying to post almost daily, if possible, and have also started posting some more analysis of the malware I review. While I have been slipping a few days here and there lately due to exhaustion, I've been happy with these trends, I hope you are, too.

Thanks to the magic of logfile analysis and Google Analytics, I have realized how global the Wormblog audience really is, and I've also been surprised at some of the inbound links and referrers. I'm happy to see this resource growing so valuable to others.

So, I just wanted to take New Year's Day and thank everyone for helping keep Wormblog going strong in 2005 and wish you all a happy 2006.

Dasher Analysis and Thoughts

Some thoughts on the new Dasher worm that's spreading.

First, I've had a chance to look at all thre variants of the worm and reverse engineer the actual code. A big thank you to some research partners for the binaries. Having looked at the operations the worm is doing, it's obvious that it's been put together in a very haphazard fashion. The main driver of the worm actually writes a batch file that gets executed, the actual exploit code and the actual scanner are not married as code. As such, it has to be coordinated by a process (Sqltob.exe) to launch the scanner process and manage the exploit process (or processes). No one even stripped out Swan's happy little printf() statements in the code! This is a very amatuer effort on the basis of the reverse engineering.

Secondly, the worm is using a central distribution point to send out the worm binaries. The tradeoffs here are mostly obvious. As a benefit, the worm master can update the binaries here and inject new exploits or new capabilities, or just bugfixes, quite handily. It may not affect the existing worm infected systems (unless they actually poll or are connected to a worm master controlled site), but that can be sufficient. If you think about it as a seeded base from which to launch a new, improved worm, that's quite an obvious benefit. The risk inherent in this is also obvious, namely that it's easy to either shut down or begin blocking access to this central distribution site. You can block a domain name or even a 2LD, an IP address, or a port and achieve most of the blocking you need to. Pretty easy to shut this one down, as happened with Dasher.A. Dasher.B and C recycle the same master fetch site. Why someone hasn't yet repackaged the worm to send the payload from the attacker to the victim is beyond me, assuming they were capable of it.

Thirdly, the worm is clearly being worked on. It's been shown that you can get an effective worm installed (some stats I've seen suggest a couple thousand hosts worldwide are infected by this worm) using the MSDTC exploit, but it's already been augmented with three older vulnerabilities: UPNP/LSASS, MS SQL, and the WINS exploit. So, this is going to see some more work before it goes away, and we'll probably see the MSDTC exploit code rolled into the various flavors of RBot, SDBot, and such in the next few days (if you're not seeing it already).

Keep in mind it's not usually the best and brightest of the attackers who write worms, which means it's usually pretty easy to analyze these things and shut them down. While there's been great effort put forth to make stealthy, polymorphic, and difficult to analyze malware, it rarely gets used in the wild on a global scale. For the forseeable future, we're going to see worms like Dasher get launched, and we're going to have to shut them down the same way we always do.

If you haven't patched your MSDTC holes yet, go do so. If you can't, make sure you block port 1025 to those systems.