Skip to content

TCP Attacks

  • TCP/IP protocol suite has two transport layer protocols: TCP and UDP
    • TCP: reliabale and ordered communication
    • UDP (User Datagram Protocol): unreliable, unordered but lightweight and lower overhead

TCP Protocol

  • requires both ends of communication maintain a connection
  • once connection is established, OS allocates two buffers at each end: one for sending, one for receiving
  • both ends can send and receive data
  • application sending data places it in the send buffer, OS manages the sending out, with possible delay to ensure there is enough data to send out
  • TCP packet header includes a sequence number used to order the packets at receiving end, even if they arrive out of order
  • Received packets are placed in receive buffer, and merged into a single data stream
  • When receive buffer has received enough data or waited sufficiently, the data is made available to application
  • the receiver must inform sender data has been received by sending an acknowledgement packet
    • for performance reasons ack is not sent for every packet; the ack includes a filed to let sender know what sequence number packet is needed next
    • if sender does not receive ack within a certain time period, it assumes data was lost and re-transmits the data
  • TCP connection is established using three-way handshake protocol

TCP header

part details
Sequence if SYN bit is set, this is the initial sequence number
Acknowledgement only valid if ACK bit it set: contains the value of next expected sequence number
Window used to specify the number of octets that the sender of this TCP segment is willing to accept, usually based on available space in receiving buffer
Urgent set when first part of data contains urgent data, e.g. exception → different mechanism is usually used to handle urgent packets at receiving end
Options variable length of options; to deal with limitation of original header
Reserved not used
Code bits SYN, FIN, ACK, RST, PSH (have different purposes)

SYN Flooding

  • targets the period when TCP connection is being established

  • three-way handshake consists of:

    1. client sends SYN packet to server, with random sequence number (SYN set to 1)
    2. server responds with SYN + ACK packet (SYN and ACK set to 1)
    3. client sends ACK packet to conclude the handshake

  • When server receives initial SYN packet it is stored as Transmission Control Block (TCB) in a queue, to persist information of ongoing connection process; the connection is half-open

  • after connection is established, TCB is removed form queue

  • if ACK is not received from client, TCP will eventually time out and removed from queue

  • In SYN flooding attack, attacker fills the queue of half-open connections, to make the server unable to accept new SYN packets

  • SYN flooding steps:

    1. continuously send SYN packets to server
    2. do not finish 3rd protocol step

  • The TCB should stay in the queue as long as possible; it may be dequeued because:

    1. if client finishes 3-way handshake
    2. it has been there too long/past timeout
    3. if server receives RST packet for half-open connection

  • Attacker needs to use random IP addresses, otherwise the attack can be easily blocked by firewalls → when server responds with SYN + ACK the random IP will likely drop because it doesn't match a valid IP or machine at that address is not configured to respond

SYN Cookies

  • idea: do not allocate resources at all for storing half-open connections

    • new problem: verifying whether received ACK is result of previous SYN+ACK, or simply spoofed
    • attacker can launch ACK flooding attack, causing server to allocate resources
    • SYN cookies provide an elegant solution

  • SYN Cookies are a countermeasures against SYN flooding; enabled by default on Ubuntu

  • kicks in when count-of half-open connections reaches a threshold indicating possible SYN flooding attack

  • SYN cookie uses uses the random sequence number to encode useful information

    • after receiving packet, it calculates a keyed hash (H), using a secret only server knows
    • the hash becomes the initial sequence number on servers SYN+ACK sent back to client
    • the value H is the SYN cookie
    • if client is legitimate, it responds with H+1
    • when server receives ACK from client, it can recalculate the H and make sure it matches
    • ensures the ACK is a consequence of previous SYN + ACK packet
    • if client is an attacker, packet will not reach the attacker, and cannot easily forge a valid cookie

TCP Reset Attack

  • objective: break existing connection between two victim hosts

  • Mechanisms for closing a TCP connection:

    • TCP FIN protocol:
      • one side (A) sending a packet with FIN bit set, other client (B) responds with ACK
      • repeated A-to-B is closed; repeated for B-to-A direction to fully close connection
    • One side sends RST packet: connection closes immediately
      • intended for emergency use in place of TCP FIN
      • also used when errors detected, e.g. after receiving unintentional SYN + ACK

  • in TCP Reset, attacker sends a RST packet to break an established connection, either from A-B or B-A

  • to make this attack successful attacker needs to complete TCP headers correctly, to include having a valid sequence number

    • if attacker is on the same network they can sniff the right sequence number

  • SSH encrypts data at transport layer, the header is still plaintext

    • attacker can perform TCP Reset on SSH because only the header part must look legitimate
    • SSH uses port 22 (telnet uses port 23)

  • This attack works on UDP connections

    • UDP sequence number increases very fast → must automate the attack
    • sniff-and-spoof: run a program that sniffs packets, gets essential packet data, automatically sends spoofed RST packet

TCP Session Hijacking

  • objective: attacker injects data of choice between two hosts who have previously established a legitimate connection, compromising the integrity of this connection

  • TCP connections can exist between multiple hosts on a single machine

    • Identifying which TCP connection a packet belongs to is based on: source and destination IP, source and destination port number, and valid sequence number
    • if this data matches, it is matches a legitimate packet belonging to a TCP session
    • if attacker can correctly spoof this data, it will be accepted by receiver

  • Telnet servers are configured to run commands → if able to hijack a session the target can be made to run malicious commands, using victims privileges

  • It maybe difficult to get the right sequence number → add small positive offset; as long as it is within valid window it will be placed in received buffer

    • if legitimate user continues communication, packet will eventually be consumed

  • After successful attack, real user will see retransmission messages because session hijack messes up sequence numbering

    • user has not reached the sequence number yet, will not respond to server
    • when server does not receive an ACK it will retransmit, again dropped by user
    • when legitimate user attempts to send packet with sequence number already used by attacker, server will disregard it
    • client and server enter a deadlock

  • TCP hijacking can be mitigated with encryption