1 / 66

15-446 Networked Systems Practicum

15-446 Networked Systems Practicum. Lecture 13 – IP Weaknesses. Overview. Security holes Firewalls TCP receiver attacks. Flashback .. Internet design goals. Interconnection Failure resilience Multiple types of service Variety of networks Management of resources Cost-effective

albin
Download Presentation

15-446 Networked Systems Practicum

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 15-446 Networked Systems Practicum Lecture 13 – IP Weaknesses

  2. Overview • Security holes • Firewalls • TCP receiver attacks

  3. Flashback .. Internet design goals • Interconnection • Failure resilience • Multiple types of service • Variety of networks • Management of resources • Cost-effective • Low entry-cost • Accountability for resources Where is security?

  4. Why did they leave it out? • Designed for connectivity • Network designed with implicit trust • No “bad” guys • Can’t security be provided at the edge? • Encryption, Authentication etc • End-to-end arguments in system design

  5. Security Vulnerabilities • At every layer in the protocol stack! • Network-layer attacks • IP-level vulnerabilities • Routing attacks • Transport-layer attacks • TCP vulnerabilities • Application-layer attacks

  6. IP-level vulnerabilities • IP addresses are provided by the source • Spoofing attacks • Using IP address for authentication • e.g., login with .rhosts • Some “features” that have been exploited • Fragmentation • Broadcast for traffic amplification

  7. Security Flaws in IP • The IP addresses are filled in by the originating host • Address spoofing • Using source address for authentication • r-utilities (rlogin, rsh, rhosts etc..) • Can A claim it is B to the server S? • ARP Spoofing • Can C claim it is B to the server S? • Source Routing C 2.1.1.1 Internet S 1.1.1.3 A 1.1.1.1 1.1.1.2 B

  8. ARP Spoofing Attacker uses ARP protocol to associate MAC address of attacker with another host's IP address E.g. become the default gateway: Forward packets to real gateway (interception) Alter packets and forward (man-in-the-middle attack) Use non-existant MAC address or just drop packets (denial of service attack) ARP Spoofing used in hotel & airport networks to direct new hosts to register before getting "connected"

  9. Source Routing ARP spoofing cannot redirect packets to another network We have studied routing protocols: routers do all the work, so if you spoof an IP source address, replies go to the spoofed host An option in IP is to provide a route in the packet: source routing. Equivalent to tunneling. Attack: spoof the host IP address and specify a source route back to the attacker.

  10. ICMP • Reports errors and other conditions from network to end hosts • End hosts take actions to respond to error • No authentication • Problem • An entity can easily forge a variety of ICMP error messages • Redirect – informs end-hosts that it should be using different first hop route • Fragmentation – can confuse path MTU discovery • Destination unreachable – can cause transport connections to be dropped • Many more… • http://www.sans.org/rr/whitepapers/threats/477.php

  11. ICMP Redirect ICMP Redirect message: tell a host to use a different gateway on the same network (saves a hop for future packets) Host A "Good" Gateway Attacker Spoof an ICMP Redirect message from "Good" Gateway to redirect traffic through Attacker TCP packets

  12. Smurf Attack Ping request to a broadcast address with source = victim's IP address Internet Ping reply from every host Attacking System Replies directed to victim Ping request to broadcast address with source = victim's IP address Broadcast Enabled Network Victim System

  13. Routing • Source routing • Destinations are expected to reverse source route for replies • Problem – Can force packets to be routed through convenient monitoring point • Solution – Disallow source routing – doesn’t work well anyway!

  14. Routing • Routing protocol • Malicious hosts may advertise routes into network • Problem – Bogus routes may enable host to monitor traffic or deny service to others • Solutions • Use policy mechanisms to only accept routes from or to certain networks/entities • In link state routing, can use something like source routing to force packets onto valid route • Routing registries and certificates

  15. Routing attacks • Divert traffic to malicious nodes • Black-hole • Eavesdropping • How to implement routing attacks? • Distance-Vector: Announce low-cost routes • Link-state: Dropping links from topology • BGP vulnerabilities • Prefix-hijacking • Path alteration • In early 2008, at least eight US Universities had their traffic diverted to Indonesia for about 90 minutes one morning in an attack kept mostly quiet by those involved. Also, in February 2008, a large portion of YouTube's address space was redirected to Pakistan when the PTA decided to block access to the site from inside the country, but accidentally blackholed the route in the global BGP table.

  16. DNS • Users/hosts typically trust the host-address mapping provided by DNS • Problems • Zone transfers can provide useful list of target hosts • Interception of requests or comprise of DNS servers can result in bogus responses • Solution – authenticated requests/responses

  17. Basic IP • End hosts create IP packets and routers process them purely based on destination address alone (not quite in reality) • Problem – End host may lie about other fields and not affect delivery • Source address – host may trick destination into believing that packet is from trusted source • Many applications use IP address as a simple authentication method • Solution – reverse path forwarding checks, better authentication • Fragmentation – can consume memory resources or otherwise trick destination/firewalls • Solution – disallow fragments

  18. Bandwidth DOS Attacks • Possible solutions • Ingress filtering – examine packets to identify bogus source addresses • Link testing – how routers either explicitly identify which hops are involved in attack or use controlled flooding and a network map to perturb attack traffic • Logging – log packets at key routers and post-process to identify attacker’s path • ICMP traceback – sample occasional packets and copy path info into special ICMP messages • IP traceback

  19. TCP-level attacks • SYN-Floods • Implementations create state at servers before connection is fully established • Session hijack • Pretend to be a trusted host • Sequence number guessing • Session resets • Close a legitimate connection

  20. SYN Flooding • Objective of attack: make a service unusable, usually by overloading the server or network • Example: SYN flooding attack • Send SYN packets with bogus source address • Server responds with SYNACK keeps state about TCP half-open connection • Eventually server memory is exhausted with this state • Solution: SYN cookies – make the SYNACK contents purely a function of SYN contents, therefore, it can be recomputed on reception of next ACK

  21. TCP • Each TCP connection has an agreed upon/negotiated set of associated state • Starting sequence numbers, port numbers • Knowing these parameters is sometimes used to provide some sense of security • Problem • Easy to guess these values • Listening ports #’s are well known and connecting port #’s are typically allocated sequentially • Starting sequence number are chosen in predictable way • Solution – make sequence number selection more random

  22. Shimomura (S) Trusted (T) Mitnick An Example Finger Showmount -e SYN • Finger @S • showmount –e • Send 20 SYN packets to S • Attack when no one is around • What other systems it trusts? • Determine ISN behavior

  23. Shimomura (S) Trusted (T) Mitnick An Example X Syn flood • Finger @S • showmount –e • Send 20 SYN packets to S • SYN flood T • Attack when no one is around • What other systems it trusts? • Determine ISN behavior • T won’t respond to packets

  24. Shimomura (S) Trusted (T) Mitnick An Example SYN|ACK X ACK SYN • Finger @S • showmount –e • Send 20 SYN packets to S • SYN flood T • Send SYN to S spoofing as T • Send ACK to S with a guessed number • Attack when no one is around • What other systems it trusts? • Determine ISN behavior • T won’t respond to packets • S assumes that it has a session with T

  25. Shimomura (S) Trusted (T) Mitnick An Example X ++ > rhosts • Finger @S • showmount –e • Send 20 SYN packets to S • SYN flood T • Send SYN to S spoofing as T • Send ACK to S with a guessed number • Send “echo + + > ~/.rhosts” • Attack when no one is around • What other systems it trusts? • Determine ISN behavior • T won’t respond to packets • S assumes that it has a session with T • Give permission to anyone from anywhere

  26. TCP Layer Attacks • TCP Session Poisoning • Send RST packet • Will tear down connection • Do you have to guess the exact sequence number? • Anywhere in window is fine • For 64k window it takes 64k packets to reset • About 15 seconds for a T1

  27. TCP • TCP senders assume that receivers behave in certain ways (e.g. when they send acks, etc.) • Congestion control is typically done on a “packet” basis while the rest of TCP is based on bytes • Problem – misbehaving receiver can trick sender into ignoring congestion control • Ack every byte in packet! • Send extra duplicate acks • Ack before the data is received (needs some application level retransmission – e.g. HTTP 1.1 range requests) • Solutions • Make congestion control byte oriented • Add nonces to packets – acks return nonce to truly indicate reception

  28. Where do the problems come from? • Protocol-level vulnerabilities • Implicit trust assumptions in design • Implementation vulnerabilities • Both on routers and end-hosts • Incomplete specifications • Often left to the imagination of programmers

  29. Overview • Security holes • Firewalls • TCP receiver attacks

  30. Introduction • TCP end-to-end congestion control mechanism implicitly rely on decent endpoints to decide proper data rate. • But misbehaving senders can send data more quickly, forcing competing traffic to be delayed or discarded. Interestingly, receivers can do the same, too! • Note that # of receivers is extremely large (all Internet users) and has both the incentive (faster download) and opportunity (open source OSes) to exploit this vulnerability.

  31. Quick Review of TCP Congestion Control • Connection-oriented, reliable, ordered, • byte-stream protocol with explicit flow control • Divides data into SMSS (Sender Maximum Segment Size), and labels with sequence #s to guarantee ordering and reliability • When a host receives in-sequence segment, it sends an ACK, if an out-of-sequence segment is received, it sends next expected sequence # • If no ACK received within a timeout, sender transmits again

  32. TCP Congestion Control Algorithms • Both Slow Start and Congestion Avoidance controls sending rate by manipulating a congestion window (cwnd) • Slow Start: • Quickly increase and decrease cwnd to roughly approximate the bottleneck capacity (exponential) • Congestion Avoidance: • Fine tuning. Increase cwnd more slowly to probe additional bandwidth that may become available. (linear)

  33. Vulnerabilities • Three types of attack: • ACK division • DupACK spoofing • Optimistic ACKing • In addition to DoS attacks, these techniques can be used to enhance attacker’s throughput at the expense of behaving clients.

  34. Attack #1: ACK Division • RFC 2581 (most recent TCP congestion control specification at the time of this paper) states • During slow start, TCP increments cwnd by at most SMSS bytes for each ACK received that acknowledges new data • … • During congestion avoidance, cwnd is incremented by one full-sized segment per RTT (round trip time) • The discord between the byte granularity of error control and the segment granularity of congestion control leads to vulnerability.

  35. Attack #1: ACK Division • The Attack: • When you receive a data segment with N bytes • Divide corresponding ACK into M pieces, where M  N • Each separate ACK covers one of M distinct pieces of received data

  36. Attack #1: ACK Division • Each ACK is valid since it covers data that was sent and previously unacknowledged • This leads the sender to grow cwnd M times faster than usual • Receiver can control this rate of growth, maximum M = N • As seen in the example, after one RTT, cwnd = 4, instead of the expected value of 2 Sample time line for ACK division attack.

  37. Attack #2: DupACK Spoofing • TCP uses two algorithms, fast retransmit and fast recovery, to decrease the effects of packet loss • Quoted from RFC 2581 • Set cwnd to ssthresh plus 3*SMSS. This artificially “inflates” the congestion window by the number of segments (3) that have left the network and which the receiver has buffered. … • For each additional duplicate ACK received, increment cwnd by SMSS. This artificially inflates the cwnd in order to reflect the additional segment that has left the network.

  38. Attack #2: DupACK Spoofing • Two problems with this approach • Byte vs. segment granularity problem • TCP requires exact duplicate ACKs, therefore it’s impossible to understand which data segment they correspond to. • There’s no way to differentiate a valid duplicate ACK with a spoofed one

  39. Attack #2: DupACK Spoofing • The Attack • When you receive a data segment, send lots of ACKs for the last sequence # received (at a start of a connection, this would be for the SYN segment)

  40. Attack #2: DupACK Spoofing • The first four ACKs for the same sequence # cause the sender to retransmit the first segment. • However, cwnd is increased by SMSS for each additional duplicate, for a total of 4 segments • Since duplicate ACKs are indistinguishable, this attack is also valid. Sample time line for DupACK attack.

  41. Attack #3: Optimistic ACKing • Since TCP’s cwnd growth is a function of RTT (exponential during slow start, linear during congestion avoidance), sender-receiver pairs with shorter RTT will transfer data more quickly • Hence, it’s possible for a receiver to emulate a shorter RTT by sending ACKs optimistically for data it has not received yet

  42. Attack #3: Optimistic ACKing • The Attack: • When you receive a data segment, send lots of ACKs anticipating data that will be sent by the sender • This attack does not preserve end-to-end reliability, e.g. if a packet is lost, it’s unrecoverable • However, new features in HTTP-1.1 allows receivers to request particular byte ranges • So, data is gathered on one connection and lost segments are then collected selectively with application layer re-transmissions

  43. Attack #3: Optimistic ACKing • What makes Optimistic ACKing more dangerous • After reaching to bottleneck rate, a receiver sends ACKs in spite of losses • By concealing losses, it eliminates the only congestion signal available to sender • A malicious attacker can conceal all losses and leads the sender to increase cwnd indefinitely

  44. Attack #3: Optimistic ACKing • Since senders generally send full-sized segments, it’s easy for a receiver to guess the correct sequence # to use in ACKs, but this accuracy is not mandatory • If an ACK arrives for the data that has not yet been sent, this is generally ignored by sender – allowing the receiver to be more aggressive Sample time line for Optimistic ACKing attack.

  45. Solution to ACK Division • Ambiguity about how ACKs should be interpreted – violation of 2nd principle • Two obvious solutions • Increment cwnd only proportional to the amount of data ACKed • Increment cwnd by one SMSS only when a valid ACK arrives covering the entire data segment sent • This technique is being used by Linux 2.2.x

  46. Solution: Cumulative Nonce • Sender sends random number (nonce) with each packet • Receiver sends cumulative sum of nonces • if receiver detects loss, it sends back the last nonce it received • Why cumulative?

  47. Overview • Security holes • Firewalls • TCP receiver attacks

  48. Firewalls • Basic problem – many network applications and protocols have security problems that are fixed over time • Difficult for users to keep up with changes and keep host secure • Solution • Administrators limit access to end hosts by using a firewall • Firewall and limited number of machines at site are kept up-to-date by administrators

  49. Firewalls (contd…) • Firewall inspects traffic through it • Allows traffic specified in the policy • Drops everything else • Two Types • Packet Filters, Proxies Internal Network Firewall Internet

  50. Typical Firewall Configuration Internet • Internal hosts can access DMZ and Internet • External hosts can access DMZ only, not Intranet • DMZ hosts can access Internet only • Advantages? • If a service gets compromised in DMZ it cannot affect internal hosts DMZ X X Intranet

More Related