worm blog

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.

The Effect of Network Topology on the Spread of Epidemics

This paper is stuffed with math, but don't be afraid to give it a few readings to try and catch what it concludes.

We study the SIS epidemic model (or contact process) on graphs, and identify topological properties of the graph that determine the persistence of epidemics. We show that if the ratio of cure to infection rates is larger than the spectral radius of the graph, then the mean epidemic lifetime is of order log n, where n is the number of nodes. Conversely, if this ratio is smaller than a generalization of the isoperimetric constant of the graph, then the mean epidemic lifetime is of order e^na, for a positive constant a. We apply these results to the hypercube and the star topologies and also to Erdos-Renyi and power law random graphs.

Source: The      Effect of Network Topology on the Spread of Epidemics, Ganesh,      Massoulie, Towsley, IEEE Infocom 2005, Miami,      FL, 2005..

Requirements on Worm Mitigation Technologies in MANETS

Here's sometihng you don't see every day, the idea of a worm loose on a mobile ad hoc network specifically in a battlefield scenario. As communications equipment becomes more linked through data transmission networks, this threat becomes more and more credible.

This study presents an analysis of the impact of mitigation on computer worm propagation in Mobile Ad-hoc Networks (MANETS). According to the recent DARPA BAA - Defense Against Cyber Attacks on MANETS [4], ”One of the most severe cyber threats is expected to be worms with arbitrary payload that can infect and saturate MANET based networks on the order of seconds”. Critical to the design of effective worm counter measures in MANET environments is an understanding of the propagation mechanisms and the performance of the mitigation technologies. This work aims to advance the security of these critical systems through increased knowledge of propagation mechanisms, performance and the effect of mitigation technologies. We present both analytic and simulation analysis of mitigation effectiveness. The ultimate goal of these studies is to develop an accurate set of performance requirements on mitigation techniques to minimize worm propagation in tactical, battlefield MANETS.

Source: Requirements on Worm Mitigation Technologies in MANETS, Robert Cole, Nam Phamdo, Moheeb Rajab, Andreas Terzis. From PADS05.

History: Xerox PARC Worm

A piece of history for everyone. Researchers at Xerox PARC had been experimenting with worms to create a distributed computing environment in their experimental network. This idea worked well until one morning ...  The topic of the Xerox PARC worm came up yesterday during a phone call with someone regarding Dave Aitel's Nematode idea.

The "worm" programs were an experiment in the development of distributed computations: programs that span machine boundaries and also replicate themselves in idle machines. A "worm" is composed of multiple "segments," each running on a different machine. The underlying worm maintenance mechanisms are responsible for maintaining the wormmfinding free machines when needed and replicating the program for each additional segment. These techniques were successfully used to support several real applications, ranging from a simple multimachine test program to a more sophisticated real-time animation system harnessing multiple machines.

Source: The "Worm" Programs Early Experience with a Distributed Computation, John F. Shoch and Jon A. Hupp, Xerox Palo Alto Research Center, 1982.

I cover this worm a bit in my book, but for a nice overall history of Xerox PARC read Dealers of Lightning : Xerox PARC and the Dawn of the Computer Age, by Michael A. Hiltzik.

Humor: Blog Worm

A piece of humor for everyone ...

Epidemic profiles and defense of scale-free networks

Scale-free networks, which have a few nodes highly connected and many nodes weakly connected to the network, are both a boon for networks and a bane for defending against autonomously propagating malware. Once a well connected node is hit, it can quickly infect all nodes on the network. For some good background on the effects of this phenomenon on networks carrying a contagen, look at Mark Newman's work.

In this paper, we study the defensibility of large scale-free networks against malicious rapidly self-propagating code such as worms and viruses. We develop a framework to investigate the profiles of such code as it infects a large network. Based on these profiles and large-scale network percolation studies, we investigate features of networks that render them more or less defensible against worms. However, we wish to preserve mission-relevant features of the network, such as basic connectivity and resilience to normal nonmalicious outages. We aim to develop methods to help design networks that preserve critical functionality and enable more effective defenses.

Source: Epidemic profiles and defense of scale-free networks, Linda Briesemeister, Patrick Lincoln, and Phillip Porras. In Proceedings of the 2003 ACM Workshop on Rapid Malcode (WORM).

Hardening Internal Networks against Worms

I don't think I've ever heard anyone actually advocate a "crunchy shell" style network ... Looking over this piece, it's very short on details and ambiguous on ideas, and it ignores some technologies like Network Admissions Controls and quarantine VLANs.

There used to be an old metaphor used by network security designers :

    Networks should be hard on the exterior, and soft and squishy on the interior. Like a chocolate.

Recent events thoughout 2003 and early 2004 show that this is no longer the case. With mobile computing (such as PDAs, and laptops), wireless networks, and increasing demands for access to mobile content it is no longer sufficient to attain security simply by installing a firewall between the enterprise network and the Internet.

Source:Hardening Internal Networks against Worms.

Microscopic simulation of a group defense strategy

Another paper on modeling from the SRI group, this one is a good complement to the one from a few days ago. And, it focuses on looking at the effects of quarantine in a model.

We introduce a novel worm containment strategy that integrates two complementary worm quarantine techniques. The two techniques are linked, with one strategy employing the other as an indicator of worm infection. A group defense mechanism shares such indicators among neighboring networks, and when enough corroboration occurs, the network engages in traffic filtering to halt infection attempts.

We present an SSFnet-based microscopic simulation of the containment strategy against random scan worms, and explore various performance characteristics of the group defense mechanism. The simulation results help to characterize the conditions and degree to which the integrated quarantine strategy can both slow worm propagation and prevent the worm from reaching its full saturation potential.

Source: icroscopic simulation of a group defense strategy, Linda Briesemeister and Phillip Porras. In Proceedings of Workshop on Principles of Advanced and Distributed Simulation (PADS), pages 254-261, June 2005.

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.

Model checking of worm quarantine and counter-quarantine under a group defense

This is a lengthy, formal paper, but quite intriguing. So far I think the research is sound and the methodology proposed is interesting, but I don't know how well it would work in the real world. But perhaps within an enterprise ... Nonetheless, if you're feeling like reading a strong academic paper, here is one for you.

We consider what it means to perform worm quarantine across a network with an emerging self-propagating worm outbreak. It is generally understood that an effective quarantine defense can under certain conditions reduce the infection growth rate, and ideally can prevent a worm from reaching its full saturation potential. This report attempts to more precisely define the desired properties of a quarantine algorithm, and suggest different forms of quarantine properties that vary in their ability to isolate infected nodes, ensure the existence of an uninfected population, and guarantee some persistent protection, no matter how the worm behaves. We employ the SAL formal modeling language and model checker to investigate these properties on a specific group-based quarantine algorithm. In addition to answering questions regarding algorithm correctness and validating some quarantine properties, the model checker disproves other quarantine properties. The proofs and counter-examples produced during this process help in algorithm design and may be useful in informing simulation experiments or building test cases. Using a game theoretic approach, counter-examples of a win scenario for the defense yield insight into smart worm behavior that defeats a known quarantine defense.

Source: Model Checking of Worm Quarantine and Counter-Quarantine under a Group Defense,  by Linda Briesemeister, Phillip A. Porras and Ashish Tiwari.  Publication number SRI-CSL-2005-03. Computer Science Laboratory, SRI International, Menlo Park, CA. October, 2005.