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 26 PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/05/$20.00 © 2005 IEEE ■ IEEE SECURITY & PRIVACY Worms 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 persis- tent 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 ap- pearance 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.