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?
Look back at some of the goals of early internet design .. Security doesn’t seem to figure at all!

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
Turns .. Out the original design was geared toward connectivity and getting different formats/protocols to interoperate. And since it was largely an academic initiative, there was implict trust across the network. Another argument was that many security properties really are edge-level -- I.e. you have to provide them end-to-end anyway .. Why bother doing anything at the network-level! There is some truth to this -- especially authentication/integrity/confidentiality etc. but there are other network-layer problems that the e2e argument doesn’t quite cover!

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
Turns out .. There are vulnerabilities at every layer in the protocol stack -- network/transport/application. E.g., of network layer attacks include attacks on routing protocols and exploiting some of the drawbacks of internet addressing. Tranport layer attacks are things like session hijacks/syn floods etc. and of course application protocols could have their own set of problems

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
Internet S A 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…

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 Attacking System Victim System 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
How do we amplify the attack?
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 Session hijack Session resets
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. An Example Finger Showmount -e SYN Trusted (T) Mitnick Shimomura (S)
Send 20 SYN packets to S
Attack when no one is around
What other systems it trusts?
Determine ISN behavior

23. X An Example Trusted (T) Syn flood Mitnick Shimomura (S) 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. X An Example SYN|ACK ACK Trusted (T) SYN Mitnick Shimomura (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. X An Example Trusted (T) ++ > rhosts Mitnick Shimomura (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
High-level question is where do these security problems come from -- protocol/implementation/specification

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 Sample time line for ACK division attack.
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

51. Types of Firewalls Proxy
End host connects to proxy and asks it to perform actions on its behalf
Policy determines if action is secure or insecure
Transport level relays (SOCKS)
Ask proxy to create, accept TCP (or UDP) connection
Cannot secure against insecure application
Application level relays (e.g. HTTP, FTP, telnet, etc.)
Ask proxy to perform application action (e.g. HTTP Get, FTP transfer)
Can use application action to determine security
Requires applications (or dynamically linked libraries) to be modified to use the proxy
Considered to be the most secure since it has most information to make decision

52. Types of Firewalls: Packet Filters
Selectively passes packets from one network interface to another
Usually done within a router between external and internal network
What/How to filter?
Packet Header Fields
IP source and destination addresses
Application port numbers
ICMP message types/ Protocol options etc.
Packet contents (payloads)

53. Packet Filters: Possible Actions
Allow the packet to go through
Drop the packet (Notify Sender/Drop Silently)
Alter the packet (NAT?)
Log information about the packet

54. Some examples Block all packets from outside except for SMTP servers
Block all traffic to/from a list of domains
Ingress filtering
Drop pkt from outside with addresses inside the network
Egress filtering
Drop pkt from inside with addresses outside the network

55. Firewall implementation
Stateless packet filtering firewall
Rule  (Condition, Action)
Rules are processed in top-down order
If a condition satisfied – action is taken

56. Sample Firewall Rule Allow SSH from external hosts to internal hosts
Two rules
Inbound and outbound
How to know a packet is for SSH?
Inbound: src-port>1023, dst-port=22
Outbound: src-port=22, dst-port>1023
Protocol=TCP
Ack Set?
Problems?
SYN
SYN/ACK
ACK
Client
Server
Rule
Dir
Src Addr
Src Port
Dst Addr
Dst Port
Proto
Ack Set?
Action
Ext
Int
Out
SSH-2 In
SSH-1
> 1023 22
TCP
Yes
Any
Alow
Allow

57. Default Firewall Rules
Egress Filtering
Outbound traffic from external address  Drop
Benefits?
Ingress Filtering
Inbound Traffic from internal address  Drop
Default Deny
Why?
Rule
Dir
Src Addr
Src Port
Dst Addr
Dst Port
Proto
Ack Set?
Action
Egress
Out
Ext
Any
Ext
Any
Any
Any
Deny
Any
Deny
Int In
Ingress
Default
Any
Deny

58. Packet Filters Advantages Disadvantages
Transparent to application/user
Simple packet filters can be efficient
Disadvantages
Usually fail open
Very hard to configure the rules
May only have coarse-grained information?
Does port 22 always mean SSH?
Who is the user accessing the SSH?

59. Types of Firewalls Stateful packet filters
Typically allow richer parsing of each packet (variable length fields, application headers, etc.)
Actions can include the addition of new rules and the creation of state to process future packets
Often have to parse application payload to determine “intent” and determine security considerations
Rules can be based on packet contents and state created by past packets
Provides many of the security benefits of proxies but without having to modify applications

60. Proxy Firewall Data Available Advantages? Disadvantages?
Application level information
User information
Advantages?
Better policy enforcement
Better logging
Fail closed
Disadvantages?
Doesn’t perform as well
One proxy for each application
Client modification

61. Intrusion Detection Systems
Firewalls allow traffic only to legitimate hosts and services
Traffic to the legitimate hosts/services can have attacks
Solution?
Intrusion Detection Systems
Monitor data and behavior
Report when identify attacks

62. Classes of IDS What type of analysis? Where is it operating?
Signature-based
Anomaly-based
Where is it operating?
Network-based
Host-based

63. Signature-based IDS Characteristics Advantages? Disadvantages?
Uses known pattern matching to signify attack
Advantages?
Widely available
Fairly fast
Easy to implement
Easy to update
Disadvantages?
Cannot detect attacks for which it has no signature

64. Anomaly-based IDS Characteristics Advantages? Disadvantages?
Uses statistical model or machine learning engine to characterize normal usage behaviors
Recognizes departures from normal as potential intrusions
Advantages?
Can detect attempts to exploit new and unforeseen vulnerabilities
Can recognize authorized usage that falls outside the normal pattern
Disadvantages?
Generally slower, more resource intensive compared to signature-based IDS
Greater complexity, difficult to configure
Higher percentages of false alerts

65. Network-based IDS Characteristics Advantages? Disadvantages?
NIDS examine raw packets in the network passively and triggers alerts
Advantages?
Easy deployment
Unobtrusive
Difficult to evade if done at low level of network operation
Disadvantages?
Different hosts process packets differently
NIDS needs to create traffic seen at the end host
Need to have the complete network topology and complete host behavior

66. Host-based IDS Characteristics Advantages Disadvantages
Runs on single host
Can analyze audit-trails, logs, integrity of files and directories, etc.
Advantages
More accurate than NIDS
Less volume of traffic so less overhead
Disadvantages
Deployment is expensive
What happens when host get compromised?