The Blaster Worm: Then and Now

Home , Blaster (computer worm), Code Red (computer worm), Patched (malware), Welchia

Worms The Blaster Worm: Then and Now

The Blaster worm of 2003 infected at least 100,000 Microsoft Windows systems and cost millions in damage. In spite of cleanup efforts, an antiworm, and a removal tool from Microsoft, the worm persists. Observing the worm’s activity can provide insight into the evolution of Internet worms.

MICHAEL n Wednesday, 16 July 2003, Microsoft and continued to BAILEY, EVAN Security Bulletin MS03-026 (www. infect new hosts COOKE, microsoft.com/security/incident/blast.mspx) more than a year later. By using a wide area network- FARNAM O announced a buffer overrun in the Windows monitoring technique that observes worm infection at- JAHANIAN, AND Remote Procedure Call (RPC) interface that could let tempts, we collected observations of the Blaster worm DAVID WATSON attackers execute arbitrary code. The flaw, which the during its onset in August 2003 and again in August 2004. University of Last Stage of Delirium (LSD) security group initially This let us study worm evolution and provides an excel- Michigan uncovered (http://lsd-pl.net/special.html), affected lent illustration of a worm’s four-phase life cycle, lending many Windows operating system versions, including insight into its latency, growth, decay, and persistence. JOSE NAZARIO NT 4.0, 2000, and XP. Arbor When the vulnerability was disclosed, no known How the Blaster worm attacks Networks public exploit existed, and Microsoft made a patch avail- The initial Blaster variant’s decompiled source code re- able through their Web site. The CERT Coordination veals its unique behavior (http://robertgraham.com/ Center and other security organizations issued advisories journal/030815-blaster.c). The Blaster worm can be over the next several days.1 Almost immediately, discus- launched in one of two ways: as the result of a successful sions of the vulnerability began appearing on security new infection or when a user reboots an already in- lists. By 26 July, HD Moore had published a working ex- fected machine. Once launched, the worm immedi- ploit, dcom.c, on the Full Disclosure mailing list ately starts the setup for further propagation by (http://lists.netsys.com/pipermail/full-disclosure/2003 choosing an address from the same local /16 (class B) -July/007092.html). address as the infected host. Next, it picks a random Scattered reports of attackers reusing the exploit number to determine whether to use the local /16 ad- emerged during the next several weeks; then, on Monday, dress it just generated or a completely random one. The 11 August, the first Blaster worm variant struck. Also bias is 60 percent toward a random address. Next, the known as MSBlast or Lovsan, the worm copied code di- worm randomly chooses the offset to determine rectly from the dcom.c exploit, added its own code, and whether to infect Windows 2000 or XP, with an 80 launched a coordinated denial-of-service (DoS) attack to percent bias toward XP. exhaust Windowsupdate.com’s resources using a Transmis- On certain system dates, the initial variant, sion Control Protocol (TCP) port 80 SYN flood. It also Blaster.A, then starts a thread to launch a DoS attack used the backdoor mechanism from the example exploit to against Windowsupdate.com. It makes no further calls transfer the worm payload to newly infected systems. to the random number generator, but repeatedly seeds Within its first week, the Blaster worm infected the random number with the number of milliseconds more than 100,000 Microsoft Windows systems. In since boot time. This indicates that the worm author spite of eradication efforts, the Blaster worm was alive significantly lacks understanding of random number

80k subnets Blaster.A still infected 11 Aug. 2003 Aug. 2004 Blaster.B 13 Aug. 2003 Blaster.B MS03-026 writer Removal 16 July 2003 HD Moore Welchia exploit 18 Aug. 2003 arrested tool Blaster.B 26 July 2003 31 Dec. 2003 writer sentenced

July 2003 August 2003 September 2003 2004 2005

Figure 1. A Blaster worm time line. Although a rapid succession of activity occurs around the worm’s initial release, its impact continues to be felt more than a year later. generators. (Others have discussed the impact of these worms not as acts of Internet vandalism but as serious poorly seeded random generators.2) The propagation crimes. Although the original Blaster.A author was setup is complete when the worm uses the previously never caught, authors of several other variants have generated starting address and exploit offset to attempt been apprehended.5,6 to infect 20 sequential addresses using 20 threads on TCP port 135. It repeats the target infection attempt on Worm measurement infrastructure the next 20 sequential addresses, indefinitely scanning We measured of the Blaster worm by using a globally an- IPv4 space in sequential order. If a connection attempt nounced but unused /8 (class A) network, which repre- to TCP port 135 is successful, the worm sends an RPC sents roughly 1/256 of the Internet, or approximately 16 bind command and an RPC request command contain- million addresses. This monitor is itself part of the Inter- ing the buffer overflow and exploit code. The exploit net Motion Sensor (IMS; http://ims.eecs.umich.edu), a opens a backdoor on TCP port 4444, which waits for network of distributed blackhole sensors that monitor further commands. The infecting system then issues a blocks of unused address space. Because no legitimate command to the newly infected system to transfer the hosts exist in an unused address block, any observed traf- worm binary using Trivial File Transfer Protocol fic destined for such addresses must be the result of mis- (TFTP) on UDP port 69 from the infecting system and configuration, backscatter from spoofed source execute it. addresses, or scanning from worms and other network Numerous Blaster variants—as well as several new probing. Prefiltering traffic in this way eliminates many families of worms that exploit the same initial RPC false positives when identifying malicious traffic and vulnerability—have appeared since its release, many of helps us avoid the scaling issues of other monitoring ap- them emerging within a few weeks of Blaster. Perhaps proaches (for a discussion of such approaches, see the the two most notable are the Welchia (http://security sidebar on p. 30). This technique goes by several names, response.symantec.com/avcenter/venc/data/w32.wel including network telescopes,7 blackholes,8,9 and dark- chia.worm.html) and SDBot (http://securityresponse. nets (www.cymru.com/Darknet/index.html). symantec.com/avcenter/venc/data/w32.randex.e.html) worms. Welchia, or Nachi as it’s sometimes called, was an The Blaster life cycle antiworm3 that attempted to patch the vulnerability and in August 2003 ended up causing significant damage of its own. SDBot One of the Blaster worm’s more interesting elements is was notable in that it used the same RPC vulnerability to that it provides an excellent example of a worm’s life install the SDBot kit, which creates a backdoor on the cycle. Although not all worms follow this cycle in its en- system that enables remote control of the infected system tirety, it’s still informative for understanding broad be- through Internet Relay Chat (IRC). haviors. As mentioned earlier, a four-phased worm life The Blaster worm’s impact wasn’t limited to a short cycle consists of latency, growth, decay, and persistence (see period in August 2003. A published survey of 19 re- Figure 2). search universities showed that each spent an average of Latency describes the time period between discov- US$299,579 during a five-week period to recover from ering a vulnerability and observing the appearance of a the Blaster worm and its variants.4 The cost of this worm in the wild. This period might include vulnerabil- cleanup effort has helped solidify a growing view of ity publication, patch release, and theoretical or working

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 27 Worms

ning for TCP port 135 against 256 contiguous addresses 15,000 began to diminish. Fitting this loss of worm activity to a Latency simple exponential decay, we calculated a half-life of Growth roughly 12 hours. This loss of activity continued for ap- Decay Persistence proximately four days. 10,000 Finally, most nondestructive worms enter a persistent phase in which a relatively small population of hosts remain infected. Following the decay phase, the observed Blaster activity reached a fairly consistent level. Figure 3 5,000 shows Blaster activity in late August 2003 compared to activity one year later. The initial growth in observations in August 2003 correlates with the Welchia worm’s appearance on 18 August. The last two days represent the Blaster activity per hour (unique IPs) steady state seen for the next several months. 0 10-8-2003 12-8-2003 14-8-2003 16-8-2003 18-8-2003 The Blaster worm a year later Date The Blaster worm was released roughly two years ago, providing ample opportunity for individuals and organi- Figure 2. The Blaster worm life cycle. The four phases shown include zations to clean up infected machines. We might thus the end of the latency phase, its growth phase, its decay phase, and expect the worm to decay quickly, with only a handful the beginning of its persistence phase. of hosts still infected in August 2004. In reality, a year later, the Blaster worm was not only still scanning the In- ternet, but the remaining infected population was larger exploits. Our measurement infrastructure observed that than expected. after the LSD group released its initial advisory and Mi- We performed observations for two months starting crosoft its advisory and patch, the number of unique hosts in August 2004 and discovered more than 200,000 scanning TCP port 135 increased from between four and unique IP addresses scanning our dark address monitor, 10 unique sources per day to between 100 and 300. Ad- with peaks of 4,100 unique addresses per day and 500 per ditionally, we observed several higher activity spikes dur- hour. Although the effects of the Dynamic Host Config- ing this period, each correlating to the release of uration Protocol (DHCP) can lead to overcounting,10 successive exploit tools from various underground indi- other effects, such as the Blaster worm’s slow scanning viduals or groups. rate and a host’s short daily operational lifetime, might In the growth phase, the worm strikes and begins lead to undercounting when we consider only daily or to infect the vulnerable population. We often use epi- hourly values. To evaluate the effects of DHCP over- demiological models from population growth and biol- counting, we analyzed the number of unique subnets. ogy to describe this period, and their application to We did this by evaluating only the first 24 bits of an ob- random scanning worms is well understood.10–12 Dur- served IP address, assuming that most DHCP-assigned ing the first few hours of its growth, the Blaster worm addresses are from a small pool of IP addresses in the local spread exponentially, with a doubling time of approxi- subnet. This analysis showed roughly 90,000 unique sub- mately nine minutes. However, as the worm’s preva- nets during the two-month period (August and Septem- lence increased, this doubling time slowed, and our ber 2004), suggesting a significant number of unique observations peaked at nearly 15,000 unique IP ad- infected hosts. dresses scanning TCP port 135 in a single, one-hour The activity in both the 2003 and 2004 observations period, with roughly 106,000 unique sources in a 24- displays a circadian pattern, with peak activity occurring hour period. Reverse Domain Name System (DNS) near midday in the eastern US (see Figure 3). Closer in- lookups for the active hosts during the peak hour of spection shows that, on average, Monday sees the most Blaster’s activity showed a global distribution of hosts traffic and Saturday the least. Additionally, the peak activ- (see Table 1). Upon analyzing the second-level domain ity typically occurs between 10:00 and 15:00 EST, which names, we see that the worm’s spread affected several roughly correspond to working hours in the eastern US consumer broadband providers. and suggests that the infected systems are power cycled The growth phase is followed by a decay phase in every day as workers and home users turn their comput- which infected systems are patched or removed from the ers on and off. network, or organizations deploy policies to minimize The fact that many old worms persist is not a new ob- the worm’s impact. Within eight hours of the worm’s ini- servation,13 but the huge number of unique hosts still in- tial outbreak, the number of unique hosts per hour scan- fected with Blaster is very surprising. Interestingly,

28 IEEE SECURITY & PRIVACY ■ JULY/AUGUST 2005 Worms

Microsoft released a Blaster removal tool on 6 January Table 1. Top-level domain (TLD) analysis of unique 2004 (www.microsoft.com/presspass/press/2004/feb source IPs on 11 August 2003 and one year later.* 04/02-24GIAISpr.asp) that was supposed to remove the worm executable and install the patch needed to prevent TLD AUGUST 2003 (%) AUGUST 2004 (%) reinfection. Although millions of users downloaded this tool, Blaster observations for January 2004 changed very net 39.3 34.2 little, suggesting that it had little effect on the infected com 15.4 19.6 population at large. Simply put, these persistent infec- jp 3.8 7.7 tions are due to people who either don’t know or don’t fr 3.1 2.1 care enough that their machines are infected. ca 1.8 1.3 One way to gain insight into the Blaster’s persistence de 1.7 5.3 is to compare the infected population observed during br 1.5 2.0 the outbreak with the infected population one year it 1.2 3.5 later. Looking first at reverse DNS data, we find that the au 1.2 0.0 two populations have similar demographics (see Table edu 1.1 0.1 1). A comparison of the number of US-based infec- *Roughly 40 percent of the addresses had reverse Domain Name System entries. tions during the outbreak with its persistent population shows them to both to be roughly 55 percent. Overall, the top-level domain distribution across countries 3,000 changed very little between outbreak and persistence. 2003 The number of infected systems in different countries 2,500 2004 appears to have remained relatively stable. However, the actual addresses have changed dramatically: 99.5 percent of persistent addresses aren’t found in the outbreak 2,000 population and vice versa. We also compared the identified Blaster populations 1,500 from August 2003 and August 2004, and tried to account for DHCP effects. It’s possible that several infected 1,000 hosts simply moved within the same LAN due to Blaster hosts per hour DHCP or other administrative decisions, so again we 500 compared only the first 24 bits of the host IP addresses. We found that 73 percent of the persistent addresses aren’t found in the outbreak population and 85 percent 0 of outbreak addresses aren’t found in the persistent pop- 19 Aug.20 Aug.21 Aug.22 Aug. 23 Aug.24 Aug.25 Aug.26 Aug.27 Aug.28 Aug.29 Aug. 30 Aug.31 Aug.1 Sept. ulation. Thus, a very significant movement exists between subnets. As a final test, we performed the same Date analysis comparing only the first 16 bits of the addresses and masking out the last 16. The results showed that 37 Figure 3. Unique Blaster hosts per hour. We measured this for late percent of persistent addresses aren’t found in the out- August 2003 and for the same period in 2004. Although the break population and 21 percent of outbreak addresses magnitude of the persistent population is less, the pattern that aren’t found in the persistent population. Hence, a sub- emerges in late August 2003 is still evident in August 2004. stantial churn still exists in the infected networks between the outbreak and infected populations. Acknowledgments This work was supported by the US Department of Homeland Security ur observations indicate that the Blaster worm (DHS) under contract number NBCHC040146, the Advanced Re- O isn’t going away anytime soon. Recent tools tar- search and Development Activity (ARDA) under contract number geted at eradicating it appear to have had little effect on NBCHC030104, and by a corporate gift from Intel Corporation. We the global population. Additionally, when we analyze thank all the IMS participants for their help and suggestions. We also the persistent population, we see that the infection ap- thank Dug Song, Robert Stone, and G. Robert Malan of Arbor Net- pears to have successfully transitioned to new hosts as works and Larry Blunk, Bert Rossi, and Manish Karir at Merit Net- the original systems are cleaned or shut off, suggesting work for their assistance and support. We thank Johannes Ullrich from that the Blaster worm, and other similar worms, will the SANS Internet Storm Center for sharing DShield data for compar- remain significant Internet threats for many years after ison. Finally, we thank the anonymous reviewers for their corrections their initial release. and helpful comments.

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 29 Worms

Worm-monitoring techniques

n contrast to monitoring unused address space—the technique onset, we were able to calculate the number of network blocks in I we used to monitoring the Blaster worm—other approaches to each region of the IPv4 space and determined which networks had monitoring worms and other global Internet threats monitor pro- infected hosts visible to each technique. Figure A shows the result duction networks with live hosts. In monitoring used networks, of this analysis. The horizontal axis in the figure ranges from 0 to systems can choose to watch traffic directly via fiber taps or span 255, showing each of the 256 possible first octets in IPv4 space. ports, or watch data abstractions, such as flow records, device The vertical axis shows the proportion of Blaster observations made alerts, or logs. Security devices are an important source of these using each method for each advertised address block. Although the abstractions; alerts and logs from host-based antivirus programs, unused address monitoring and firewall logs show similar visibility intrusion-detection systems, and firewalls can all help effectively in the networking space, neither technique saw infection attempts characterize worms. To achieve the scale required to monitor from nearly 95 percent of the routed networks. Whether the lack of broadly scoped threats, systems that use this direct monitoring observations from these blocks is the result of some policy deployed approach often aggregate data from tens of thousands of individual at these networks, an artifact of worm propagation, or the distri- devices into a global view (see http://analyzer.securityfocus.com). bution of the vulnerable hosts is unknown. Understanding the dif- Our observations of Blaster worm activity differ significantly ferences between these two perspectives of the vulnerable from Blaster observations performed using other methods. For population remains an interesting research problem. example, the Microsoft remove tool saw a completely different view of Blaster activity. Microsoft reported that this tool helped 1.0 clean 8 million infected computers in January 2004 (www. Telescope microsoft.com/presspass/press/2004/feb04/02-24GIAISpr.asp). Enterprise The maximum number of unique hosts per day we measured was 0.8 Both Neither 106,000. To understand these differences, we compared the observations from our network monitor to data collected from 0.6 DShield (www.dshield.org). The DShield approach to network monitoring aggregates information from tens of thousands of indi- 0.4 vidual security devices throughout the network. During Blaster’s onset, DShield saw a maximum number of 208,000 unique IP 0.2 addresses scanning TCP port 135. Prior to the initial Blaster worm

attack, DShield saw roughly 7,000 unique IP address scanning this Proportion of Blaster observations port. Although these two methods saw roughly the same order of 0 50 100 150 200 250 infections, these numbers differ signiﬁcantly from the values Octets in IPv4 space Microsoft reported. To explore where these differences might have come from, we Figure A. The percentage of routed networks with Blaster examined the distribution of the source IP addresses from both our activity recorded by two different network-monitoring unused network monitor and the DShield data. By examining a techniques. BGP routing table from 11 August 2003, just before the worm’s

References tence,” Seattle Times, Business and Technology section, 29 1. CERT Coordination Center, “CERT Advisory CA- Jan. 2005. 2003-20 W32/Blaster worm,” Aug. 2003; www.cert. 6. P. Roberts, “Suspected Blaster-F Author Nabbed,” PC org/advisories/CA-2003-20.html. World, 3 Sept. 2003; www.pcworld.com/news/article/ 2. E. Cooke, Z.M. Mao, and F. Jahanian, Worm Hotspots: 0,aid,112308,00.asp. Explaining Non-uniformity in Worm Targeting Behavior, tech. 7. D. Moore, G.M. Voelker, and S. Savage, “Inferring Inter- report CSE-TR-503-04, Dept. Electrical Eng. and net Denial-of-Service Activity,” Proc. 10th Usenix Secu- Computer Science, Univ. of Michigan, 2004. rity Symp., Usenix Assoc., 2001, pp. 9–22. 3. F. Castaneda, E.C. Sezer, and J. Xuy, “Worm vs. Worm: 8. M. Bailey et al., “The Internet Motion Sensor: A Dis- Preliminary Study of an Active Counter-Attack Mech- tributed Global Scoped Internet Threat Monitoring Sys- anism,” Proc. 2004 ACM Workshop Rapid Malcode tem,” Proc. Network and Distributed System Security Symp. (WORM 04), ACM Press, 2004, pp. 83–93. (NDSS 05), Internet Soc., 2005. 4. A.L. Foster, “Colleges Brace for the Next Worm,” Chron- 9. D. Song, R. Malan, and R. Stone, “A Snapshot of Global icle of Higher Education, vol. 50, no. 28, 2004, p. A29. Internet Worm Activity,” Proc. 1st Conf. Computer Secu- 5. K. Peterson, “Blaster Hacker Receives 18-Month Sen- rity Incident Handling and Response, 2002; www.4law.co.

30 IEEE SECURITY & PRIVACY ■ JULY/AUGUST 2005 Worms

il/Le288.htm. Internet measurement, and distributed systems. Cooke has BS 10. C. Shannon, D. Moore, and J. Brown, “Code-Red: A degrees in electrical engineering, computer science, and psy- chology from the University of Wisconsin and an MS in com- Case Study on the Spread and Victims of an Internet puter science from the University of Michigan. Contact him at Wor m,” Proc. Internet Measurement Workshop (IMW), [email protected]. ACM Press, 2002, pp. 273–284. 11. S. Staniford, V. Paxson, and N. Weaver, “How to Own Farnam Jahanian is a professor of electrical engineering and the Internet in Your Spare Time,” Proc. 11th Usenix Secu- computer science at the University of Michigan and cofounder of Arbor Networks. His research interests include distributed rity Symp., Usenix Assoc., 2002, pp. 149–167. computing, network security, and network architectures. Jahan- 12. C. Changchun et al., “Monitoring and Early Warning ian has an MS and a PhD in computer science from the Uni- for Internet Worms,” Proc. 10th ACM Conf. Computer and versity of Texas at Austin. Contact him at [email protected]. Comm. Security, ACM Press, 2003, pp. 190–199. 13. D. Song, R. Malan, and R. Stone, A Snapshot of Global Inter- David Watson is a postdoctoral research fellow at the Univer- sity of Michigan. His research interests include network routing net Worm Activity, tech. report, Arbor Networks, June 2002. protocols and network infrastructure security Watson has a BS in computer science from Carnegie Mellon University, and an Michael Bailey is a graduate student and program manager at MSE and PhD in computer science from the University of Michi- the University of Michigan, and a former director of engineer- gan. Contact him at [email protected]. ing at Arbor Networks. His research interests include the security and availability of complex distributed systems. Bailey has Jose Nazario is a software and security engineer at Arbor Net- a BS in computer science from the University of Illinois at works. His research interests include worm detection techniques, Urbana-Champaign and an MS in computer science from distributed denial-of-service activity, and large-scale Internet DePaul University. Contact him at [email protected]. measurements. Nazario has a BA in biology from Luther Col- lege and a PhD in biochemistry from Case Western Reserve Uni- Evan Cooke is a PhD candidate at the University of Michigan versity. He is the author of Defense and Detection Strategies and a lead researcher on the Internet Motion Sensor (IMS) pro- Against Internet Worms (Artech House, 2003). Contact him ject. His research interests include network security, large-scale at [email protected]. Put Your Mark on Security

Submitting an article to Write for IEEE Security & Privacy magazine is easy. Log onto Manuscript Central at http:// cs-ieee.manuscriptcentral.com/. Please visit Authors must use Manuscript Central to upload their www.computer.org/ submissions. First-time users security/author.htm must create a new account. for a full description

CONTENT AND STYLE STANDARDS Successful articles tell a story: they define a problem, advocate solutions, describe how and why the solutions are appropriate, and close by putting the topic in perspective and perhaps indicating a direction for future work. Organize and write your article concisely and clearly; make your style informal, direct, and lively. Use active voice (“We discovered ...” rather than “It was discovered ...”). In the first few paragraphs, tell why your subject is significant in the field of security and privacy. Explain any field-specific vocabulary, preferably with examples. Include an annotated Further Reading List for readers who want to explore further. Describe each item listed in a few sentences.