Threeway handshake

1
Authentication Protocols
CHK, SHK are keys known by both sides

• Three-way handshake

2
Three Way Handshake

• Assumes both sides know CHK and SHK
• This could correspond to a password
• We still need a way to distribute keys assuming
  the client and server share no keys

3
Kerberos

• Trusted third party (Kerberos)

B
A
S
S shares KA with A, but B does not know KA, A
does not know KB
A, B
E((T,L,K,B),KA),
E((T,L,K,A),KB)
E((A,T),K), E((T,L,K,A),KB)
E(T1,K)
4
Kerberos

• K is used like a DES session Key
• Key exchange depends on a trusted 3rd party

5
Public key authentication
A
B
E(x, Public )
B
x
6
Message Integrity Protocols

• Digital signature using RSA
• special case of a message integrity where the
  code can only have been generated by one
  participant
• compute signature with private key and verify
  with public key

7
Dont send same text to several destinations
Suppose that RSA is used to send a message m to
three recipients, who have relatively prime
encryption moduli n1, n2, n3. All three
recipients use the same encryption exponent e3,
a once-popular choice as it makes encryption very
fast. Show that someone who intercepts all three
messages c1m3mod n1, c2m3mod n2, c3m3mod n3
can efficiently decipher m. The Chinese remainder
theorem implies that you can efficiently find a c
such that c c1mod n1, c c2mod n2, c c3mod n3.
Assume this and show that it implies c m3mod n1
n2 n3.
8
Keyed MD5

• Sender and receiver share key k
• sender
• m MD5(m k)
• receiver
• applies MD5 to the concatenation of random key
  message
• compares result with checksum sent with message
• Man-in-the middle can not recompute MD5 because
  he doesnt have secret key k

9
Keyed MD5

• sender
• m MD5(m k) E(k, private)
• receiver
• recovers random key using the sender's public key
• applies MD5 to the concatenation of this random
  key message
• compares result with checksum sent with message
• Man-in-the middle can intercept k, change
  message, change checksum, and the receiver wont
  know

10
Fixed Keyed MD5

• Sender
• m MD5(m k) E(E(k, r-public), s-private)
• receiver
• recovers random key using the sender's public key
  and receivers private key
• applies MD5 to the concatenation of this random
  key message
• compares result with checksum sent with message
• Authenticates sender
• Man-in-the middle can not intercept k because it
  is encrypted with the public key of the receiver
• Only works for one receiver

11
What about this?

• Sender
• m MD5(m k) E(k, r-public)
• receiver
• recovers random key using the receivers private
  key
• applies MD5 to the concatenation of this random
  key message
• compares result with checksum sent with message
• Man-in-the middle can make up a new key and send
  it using the receivers public key

12
Another Keyed MD5

• Sender m E(MD5(m k) k, s-private)
• receiver
• recovers random key using the sender's public key
  
• applies MD5 to the concatenation of this random
  key message
• compares result with checksum sent with message
• Man-in-the middle can not change message because
  checksum is encrypted with the private key of the
  sender

13
MD5 with RSA signature

• sender
• m E(MD5(m), s-private)
• receiver
• decrypts signature with sender's public key
• compares result with MD5 checksum sent with
  message

14
Certificates
CA
Certified Entity
Register with CA, send client Public Key
Albert Levi
Albert Levi
CA-Publickey and Certificate with RSA(client
Public Key,CA-privatekey)
Certificate
Verifier Decrypt senders public key using
CA-publickey
Albert Levi
15
Hierarchical PKI Example
RSA(UserPubK,CAPriK) RSA(CAPubK.UCAPriK) RSA(UCAPu
bK,RootCAPriK)
16
PEM Encryption Illustrated
17
PEM message integrity and authentication
mE(MD5(m),privatesender)
18
PEM Certificates
19
TLS,SSL,HTTPS
Transport Layer Security, Secure Socket Layer
20
SSL

• Each browser is configured with a root CA
• When a session is initiated, server and client
  agree on security capabilities. (most clients
  are 40 bit encryption, but 128 bit encryption is
  available on many strong servers
• The server is authenticated by the certificate
  authority
• Using the server public key from the CA, the
  client sends a DES key to the server
• The DES key is used to encrypt the session

21
IPSEC

• Optional in IPv4, mandatory in IPv6
• Data Confidentiality---The IPSec sender can
  encrypt packets before transmitting them across a
  network.
• Data Integrity---The IPSec receiver can
  authenticate packets sent by the IPSec sender to
  ensure that the data has not been altered during
  transmission.
• Data Origin Authentication---The IPSec receiver
  can authenticate the source of the IPSec packets
  sent. This service is dependent upon the data
  integrity service.
• Anti-Replay---The IPSec receiver can detect and
  reject replayed packets.

22
Firewall
23
Firewall
24
Proxy Firewall
25
does security matter?
Would you care if someone could

• Crash your computer every 5 minutes?
• Subtly change your thesis?
• Change your bank statement?
• Sink a ship?
• (Think its unlikely? It happened see NY Times,
  vol. CXLIII, page E7 - Oct. 24, 1993)

26
when will it matter?
Some systems and/or protocols are designed with
security in mind from the beginning -- maybe even
as their primary design goal. But for most? The
storys the same

• Protocol design? (Nah, thats an application
  problem)
• Application design? (We plan to add that in the
  future...)
• Application deployment? (Lets get it running
  first)
• System administration? (Im putting out fires
  every day!)

27
Who perpetrates most Computer Crime?
Insiders are the biggest threat!
27
28
system vulnerabilities

• Almost all vulnerabilities come from bugs in the
  implementation of, or misconfigurations of, the
  OS and/or apps
• Rarely, a problem with a protocol itself
• Vulnerabilities can lead to
• Unauthorized access attacker gains control of
  the victims machine (attacker can log in, read
  files, and/or make changes to the system)
• Denial of Service against host (attacker can
  crash the computer, disable services, etc.)
• Denial of Service against network (attack can
  disrupt routing, flood the network, etc.)

29
Statistics

• 2000 CSI/FBI Computer Crime and Security Survey
• 90 of respondents (primarily large corporations
  and government agencies) detected computer
  security breaches within the last twelve months.
• 70 reported a variety of serious computer
  security breaches other than the most common ones
  of computer viruses, laptop theft or employee
  "net abuse"--for example, theft of proprietary
  information, financial fraud, system penetration
  from outsiders, denial of service attacks and
  sabotage of data or networks.
• 74 acknowledged financial losses due to computer
  breaches.
• 42 were willing and/or able to quantify their
  financial losses. The losses from these 273
  respondents totaled 265,589,940 (the average
  annual total over the last three years was
  120,240,180).

30
Federal Computer Incident Response Center
31
who is the enemy?

• The Troubled Genius
• Has a deep understanding of systems
• Capable of finding obscure vulnerabilities in
  OSs, apps, and protocols, and exploiting them
• Extremely skilled at evading countermeasures
• Can dynamically adapt to new environments

• The Idiot
• Little or no true understanding of systems
• Blindly downloads runs code written by T.G.
• Can usually be stopped by calling his mother

Who do you think causes more damage?
32
doh!

• The idiots collectively cause more damage because
  there are a vast number of them
• Every security incident analyzed at NIH was the
  work of an idiot
• Every time smart hackers find a new security
  hole, they make it public -- they have a publish
  or perish ethic
• Each time, hordes of idiots pounce on it and
  break into every system they can find

33
publish or perishor, good help is not hard to
find
34
the never-ending game

• 1. New bugs are found exploits are published
• 2. Hordes of idiots cause damage using those
  exploits
• 3. Vendors are pressured to come out with fixes
• 4. Users install the fixes (sometimes? rarely?)
• 5. Go to step 1.

The big questions are
1. How can we protect a large site? (The site is
only as strong as its most poorly administered
machine.) 2. How can we pro-actively protect
against attacks that we have never seen before,
to avoid Step 2 damage?
35
buffer overflowson the stack
36
buffer overflowson the stack
Attacker is supplying input to buf so buf gets a
very carefully constructed string containing
assembly code, and overwriting func 2s address
with bufs address. When func3 returns, it will
branch to buf instead of func2.
37
(No Transcript)
38
securing your systemthe quick easy way

Its easy to run a secure computer system. You
just have to disconnect all dial-up connections
and permit only direct-wired terminals, put the
machine and its terminals in a shielded room, and
post a guard at the door.

F.T. Grampp and R.H. Morris
(Great! Lets go to the router room with some
bolt cutters.)
39
firewalls(not as good as bolt cutters, but)

• Routers easy to say allow everything but
• Firewalls easy to say allow nothing but
• This helps because we turn off access to
  everything, then evaluate which services are
  mission-critical and have well-understood risks
• Note the only difference between a router and a
  firewall is the design philosophy do we
  prioritize security, or connectivity/performance?
  (configurability, logging)

40
typical firewall setup
evil Internet
DMZ
internal network
Diagram courtesy of CheckPoint Software Tech,
www.checkpoint.com
41
the firewall setup

• Firewall ensures that the internal network and
  the Internet can both talk to the DMZ, but
  usually not to each other
• The DMZ relays services at the application level,
  e.g. mail forwarding, web proxying
• The DMZ machines and firewall are centrally
  administered by people focused on security
  full-time (installing patches, etc.) its easier
  to secure 20 machines than 20,000
• Now the internal network is safe (but not from
  internal attacks, modems, etc.)

42
firewall politics

• In a corporate environment, firewalls are great.
  The network user is an employee of the network
  service provider its in the providers power to
  say Thou Shalt Not Use Any Internet Services
  Except For These...
• How well do you think that would work here?

43
Firewall Details

• Rules based on
• IP Source Address
• IP Destination Address
• Encapsulated Protocol
• TCP/UDP destination port
• TCP/UDP source port

TCP DPort TCP SPort TCP Hdr
Eth Dest Eth Src Eth Hdr
IP Dest IP Src IP Hdr
Data
44
Compared to Proxy

• Pros
• Good Performance
• Easy to support new protocols

• Cons
• IP TCP/UDP headers cant be trusted
• Most attacks spoof IP TCP/UCP ports
• Must look at other application signatures

45
Application Proxy

• Changes source address so that responses come to
  proxy from web server
• Proxy is more secure than internal nodes
• Performance degradation

46
big brother is watching

• Bro passively monitors the network at some key
  location (say, the border router)
• Reconstructs flows and searches for known attack
  signatures -- a manually created database, based
  on known network attacks
• Provides real-time notification of security
  personnel when it sees something suspicious
• Future versions may actively terminate
  connections by sending forged TCP RST

ftp//ftp.ee.lbl.gov/papers/bro-usenix98-revised.p
s.Z
47
thoughts on bro

• It provides a nice site-wide view of security
• Its not disruptive to users
• Its centrally administered
• Unlike a firewall, which stops badness before it
  starts, bros alarm may come too late
• It cant flag attacks that are not in its
  database of known attack signatures
• It can not reliably determine what an end-station
  is seeing, for a variety of reasons

48
subverting bro(well start with the easy ones)

• Lets say were trying to scan for the string su
  root.
• What if I type su meHHroot?
• What if I type sulttelnet optiongt root?
• What if I type alias blammo su, then type
  blammo root?

49
reconstructing flows

• Lets say you want to search for the text USER
  root. Is it enough to just search the data
  portion of TCP segments you see?

USER root
(Uh oh we have to reassemble frags and
resequence segs)
50
fun with fragments
Imagine an attacker sends
1.
2.
3. 1,000,000 unrelated fragments
4.
5.
Think of the entire campus as being a massively
parallel computer. That supercomputer is solving
the flow-reconstruction problem. Now were asking
a single host to try to solve that same problem.
51
more fragment fun
Imagine an attacker sends
Seq.
1.
Time
2.
3a.
3b.
4.
Should we consider 3a part of the data stream
USER root? Or is 3b part of the data stream?
USER foot! -- If the OS makes a different
decision than the monitor Bad. -- Even worse
Different OSs have different protocol
interpretations, so its impossible for Bro to
agree with all of them
52
trickery

• Non-standard parts of standards
• IP fragment overlap behavior
• TCP sequence number overlap behavior
• Invalid combinations of TCP options
• Other ways to force a disparity between the
  monitor and the end-station
• TTL
• Checksum
• Overflowing monitor buffers

See http//www.secnet.com/papers/ids-html/ for
detailed examples
53
is bro useless?

• Of course not.
• Remember, most of the problems are caused by
  idiots they dont know how to subvert bro and
  the techniques cant be pre-packaged easily.
• It doesnt cost us anything.
• Just because the monitor can be subverted doesnt
  mean we cant use it. Using it doesnt mean we
  are making a tradeoff, so why not?
• There is no silver bullet.
• Dont expect any system to single-handedly
  solve the security problem. Take what you can
  get.

54
the reverse approach

• Systems like Bro define bad -- anything they
  dont recognize, therefore, is assumed to be
  good.
• Problem Your bad list is always out of date
• Other systems attempt to define good --
  anything they dont recognize is bad
• Now, new badness is automatically caught!
• Problem How do you define good?

55
the immune system

• Stephanie Forrest et al were inspired by
  biological immune systems.
• A biological immune system doesnt have a catalog
  of all viruses that exist in the world
• They have a strong sense of self, allowing them
  to identify and attack non-self entities
• Is the same thing possible on the computer?
• Motivation UNIX processes there is a well-known
  and easy technique for getting almost any buggy
  program to execute arbitrary code by just sending
  it carefully!

http//www.cs.unm.edu/steveah/research.html
56
getting to know yourself

• 1. Find a metric that characterizes the system.
• 2. Build up a database of normal values for that
  metric when the system is working as it should.
• 3. Continually monitor the metric set off an
  alarm if it deviates from the database.
• 4. Test the metric for false positives/negatives.

57
applying the method

• First target application sendmail (infamous for
  many security holes)
• First metric system call traces
• Normal database to be built up by recording
  sendmails behavior in a wide variety of everyday
  tasks (many types of messages)

58
system call traces
Sample call sequence open, read, mmap, mmap,
open, getrlimit, mmap, close
read mmap mmap open
mmap mmap, open, getrlimit, open, getrlimit
mmap close getrlimit mmap close close
59
database in training
60
the normal database

• Using a window size of 6, running sendmail
  through its paces produced a database of only
  1500 entries and was stable!
• This is only 5x10-5 of all possible entries
• The small size of the database is critical
• Big database variability in normal
  difficulty in detecting anomalies
• Big database no realtime monitoring

61
results
Anomaly Num sunsendmailcp 4.1 95 syslog remo
te 1 4.2 470 remote 2 1.5 137 local
1 4.2 398 local 2 3.4 309 decode 0.3 24 lprcp
1.4 12 sm565a 0.4 36 sm5x 1.7 157 forward
loop 1.8 58
(sm565a and sm5x were unsuccessful attacks
forward loop was nonmalicious anomalous behavior
others were successful breakins.)
62
discussion

• Programs seem to exhibit remarkable amounts of
  find-grained consistency when operating normally
  this can be used to detect anomalies.
• Since we now know whats good, we can report
  badness that we have never seen before
• Will not help to do things like determine that a
  user has stolen another users password
• A solution for one host, not an entire site
• Current system runs off-line (on-line planned)

63
related work

• Various expert systems for analyzing logs
• Systems remain vigilant even given megs of log
  data every day, where humans throw away data
• NIDES (ftp//ftp.csl.sri.com/nides)
• Defines a set of events (e.g. directory
  modification, password file access, etc.)
• Complex statistical algos for reporting anomalies
  while still adaptively learning new user behavior
• Keystroke Dynamics - knows how users type

64
bringing it all together

• Bro is powerful in that it can monitor an entire
  site, but weak in that it cant predict what
  future attack profiles will look like
• Forrests work, and other systems mentioned, all
  suggest you can do well by adaptively learning
  normal and reporting deviations
• Forrests work shows that surprisingly high-level
  characteristics of a system can become evident by
  looking at events on an extremely low level, fine
  grain, and small time scale

65
another idea

• Based on motivations mentioned in the previous
  slide, a new type of network intrusion detector
• Monitors network traffic at the packet level
• Creates per-flow packet traces similar to system
  call traces (e.g. SYN -gt SYNACK -gt ACK ACK -gt
  DATA -gt ACK)
• Uses various other metrics (e.g. of total
  traffic that is SYN, ACK, RST ratio of ACKs to
  data packet size distribution distribution of
  source and destination port numbers)
• Adaptively learns what is normal for both
  traces and other metrics reports abnormalities