Chap3_3 Flashcards
User Datagram Protocol (UDP)
Unreliable transport on top of IP:
No acknowledgments; no message continuation
No congestion/flow control
Simply: IP + ports
UDP Vulnerabilities
Source IP and port not authenticated
Some UDP based services reply to any message
UDP Attacks Fraggle
Broadcast UDP packet sent to the “echo” service
All computers reply (amplification)
Source IP was spoofed, victim is overwhelmed
Similar to the ICMP Smurf attack
UDP Ping-Pong
Some service or application issues a UDP reply no matter what is the input packet
Set the source and destination ports of a UDP to
be one of the following ports
daytime (port 13)
time (port 37)
This causes a Ping-Pong effect between the source
and the destination.
UDP: DoS Attacks
Applications that reply with large packets to
small requests, e.g., games
Hosts can be attacked by using these applications
as amplifiers, with forged source IP packets
Transmission Control Protocol (TCP)
Connection-oriented, preserves order Sender • Break data into packets • Attach packet numbers Receiver • Acknowledge receipt; lost packets are resent • Reassemble packets in correct order Connection setup mechanisms (three-way handshaking)
But NO authentication
TCP Vulnerabilities
No authentication of source A TCP endpoint must accept out of order packets that are within the range of a window size RST segments must be processed immediately No authentication of SYN, RST, FIN messages No authentication of quench requests
TCP:Attack: Sequence number prediction
Insider sniffing attack (insider adversary)
Outsider attack:
• Sequence number increments a constant amount per
second (prediction straightforward)
• Sequence number generated using a pseudo-random
algorithm (prediction possible but maybe complex)
Implications:
TCP connection spoofing
TCP session hijacking
DoS
Defense: random initial sequence numbers
TCP: SYN Flooding
An attacker sends many SYN packets to create
multiple connections without ever sending an ACK
to complete the connection
The victim has to keep the half-opened connection
in its memory for certain amount of time (ex: 75
seconds)
If there are so many of these malicious packets,
the victim quickly runs out of memory
TCP SYN Flooding: Real Example
MS Blaster worm (2003)
Infected machines sent:
• SYN flood on port 80 to windowsupdate.com
• 50 SYN packets every second.
– each packet is 40 bytes.
• Spoofed source IP: a.b.X.Y where X,Y random.
On 16 July 2003 Microsoft Security Bulletin
MS03-026 announced a buffer overrun in the
Windows Remote Procedure Call (RPC) interface
that could let attackers execute arbitrary code
TCP SYN Flooding: Example II
DDoS attack
20,000 bots can generate 2Gb/sec of SYNs
At web site:
• Saturates network uplink or network router
• Random source IP
attack SYNs look the same as real SYNs
TCP Session or Connection
Hijacking (Mitnick Attack)
Attacker gains control of a communication
mid stream
Disrupt: Send a packet with RST and correct
sequence and Ack numbers, and spoofed IP of
one of the victims
Works because even if data is encrypted
TCP header is not
TCP RST Attacks
Attackers inject RST segment into an existing TCP
connection, causing it to be closed
TCP Reset attack is possible due to the requirements
that:
A TCP endpoint MUST accept out of order packets that are
within the range of a window size, and
The Reset flags SHOULD be processed immediately
TCP Connection Spoofing
Suppose init. sequence numbers are predictable
Attacker can create TCP session on behalf of forged source
IP
Random Initial TCP SNs
Unpredictable SNs prevent basic packet injection
… but attacker can inject packets after
eavesdropping to obtain current SN
Most TCP stacks now generate random SNs
TCP DoS Attack
Suppose attacker can guess sequence number for an
existing connection:
Attacker can send Reset packet to close connection;
results in DoS.
TCP: Fingerprinting Hosts
Unique responses and values used (TTL, TOS, …)
facilitate host fingerprinting
Tool: nmap –O –v host: identifies OS version and tells
you how difficult it is to predict ISN
FIN Probe
Send FIN packet (or any packet without ACK or SYN flag) to
an open port
Wait for response
Correct RFC793 behavior is to NOT respond
Many broken implementations (MS Windows, BSDI, CISCO,
HP/UX, MVS and IRIX) send a RST back
Most current tools utilize this technique
Fingerprinting Hosts: BOGUS Flag Probe
Queso was the first scanner to use this clever test
Set an undefined TCP Flag (bit 7 or 8, counting from
the left) in a SYN packet
Linux prior to 2.0.35 keep the flag set in their
response
However, some OSs reset the connection when they
receive SYN+BOGUS packet
Update: Bit 8 (and 9) are now used as the “ECN field”
for TCP congestion control
Explicit Congestion Notification (ECN) for TCP/IP