Session integrity attacks¶

Attack pattern¶

TCP session authentication is meant to make a peer impossible to impersonate and the data it carries impossible to forge, which is why long-lived sessions like BGP lean on it. The target is the seal rather than the letter. TCP-MD5 is old, keyed once and rarely rotated; TCP-AO is stronger but only as good as the keys configured for it, and where authentication is left optional a peer can be pushed onto a session without it; the code that checks the integrity value has its own bugs. Break, downgrade or sidestep the check and forged segments travel as though genuine, with nothing louder than a valid-looking packet to show for it.

1. Session integrity attacks [OR]

    1.1 Cryptographic weaknesses [OR]
    
        1.1.1 TCP-MD5 hash cracking (weak keys)
            1.1.1.1 Brute force attacks against short key lengths
            1.1.1.2 Dictionary attacks against poorly chosen keys
            1.1.1.3 Key recovery through cryptanalysis of MD5 weaknesses
            
        1.1.2 TCP authentication option hash collision attacks
            1.1.2.1 Collision attacks against HMAC construction
            1.1.2.2 Chosen-prefix collision attacks
            1.1.2.3 Algorithm-specific vulnerability exploitation
            
        1.1.3 TCP authentication option key compromise through side-channels
            1.1.4.1 Timing attacks against key verification
            1.1.4.2 Power analysis for key extraction
            1.1.4.3 Cache-based side-channel attacks
            1.1.4.4 Electromagnetic emanation analysis
            
        1.1.4 Algorithm vulnerability exploitation
            1.1.5.1 SHA-1 collision attacks
            1.1.5.2 Cryptographic implementation flaws
            1.1.5.3 Weak random number generation exploitation
            
    1.2 Protocol downgrade attacks [AND]
    
        1.2.1 Force unauthenticated BGP sessions
            1.2.1.1 Authentication negotiation manipulation
            1.2.1.2 Session reset attacks to clear security context
            1.2.1.3 Error condition induction to disable security
            1.2.1.4 Configuration manipulation through other vulnerabilities
            
        1.2.2 Exploit missing authentication
            1.2.2.1 Session establishment without security parameters
            1.2.2.2 Fallback to insecure protocol versions
            1.2.2.3 Exploit misconfigured security settings
            1.2.2.4 Target sessions with incomplete security implementation
            
    1.3 Key management attacks [OR]
    
        1.3.1 Key distribution compromise
            1.3.1.1 Man-in-the-middle during key exchange
            1.3.1.2 Key storage system penetration
            1.3.1.3 Key transmission interception
            1.3.1.4 Backup key material theft
            
        1.3.2 Key generation weaknesses
            1.3.2.1 Poor entropy sources exploitation
            1.3.2.2 Weak random number generation
            1.3.2.3 Algorithmic bias in key generation
            1.3.2.4 Predictable key material generation
            
        1.3.3 Key rotation exploitation
            1.3.3.1 Key transition period attacks
            1.3.3.2 Old key retention exploitation
            1.3.3.3 Key synchronisation attacks
            1.3.3.4 Key revocation bypass
            
    1.4 Implementation-specific vulnerabilities [OR]
    
        1.4.1 Cryptographic library flaws
            1.4.1.1 Memory handling errors in crypto operations
            1.4.1.2 Side-channel vulnerabilities in implementations
            1.4.1.3 Algorithm implementation errors
            1.4.1.4 Performance optimisation introduced weaknesses
            
        1.4.2 Protocol stack integration issues
            1.4.2.1 State management between crypto and protocol layers
            1.4.2.2 Error handling in security negotiations
            1.4.2.3 Resource exhaustion during crypto operations
            1.4.2.4 Timing issues in security context establishment
            
        1.4.3 Hardware security module exploitation
            1.4.3.1 HSM firmware vulnerabilities
            1.4.3.2 API security flaws
            1.4.3.3 Physical tampering attacks
            1.4.3.4 Side-channel attacks against HSMs

The seal is weaker than the letter¶

Deployed algorithms are often known-weak: MD5 and its kind linger long after their flaws are public.
Key management at scale is genuinely hard, and hard things get done badly or not at all.
Cryptographic code is notoriously easy to get subtly wrong, and subtle is enough.
Security and performance pull opposite ways, and performance usually wins the argument.
Authentication is optional on these protocols and off by default in many builds, so the unprotected case is common.
People pick poor keys, reuse passwords and misconfigure, undoing the maths from the outside.