worm blog

Analytically Modeling Worm Attacks in Internet Protocol Networks

What I like about this model and this work is that it attempts to take real world scenarios into account, namely bandwidth and packet characteristic distributions. I also appreciate how the author's slides are informative even without the talk available.

Network attacks are a growing national concern in both the government and private sector. This presentation focuses on analytic queueing and simulation capabilities that have been developed to analyze the performance of Federal Private IP Networks, especially in the presence of worm attacks.

We have developed an analytical queueing model called the IP Network Performance and Analysis Tool. The assumptions made and methodology used to analyze network performance using analytical queueing and numerical approaches will be presented. Worms typically propagate by first infecting a single node; infected node(s) then scan other network nodes and infect those that are vulnerable. Thus propagation of the worm occurs in stages as more and more nodes are infected. The impact of the scanning traffic during worm propagation on network performance will be examined. The relationship between our approach and to epidemic models discussed in the literature will be discussed. The problems with incorporating the different approaches into analytic performance models, the use of stages in modeling, and the relationship of stages to continual time will be discussed. The mitigating effect of worm deactivation is also modeled. Numerical results and validation will be presented.

Source: Masi, D.M., and M.J. Fischer. Analytically Modeling Worm Attacks in Internet Protocol Networks, Ninth INFORMS Computing Society (ICS) Conference. Annapolis, Md. January 5-7, 2005. [PDF slides]

Protocol-Independent Adaptive Replay of Application Dialog

This is an incredibly cool development, one that I've wanted for a few years but never fully knew how to build. I'm glad to see it's been done, and honestly I figured Paxson would have been involved.

For many applications—including recognizing malware variants, determining the range of system versions vulnerable to a given attack, testing defense mechanisms, and filtering multi-step attacks—it can be highly useful to mimic an existing system while interacting with a live host on the network. We present RolePlayer, a system which, given examples of an application session, can mimic both the client side and the server side of the session for a wide variety of application protocols. A key property of RolePlayer is that it operates in an application-independent fashion: the system does not require any specifics about the particular application it mimics. It instead uses byte-stream alignment algorithms to compare different instances of a session to determine which fields it must change to successfully replay one side of the session. Drawing only on knowledge of a few low-level syntactic conventions (such as representing IP addresses using “dotted quads”), and contextual information such as the domain names of the participating hosts, RolePlayer can heuristically detect and adjust network addresses, ports, cookies, and length fields embedded within the session, including sessions that span multiple, concurrent connections on dynamically assigned ports.

We have successfully used RolePlayer to replay both the client and server sides for a variety of network applications, including NFS, FTP, and CIFS/SMB file transfers, as well as the multi-stage infection processes of the Blaster and W32.Randex.D worms.

Source: Protocol-Independent Adaptive Replay of Application Dialog, Weidong Cui, Vern Paxson, Nicholas C. Weaver, Randy H. Katz.

The Future of Bot Worms

Another white paper from Trend Micro, but this one is much shorter.

The current trend in worms seems to go the bot route. Bots—programs that operate as an agent for a user or another program—are most often seen as malware and keep attacking unsuspected users in surprisingly high numbers. This document details the possible new additions and modifications that bot authors might incorporate to their hideous creations in the very near future.

Source: The Future of Bot Worms, Trend Micro, August 18, 2005.

Top three findings in the whitepaper:

• a continued shortening of the time between vuln described, exploit released and a worm launched.
• RSS feed hijacking
• polymorphic shellcode attack vectors

Take them as you will, the paper itself is short and offers little in the way of justification for these findings and predictions.

Comments, analysis and thoughts

The first is something all corporate marketing organizations have been saying for some time now, although the data I compiled for our wormability paper last year does bear this out. We're seeing a decrease in some cases, although we're continuing to see a lot of old vulnerabilities, exploits, and a lot of old cruft (ie password guessing attacks) still work in many worms.

RSS feed hijacking I don't forsee, but perhaps I'm being too simplistic. While it's an automatic threat delivery vector, an attacker would have to compromise some major websites to get the readership that's worthwhile (for example, my blog's readers are so small in number I think I'm safe). However, recent bugs like the XML-RPC worm, which affected several PHP-based blogging systems like Word Press, can help speed this along and get coverage in the number of feed sources, and thus audience, as opposed to a single point of distribution. However, if you do accomplish that, what do you get? You get a huge disparity in RSS feed readers people use (trying to find the status in my archives, see Surprising RSS Reader Usage Stats: What Do They Mean for Marketers? (The Marketing Diary, July, 2005) and Aggregator usage is a power law too (Dive Into Mark, 2003)). Until MS Longhorn or IE7 deploy a popular RSS reader (which is coming, according to Microsoft RSS cat out of the bag and What Microsoft Longhorn RSS means to me: sane, peaceful mornings, both from Charlene Li's Blog where she posts about online marketingt trends) we wont see a huge footprint of any single point of entry.

Finally, polymorphc shellcode techniques (see Polymorphic Shellcode Engine from Phrack 61,  What is polymorphic shell code and what can it do? from the SANS Reading Room, KTwo's README file for his ADMutate tool (A9 search engine archive, the original appears to be offline))  have been on everyone's radar for years (including mine), but we have yet to really see them. Polymorphic viruses have been around for years (see this Symantec writeup for a nice overview), but we haven't really seen the same sort of thing in the worm world. This is a growing likelyhood in terms of payload, simply using dynamically encrypting packers is becoming widely adopted, but the attack vectors themselves being polymorphic has yet to really catch on. I'm not entirely sure why, but I don't think the time is right for worm authors to include that just yet. So, probably in a year or two (as techniques like those in Metasploit and Canvas become more widely understood and adopted) before we see that getting used. However, I'm sure some enterprising young RBot variant user is looking at hooking it in.

In short, I disagree with much of what the prediction holds, but I'm definitely open to being corrected and shown ot be wrong. I certainly don't possess a crystal ball, I just analyze data.

Los Alamos enters market with worm defense

From Federal Computing Weekly via DE, a press release that says that the Los Alamos National Laboratory is going to be making their worm defense tool Network Automated Response and Quarantine ("NARQ") available via licensing to the general technical community. Probably not for end users, but instead software makes and integrators.

Los Alamos developed NARQ after it failed to find a ready-made commercial product to help stymie the specific threat it faced from worms. Unlike viruses, worms don't directly infect programs and files. Instead they make copies of themselves and then propagate via the network to other machines, bringing the network down through denial of service.

NARQ detects such worms and then instantly quarantines all the affected machines and devices on the network at the port level.

Source: Los Alamos enters market with worm defense, FCW, Nov. 16, 2005.

For more information on the LANL NARQ project, see the LANL NARQ website. The website describes NARQ thusly:

Network Automated Response and Quarantine (NARQ™)

Los Alamos National Laboratory (LANL) has developed a semi-automated and instantaneous layer-2 (Ethernet) network mapping and quarantine system. The Network Automated Response and Quarantine (NARQ™) software is designed to locate infected systems and reconfigure ports to remove the infected devices from the network.

When they put it like this, it sounds more like Packetfence than anything else, although I have yet to really review the technology.

See the Wormblog paper archives for discussions about the effectiveness o quarantne approaches.

The Sasser Event: History and Implications

Normally I'm reluctant to post a vendor white paper, mostly because they contain little technical information and are more marketing than substance. However, this is an exception to that trend. While the Sasser worm event is now well over a year and a half gone, the timeline itself is intriguing to study. Trend Micro has written up a nice, detailed overview of the event which may be interesting to Wormblog readers.

This White paper is not an exhaustive technical guide on how SASSER operates and how to deal with it. Rather, it presents the said malware family as an event that has a unique context. Hence, this study is primarily concerned with SASSER’s behavior in relation to other chronological events and other malware families.

Source: The Sasser Event: History and Implications [PDF], from Trend Micro.

Visual Basic Worm Recipe

I found this in my blog monitoring for worm-related topics. It's a very simple mass mailer recipe, using Visual Basic to spread. While at first this may seem quite irresponsible of me to post it, think about how many mass-mailer detection and prevention systems are in place, and know that there are safeguards in place to prevent this from being a problem. Now, of course, be responsible when you use this. I hope you're using it to study the effects of malware on a test network and maybe to develop detection tools and improve the state of security.

Now the 1st thing we are going to do is show you what our worm we are going to create is going to preform. The worm we are going to create is w32.N00bie. This worm is not very powerfull but is good for the beginner. To be able to create this worm you will need Microsoft Visual Basic. Visual Basic is a RPD or Rapid Application Builder. We will now begin to make our 1st program in Visual Basic. Open up Visual Basic and select a Standrad .exe Program. Now, Visual Basic will load a Windows that is titled “Form1″ This is the main form for Visual Basic. This is your worm.

Source: Worm Writing Tutorial, November 20, 2005.

Trip Report: Worm05

Friday I went to The 3rd Workshop on Rapid Malcode (WORM) and heard some of the latest in worm-related research. I'll be focusing on some of the papers in the coming days and weeks, but two of the invited talks were quite interesting.

The first one of note was Invited talk: Scalable Internet Threat Monitoring by Stefan Savage (UCSD). He talked about two of the major research projects he's been involved in, the Ptomkin honeyfarm and Autograph. Both are large scale worm detection and characterization techniques. The honeyfarm project represents a major step forward in detecting worms using honeypots. The methods used in the project allow for massive amounts of stacking of guest systems on a single host, well beyond the limits possible in previous projects like iSink. Autograph, in turn, had been commercialized by Netsift (since acquired by Cisco). Again, scalability and fidelity beyond the levels which most other groups had been able to achieve before. Think "Honeycomb" on steroids.

The other invited talk of note was An Analysis of the Witty Outbreak: Exploiting Underlying Structure for Detailed Reconstructions of an Internet-scale Event by Vern Paxson (ICSI). What Paxson and his colleagues had been able to do was to take a large amount of data they had gathered on the Witty worm and, knowing how the worm generated its random target addresses and how the random function worked, they were able to do a number of things. They could reconstruct the number of infected hosts, how often they hit the disk with a piece of random damage, their uptime, and the initial site that was infected. All in all, a very impressive piece of work.

Wormboy

One of the things I saw on Friday at WORM05 was "Wormboy", a new tool released as part of a research project. The author, David Malan, is interested in using a Peer to Peer communication system of nodes to determine if any of their processes are possibly malware. The tool "Wormboy" examines a process's system calls and can determine if it's a suspicious pattern of behavior or not with pretty decent frequency.

To trace, as part of my research, the behavior of worms, we have implemented Wormboy, a kernel-mode driver for Windows XP with Service Pack 2 that inserts hooks into _KeServiceDescriptorTable before and after all but two system services. Inspired by Strace for NT, as well as by work by Nebbett and Dabak et al., Wormboy not only captures a call's service ID and input parameters, but also its output parameters and return value, along with a caller's name, process ID, thread ID, and mode.

Source: Wormboy website, where you can download the tool and test it out for yourself.

Worms and Viruses Are A Thing of the Past

Another writeup dismissing the worm and bot thing as "a thing of the past." I firmly believe that the death of the worm (or bot) is greatly exaggerated.

From the article:

Ok, now that we covered what classical trojans are all about, what's the deal with the RATs? How do they manage to get passed [sic] firewalls and antivirus running on the target system? Security companies announced that RATs can be found bundled with freeware; their favorite location is deep inside file-sharing applications and even electronic greeting cards. Now, who would have thought of such a thing? File sharing programs which include unwanted and dangerous software... well, nothing new about that. Kazaa used to be the champion of bundling spyware, adware and other such 'pleasant' surprises. RATs can also be found on porn sites and also inside online casinos. So if you plan on visiting such sites or using the applications mentioned earlier, don't be too surprised if you'll end up with a few 'gifts'.

Source: Worms and Viruses Are A Thing of the Past on SoftPedia, 13th of November 2005.

Think about it this way: if you're interested in spreading malware you thousands of users, would you go after hardened servers and hope to distribute your software via that site? You'd have to drive traffic to the site, as well, so you want to go after something pretty big or use major DNS injection. However, you know that these web servers are hardened or monitored, or worse they already have deals with adware and spyware distributors, so whatever you do gets caught in a matter of hours and taken down.

Or you can write software which autonomously goes from one to many hosts, persists for years, and can be updated.

I'll let you digest that one for a while.

One thing that we see time and time again is that worms like Code Red, Nimda, and Blaster, they all linger for years. The quantity of hosts infected with any of the RBot, Spybot or SDBot variants is huge, and they're all at peoples' disposal. This malware is very hard to get rid of, because it just keeps going. You can update it, and you can use many of the same techniques the "RAT" author (above) talks about. You can use rootkits to hide the processes and software, you can use droppers to bootstrap it on there, and you can use an IRC server to control your network. But you get it on there by using an epidemic spreading approach as opposed to the "herd and infect" model. You get it on there in the way that is going to get you the biggest bang for your effort and last the longest. You get it on there using automatic means.

The worm isn't going away for a long time, at least as a distribution model for malware. The bot is the worm's natural evolution (look at our "Future of ..." paper from 2001), the Trojan is another way to get the malware on there, and  all of these approaches can easily be automated in a worm-like approach.

A Hybrid Quarantine Defense

Since I'm at WORM05 today, I figured I'd post a paper from WORM04. Having worked on a quarantine approach in a commercial solution, it's interesting to me to look at other approaches. This one, as the title suggests, combines approaches and models the results. An interesting study, although a shorter paper.

We study the strengths, weaknesses, and potential synergies of two complementary worm quarantine defense strategies under various worm attack profiles. We observe their abilities to delay or suppress infection growth rates under two propagation techniques and three scan rates, and explore the potential synergies in combining these two complementary quarantine strategies. We compare the performance of the individual strategies against a hybrid combination strategy, and conclude that the hybrid strategy yields substantial performance improvements, beyond what either technique provides independently. This result offers potential new directions in hybrid quarantine defenses.

Source: A Hybrid Quarantine Defense, Phillip Porras, Linda Briesemeister, Keith Skinner, Karl Levitt, Jeff Rowe, Yu-Cheng Allen Ting.