Authentication Protocols

1. When this message is received by the server, the identity of the client is not known Client Server At this point the client knows the identity of the server since it decrypted x ClientID, E(x, CHK) E(x+1, SHK), E(y, SHK) E(y+1, CHK) At this point the server knows the client because it was able to decrypt y E(SK, SHK) A new session key is exchanged so CHK and SHK aren’t as vulnerable to attacks 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. A Asks S for a key to communicate with B A proves it knows the encryption key K Forwarded from S S responds encoding the session key K and timestamp T and length of time to expire L A can’t decrypt the second message B Proves it was able to decrypt message from S Kerberos B S shares KA with A, but B does not know KA, A does not know KB S A • Trusted third party (Kerberos) 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(T+1,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. Don’t 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 e=3, a once-popular choice as it makes encryption very fast. Show that someone who intercepts all three messages c1=m3mod n1, c2=m3mod n2, c3=m3mod 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 doesn’t 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(UCAPubK,RootCAPriK)

16. Create a random secret key k Original message Encrypt message using Decrypt message using DES with secret key k DES with secret key k Encrypt k using RSA with Decrypt E ( k ) using RSA with recipient ’ s public key my private key -> k Encode message + E ( k ) Convert ASCII message in ASCII for transmission T ransmitted message PEM Encryption Illustrated

17. Sender identity and message integrity confirmed if checksums match Calculate MD5 checksum on received message and compare Calculate MD5 checksum over message contents against received value Sign checksum using RSA Decrypt signed checksum with sender ’ s private key with sender ’ s public key T ransmitted message PEM message integrity and authentication m+E(MD5(m),privatesender)

18. IPRA = Internet Policy IPRA Registration Authority (root) PCA n = policy certification authority CA = certification authority PCA1 PCA2 PCA3 CA CA CA CA CA CA User User CA User User User CA User User User 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. Rest of the Internet Firewall Local site Firewall

23. Remote company user W eb Internet Firewall Company net server Random external user Firewall

24. Firewall External Local client server Proxy External HTTP/TCP connection Internal HTTP/TCP connection Proxy Firewall

25. 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 victim’s 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.)

26. 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).

27. Federal Computer Incident Response Center (2002)

28. Mitnick Simpson who is the enemy? • The Troubled Genius • Has a deep understanding of systems • Capable of finding obscure vulnerabilities in OS’s, 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?

29. d’oh! • 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

30. publish or perishor, good help is not hard to find

31. 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?

32. func 2’s address func 1’s address buf c, d a, b func_3() { char buf[100]; read_user_input(buf); } func_2() { int c, d; func_3(); } func_1() { int a, b; func_2(); } buffer overflowson the stack

33. func 2’s address buf’s address func 1’s address buf c, d a, b evil_assembly_code() func_3() { char buf[100]; read_user_input(buf); } func_2() { int c, d; func_3(); } func_1() { int a, b; func_2(); } buffer overflowson the stack Attacker is supplying input to buf… so buf gets a very carefully constructed string containing assembly code, and overwriting func 2’s address with buf’s address. When func3 returns, it will branch to buf instead of func2.

35. securing your systemthe quick & easy way “ It’s 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! Let’s go to the router room with some bolt cutters.)

36. 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)

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

38. 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.); it’s easier to secure 20 machines than 20,000 • Now the internal network is “safe” (but not from internal attacks, modems, etc.)

39. Dear Professor _____________ , Our firewall has detected your attempt to use the network protocol ________. This protocol is not supported under the USC Security Policy. Please cease these activities at once. Any further infractions will result in your disconnection from our network. Cordially, UCS Clement PIM firewall politics • In a corporate environment, firewalls are great. The network user is an employee of the network service provider; it’s in the provider’s power to say “Thou Shalt Not Use Any Internet Services Except For These...” • How well do you think that would work here?

40. 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

41. 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 Compared to Proxy

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

43. 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.ps.Z

44. thoughts on bro • It provides a nice site-wide view of security • It’s not disruptive to users • It’s centrally administered • Unlike a firewall, which stops badness before it starts, bro’s alarm may come too late • It can’t 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

45. subverting bro(we’ll start with the easy ones) • Let’s say we’re trying to scan for the string “su root”. • What if I type “su me^H^Hroot”? • What if I type “su<telnet option> root”? • What if I type “alias blammo su”, then type “blammo root”?

46. TCP: HDR USER HDR root HDR HDR US HDR ER HDR HDR ro IP: HDR ot reconstructing flows • Let’s 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)

47. HDR HDR US HDR ER HDR HDR ro HDR ot 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 we’re asking a single host to try to solve that same problem.

48. HDR HDR US HDR ER HDR HDR HDR HDR ro fo HDR ot 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 OS’s have different protocol interpretations, so it’s impossible for Bro to agree with all of them

49. 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

50. is bro useless? • Of course not. • Remember, most of the problems are caused by idiots; they don’t know how to subvert bro and the techniques can’t be pre-packaged easily. • It doesn’t cost us anything. • Just because the monitor can be subverted doesn’t mean we can’t use it. Using it doesn’t mean we are making a tradeoff, so why not? • There is no silver bullet. • Don’t expect anysystem to single-handedly “solve” the security problem. Take what you can get.