worm blog

Is BGP Update Storm a Sign of Trouble: Observing the Internet Control and Data Planes During Internet Worms

I recall doing some analysis when SQLSlammer hit, and looking over the routing data I had available to me. It was a pretty disruptive 36 hours or so, honestly, and looking over the changes in the network, I saw an avergae of three BGP messages for every network that was affected. This appearantly mapped to a BGP withdaw message, an announcement, and then a path update message. What's interesting in this work is that they line up such BGP data with reachability measurements, which I did not have access to at the time.

There are considerable reasons to wish to understand the relationship between the Internet’s control and data planes in times for stress. For example, the much publicized Internet worms—Code Red, Nimda and SQL Slammer—caused BGP storms, but there has been comparatively little study of whether the storms impacted network performance. In this paper, we study these worm events and see whether the BGP storms observed during the worms actually corresponded to problems in the Internet’s data plane. By processing and analyzing two datasets from RIPE, we have found that while BGP update storms occurred in all three worms, the performance of the data plane degraded during the Slammer worm but did not during the Code Red and the Nimda. No direct correlation should be drawn between the degradation of the Internet data plane and the occurrence of a BGP update storm—it may not be a sign of trouble but a sign of the Internet control plane doing its job.

Source: Is BGP Update Storm a Sign of Trouble: Observing the Internet Control and Data Planes During Internet Worms, by Matthew Roughan, Jun Li, Randy Bush, Zhuoqing Mao and Timothy Griffin, Proceedings of SPECTS 2006.

Animations form CAIDA

Via Kamal (and in my inbox for far too long ...) ...

CAIDA has a neat set of animations over the years of various important worm events. SQLSlammer, Code Red, and Witty. They use a map tool and (presumably) GeoIP-type information along with their sensors to map the source of infected boxes and animate it over time. You can see things spread geographically.

All of this is in the Animations section of the CAIDA publications page.

Updated Microsoft Malware Removal Tool (Jan, 2006)

It's Patch Tuesday, and that means that Microsoft has updated their Malware Removal Tool. Detection this month focuses on some of the more prolific but "beneath the radar" malware:

• Parite
• Maslan
• Bofra

The full list of families detected and removed by the Windows Malware Removal Tool is listed on the website. The team responsible for the product are also blogging their work.

Updated Windows Defender Tool (Nov, 2005)

It's "patch Tuesday", the day when Microsoft releases their monthly patches (in this case, one fixup for November, 2005), and they also release updates to their malware removal tool. It now has a new name, too, Windows Defender, signifying it's larger purpose. The new families detected by this latest update to Windows Defender:

• Bugbear
• Codbot
• Mabutu
• Opaserv
• Swen

You can see the full list of families detected by the tool on the Microsoft website Families Cleaned by the Malicious Software Removal Tool. Remember, keep your AV policies current, always make sure you have the latest tool for the newest malware, and check on their sites for updates. You wont detect new threats with out of date tools.

Update: As noted in comments, the malicious software removal tool has not been renamed. I guess I'll still call it the MSRT in future posts.

Can a Network be Protected from Single-Packet Warhol Worms?

Given the recent back and forth debate over the wormability of a recent Snort bug (single UDP packet, a'la Witty), this paper couldn't be more timely.

Can a network be protected from single-packet Warhol worms? This paper generates and simulates random network environments to answer that question. The research assumes a perfect detection algorithm and varies the time required to perform the identification. Perfect detection alone is not sufficient; it must also be swift in recognizing threats as some cases presented here show that perfect detection offers no noticeable protection. The impact of other network factors on worm propagation and prevention are investigated as well, including: router participation in the prevention scheme, the percentage of routers involved in the traffic passing, and the ability for participating routers to communicate. The results are promising: realistic simulations without communication can protect over 50% of the network. The addition of communication increases that protection to over 80%. The key result is that emerging identification technologies such as LeBrea can be leveraged into viable automated network protection systems against single-packet worms.

Source: Can a Network be Protected from Single-Packet Warhol Worms?, Larry G. Irwin II & Richard J. Enbody.

Early Detection of BGP Instabilities Resulting from Internet Worm Attacks

This is an interesting proposal, but I'm not sure that routing disruptions are the right place to detect the spread of a worm. After all, the preceeding days' worth of posts showed how large the routing disruptions can be, but there's always some BGP disruption that is going on. What's more, only a small number of worms have truly impacted BGP routing tables.

The increasing incidences of worm attacks in the Internet and the resulting instabilities in the global routing properties of the Border Gateway Protocol (BGP) routers pose a serious threat to the connectivity and the ability of the Internet to deliver data correctly. In this paper we propose a mechanism to detect/predict the onset of such instabilities which can then enable the timely execution of preventive strategies in order to minimize the damage caused by the worm. Our technique is based on online statistical methods relying on sequential change-point and persistence filter based detection algorithms. Our technique is validated using a year's worth of real traces collected from BGP routers in the Internet that we use to detect/predict the global routing instabilities corresponding to the Code Red II, Nimda and SQL Slammer worms.

Source: Early Detection of BGP Instabilities Resulting from Internet Worm Attacks, S. Deshpande,  M. Thottan, B. Sikdar.

A first look at Saturday’s MS-SQL worm as seen by BGP activity recorded by the RIS project

Here's a very short (10 slides) slide deck presented at the RIPE 44 meting a couple of years ago. A first look at Saturday’s MS-SQL worm  as seen by BGP activity recorded by the RIS project, James Aldridge, Arife Vural, RIPE NCC New Projects group. It's some more routing information on the effect of SQLSlammer, showing that while the disruptions were very real and widespread, their impact was minimal when the larger Internet topology is taken into account.

Sapphire/Slammer Worm Impact on Internet Performance

SQLSlammer was one of the largest impacts on routing caused by the release of malicous code. This report looks at the effects and presents several measurements during the worm's outbreak in January, 2003.

Looking at all data we can conclude that the Internet did not come to a global "meltdown" even though some individual sites were highly affected by this worm. Sixty percent of the measured relations do not show any sign of deterioration. This indicates most backbone links were fine and the problems were localized in edge sites or their immediate upstream provider. Also, eleven of the thirteen root servers remained accessible.

This data clearly shows that many of the routine measurements taken by the RIPE NCC can be used to detect widespread problems in the Internet infrastructure and to differentiate them from local problems. This can be crucial information to NOCs at the time of a problem. We are investigating how we can combine this data and make it available in real time.

Source: Sapphire/Slammer Worm Impact on Internet Performance, James Aldridge, Daniel Karrenberg, Henk Uijterwaal and René Wilhelm, New Projects Group / RIPE NCC, February 10, 2003.

Analysis of the “SQL Slammer” worm and its effects on Indiana University and related institutions

This writeup is interesting, because it shows how a large university detected and dealt with the SQLSlammer worm. There's a lot of information on how a distributed setup played a role in mitigating this problem.

On November 2nd 1988 Robert Morris, then a Cornell University computer science graduate student, released the first Internet worm. Morris’s Worm, as it was known, exploited known flaws in the finger and sendmail services as well as in common webs of trust inherent in the rlogin facility. The worm’s only activity was that of replicating itself to as many hosts as possible. Towards that end, the worm searched local files (such as /etc/hosts) to identify machines to infect as well as scanning likely addresses in the local network. The worm did not damage files or otherwise disrupt operation of the infected machines; however the traffic volume generated by its replication attempts severely disrupted the global Internet, local enterprise networks, and the processing ability of the infected machines themselves. The Morris worm infected roughly 10 percent of Internet computers and cost an estimated 100 million dollars (156 million in 2003 dollars) to clean up.

Like the Morris worm, Slammer’s only disruptive activity was the traffic associated with its replication. SQL Slammer infected less than one in a thousand Internet computers, but its effect was much more dramatic. Slammer targeted random hosts, which is relatively inefficient, however a Slammer infected computer would try as many as 25,000 target addresses a second. The simplicity of the infection method, which required only a single packet to infect a vulnerable computer and, like Morris, exploited a known vulnerability, combined with the speed at which potential computers where probed, allowed Slammer to reach global proportions in less than eight minutes (it doubled in size every 8 seconds). Current estimates put the cost of Slammer at approximately one billion dollars – an order of magnitude more expensive than the Morris worm in constant dollars.

Source: Analysis of the “SQL Slammer” worm and its effects on Indiana University and related institutions, by Gregory Travis, Ed Balas, David Ripley, and Steven Wallace.

Back-Door'ed by the Slammer

Another SANS GIAC paper. This one studies the SQLSlammer/Sapphire worm and the disaster recovery process that took place when that worm hit.

On Sunday, January 26, 2003, The Company I work for was involved in an incident caused by SQLSlammer. What makes this particularly interesting is that the course of the infection happened from within the company, actually starting at our corporate headquarters. It found its way through a small 56k frame relay connection that had been monitored, but through a configuration mishap, the traffic was allowed through undetected. To make matters worse, a few days before we were hit, we had been in contact with another company that was infected and were taking precautions to avoid being infected ourselves.

The goal of this paper is show how the incident was handled, and demonstrate that even though you may think you're protected, it's imperative to double check your perimeter protection and have good lines of communication with sites that have direct access to your network. I also plan to touch upon the reasons behind not being sufficiently patched and the importance of patch management, along with how the incident was handled, and in parts, mis-handled.

In each of the 6 steps of incident handling: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned, I will describe how the process took place at the time of the incident and also add comments on how the incident could have been handled more efficiently with the knowledge attained from this class.

Source: Back-Door'ed by the Slammer, John Hally