Today is the 10 year anniversary of the SQL Slammer worm.Since I have a unique history with this, I thought I’d write up something.
Historically, most worms were named by anti-virus (AV)companies, since AV was often the first to detect new malware. In this case,the name “Slammer” came from an intrusion detection company “Internet SecuritySystems” or “ISS” (now a division of IBM). That’s because Slammer wasn’t thesort of thing AV was designed to detect. For one thing, it never existed as afile on the disk.
Worms were the sort of thing intrusion detection systems(IDS) were designed to detect. Whereas AV scanned the disk looking for signs ofmalware, IDS scanned network traffic looking for signs of hacker activity.Slammer used a buffer overflow exploit in order to propagate just like howhackers use buffer overflow exploits to break into computers.
The thing about Slammer is that virtually all IDSs failed atdetecting it. If they did anything, they triggered on “UDP flood” or “UDP portscan”. Early traffic on the NANOG mailing list described it as a new DDoS(Distributed Denial of Service) attack. That’s because high levels of UDPtraffic had been seen for previous DDoS attacks, but never before with a worm.
However, ISS’s product could detect Slammer for what it was:a worm exploiting a buffer overflow. The exact name of the event was “SQL_SSRP_StackBo”
The reason we could detect this was because ISS used a“vulnerability signature”. What hackers do is composed of two parts. The firstis the bug, weakness, or “vulnerability” that can be leveraged by the hacker togain access to the system. The second is a tool, software, or “exploit” thatuses the vulnerability. Historically, IDS focused on detecting known exploits.When hackers created new unknown exploits for known vulnerabilities, IDS had toupdate their products with new “signatures” to recognize the new exploits.ISS’s technology was different. By writing signatures based on thevulnerability, we could detect any unknown exploits targeting thatvulnerability.
A common type of vulnerability is the buffer overflow, wherehackers send too much data in a protocol field or “buffer”, thus “overflowing”it. The way to detect this class of vulnerability is to measure the length ofthe buffer, and trigger when it exceeds a threshold.
In order to measure the length of buffers we first had tofind buffers. Historically, IDS treated network payloads as just a string ofundifferentiated bytes. This meant that they couldn’t figure out where buffersstarted and stopped, and hence could not measure their lengths. For our IDS, wedid what’s known as a “protocol decode”, finding the start/stop of everyfield/buffer in the payload.
Since a typical payload contains hundreds of fields, thissounds slow. However, we used a technology called “state machines” to processthese fields. State machines are extremely fast, faster even than the patternmatching used in traditional IDS.
Today, most IDS uses these protocol state machines and havethe ability to measure the length of buffers and trigger on them. But back in2003, this was unique to ISS’s technology.
The consequence of this was ISS could detect the new unknownexploit used by the worm against a known vulnerability, whereas other IDSscouldn’t.
But there is more to the story than just detection. Anotherinteresting feature is that ISS IDS sensors could survive the onslaught.
What was interesting about Slammer is the way it created aflood of UDP packets. A single infected machine could fill a gigabit Ethernetlink with roughly 300,000 packets/second. At the time, most IDS products couldnot handle packets at that rate. The problem was that most IDS was written ontop of traditional operating systems (Windows, Linux, etc.). Operating systemscould not handle packets at that rate, and would lock up in their interrupthandlers.
ISS’s technology was unique because it wrote its own networkdrivers that bypassed the operating system. Thus, even though technically theyran on Linux, their drivers didn’t, so whereas other products would be crushedunder the load of 300,000 packets/second, ISS could handle about 2 millionpackets/second.
At the time there was some drama in the industry caused byGartner who claimed that IDS products needed to be based on “hardware” (customASIC chips) instead of “software” for this reason. They claimed that softwarerunning on traditional operating systems could not keep up with traffic, andthus, IDS needed to be based on hardware. The ISS technology straddled bothworlds. It was purely “software”, but by having custom drivers that bypassedthe operating system, it was in fact faster than any competing “hardware”products.
Months later, a large government customer invited some IDS people like myself (Dug Song, Marty Roesch, Greg Shipley, and some others I can't recall off the top of my head) to debate with the Gartner analyst his claims that "no IDS could handle more than 500mbps". Also there were the customer's own IT people running my product, who then described how my product could handle the Slammer worm at 800mpbs on their network with only the problem that there was a slight delay in events reaching the console -- whereas everything else in their network fell over under the onslaught. Despite this first hand evidence given to the analyst, he still claimed afterward that no software IDS like mine could keep up with traffic above 500mbps.
Today, things have changed. Drivers bypassing the operatingsystem kernel are now common. There is an open-source project that does thiscalled PF_RING, and a closed product form Intel called DPDK. Using theirsoftware and a normal server (single-socket 8 core Sandy Bridge at 2 GHz),Intel has benchmarked their system at being able to forward traffic at a rateof 80 million packets/second. This is in fact faster than any “hardware” systemanywhere close to the same price, form factor, or power consumption. Thus,today in 2013, this is extreme level of performance is normal, but back in2003, it was unusual.
These two features are having a signature and keeping upwith traffic are still incomplete. Each packet would trigger an event.Therefore, at 300,000 packets/second caused by Slammer, a typical IDS would tryto log 300,000 events/second. The event handling system can’t handle this rate,but if it could, it would quickly fill up the database.
The ISS technology had a unique feature called the“coalescer”. It would automatically combine multiple identical events into asingle event. Thus, each event that went through the system would have twotimestamps of the first and last original events, and a count of the number oforiginal events that were combined into a single event.
The coalescer didn’t just reduce “identical” events but also“similar” events. It would look for patterns like the same attack sweepingacross many machines – just like a worm. It would then combine these and changethe target from a single IP address to a range of IP addresses.
The consequence was that the 300,000 Slammer events/secondwere automatically reduced to a rate of about 500 events/second. The systemcould handle this smaller rate, and they didn’t fill up the databse. Moreover,the management console also did it’s own “coalescing”, so only a single “SQL_SSRP_StackBo”showed up on the console with a rapidly increasing “count” field.
Today, as far as I can tell, no other IDS has a featuresimilar to the “coalescer", and suffer from event overloads. The best thatthey do is for known worms like Slammer is to trigger on the first event everyminute, but then discard additional events, thus losing a huge amount ofinformation. In contrast, the ISS coalescer keeps a 100% accurate count ofprecisely the number of SQL Slammer packets it detected. If you sent precisely1.0 billion SQL Slammer packets, you’ll see the 1.0 billion count appear on theconsole – even though the precise number of events in the database will beconsiderably less.
The reason the ISS technology performed so well with Slammerwas because I designed to do so back in 1998.
Back in 1998 I left McAfee (aka. Network Associates) tocreate my own company to specifically target network worms. I believed (andturned out to be right) that worms were coming that would devastate theInternet. Therefore, I designed from scratch an anti-worm technology. Thistechnology is now known as the “intrusion prevention system” or “IPS”. They wayit would work is that it would forward traffic like a router/firewall/bridge,but filter out malicious traffic from hackers/worms.
I called my company “Network ICE” and called my product“BlackICE”.
BlackICE ran in three modes. The first was the traditionalIDS, which we called “BlackICE Sentry”. The second was IPS inline mode, whichwe called “BlackICE Guard”. The third was in IPS mode on the desktop, which wecalled “BlackICE Defender”.
My company was bought by ISS in 2001, whereas it wasrebranded as “RealSecure”. ISS itself was bought by IBM in 2006, and theproduct is now branded as “Proventia”.
The reason I write this retrospective of Slammer is becauseof the frustration I had 10 years ago. My product dealt with Slammer extremelywell, as I’d designed it five years previously. It had a “vulnerabilitysignature” that could detect it, it could keep up with the packet load, and itdidn’t fall over from the event load. No competing product could say the same.Yet, EVERY competing security vendor came out with marketing blurbs extollingthe virtues of their product with regards to Slammer. This has taught me animportant lesson: it’s pointless trying to be clever trying to outwit thehacker, all you really need to succeed in this industry is good marketing thatoutwits the customers.
Hiç yorum yok:
Yorum Gönder