TAOSSA Chapters 14-15

Ch. 14 Network Protocols

Internet Protocol

General intro about IP packet structure

Basic IP header validation

• Is the received packet too small?
  • Must be at least 20 bytes.
• Does the IP packet contain options?
  • Packets with options can be bigger than 20 bytes, up to 60.
• Is the IP header length valid?
  • IP header length must be at least 5 (4*5=20).
• Is the total length field too large?
  • Compared to the actual data received.
• Are all field lengths consistent?
  • IP header length <= data available
  • 20 <= IP header length <= 60
  • IP total length <= data available
  • IP header length <= IP total length
• Is the IP checksum correct?

IP options processing

• Is the option length sign-extended?
  • It shouldn’t be. Byte to int promotion issues are common
• Is the header big enough to contain the IP option?
• Is the option length too large?
  • Offset of IP option + IP option length <= IP header length
  • Offset of IP option + IP option length <= IP total length
• Does the option meet minimum size requirements?
  • Should be at least 2
• Are IP option buts checked?
  • Most implementations ignore the separate bitfields without parsing
• Unique problems
  • Solaris example

Source routing

• Processing
  • Ensure that the pointer byte is within the specified bounds. During processing, an IP option often modifies bytes it pointing at.
  • The pointer is a single-byte field - beware type conversions.
  • Sign extensions could cause the offset to take on a negative value
  • Check that the length of routing options is validated

Fragmentation

Pathological fragment sets

• Data beyond the end of the final segment
  • Attackers can put the final fragment (MF=0) in the middle or beginning of the set of fragments
• Multiple final fragments
• Overlapping fragments
• Idiosyncrasies

User datagram protocol

Basic UDP header validation

• Us the UDP length field correct?
  • The minimum value is 8 bytes (no data)
• Is the UDP checksum correct?

Transmission control protocol

Basic TCP header validation

• Is the TCP data offset field too large?
  • TCP header length <= data available
  • 20 bytes (5 * 4) <= TCP header length <= 60 bytes
• Is the TCP header length too small?
• Id the TCP checksum correct?

TCP options processing

• Is the option length field sign extended?
  • It shouldn’t be, possibility of dangerous bugs
  • For example, assigning char value to an int variable
• Are enough bytes left for the current option?
• Is the option length too large or too small?
  • Compared to the size of the TCP header / packet

TCP connections

• 11 states: LISTEN, SYN_SENT, SYN_RCVD, ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, CLOSING, TIME_WAIT, CLOSE_WAIT, LAST_ACK, CLOSED
• 6 flags: SYN, ACK, RST, URG, FIN, PSH
• Setting up, closing, tearing down of connections

TCP streams

Sequence numbers (ISNs). TCP spoofing attacks and others

TCP state processing

Various vulns

Urgent pointer processing

• Handling pointers tint other packets
  • Neglecting to check that the pointer is within the bounds of the current packet
  • Recognising that the pointer is pointing beyond the end of the packet and trying to handle it (often incorrectly)
• Handling 0-offset urgent pointers
  • 0 offset URG pointer is invalid

Simultaneous open

Both peers send a SYN packet at the same time with mirrors source and destination ports. Then they both send a SYN-ACK packet, and the connection is established.

Ch. 15 Firewalls

Intro

Attack surface - Proxy firewalls

Same issues as with network servers. Also make sure the firewall makes a clear distinction between internal and external users or tracks authorised users.

Packet-filtering firewalls

Stateless vs stateful filters

Stateless Firewalls

TCP
Stateless firewalls look for connection initiation packets - SYNs, and more or less let other packets go through.
Can be abused for FIN scanning (not sure this works anymore). Stateless FW has to let FIN and RST packets through.
Different stacks behave differently for weird combinations of flags. Eg. SYN-FIN may initiate a connection.
UDP
Only port-based rules. Return packets a big problem - e.g. DNS replies from servers. Effectively creates a hole for UDP scanning with a source port 53.
FTP
Active / passive FTP; active is a problem for stateless firewalls, similar to UDP above but with TCP.
Fragmentation
Either deny completely or apply very simple set of rules to process. No tracking because stateless. Some rules:

• Fragments with low IP offset (1,2 etc) - drop as they will mess with TCP flags
• Fragments with 0 offset should contain the full header, otherwise drop
• Multiple offset 0 fragments - drop all after the full header
• Fragments with high offset can pass

Simple stateful firewalls

• TCP
  • These days any issues are rare
• UDP
  • A common mistake is to allow responses from any UDP port
• Directionality
• Fragmentation handling
  • Can be done better than with stateless FWs. Bugs existed
• Fooling virtual reassembly
• IP TTL field
• IP options

Stateful inspection firewalls

• Checkpoint’s original term - looking inside the packet
• Layering issues
  • Firewalls are not doing full TCP/IP processing and so make mistakes because they peek at layer they do not understand
  • For FTP, simplistic port lookup in the packet can be fooled into creating connections in the state table by faking 227 responses in the packet

Spoofing attacks

Obviously cannot muck with the destination IP.

• Spoofing from an internal trusted source
• Spoofing for a response
  • Try to get hosts to respond to addresses you cannot reach otherwise
  • Especially with source address 224.0.0.1 or 127.0.0.1
• Spoofing for a state entry - to get special entries added to the firewall state table for later use
• Spoofing from a network peer
• Spoofing destinations to create state table entries
• Source routing and encapsulation