Sniffing, Spoofing, MITM

Off-path TCP injection via shared counters

Cao, Qian, Wang, Dao, Krishnamurthy, Mao (USENIX 2016) showed off-path attackers could detect the existence of, and inject into, TCP connections by exploiting a global rate limit on challenge ACKs introduced by RFC 5961 (added 2010 to mitigate blind reset attacks).

Attack outline:

1. Attacker guesses the four-tuple (src IP, src port, dst IP, dst port). With knowledge of typical port ranges, only ~30K possibilities.
2. Sends an ACK packet probing the existence of the connection. The server's response (or lack thereof) depending on the global challenge-ACK counter reveals whether the connection exists.
3. Once the connection is confirmed, similar probing reveals the current sequence number window.
4. Inject data into the connection using the recovered four-tuple and sequence number.

Patched in Linux by per-connection rate limiting. The lesson: shared global counters across security domains leak signal.

CRIME and BREACH

Both exploit the fact that HTTP compression reduces output size when input contains repeated strings. If the attacker can include strings in a compressed encrypted stream that already contains a secret, the compressed length reveals whether the attacker's string matches a substring of the secret.

CRIME (Rizzo, Duong, 2012): TLS-level compression. Attacker controls part of the URL, compression includes the session cookie, response size leaks one byte of the cookie at a time. Killed TLS compression.

BREACH (Prado, Harris, Gluck, 2013): HTTP response compression. Same idea at the HTTP layer. Defense is harder: turn off response compression on responses containing secrets, or randomize response lengths, or use length-hiding padding.

Amplification DDoS

UDP services that respond with much larger packets than the request, combined with source-IP spoofing, give attackers a multiplier. Notable vectors:

• DNS open resolvers: ~10x amplification on EDNS queries.
• NTP monlist: ~200x amplification. Largely patched but long tail remains.
• memcached: ~50,000x amplification at peak (2018 GitHub 1.35 Tbps attack).
• SSDP, CLDAP, CharGen: various, all in the hundreds.

Defenses: source-address validation (BCP 38) at the ISP edge to block spoofed packets, plus operator-side rate limits on amplifiable services. BCP 38 deployment is still nowhere near complete after 25 years.

BGP incident response

When a hijack occurs:

1. External monitoring (BGPmon, RIPEstat) alerts within minutes. Internal NOC paged.
2. Verify the announcement: who is announcing, from where, when did it start.
3. Contact upstream providers with the prefix and the rogue AS number. Major transits respond within hours.
4. Mitigations during the incident: announce a more-specific yourself (longer prefix wins), arrange filtering at upstream level, prepare a public statement if customer-visible.
5. Post-incident: review whether ROA was published and whether ROV at upstreams would have rejected. Tune for next time.

An incident contact list of your upstreams' NOC numbers, kept current, makes the difference between a 30-minute outage and a 6-hour one.

Side channels you do not control

The class of "tell me a secret without saying it" attacks is durable:

• Cache timing inside enclaves and inside web platforms (timing attacks against compare functions).
• Power analysis against embedded crypto (correlation power analysis, EM emanation).
• Network-level timing inference (the 2025 attack on a major API leaked tenant via response-time variance).

End-to-end encryption protects the data. It rarely protects the metadata or the timing. For high-value flows, padding, dummy traffic, and constant-time everything are the durable answers.