Network Security Issues, Part 1

Transcription

1 Network Security Issues, Part 1 EE Networking Prof. Vern Paxson November 18, 2013

2 Game Plan Two network security lectures Today: threats at different Internet layers Next Monday: building secure channels (TLS) Providing end-to-end security Huge landscape So we will leave a lot undiscussed (feel free to ask!) and omit numerous details Former CS161 students: You will be bored :-(. Feel free to check out. But: pls don't answer questions posed for the class

3 What We Won't Be Talking About Layer 7 / Applications presents enormous range of diverse threats Browser drive-by exploits, server vulnerabilities (buffer overflow, SQL injection, XSS, CSRF), spam, phishing, account theft, user tracking Internet also enables robust, diverse markets that fuel cybercrime Trade in credit cards, malware installs, stolen accounts, exploit toolkits, spam lists, money mules for cash-out, bulletproof hosting, CAPTCHA-solving And in general, rapid sharing of knowledge (vulnerablities, automated attacks)

4 General Communication Security Goals: CIA! Confidentiality: No one can read our data / communication unless we want them to Integrity No one can manipulate our data / processing / communication unless we want them to Availability We can access our data / conduct our processing / use our communication capabilities when we want to Also: no additional traffic other than ours 4

5 Layers 1 & 2: General Threats?! 7 4 Application Transport Framing and transmission of a collection of bits into individual messages sent across a single subnetwork (one physical technology) 3 (Inter)Network 2 1 Link Physical Encoding bits to send them over a single physical link e.g. patterns of voltage levels / photon intensities / RF modulation 5

6 Physical/Link-Layer Threats: Eavesdropping! Also termed sniffing For subnets using broadcast technologies (e.g., WiFi, older Ethernet), get it for free Each attached system's NIC can capture any communication on the subnet Some handy tools for doing so: o tcpdump / windump (low-level ASCII printout) o Wireshark (GUI for displaying 800+ protocols) 6

7 Physical/Link-Layer Threats: Eavesdropping! Also termed sniffing For subnets using broadcast technologies (e.g., WiFi, older Ethernet), get it for free Each attached system's NIC can capture any communication on the subnet Some handy tools for doing so: o tcpdump / windump (low-level ASCII printout) o Wireshark (GUI for displaying 800+ protocols) For any technology, routers (and switches) can look at / export traffic they forward You can also tap a link Insert a device to mirror physical signal Or: just steal it! 7

8 Stealing Photons! 8

9 Physical/Link-Layer Threats: Disruption! General term for disruption: denial-of-service (DoS) Given physical access to a subnetwork, attacker can: Overwhelm its signaling o E.g., jam WiFi's RF Send messages violating Layer-2 protocol's rules o E.g., send messages > maximum allowed size, disrupt timing synchronization, ignore fairness rules Routers & switches can simply drop traffic There's also the heavy-handed approach 9

10 10

11 Physical/Link-Layer Threats: Spoofing! With physical access to a subnetwork, attacker can create any message on it that they wish When with a bogus source address: spoofing When using a typical computer, may require root/administrator to have full freedom Particularly powerful when combined with eavesdropping Because attacker can understand exact state of victim's communication and craft their spoofed traffic to match it Spoofing w/o eavesdropping = blind spoofing o Attacks that work with blind spoofing are a huge threat because of low physical barrier to launching them 11

12 Spoofing Considerations! On path attackers can see victim's traffic spoofing is easy Off path attackers can't see victim's traffic They have to resort to blind spoofing how? Often must guess/infer header values to succeed o We then care about work factor: how hard is this 12

13 Spoofing Considerations! On path attackers can see victim's traffic spoofing is easy Off path attackers can't see victim's traffic They have to resort to blind spoofing how? Often must guess/infer header values to succeed o We then care about work factor: how hard is this But sometimes they can just brute force o E.g., 16-bit value: just try all 65,536 possibilities! 13

14 Spoofing Considerations! On path attackers can see victim's traffic spoofing is easy Off path attackers can't see victim's traffic They have to resort to blind spoofing how? Often must guess/infer header values to succeed o We then care about work factor: how hard is this But sometimes they can just brute force o E.g., 16-bit value: just try all 65,536 possibilities! When we say an attacker can spoof, we usually mean w/ reasonable chance of success 14

15 Dynamic Host Configuration Protocol! DHCP discover! (broadcast)! new client! DHCP offer! DHCP request! (broadcast)! DHCP server! offer message includes IP address, DNS server, gateway router, and how long client can have these ( lease time) DHCP ACK! 15

16 Dynamic Host Configuration Protocol! DHCP discover! (broadcast)! new client! Threats? DHCP offer! DHCP request! (broadcast)! DHCP ACK! DHCP server! offer message includes IP address, DNS server, gateway router, and how long client can have these ( lease time) 16

17 Dynamic Host Configuration Protocol! DHCP discover! (broadcast)! new client! Attacker on same subnet can hear new host's DHCP request DHCP offer! DHCP request! (broadcast)! DHCP ACK! DHCP server! offer message includes IP address, DNS server, gateway router, and how long client can have these ( lease time) 17

18 Dynamic Host Configuration Protocol! DHCP discover! (broadcast)! new client! DHCP offer! DHCP request! (broadcast)! DHCP server! offer message includes IP address, DNS server, gateway router, and how long client can have these ( lease time) DHCP ACK! Attacker can race the actual server; if they win, replace DNS server and/or gateway router 18

19 DHCP Threats! Substitute a fake DNS server Redirect any of a host's lookups to a machine of attacker's choice Substitute a fake gateway Intercept all of a host's off-subnet traffic o (even if not preceded by a DNS lookup) Relay contents back and forth between host and remote server o Modify however attacker chooses An invisible Man In The Middle (MITM) Victim host has no way of knowing it's happening How can we fix this? Hard - (Can't necessarily alarm on peculiarity of receiving multiple DHCP replies, since that can happen benignly) 19

20 Layer 3: General Threats?! Application Transport (Inter)Network Link Physical 4-bit Version Bridges multiple subnets to provide end-to-end internet connectivity between nodes 4-bit Header Length 8-bit Type of Service (TOS) 16-bit Identification 16-bit Total Length (Bytes) 3-bit Flags 13-bit Fragment Offset 8-bit Time to Live (TTL) 8-bit Protocol 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address IP = Internet Protocol Payload 20

21 (Some) Network-Layer Threats! Can set arbitrary source address Receiver has no idea who you are Could be blind, or could be coupled w/ sniffing Note: many attacks require two-way communication o So successful off-path/blind spoofing might not suffice Can set arbitrary destination address Enables scanning - brute force searching for hosts Can send like crazy (DoS flooding) IP has no general mechanism for tracking overuse IP has no general mechanism for tracking consent Very hard to tell where a spoofed flood comes from! If attacker can manipulate routing, can bring traffic to themselves for eavesdropping (viewed as hard)

22 Layer 4: Manipulation of TCP! Application Transport (Inter)Network Link Physical End-to-end communication between processes (TCP, UDP) Source port Sequence number Acknowledgment Destination port HdrLen 0 Flags Advertised window Checksum Urgent pointer Options (variable) Data 22

23 Layer 4: Manipulation of TCP! 7 4 Application Transport These plus IP addresses define a given connection 3 (Inter)Network 2 Link Source port Destination port 1 Physical Sequence number Acknowledgment HdrLen 0 Flags Advertised window Checksum Urgent pointer Options (variable) Data 23

24 Layer 4: Manipulation of TCP! Application Transport (Inter)Network Link Physical Defines where this segment fits within the sender's bytestream Source port Sequence number Acknowledgment Destination port HdrLen 0 Flags Advertised window Checksum Urgent pointer Options (variable) Data 24

25 TCP Conn. Setup & Data Exchange! Client (initiator) IP address , port 3344 Server IP address , port 80 SrcA= , SrcP=3344, DstA= , DstP=80, SYN, Seq = x Client picks an Initial Sequence Number (ISN) 25

26 TCP Conn. Setup & Data Exchange! Client (initiator) IP address , port 3344 Server IP address , port 80 SrcA= , SrcP=3344, DstA= , DstP=80, SYN, Seq = x SrcA= , SrcP=80, DstA= , DstP=3344, SYN+ACK, Seq = y, Ack = x+1 Server also picks an ISN (spec says to use local clock) and acknowledges the client s ISN 26

27 TCP Conn. Setup & Data Exchange! Client (initiator) IP address , port 3344 Server IP address , port 80 SrcA= , SrcP=3344, DstA= , DstP=80, SYN, Seq = x SrcA= , SrcP=80, DstA= , DstP=3344, SYN+ACK, Seq = y, Ack = x+1 SrcA= , SrcP=3344, DstA= , DstP=80, ACK, Ack = y+1 Client completes 3-way handshake by ack ing server s ISN 27

28 TCP Conn. Setup & Data Exchange! Client (initiator) IP address , port 3344 Server IP address , port 80 SrcA= , SrcP=3344, DstA= , DstP=80, SYN, Seq = x SrcA= , SrcP=80, DstA= , DstP=3344, SYN+ACK, Seq = y, Ack = x+1 SrcA= , SrcP=3344, DstA= , DstP=80, ACK, Ack = y+1 SrcA= , SrcP=3344, DstA= , DstP=80, ACK, Seq=x+1, Ack = y+1, Data= GET /login.html SrcA= , SrcP=80, DstA= , DstP=3344, ACK, Seq = y+1, Ack = x+16, Data= 200 OK <html> 28

29 TCP Abrupt Termination! B X SYN SYN ACK ACK Data ACK RST A time A sends a TCP packet with RESET (RST) flag to B E.g., because app. process on A crashed (Could instead be that B sends a RST to A) Assuming sequence numbers in RST packet fit with what B expects, That's It: B's user-level process receives: ECONNRESET No further communication on connection is possible So: attacker who knows ports & sequence numbers can disrupt any TCP connection 29

30 TCP Threat: RST Injection! Client (initiator) IP address , port Server IP address , port 80 SrcA= , SrcP=3344, DstA= , DstP=80, ACK, Seq=x+1, Ack = y+1, Data= GET /login.html Attacker IP address , port N/A SrcA= , SrcP=80, DstA= , DstP=3344, RST, Seq = y+1, Ack = x+16 Client dutifully removes connection 30

31 TCP Threat: RST Injection! Client (initiator) IP address , port Server IP address , port 80 SrcA= , SrcP=3344, DstA= , DstP=80, ACK, Seq=x+1, Ack = y+1, Data= GET /login.html Attacker IP address , port N/A SrcA= , SrcP=80, DstA= , DstP=3344, RST, Seq = y+1, Ack = x+16 Client rejects since no active connection X SrcA= , SrcP=80, DstA= , DstP=3344, ACK, Seq = y+1, Ack = x+16, Data= 200 OK <html> 31

32 TCP Threat: Data Injection! B SYN SYN ACK ACK Data ACK Nasty Data Nasty Data2 A time What about inserting data rather than disrupting a connection? Again, all that's required is attacker knows correct ports, seq. numbers Receiver B is none the wiser! Termed TCP connection hijacking (or session hijacking ) A general way to take over an already-established connection! We are toast if an attacker can see our TCP traffic! Because then they immediately know the port & sequence numbers 32

33 TCP Data Injection! Client (initiator) IP address , port Server IP address , port 80 SrcA= , SrcP=3344, DstA= , DstP=80, ACK, Seq=x+1, Ack = y+1, Data= GET /login.html Client dutifully processes as server's response Attacker IP address , port N/A SrcA= , SrcP=80, DstA= , DstP=3344, ACK, Seq = y+1, Ack = x+16 Data= 200 OK <poison> 33

34 TCP Data Injection! Client (initiator) IP address , port Server IP address , port 80 SrcA= , SrcP=3344, DstA= , DstP=80, ACK, Seq=x+1, Ack = y+1, Data= GET /login.html Client ignores since already processed that part of bytestream Attacker IP address , port N/A SrcA= , SrcP=80, DstA= , DstP=3344, ACK, Seq = y+1, Ack = x+16 Data= 200 OK <poison> SrcA= , SrcP=80, DstA= , DstP=3344, ACK, Seq = y+1, Ack = x+16, Data= 200 OK <html> 34

35 TCP Threat: Blind Spoofing! Is it possible for an attacker to inject into a TCP connection even if they can't see our traffic? YES: if somehow they can guess the port and sequence numbers Let's look at related attack where goal of attacker is to create a fake connection, rather than inject into a real one Why? To leverage server's trust of authenticating clients by their IP addresses (since fixed!) 35

36 Spoofing an Entire TCP Connection! Alleged Client (not actual) IP address , port N/A Server IP address , port 80 Blind Attacker SrcA= , SrcP=5566, DstA= , DstP=80, SYN, Seq = z SrcA= , SrcP=80, DstA= , DstP=5566, SYN+ACK, Seq = y, Ack = z+1 Attacker's goal: SrcA= , SrcP=5566, DstA= , DstP=80, ACK, Seq = z+1, ACK = y+1 SrcA= , SrcP=5566, DstA= , DstP=80, ACK, Seq = z+1, ACK = y+1, Data = GET /transfer-money.html 36

37 Spoofing an Entire TCP Connection! Alleged Client (not actual) IP address , port N/A Server IP address , port 80 Blind Attacker SrcA= , SrcP=5566, DstA= , DstP=80, SYN, Seq = z SrcA= , SrcP=80, DstA= , DstP=5566, SYN+ACK, Seq = y, Ack = x+1 Small Note #1: if real client receives this, will be confused send a RST back to server So attacker may need to hurry! 37

38 Spoofing an Entire TCP Connection! Alleged Client (not actual) IP address , port N/A Server IP address , port 80 Blind Attacker SrcA= , SrcP=5566, DstA= , DstP=80, SYN, Seq = z SrcA= , SrcP=80, DstA= , DstP=5566, SYN+ACK, Seq = y, Ack = z+1 Big Note #2: attacker doesn't get to see this packet! 38

39 Spoofing an Entire TCP Connection! Alleged Client (not actual) IP address , port N/A Server IP address , port 80 Blind Attacker SrcA= , SrcP=5566, DstA= , DstP=80, SYN, Seq = z SrcA= , SrcP=80, DstA= , DstP=5566, SYN+ACK, Seq = y, Ack = z+1 SrcA= , SrcP=5566, DstA= , DstP=80, ACK, Seq = z+1, ACK = y+1 So how can the attacker figure out what value of y to use for their ACK? SrcA= , SrcP=5566, DstA= , DstP=80, ACK, Seq = z+1, ACK = y+1, Data = POST /transfer-money.html 39

40 TCP Conn. Setup & Data Exchange! Client (initiator) IP address , port 3344 Server IP address , port 80 SrcA= , SrcP=3344, DstA= , DstP=80, SYN, Seq = x SrcA= , SrcP=80, DstA= , DstP=3344, SYN+ACK, Seq = y, Ack = x+1 Server also picks an ISN (spec says to use local clock) How Do We Fix This? Hmm, any way for the attacker to know this? Use a (Pseudo)- Random ISN Make a non-spoofed connection first, and see what server used for ISN then! 40 40

41 TCP's Rate Management! Unless there's loss, TCP doubles data in flight every round-trip. All TCPs expected to obey ( fairness ). Mechanism: for each arriving ack for new data, increase allowed data by 1 maximum-sized packet Src D 0-99 A D A 200 A 300 D D D D 100 D A A A A Dest Time E.g., suppose maximum-sized packet = 100 bytes 41

42 Protocol Cheating! How can receiver get data to arrive faster than normally allowed? (say to juice their web surfing) ACK-Splitting: each ack, even if partial, increases allowed data by one maximum-sized packet Src D D D 0-99 A 25 A 50 D D D Dest A 75 A 100 Time How do we prevent this? Change rule to require full ack for all data sent in a packet 42

43 Protocol Cheating! How can the destination (receiver) still get data to come to them faster than normally allowed? Optimistic ack'ing: acknowledge data not yet seen! Src D D D 0-99 D D A 100 A 200 D Dest A 300 A 400 Time How do we prevent this? 43

44 Keeping Receivers Honest! Approach #1: if you receive an ack for data you haven't sent, kill the connection Works only if receiver acks too far ahead Approach #2: follow the round trip time (RTT) and if ack arrives too quickly, kill the connection Flaky: RTT can vary a lot, so you might kill innocent connections Approach #3: make the receiver prove they received the data Note: a protocol change Add a nonce ( random marker) & require receiver to include it in ack. Kill connections w/ incorrect nonces o (nonce could be function computed over payload, so sender doesn't explicitly transmit, only implicitly) 44

45 Summary of TCP Security Issues! An attacker who can observe your TCP connection can manipulate it: Forcefully terminate by forging a RST packet Inject (spoof) data into either direction by forging data packets Works because they can include in their spoofed traffic the correct sequence numbers (both directions) and TCP ports Remains a major threat today 45

46 Summary of TCP Security Issues! An attacker who can observe your TCP connection can manipulate it: Forcefully terminate by forging a RST packet Inject (spoof) data into either direction by forging data packets Works because they can include in their spoofed traffic the correct sequence numbers (both directions) and TCP ports Remains a major threat today An attacker who can predict the ISN chosen by a server can blind spoof a connection to the server Makes it appear that host ABC has connected, and has sent data of the attacker's choosing, when in fact it hasn't Undermines any security based on trusting ABC's IP address Allows attacker to frame ABC or otherwise avoid detection Fixed today by choosing random ISNs 46

47 TCP Security Issues, con't! TCP limits the rate at which senders transmit: TCP relies on endpoints behaving properly to achieve fairness Protocol lacks mechanism to prevent cheating Senders can cheat by just not abiding by the limits o Remains a significant vulnerability: essentially nothing today prevents Receivers can manipulate honest senders into sending too fast because senders trust that receivers are honest To a degree, sender can validate (e.g., partial acks) A nonce can force receiver to only act on data they've seen Such rate manipulation remains a vulnerability today General observation: tension between ease/power of protocols that assume everyone follows vs. violating Security problems persist due to difficulties of retrofitting coupled with investment in installed base 47