Transcript 127sp09Lec10 - Systems and Networking

CSE 127
Computer Security
Spring 2009
Network worms and worm defense
Stefan Savage
Network Worms


Programs that actively spread between
machines
Infection strategy more active



2
Exploit buffer overflows, format bugs, etc
Exploit bad password choice
Entice user into executing program
Network Worms in action

Self-propagating self-replicating network program


Exploits some vulnerability to infect remote machines
Infected machines continue propagating infection
3
A brief history of worms…

As always Sci-Fi authors get it right first



Shoch&Hupp co-opt idea; coin term “worm” (1982)



Gerold’s “When H.A.R.L.I.E. was One” (1972) – “Virus”
Brunner’s “Shockwave Rider” (1975) – “tapeworm
program”
Key idea: programs that self-propagate through network to
accomplish some task; benign
Fred Cohen demonstrates power and threat of selfreplicating viruses (1984)
First significant worm in the wild: Morris worm
(1988)
4
History: Morris Internet Worm




November 2, 1988
Infected around 6,000 major Unix machines
Cost of the damage estimated at $10m - $100m
Robert T. Morris Jr. unleashed Internet worm





5
Graduate student at Cornell University
Convicted in 1990 of violating Computer Fraud and Abuse Act
$10,000 fine, 3 yr. Suspended jail sentence, 400 hours of
community service
Son of the chief scientist at the National Computer Security
Center -- part of the National Security Agency
Today he’s a professor at MIT (and a great guy I might add)
Morris Worm Transmission

Find user accounts on the target machine



Exploit bug in fingerd


Classic buffer overflow attack
Exploit trapdoor in sendmail

6
Dictionary attack on /etc/passwd
If it found a match, it would log in and try the same
username/password on other local machines
Programmer left DEBUG mode in sendmail, which allowed
sendmail to execute an arbitrary shell command string.
Morris Worm Infection

Sent a small loader to target machine





7
99 lines of C code
It was compiled on the remote platform (cross
platform compatibility)
The loader program transferred the rest of the
worm from the infected host to the new target.
Used authentication! To prevent sys admins from
tampering with loaded code.
If there was a transmission error, the loader would
erase its tracks and exit.
Morris Worm Stealth/DoS

When loader obtained full code





Worm periodically changed its name and process ID
Resource exhaustion



Denial of service (accidental)
There was a bug in the loader program that caused many
copies of the worm to be spawned per host
System administrators cut their network connections

8
It was put into main memory and encrypted
Original copies were deleted from disk
(Even memory dump wouldn’t expose worm)
Couldn’t use internet to exchange fixes!
Odd observation

Between the late 80s and late 90s there are
basically no new worm outbreaks…
April 8, 2016
CSE 127 -- Lecture 5: User Authentication
9
The Modern Worm era

Email based worms in late 90’s (Melissa & ILoveYou)


CodeRed worm released in Summer 2001





Infect >1M hosts, but requires user participation
Exploited buffer overflow in IIS; no user interaction
Uniform random target selection (after fixed bug in CRv1)
Infects 360,000 hosts in 10 hours (CRv2)
Like the energizer bunny… still going years later
Energizes renaissance in worm construction (1000’s)




10 
Exploit-based: CRII, Nimda, Slammer, Blaster, Witty, etc…
Human-assisted: SoBig, NetSky, MyDoom, etc…
6200 malware variants in 2004; 6x increase from 2003 [Symantec]
>200,000 malware variants in first 6mos of 2006 [Symantec]
Convergence w/SPAM, DDoS, Spyware, IdTheft, BotNets
The worm threat by metaphor

Imagine the following species:







Poor genetic diversity; heavily inbred
Lives in “hot zone”; thriving ecosystem of infectious
pathogens
Instantaneous transmission of disease
Immune response 10-1M times slower
Poor hygiene practices
What would its long-term prognosis be?
What if diseases were designed…


11
Trivial to create a new disease
Highly profitable to do so
Technical enablers for worms

Unrestricted connectivity


Software homogeneity & user naiveté




12
Large-scale adoption of IP model for networks &
apps
Single bug = mass vulnerability in millions of hosts
Trusting users (“ok”) = mass vulnerability in millions
of hosts
Few meaningful defenses
Effective anonymity (minimal risk)
How to think about outbreaks

Worms well described as infectious epidemics


Simplest model: Homogeneous random contacts
Classic SI model
dI
IS


» N: population size
dt
N
» S(t): susceptible hosts at time t dS
IS



» I(t): infected hosts at time t
dt
N
» ß: contact rate
» i(t): I(t)/N, s(t): S(t)/N
courtesy Paxson,
Staniford, Weaver
di
  i (1  i )
dt
e  (t T )
i (t ) 
1  e  (t T )
13
What’s important?

There are lots of improvements to this model…





… but the conclusion is the same. We care about two
things:
How likely is it that a given infection attempt is
successful?



Chen et al, Modeling the Spread of Active Worms, Infocom 2003 (discrete time)
Wang et al, Modeling Timing Parameters for Virus Propagation on the Internet ,
ACM WORM ’04 (delay)
Ganesh et al, The Effect of Network Topology on the Spread of Epidemics,
Infocom 2005 (topology)
Target selection (random, biased, hitlist, topological,…)
Vulnerability distribution (e.g. density – S(0)/N)
How frequently are infections attempted?

14
ß: Contact rate
What can be done?

Reduce the number of susceptible hosts


Reduce the number of infected hosts


Treatment, reduce I(t) after the fact
Reduce the contact rate

15
Prevention, reduce S(t) while I(t) is still small
(ideally reduce S(0))
Containment, reduce ß while I(t) is still small
Prevention: Software Quality





Goal: eliminate vulnerability
Static/dynamic testing (e.g. Cowan, Wagner, Engler, etc)
Software process, code review, etc.
Active research community
Taken seriously in industry



Security code review alone for Windows Server 2003 ~ $200M
Traditional problems: soundness, completeness, usability
Practical problems: scale and cost
16
Prevention: Wrappers

Goal: stop vulnerability from being exploited

Hardware/software buffer overflow prevention


Sandboxing (BSD Jail, Virtual Machines)


17
NX, /GS, StackGuard, etc
Limit capabilities of potentially exploited program
Don’t allow certain system calls, network packets,
privileges, etc.
Prevention: Software
Heterogeneity

Goal: reduce impact of vulnerability

Use software diversity to tolerate attack

Exploit existing heterogeneity
» Store you data on a Mac and on Windows

Create artificial heterogeneity (hot research topic)
» Large contemporary literature (address randomization,
execution polymorphism… use the tricks of the virus writer as a
good guy)

Open questions: class of vulnerabilities that can
be masked, strength of protection, cost of support
18
Prevention: Software
Updating


Goal: reduce window of vulnerability
Most worms exploited known vulnerability
(1 day -> 3 months)




Window shrinking: automated patch->exploit
(some now have negative windows; zeroday attacks)
Patch deployment challenges, downtime, Q/A, etc
Rescorla, Is finding security holes a good idea?, WEIS ’04
Network-based filtering: decouple “patch” from code


19
E.g. TCP packet to port 1434 and > 60 bytes
Symantec: Generic Exploit Blocking
Prevention: Known Exploit
Blocking

Get early samples of new exploit



Network sensors/honeypots
“Zoo” samples
Security company distills “signature”

Labor intensive process
Assumes long
reaction window

Signature pushed out to all customers
Host recognizer checks files/memory before execution

Example: Symantec




20
Gets early intelligence via managed service side of business
and DeepSight sensor system
>60TB of signature updates per day
Key assumptions: can get samples and
signature generation can be amortized
Prevention: Hygiene
Enforcement


Goal: keep susceptible hosts off network
Only let hosts connect to network if they are
“well cared for”




21
Recently patched, up-to-date anti-virus, etc…
Manual version in place at some organizations
(e.g. NSF)
Cisco Network Admission Control (NAC)
Can be expensive to administer
Treatment

Reduce I(t) after the outbreak is done


Practically speaking this is where much happens because our
defenses are so bad
Two issues

How to detect infected hosts?
» They still spew traffic (commonly true, but poor assumption)
» Look for known signature (malware detector)

What to do with infected hosts?
»
»
»
»
22
Wipe whole machine
Custom disinfector (need to be sure you get it all…backdoors)
Interesting opportunities for virtualization (checkpoint/rollback)
Aside: interaction with SB1386…
Aside: white worms
April 8, 2016
CSE 127 -- Lecture 5: User Authentication
23
Containment

Reduce contact rate

Slow down

Throttle connection rate to slow spread
» Used in some HP switches


Quarantine


24
Important capability, but worm still spreads…
Detect and block worm
Lock Down, Scan Detection, Signature inference
Quarantine requirements

We can define reactive defenses in terms of:




25
Reaction time – how long to detect, propagate
information, and activate response
Containment strategy – how malicious behavior is
identified and stopped
Deployment scenario - who participates in the
system
Given these, what are the engineering
requirements for any effective defense?
Its difficult…

Even with universal defense deployment,
containing a CodeRed-style worm
(<10% in 24 hours) is tough




Address filtering (blacklists), must respond <
25mins
Content filtering (signatures), must respond < 3hrs
For faster worms, seconds
For non-universal deployment, life is worse…
See: Moore et al, Internet Quarantine: Requirements for Containing
Self-Propagating Code, Infocom 2003 for more details
26
A pretty fast outbreak:
Slammer (2003)

First ~1min behaves like classic
random scanning worm



>1min worm starts to saturate
access bandwidth



Some hosts issue >20,000 scans
per second
Self-interfering
(no congestion control)
Peaks at ~3min


Doubling time of ~8.5 seconds
CodeRed doubled every 40mins
>55million IP scans/sec
90% of Internet scanned in <10mins
27

Infected ~100k hosts
(conservative)
See: Moore et al, IEEE Security & Privacy,
1(4), 2003 for more details
Was Slammer really fast?



Yes, it was orders of magnitude faster than
CodeRed
No, it was poorly written and unsophisticated
Who cares? It is literally an academic point


28
The current debate is whether one can get < 500ms
Bottom line: way faster than people!
See: Staniford et al, ACM WORM, 2004
for more details
Outbreak
Detection/Monitoring

Two classes of monitors

Ex-situ: “canary in the coal mine”
» Network Telescopes
» HoneyNets/Honeypots

29
In-situ: real activity as it happens
Network Telescopes



Infected host scans for other vulnerable hosts by randomly
generating IP addresses
Network Telescope: monitor large range of unused IP addresses –
will receive scans from infected host
Very scalable. UCSD monitors > 1% of all routable addresses
30
Why do telescopes work?

Assume worm spreads randomly



Picks 32bit IP address at random and probes it
Monitor block of n IP addresses
If worm sends m probes/sec, we expect to see one
nm
within:
2

32
sec
We monitor receives R’ probes per second, can
estimate infected host is sending at:
32
31
2
R R'
n
What can you learn?





32
How many hosts are infected?
How quickly?
Where are they from?
How quickly are they fixed?
What happens in the long term?
Code Red: Growth
33
Code Red: Country of Origin
160000
140000
120000
100000
80000
60000
40000
20000
0
Infected Hosts
525 hosts in NZ
US
Korea
China
Taiwan
Canada
UK
Germany
Australia
Japan
Netherlands
34
Code Red: patching rate
35
Code Red: decay
36
Global animation
37
Problem


Telescopes are passive, can’t respond to
external packets
How to tell the difference between two worms?


38
Initial packet may be identical?
How to tell the difference between a worm
something else?
Example: Blaster Worm
Courtesy 39
Farnam Jahanian
Example: Blaster
How telescopes fail
Courtesy 40
Farnam Jahanian
One solution: active responders

Active responder blindly responds to all traffic



This is the moral equivalent to saying “uh huh”
on the phone…

41
External SYN packet (TCP connection request)
Send SYN/ACK packet in response
It elicits a bit more response – hopefully you see
what’s going on
Using Active Responder
Courtesy 42
Farnam Jahanian
Limited fidelity


43
Difficult to mimic complex protocol interactions
(some malware requires up to 70 message
exchanges)
Can’t tell if the machine would be infected,
what it would do etc…
Honeypots

Solution: redirect scans to real “infectable” hosts
(honeypots)
Analyze/monitor hosts for attacks

Challenges


Scalability
» Buy one honeypot per IP address?

Liability
» What if a honeypot infects someone else?

44
Detection
» What techniques to tell if a honeypot has been compromised
Aside: UCSD Potemkin
honeyfarm

Largest honeypot system on the planet



Uses lots of implementation tricks to make this
feasible



45
Currently supports 65k live honeypots
Scalable to several million at reasonable cost
Only uses a handful of physical machines
Only binds honeypots to addresses when an
external request arrives
Supports multiple honeypots per physical machine
using “virtual machines”
Overall limitations of telescope,
honeynet, etc monitoring

Depends on worms scanning it



Inherent tradeoff between liability exposure and
detectability



46
What if they don’t scan that range (smart bias)
What if they propagate via e-mail, IM?
Honeypot detection software exists
It doesn’t necessary reflect what’s happening on your
network (can’t count on it for local protection)
Hence, we’re always interested in in situ detection as
well
Detecting worms on your
network

Two classes of approaches


47
Scan detection: detect that host is infected by
infection attempts
Signature inference: automatically identify content
signature for exploit (sharable)
Scan Detection


Basic idea: detect scanning behavior indicative
of worms and quarantine individual hosts
Lots of variants of this idea, here’s one:

Threshold Random Walk algorithm
» Observation: connection attempts to random hosts usually
won’t succeed (no machine there, no service on machine)
» Track ratio of failed connection attempts to connection
attempts per IP address; should be small
» Can be implemented at very high speed
See: Jung
et al, Fast Portscan Detection Using Sequential Hypothesis Testing, Oakland 2004,
48
Weaver et al, Very Fast Containment of Scanning Worms, USENIX Security 2004
Signature inference


49
Challenge: automatically learn a content
“signature” for each new worm – potentially in
less than a second!
Singh et al, Automated Worm
Fingerprinting, OSDI ’04
Approach


Monitor network and look for strings common
to traffic with worm-like behavior
Signatures can then be used for content
filtering
PACKET HEADER
SRC: 11.12.13.14.3920 DST: 132.239.13.24.5000 PROT: TCP
PACKET PAYLOAD (CONTENT)
00F0
0100
0110
0120
0130
0140
90
90
90
90
90
66
. . .
50
90
90
90
90
90
01
90
90
90
90
90
80
90 90 90 90 90 90 90 90 90 90 90 90 90 ................
signature
captured
by............M?.w
90 Kibvu.B
90 90 90 90
90 90 90 90
4D 3F E3 77
90 FF 63 64 90 90 90 90 90 90
90 90 .....cd.........
th,902004
Earlybird
on
May
14
90 90 90 90 90 90 90 90 90 90 90 90 90 ................
90 90 90 90 90 EB 10 5A 4A 33 C9 66 B9 ..........ZJ3.f.
34 0A 99 E2 FA EB 05 E8 EB FF FF FF 70 f..4...........p
Content sifting


Assume there exists some (relatively) unique
invariant bitstring W across all instances of a
particular worm (true today, not tomorrow...)
Two consequences



Content Prevalence: W will be more common in traffic
than other bitstrings of the same length
Address Dispersion: the set of packets containing W
will address a disproportionate number of distinct
sources and destinations
Content sifting: find W’s with high content
prevalence and high address dispersion and drop
that traffic
51
The basic algorithm
Detector in
network
A
B
C
cnn.com
E
Prevalence Table
D
Address Dispersion Table
Sources
Destinations
52
The basic algorithm
Detector in
network
A
B
C
cnn.com
E
D
Prevalence Table
1
Address Dispersion Table
Sources
Destinations
1 (A)
1 (B)
53
The basic algorithm
Detector in
network
A
B
C
cnn.com
E
D
Prevalence Table
1
1
Address Dispersion Table
Sources
Destinations
1 (A)
1 (C)
1 (B)
1 (A)
54
The basic algorithm
Detector in
network
A
B
C
cnn.com
E
D
Prevalence Table
2
1
Address Dispersion Table
Sources
Destinations
2 (A,B)
1 (C)
2 (B,D)
1 (A)
55
The basic algorithm
Detector in
network
A
B
C
cnn.com
E
D
Prevalence Table
Address Dispersion Table
Sources
Destinations
3
1
3 (A,B,D) 3 (B,D,E)
1 (C)
1 (A)
56
Challenges

Computation

To support a 1Gbps line rate we have 12us to process
each packet… at 10Gbps 1.2us
» Dominated by memory references; state expensive


State


57
Content sifting requires looking at every byte in a packet
On a fully-loaded 1Gbps link a naïve implementation
can easily consume 100MB/sec for tables
If you’re interested you can read the paper for the
gory details on how we actually do it :-)
Software prototype: Earlybird
To other sensors and
blocking devices
EB Sensor code (using C)
Apache + PHP
TAP
Libpcap
Summary
data
Mysql + rrdtools
Linux 2.6
Aggregator
(using C)
Setup 1: Large
fraction of the UCSD EB
campus
traffic,
Traffic
mix: approximately 5000 end-hosts,Linux
dedicated
2.6
AMD Opteron 242 (1.6Ghz)
servers for campus wide services (DNS, Email, NFS etc.)
EarlyBird
Aggregator
Line-rate EarlyBird
of traffic Sensor
varies between 100
& 500Mbps.
Reporting
& Control
Setup 2: Fraction of local ISP Traffic,
Traffic mix: dialup customers, leased-line customers
Line-rate of traffic is roughly 100Mbps.
70
Experience w/Earlybird

Extremely good



Known worms detected:


Code Red, Nimda, WebDav, Slammer, Opaserv, …
Unknown worms (with no public
signatures) detected:

73
Detected and automatically generated signatures
for every known worm outbreak over eight months
Can produce a precise signature for a new worm in
a fraction of a second
MsBlaster, Bagle, Sasser, Kibvu, …
Sasser
74
False Negatives



Easy to prove presence, impossible to prove absence
Live evaluation: over 8 months detected every worm
outbreak reported on popular security mailing lists
Offline evaluation: several traffic traces run against
both Earlybird and Snort IDS (w/all worm-related
signatures)


77
Worms not detected by Snort, but detected by Earlybird
The converse never true
False Positives

Common protocol
headers



Mainly HTTP and SMTP
headers
Distributed (P2P) system
protocol headers
Procedural whitelist
» Small number of popular
protocols

Non-worm
epidemic Activity


SPAM
BitTorrent
GNUTELLA.CONNECT
/0.6..X-Max-TTL:
.3..X-Dynamic-Qu
erying:.0.1..X-V
ersion:.4.0.4..X
-Query-Routing:.
0.1..User-Agent:
.LimeWire/4.0.6.
.Vendor-Message:
.0.1..X-Ultrapee
r-Query-Routing:
78
Major UCSD success story

Major UCSD success story




79
Content sifting technologies patented by UC and
licensed to startup, Netsift Inc.
Improved and accelerated (esp for hardware
implementation)
12mos later Netsift was acquired by Cisco
When you buy a Cisco enterprise switch in
24mos it will have this capability
Limitations

Variant content


Network evasion


Make a worm with the string “Republican” in it
Trust between monitors

80
Under threshold
DoS via manipulation


Privacy vs security policy
Slow/stealthy worms


More about this when we cover IDS
End-to-end encryption vs content-based security


Polymorphism, metamorphism… no invariant signature
You say “ABC” is a worm signature, why should I trust you?
Distributed detection issues

Suppose I detect a worm… I want to tell you
about it. Why should I trust you?


Self-Certifying Alerts (Microsoft Research)


81
If you lie you might tell me that “From: “ was a worm
signature
Have worm alert encode the vulnerability itself
Recipient runs alert in safe “sandboxed”
environment and proves to self that vulnerability
exists (and thus signature is valid)
Next time

82
Bots, rootkits and spyware