Domain: silicondefense.com
Stories and comments across the archive that link to silicondefense.com.
Comments · 7
-
Hank: the response to snort
The OSS app known as Hank was pretty much written as a reponse to the short-comings of Snort.
It supports XML based network rules, and has really advanced things like an ACBM implementation
Sunny Dubey -
Re:Why do delinquents bother?
Not to nitpick, but the SQL Slammer worm appeared to be written in assembly. It is quite interesting to read through the source. [alt] [alt]
While the PRNG isn't of the highest quality, its brevity is what allowed it to spread so quickly. An infected system was sending out packets as fast as the outbound pipe could handle it. A smaller virus, even by a few bytes, would mean that much faster of an infection rate.
By and large, you're right about VBScript making for simple virii, but this isn't the one to use as an example. -
Analysis of the Slammer/Sapphire wormThis was posted on BugTraq:
From: "Nicholas Weaver"
A must read for anyone who wants to know about this worm. Its impact was huge--90% infection of all vulnerable hosts in 10 minutes . Even some E911 systems were knocked out. The internet routers at large were saturated with 120ms latency. Twice the speed of Code Red. All this with a simple PRNG scanning algorithm.
Date: Fri, 31 Jan 2003 6:09 PM
To: bugtraq@securityfocus.com
Subject: The Spread of the Sapphire/Slammer SQL Worm
We have completed our preliminary analysis of the spread of the Sapphire/Slammer SQL worm. This worm required roughly 10 minutes to spread worldwide making it by far the fastest worm to date. In the early stages the worm was doubling in size every 8.5 seconds. At its peak, achieved approximately 3 minutes after it was released, Sapphire scanned the net at over 55 million IP addresses per second. It infected at least 75,000 victims and probably considerably more.This remarkable speed, nearly two orders of magnitude faster than Code Red, was the result of a bandwidth-limited scanner. Since Sapphire didn't need to wait for responses, each copy could scan at the maximum rate that the processor and network bandwidth could support.
There were also two noteworthy bugs in the pseudo-random number generator which complicated our analysis and limited our ability to estimate the total infection but did not slow the spread of the worm.
The full analysis is available at
- http://www.caida.org/analysis/security/sapphire/
- http://www.silicondefense.com/sapphire/
- http://www.cs.berkeley.edu/~nweaver/sapphire/
David Moore, CAIDA & UCSD CSE
Vern Paxson, ICIR & LBNL
Stefan Savage, UCSD CSE
Colleen Shannon, CAIDA
Stuart Staniford, Silicon Defense
Nicholas Weaver, Silicon Defense and UC
Berkeley EECS -
And also useful...
I'm sure some of you would prefer the Windows version of Snort, put together by Silicon defense.
-
And also useful...
I'm sure some of you would prefer the Windows version of Snort, put together by Silicon defense.
-
Warhol, Flash, and Extortion worms
The next evolutionary step after the Warhol Worm is the Flash Worm and the Extortion Worm.
-
Worm Author's RestraintHas anyone stopped to notice how much restraint the worm writer is showing? Think a second. The person writing this thing was not an idiot. It required serious technical skills and probably a large investment of time and energy. Anyone who says "Oh, the worm author was so stupid for using a hard-coded IP addresss for whitehouse.gov" or "They must have been dumb to forget to seed their random number generator" is not looking carefully. The worm has always been carefully, purposefully shackled by its creator not to do too much harm. Did you read the eEye analysis? Or the CAIDA or Staniford stastical studies of the worm's spread? Some facts:
- The first version of the worm appeared on July 13 or so.
- It had an unseeded random number generator, so the IP's it scanned were a fixed sequence -- BUT it contained the code to seed the random number generator; this code was disabled.(*)
- Its DoS attack was set to bomb a particular fixed IP address, AND not even send the bomb packets if that IP could not be reached
- It contained code to deface web pages served making its presence very visable well before the bombing attack was scheduled to take place
- It contained code to deactivate its spread if a particular file (c:\notworm) was present.
- It contained code to deactivate its spread after the "attack phase" began
- On July 19, a second version was introduced.
- The second version re-enabled the random number generating seed but was otherwise no less shackled than the first version.
- This version spread exponentially, with growth finally being limited by the number of susceptible servers connected to the internet and the fact that it reached the time of the "attack phase"
- This version infected over 359,000 hosts in under 14 hours.
The point? The worm author has carefully controlled the attack to cause alarm but not do real damage. When the initial version failed to cause serious alarm, it was loosened slightly from its shackles but still extremely restrained. More to the point? If the worm author -- or anyone else among the thousands with the technical skills to do so -- chose to, they could DoS basically the whole internet. According to netsizer.com, there are about 121 million internet hosts right now, so that gives a ratio of 1 infected computer to 300 hosts. That sounds like too small of a ratio to DoS all of them, but remember to shut things down all that has to happen is to saturate bandwidth, not overload servers. The only reason we're using the net happily today is that the worm author and others with those skills choose to restrain themselves.
- The first version of the worm appeared on July 13 or so.