Addressing The Threat of Internet Worms Vern Paxson ICSI Center for Internet Research and Lawrence Berkeley National Laboratory April 14, 2005

Outline Worms as seen in the wild “Better” worms: likely evolution Detection & defense CCEID: Collaborative Center for Internet Epidemiology and Defenses -- UCSD (Prof. Stefan Savage) & ICSI

What is a Worm? Self-replicating/self-propagating code. Spreads across a network by exploiting flaws in open services. –As opposed to viruses, which require user action to quicken/spread –Enabled by Internet’s open communication model plus lack of implementation diversity

The Morris Worm: Nov First large-scale worm Targeted VAX, Sun Unix systems Spread by –Scanning the local subnet –Mining /etc/passwd, /etc/hosts.equiv/.rhosts for targets –Exploiting a fingerd buffer overflow –Exploiting sendmail’s DEBUG mode (not a bug!!) Included code to –Crack passwords (including 400-word obfuscated dictionary) –Detect co-resident worm processes –Die off if magic global is set –Phone home to ernie.berkeley.edu (buggy) 6-10% of all Internet hosts infected

Code Red: July/Aug Initial version released July 13, Exploited known bug in Microsoft IIS Web servers. Payload: web site defacement –HELLO! Welcome to Hacked By Chinese! –Only done if language setting = English

Code Red of July 13, con’t 1 st through 20 th of each month: spread. 20 th through end of each month: attack. –Flooding attack against … –… i.e., Spread: via random scanning of 32-bit IP address space. But: failure to seed random number generator  linear growth.

Code Red, con’t Revision released July 19, White House responds to threat of flooding attack by changing the address of Causes Code Red to die for date ≥ 20 th of the month due to failure of TCP connection to establish. But: this time random number generator correctly seeded. Bingo!

Measuring Internet-Scale Activity: Network Telescopes Idea: monitor a cross-section of Internet address space to measure network traffic involving wide range of addresses –“Backscatter” from DOS floods –Attackers probing blindly –Random scanning from worms LBNL’s cross-section: 1/32,768 of Internet –Small enough for appreciable telescope lag UCSD, UWisc’s cross-section: 1/256.

Spread of Code Red Network telescopes give lower bound on # infected hosts: 360K. (Beware DHCP & NAT) Course of infection fits classic logistic. Note: larger the vulnerable population, faster the worm spreads. That night (  20 th ), worm dies … … except for hosts with inaccurate clocks! It just takes one of these to restart the worm on August 1 st …

Striving for Greater Virulence: Code Red 2 Released August 4, Comment in code: “Code Red 2.” –But in fact completely different code base. Payload: a root backdoor, resilient to reboots. Bug: crashes NT, only works on Windows Localized scanning: prefers nearby addresses. Kills Code Red I. Safety valve: programmed to die Oct 1, 2001.

Striving for Greater Virulence: Nimda Released September 18, Multi-mode spreading: –attack IIS servers via infected clients – itself to address book as a virus –copy itself across open network shares –modifying Web pages on infected servers w/ client exploit –scanning for Code Red II backdoors (!)  worms form an ecosystem! Leaped across firewalls.

Code Red 2 kills off Code Red 1 Code Red 2 settles into weekly pattern Nimda enters the ecosystem Code Red 2 dies off as programmed CR 1 returns thanks to bad clocks

Code Red 2 dies off as programmed Nimda hums along, slowly cleaned up With its predator gone, Code Red 1 comes back!, still exhibiting monthly pattern

Life Just Before Slammer

Life Just After Slammer

A Lesson in Economy Slammer exploited connectionless UDP service, rather than connection-oriented TCP. Entire worm fit in a single packet!  When scanning, worm could “fire and forget”. Stateless! Worm infected 75,000+ hosts in 10 minutes (despite broken random number generator). –At its peak, doubled every 8.5 seconds Progress limited by the Internet’s carrying capacity (= 55 million scans/sec)

Modeling Worm Spread Often well described as infectious epidemics –Simplest model: Homogeneous random contacts Classic SI model –N: population size –S(t): susceptible hosts at time t –I(t): infected hosts at time t –  : contact rate –i(t): I(t)/N, s(t): S(t)/N

The Usual Logistic Growth

Slammer’s Bandwidth-Limited Growth

Blaster Released August 11, Exploits flaw in RPC service ubiquitous across Windows. Payload: attack Microsoft Windows Update. Despite flawed scanning and secondary infection strategy, rapidly propagates to 8 million (?!) hosts. Actually, bulk of infections are really Nachia, a Blaster counter-worm. Key paradigm shift: the “perimeter” is gone.

80% of Code Red 2 cleaned up due to onset of Blaster Code Red 2 re- released with Oct die-off Code Red 1 and Nimda endemic Code Red 2 re-re- released Jan 2004 Code Red 2 dies off again

Attacks on Passive Monitoring Exploits for bugs in read-only analyzers! Suppose protocol analyzer has an error parsing unusual type of packet –E.g., tcpdump and malformed options Adversary crafts such a packet, overruns buffer, causes analyzer to execute arbitrary code

Witty Released March 19, Single UDP packet exploits flaw in the passive analysis of Internet Security Systems products. “Bandwidth-limited” UDP worm ala’ Slammer. Vulnerable pop. (12K) attained in 75 minutes. Payload: slowly corrupt random disk blocks. Flaw had been announced the previous day. Written by a Pro. Detailed telescope analysis reveals worm targeted a US military base and was launched from a European retail ISP account.

What if Spreading Were Well-Designed? Observation (Weaver): Much of a worm’s scanning is redundant. Idea: coordinated scanning –Construct permutation of address space –Each new worm starts at a random point –Worm instance that “encounters” another instance re-randomizes.  Greatly accelerates worm in later stages. Also note: worm can spread & then stop.

What if Spreading Were Well-Designed?, con’t Observation (Weaver): Accelerate initial phase using a precomputed hit-list of say 1% vulnerable hosts.  At 100 scans/worm/sec, can infect huge population in a few minutes. Observation (Staniford): Compute hit-list of entire vulnerable population, propagate via divide & conquer.  With careful design, 10 6 hosts in < 2 sec!

What if Spreading Were Well-Designed?, con’t Observation (Morris): worms don’t need to randomly scan Meta-server worm: ask server for hosts to infect (e.g., Google for “ powered by phpbb ”) Topological worm: fuel the spread with local information from infected hosts (web server logs, address books, config files, SSH “known hosts”)  No scanning signature; with rich inter- connection topology, potentially very fast.

What if Spreading Were Well-Designed?, con’t Contagion worm: propagate parasitically along with normally initiated communication. E.g., using 2 exploits - Web browser & Web server - infect any vulnerable servers visited by browser, then any vulnerable browsers that come to those servers. E.g., using 1 P2P exploit, glide along immense file sharing networks in days/hours.  No unusual connection activity at all! :-(

What can be done?* Recall SI model: –N: population size –S(t), I(t): susceptible/infectible hosts at time t –  : contact rate Reduce the number of susceptible hosts –Prevention, reduce S(t) while I(t) is still small (ideally reduce S(0)) Reduce the contact rate –Containment, reduce  while I(t) is still small * Much of this framing of the material is courtesy Stefan Savage.

Prevention Host-based: –Make the monoculture hardier –Diversify the monoculture Network-based: –Keep vulnerabilities inaccessible Cisco’s Network Admission Control –Frisk hosts that try to connect, block if vulnerable Microsoft’s Shield –Shim-layer blocks network traffic that fits known vulnerability (rather than known exploit )

Containment Reduce contact rate Slow down –Throttle connection rate to slow spread Twycross & Williamson, Implementing and Testing a Virus Throttle, USENIX Sec ‘03 –Important capability, but worm still spreads… Quarantine –Detect and block worm

Outbreak Detection/Monitoring Classes of detection –Scan detection: detect infected hosts by their propagation attempts –Host detection: detect that network activity resulted in violation of programming model –Signature inference: automatically identify content signature for exploit (sharable) Classes of monitors –Observing actual victims –Creating your own victims (Honeynets)

Scan Detection Indirect scan detection –Berk et al, Designing a Framework for Active Worm Detection on Global Networks (ICMP) –Wong et al, A Study of Mass-mailing Worms, WORM ’04 –Whyte et al. DNS-based Detection of Scanning Worms in an Enterprise Network, NDSS ‘05 Direct scan detection –Weaver et al. Very Fast Containment of Scanning Worms, USENIX Sec ’04 Threshold Random Walk – bias source based on connection success rate (Jung et al); use approximate state for fast HW implementation Multi-Gbps design, detect scan in 5-10 attempts Few false positives: Gnutella (peer access), Windows File Sharing (benign scanning) –Venkataraman et al, New Streaming Algorithms for Fast Detection of Superspreaders, NDSS ‘05

Telescopes + Active Responders Problem: Telescopes are passive, can’t respond to TCP handshake –Can’t determine payload Solution: proxy responder –Stateless: TCP SYN/ACK (Internet Motion Sensor), per-protocol responders (iSink) –Stateful: Honeyd –Can differentiate and fingerprint payload False positives generally low since no regular traffic

HoneyNets Problem: what will payload do? No code executes. Solution: redirect scans to real “infectible” hosts (honeypots) –Individual hosts or VM-based: Collapsar, HoneyStat, Symantec –Can reduce false positives/negatives with host-analysis (e.g. TaintCheck, Vigilante, Minos) and behavioral/procedural signatures Challenges –Scalability, liability, detection by malware

Honeynets: Not a Panacea Depends on worms scanning it –What if don’t scan that range (smart bias)? –What if propagate via , IM, topologically? Background radiation is a big pain –How do you weed out the boring same-old / same- old ? It comes in zillions of variants. Just how realistic can your environment be? –What if code you’re executing wants to make outbound connections of various sorts? E.g., TFTP, HTTP, DNS, …

Signature inference Idea: look for unusual repeated content –Can work on non-scanning worms –Key off many-to-many communication to avoid confusion w/ non-worm sources –“Content Sifting” systems can distill signatures: Singh et al, Automated Worm Fingerprinting, OSDI ’04 Kim et al, Autograph: Toward Automated, Distributed Worm Signature Detection, USENIX Sec ‘04 –But: what about polymorphic worms?

Once You Have A Live Worm, Then What? Containment –Use distilled signature to prevent further spread –Different granularities possible: Infectees (doesn’t scale well) Content (or more abstract activity) description Vulnerable population Would like to leverage detections by others –But how can you trust these? –What if it’s an attacker lying to you to provoke a self-damaging response? (Or to hide a later actual attack)

Once You Have A Live Worm, Then What?, con’t Proof of infection –Idea: alerts come with a verifiable audit trail that demonstrates the exploit, ala’ proof-carrying code Auto-patching –Techniques to derive (and test!) patches to fix vulnerabilities in real-time (Excerpt from my review: “Not as crazy as it sounds”) Auto-antiworm –Techniques to automatically derive a new worm from a propagating one, but with disinfectant payload (This one, on the other hand, is as crazy as it sounds)

Final Thoughts The big worry these days isn’t worms but phishing and spyware –These are dicey because there’s money involved  Arms race There’s nothing to stop attackers from using worms to help with their phishing & spyware –Plus viruses, botnets / spam, DDOS-for-hire –“Blended threats” Key question: how will the arms race evolve? –A series of gradual steps, with time to adapt/respond … –… Or?