640 likes | 1.2k Views
Transport Layer Security. Outline. Review: Transport Layer Transport Layer Attacks Defense Mechanisms: Secure Sockets Layer (SSL)/Transport Layer Security (TLS) Secure Shell (SSH). Transport Layers. TCP/UDP. TCP. Transport Control Protocol Flow control and responds to congestion
E N D
Outline • Review: Transport Layer • Transport Layer Attacks • Defense Mechanisms: • Secure Sockets Layer (SSL)/Transport Layer Security (TLS) • Secure Shell (SSH)
Transport Layers • TCP/UDP
TCP • Transport Control Protocol • Flow control and responds to congestion • Reliable In-order delivery • “Nice” protocol
32 bits Source port # Destport # Sequence number Acknowledgement number Head len Not used Rcvr window size U A P R S F Checksum Ptrurgent data Options (variable length) Application data (variable length) TCP Segment Structure URG: urgent data (generally not used) Counting bytes of data (not segments!) ACK: ACK # valid PSH: push data now (generally not used) # bytes rcvr willing to accept RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP)
time TCP Sequence Numbers & ACKs Sequence Numbers: • Byte stream “number” of 1st byte in segment’s data ACKs: • Seq. # of next byte expected from other side • Cumulative ACK Q: How does receiver handles out-of-order segments? • A: TCP spec doesn’t say, up to implementer Host B Host A User types ‘C’ Seq=42, ACK=79, data = ‘C’ Host ACKs receipt of ‘C’, echoes back ‘C’ Seq=79, ACK=43, data = ‘C’ Host ACKs receipt of echoed ‘C’ Seq=43, ACK=80 Simple Telnet scenario
UDP • No reliability, flow control, congestion control • Sends data in a burst • Provides multiplexing and demultiplexing of sources • Many multimedia applications using UDP
UDP: User Datagram Protocol [RFC 768] • “No frills,” “bare bones” Internet transport protocol • “Best effort” service: UDP segments may be: • Lost • Delivered out of order to app • Connectionless: • No handshaking between UDP sender, receiver • Each UDP segment handled independently of others Why is there a UDP? • No connection establishment (which can add delay) • Simple: no connection state at sender, receiver • Small segment header • No congestion control: UDP can blast away as fast as desired
UDP segment structure • Often used for streaming multimedia apps • loss tolerant • Rate sensitive • Other UDP uses (why?): • DNS • SNMP • Reliable transfer over UDP: add reliability at application layer • App-specific error recovery 32 bits Source port # Destport # Length (bytes) of UDP segment, including header Checksum Length Application data (message) UDP segment format
Outline • Review: Transport Layer • Transport Layer Attacks • Defense Mechanisms: • Secure Sockets Layer (SSL)/Transport Layer Security (TLS) • Secure Shell (SSH)
TCP Attacks • TCP Traffic Records • TCP Port Scans • TCP Host Sweeps • SYN Flood & TCP Hijacking Attacks • TCP Applications Application Application TCP TCP UDP IP Data Link Physical
TCP Port Scans • TCP port scanoccurs when one host searches for multiple TCP services on a singlehost • Common scans use normal TCP-SYN • Stealth scans use • FIN, SYN-FIN, null, or PUSH • And/or fragmented packets T C P Source Port Destination Port Source Sequence Number Acknowledge Sequence Num Len Res Flags Window Checksum Urgent Pointer I P Ver Len Serv Length Identification Flg Frag Offset TTL TCP Checksum Source IP Destination IP
TCP Port Scan Attacks • High port sweep • SYNs to ports > 1023 • Triggers when type of sweep can’t be determined • FIN high port sweep • FINs to ports > 1023 • Null port sweep • TCPs without SYN, FIN, ACK, or RST to any port • Queso port sweep • FIN, SYN/FIN, and a PUSH • Port sweep • SYNs to ports < 1024 • Triggers when type of sweep can’t be determine • SYN port sweep • SYNs to any ports • FIN port sweep • FINs to ports < 1024 • SYN/FIN can be combined; fragmented packets can be used.
TCP Host Sweeps • A TCP host sweepoccurs when one host searches for a single TCP service on multiple hosts • Common scans use normal TCP-SYN • Stealth scans • Use FIN, SYN-FIN, and null • And/or fragmented packets • Possible attacks similar to port scans T C P Source Port Destination Port Source Sequence Number Acknowledge Sequence Num Len Res Flags Window Checksum Urgent Pointer I P Ver Len Serv Length Identification Flg Frag Offset TTL TCP Checksum Source IP Destination IP
SYN Flood and TCP Hijacks • Half-Open SYN attack • DoS-SYN flood attack • Ports 21, 23, 25, and 80 • TCP Hijacking • Access-attempt to take over a TCP session
TCP Intercept (Cisco Routers) Request Intercepted Connection Established Connection Transferred • TCP SYN flooding can overwhelm server and cause it to deny service, exhaust memory or waste processor cycles • TCP Intercept protects network by intercepting TCP connection requests and replying on behalf of destination • Can be configured to passively monitor TCP connection requests and respond if connection fails to get established in configurable interval
TCP Hijacking • TCP hijacking works by correctly guessing sequence numbers • Newer O/S’s & firewalls eliminate problem by randomizing sequence numbers • TCP Hijacking Simplex Mode • One command followed by RST
UDP Attacks • UDP Traffic Records • UDP Port Scan • UDP Attacks • UDP Applications Application Application TCP TCP UDP IP Data Link Physical
UDP Attacks • UDP port scans similar to TCP ones • UDP flood (disabled) • Many UDPs to same host • UDP Bomb • UDP length < IP length • Snork • Src=135, 7, or 19; Dest=135 • ChargenDoS • Src=7 & Dest=19 U D P Source Port Destination Port Length Checksum Data . . . I P Ver Len Serv Length Identification Flg Frag Offset TTL UDP Checksum Source IP Destination IP
Active Worm vs. Virus • Active Worm • A program that propagates itself over a network, reproducing itself as it goes • Virus • A program that searches out other programs and infects them by embedding a copy of itself in them
Active Worm vs. DDoS • Propagation • Active worm: from few to many • DDoS: from many to few • Relationship • Active worm can be used for network reconnaissance, preparation for DDoS
Instances of Active Worms (1) • Morris Worm (1988) [1] • First active worm; took down several thousand UNIX machines on Internet • Code Red v2 (2001) [2] • Targeted, spread via MS Windows IIS servers • Launched DDoS attacks on White House, other IP addresses • Nimda (2001, netbios, UDP) [3] • Targeted IIS servers; slowed down Internet traffic • SQL Slammer (2003, UDP) [4] • Targeted MS SQL Server, Desktop Engine • Substantially slowed down Internet traffic • MyDoom (2004–2009, TCP) [5] • Fastest spreading email worm (by some estimates) • Launched DDoS attacks on SCO Group
Instances of Active Worms (2) • Jan. 2007: Storm [6] • Email attachment downloaded malware • Infected machine joined a botnet • Nov. 2008–Apr. 2009: Conficker [7] • Spread via vulnerability in MS Windows servers • Also had botnet component • Jun.–Jul. 2009, Mar.–May 2010: Stuxnet [8–9] • Aim: destroy centrifuges at Natanz, Iran nuclear facility • “Escaped” into the wild in 2010 • Aug. 2011: Morto [10] • Spread via Remote Desktop Protocol • OSU Security shut down RDP to all OSU computers
(3) Transfer copy (1) Scan (2) Probe infected machine machine How an Active Worm Spreads • Autonomous: human interaction unnecessary Infected
Conficker Worm Spread Data normalized for each country. Source: [7]
Scanning Strategy • Random scanning • Probes random addresses in the IP address space (CRv2) • Hitlist scanning • Probes addresses from an externally supplied list • Topological scanning • Uses information on compromised host (Email worms, Stuxnet) • Local subnet scanning • Preferentially scans targets that reside on the same subnet. (Code Red II & Nimda)
Techniques for Exploiting Vulnerabilities • Morris Worm • fingerd (buffer overflow) • sendmail (bug in “debug mode”) • rsh/rexec (guess weak passwords) • Code Red, Nimda, etc. (buffer overflows) • Tricking users into opening malicious email attachments
Worm Exploit Techniques • Case study: Conficker worm • Issues malformed RPC (TCP, port 445) to Server service on MS Windows systems • Exploits buffer overflow in unpatched systems • Worm installs backdoor, bot software invisibly • Downloads executable file from server, updates itself • Workflow: see backup slides (1), (2)
Worm Behavior Modeling (1) • Propagation model mirrors epidemic: • V: total # of vulnerable nodes • N : size of address space • i(t): percentage of infected nodes among V • r : an infected node’s scanning speed
Worm Behavior Modeling (2) • Multiply (*) by V⋅dt and collect terms:
Modeling the Conficker Worm • This model’s predicted worm propagation similar to Conficker’s actual propagation Conficker’s propagation Sources: [7], Fig. 2; [8], Fig. 4
Outline • Review: Transport Layer • Transport Layer Attacks • Defense Mechanisms: • Secure Sockets Layer (SSL)/Transport Layer Security (TLS) • Secure Shell (SSH)
SSL: Secure Sockets Layer • Widely deployed security protocol • Supported by almost all browsers, web servers • HTTPS • Billions $/year over SSL • Variant: TLS: transport layer security (RFC 2246) • Provides • Confidentiality • Integrity • Authentication • Original goals: • Web e-commerce transactions • Encryption (especially credit-card numbers) • Web-server authentication • Optional client authentication • Minimum hassle in doing business with new merchants • Available to all TCP/IP applications: secure socket API “above” TCP
Toy SSL: A Simple Secure Channel • Handshake:Alice and Bob use their certificates, private keys to authenticate each other and exchange shared secret • Key Derivation: Alice and Bob use shared secret to derive set of keys • Data Transfer:data to be transferred is broken up into series of records • Connection Closure: special messages to securely close connection
Toy: A Simple Handshake MS:Master Secret EMS:Encrypted Master Secret Hello Public Key Certificate KB+(MS) = EMS
Toy: Key Derivation • Considered bad to use same key for more than one cryptographic operation • Use different keys for message authentication code (MAC) and encryption • Four keys: • Kc = encryption key for data sent from client to server • Mc = MAC key for data sent from client to server • Ks = encryption key for data sent from server to client • Ms = MAC key for data sent from server to client • Keys derived from key derivation function (KDF) • Takes master secret and (possibly) some additional random data and creates the keys
Toy: Data Records • Why not encrypt data in constant stream as we write it to TCP? • Where would we put the MAC? If at end, no message integrity until all data processed. • E.g., with instant messaging, how can we do integrity check over all bytes sent before displaying? • Instead, break stream in series of records • Each record carries a MAC • Receiver can act on each record as it arrives • Issue: in record, receiver needs to distinguish MAC from data • Want to use variable-length records Length Data MAC
Toy: Sequence Numbers • Problem:Attacker can capture and replay record or re-order records • Solution:Put sequence number into MAC: • MAC = MAC(Mx, sequence||data) • Note: No sequence number field • Problem:Attacker could replay all records • Solution:Use nonce
Toy: Control Information • Problem:Truncation attack: • Attacker forges TCP connection close segment • One or both sides thinks there is less data than there actually is. • Solution:Record types, with one type for closure • Type 0 for data; type 1 for closure • MAC = MAC(Mx, sequence||type||data) Data Length Type MAC
Hello Certificate, Nonce KB+(MS) = EMS Type 0, Seq1, Data Type 0, Seq2, Data Type 0, Seq1, Data Type 0, Seq3, Data Type 1, Seq4, Close Type 1, Seq2, Close Toy SSL: Summary bob.com encrypted
Toy SSL Isn’t Complete • How long are fields? • Which encryption protocols? • Want negotiation? • Allow client and server to support different encryption algorithms • Allow client and server to choose together specific algorithm before data transfer
SSL Cipher Suite Common SSL Symmetric Ciphers • DES – Data Encryption Standard: block • 3DES – Triple strength: block • RC2 – Rivest Cipher 2: block • RC4 – Rivest Cipher 4: stream SSL Public Key Encryption • RSA • Cipher suite • Public-key algorithm • Symmetric encryption algorithm • MAC algorithm • SSL supports several cipher suites • Negotiation: Client, server agree on cipher suite • Client offers choice • Server picks one
Real SSL: Handshake (1) Purposes: • Server authentication • Negotiation: agree on crypto algorithms • Establish keys • Client authentication (optional)
Real SSL: Handshake (2) • Client sends list of algorithms it supports, along with client nonce • Server chooses algorithms from list; sends back: choice + certificate + server nonce • Client verifies certificate, extracts server’s public key, generates pre_master_secret, encrypts with server’s public key, sends to server • Client and server independently compute encryption and MAC keys from pre_master_secret and nonces • Client sends a MAC of all the handshake messages • Server sends a MAC of all the handshake messages Last 2 steps protect handshake from tampering
Real SSL: Handshake (3) • Why two random nonces? • Suppose Trudy sniffs all messages between Alice & Bob • Next day, Trudy sets up TCP connection with Bob, sends exact same sequence of records • Bob (Amazon) thinks Alice made two separate orders for the same thing • Solution: Bob sends different random nonce for each connection. This causes encryption keys to be different on the two days • Trudy’s messages will fail Bob’s integrity check
Data Data Fragment MAC Data Fragment MAC Record Header Encrypted Data and MAC Record Header Encrypted Data and MAC SSL Record Protocol Record Header: Content type; version; length MAC: includes sequence number, MAC key Mx Fragment: each SSL fragment 214 bytes (~16 Kbytes)
1 byte 2 bytes 3 bytes Content Type Length SSL Version Data MAC SSL Record Format Data and MAC encrypted (symmetric algorithm)
Handshake: ClientHello Handshake: ServerHello Handshake: Certificate Handshake: ServerHelloDone Handshake: ClientKeyExchange ChangeCipherSpec Handshake: Finished ChangeCipherSpec Handshake: Finished Application_data Application_data Alert: Warning, Close_Notify Real SSLconnection Everything henceforth is encrypted TCP FIN follows
Outline • Review: Transport Layer • Transport Layer Attacks • Defense Mechanisms: • Secure Sockets Layer (SSL)/Transport Layer Security (TLS) • Secure Shell (SSH)
Secure Shell (SSH); Protocol Stack • Protocol for secure network communications designed for simplicity, easy to implement (Telnet replacement) • SSH client and server applications widely available for most OSes • Has become method of choice for remote login, X tunneling • Pervasive application for encryption technology outside of embedded systems • SSH provides general client/server capability: can be used for network functions, e.g., file transfer, e-mail TCP IP SSH Protocol Stack