Signed Sessions Spoil Spoofing:Building

assured ephemeral identity continuity into TCP

Jim MacLeod, @shewfigBayThreat 2010

shewfig.blogspot.com

Stealing my own Thunder

• Embed Diffie-Hellman in TCP SYN exchange– Create ephemeral shared secret– Maybe sign DH using RSA/DSA

• Lightweight signature– Hash every packet in TCP stream on send– Verify on receive– If no signature: assume spoofed/injected: drop

• Transparent to high-level app:– Tie in through iptables ipq/nfqueue

The Problem

• IP spoofing– Injected content / hijacking– Injected control / RST spoof (cf. RFC 4953)– FW rule evasion

• Results– Session hijacking: steal credentials– Info injection: SSL re-negotiation attack– BGP TCP RST injection: routes marked as invalid

Comparison

• Swap people during conversation• http://www.youtube.com/watch?v=vBPG_OBgTWg

• IP spoofing does the same thing with TCP/IP• We want to know if the switch occurs!– Almost never a good thing.

Level of paranoia

• Spoofing can be on-path or off-path– Off-path

• Can’t sniff packets, attacks are blind• Can pull state info from either endpoint, but cross-

connection states have been randomized (to counter this!)

– On-path• In the packet path, or same subnet* as an endpoint• Can sniff, can inject, can potentially MitM• Coffee-shop WiFi, office network, cable modem, hotel…• Anywhere FireSheep would work• These networks are often behind NAT

The Scope

• Provide session continuity assurance– Endpoints can validate each other during transitory

conversation• Arbitrary endpoints– Could be on opposite ends of the Internet– Most needed in locations where NAT use is likely

• No pre-existing relationship required– No PKI-verifiable client cert, no password, no account

• No flaming hoops to jump through– No VPN, no special client, no plugin, etc.

PREVIOUS SOLUTIONSBut Jim, aren’t there

RFC 4953: “Defending TCP Against Spoofing Attacks”

• Lots of good discussion and background, but:“Note that Network Address Translators (NATs) and other

middleboxes complicate the design and deployment of techniques to defeat spoofing attacks. Devices such as these, that modify IP and/or TCP headers in-transit, generate traffic equivalent to a spoofing attack, and thus should be inhibited by antispoofing mechanisms. Details of these middlebox-related problems are out of scope for this document[…]” [emphasis added]

(Section 6, “Security Considerations”, p. 23)• Translation: treat NAT like a spoof attack

– Directed at network operators, not enlightened users– Spoofing is most dangerous where NAT is common!

IPSec

• Too much overhead– Crypto is easy, ID management is annoying– Requires pre-existing relationship• Shared secret or shared CA

• Too big a scope– Encrypts ALL IP traffic between endpoints– Breaks NAT in the server->client direction• e.g. AOL proxy – 1 IP, multiple remote endpoints• Will IPsec tunnel capture all traffic back to that IP?

IPSec AH

• Provides auth • Oops, NAT breaks it • Requires pre-existing relationship• All the setup of ESP, ½ the value– Rumor is it’s going away• If it was ever here at all…

BTNS (anonymous IPSec)

• “Better-Than-Nothing Security”– Non-authenticated IPSec– Ephemeral but assured association

• Still IPSec– L3 – Same problems w/ NAT

DNSSEC?

• Good to validate server ID• Apparently good to sign emails • Can it work with client behind NAT?– ID still tied to address/hostname– Can a client validate its ID from behind NAPT?• Especially a dynamic IP address?

SSL?

• Closer to being the solution:– No shared setup (other than signed server cert)– Encryption implies ID continuity• Only the endpoints have the session key

• L7 protocol– Can be undermined at L2/L3/L4• e.g. Re-binding attack

– Can’t spoof cert (go with me on this one)• Can still inject RST

SSL VPN (L3 over L7)

• Beautifully complicated• L3 tunnel through single L7 connection• Waaaaay outside this scope– User must manually start / install software• “Jump through a flaming hoop”

– Pre-existing relationship required

SSH Port Forwarding?

• Could be done…• Would require different port?– Non-transparent to application/user

• SSH really really wants to do user auth– Implies pre-shared association

• Full encryption: overkill?

TOR

• Solves exactly the opposite problem• Encryption is implicit ID continuity• Still open to L4 control channel attacks

TCP-MD5 / TCP-AO

• Designed to solve this problem • Designed to solve this problem for BGP• Requires pre-existing relationship / PSK• Doesn’t survive NAT – A draft exists to cover this case– draft-touch-tcp-ao-nat-01– Still requires pre-existing relationship

The Fossil Record

• Skeeter and Bubba, FTP Software, 1991• “Levy, Kastenholz and Knowles realized that they could improve

the security of TCP by putting a Diffie-Hellman key agreement step directly into TCP’s three-way handshake. […and] encrypt all future communications[…]

• “The project was abandoned for two reasons. First, an engineer at FTP thought that it would be wasteful to have computers calculate large prime numbers for every TCP connection[…] Second[…] it was susceptible to the man-in-the-middle attack.”– Design Principles and Patterns for Computer Systems That Are

Simultaneously Secure and Usable by Simson L. Garfinkel (Ph.D thesis, 2005) Section 6.1 (p. 201) [emphasis and format added]

NEW DESIGNIs it time for a

Scope, revisited: Auth?

• Authentication: not necessary!– Actual auth can happen in L7

• RFC 4953 Section 5.5 p. 22 (TCP spoofing)It is sufficient to authenticate the other party as "a party you have exchanged packets with", rather than establishing their trusted identity ("Bill" vs. "Bob")

Scope, revisited: Crypto?

• Encryption: not necessary?– Signing is sufficient to assure sender ID– Encryption can be done at L7• Anything sensitive should of course be encrypted

• RFC 4953 Section 5.5 p. 22“Only the IP header is fundamentally in question, so securing the entire packet […] is computational overkill.”

Scope, revisted: Which OSI Layer?

• RFC 4953 likes L3 (sections 5.1, 5.2)– Establish ID once for all L4 connections

• NAPT creates multiple hosts per L3 address– L4 is lowest layer with unique endpoints

• Control channels at L3 & L4– L3: ICMP: common practice is to firewall– L4: RST, ACK, etc.: necessary part of conv.

• L4 looks like best fit: extend TCP

Scope, revisited: Where in TCP?

• Injecting data will change TCP seq/ack– Too hard to track, work to re-write

• TCP option– Control field at same layer as control channel– “Easy” to add, verify– Similar to TCP-MD5 and TCP-AO

• Either way, will affect checksum– Easy to calculate– Hardware offload common

Scope, revisited: Signature?

• Both endpoints must be able to validate packets from other endpoint– Only need 1 RST in either direction to kill stream

• 2 options:– Shared secret w/ symmetric key– Public/Private signature

• Symmetric is faster– Must not expose key: requires setup– Can setup be accomplished during TCP setup?

Symmetric solution: DH

• Diffie Hellman solves this exact problem– Secure negotiation of shared secret key

• Doesn’t provide auth– Public key != Identity (vs. SSL cert)

• Subject to MITM– Requires attacker to proxy TCP SYN exchange– Bi-directional spoofing

Hybrid solution

• Common practice (IPSec, SSL, etc.)• Use RSA/DSA signature validation– DH doesn’t need protection– Can sign DH pub key is validate RSA/DSA key– Valid key = assured identity

• True “Digital Signature”– Packet includes signature with signed data– No advance association required

Server-Side real ID validation

• Use verifiable server ID– Similar trust model to SSL in common case– Use SSL cert or SSH host keys (with SSHFP)

• Client can verify server ID– Detect MITM from client side

• Client still relatively anonymous to server– Server can’t verify client ID

Client-side anonymous ID persistence

• Client RSA/DSA public key is relatively unique– Not listed in verifiable PKI– “Randomly” generated

• Server can cache client public key– Becomes ID-equivalent– Useful for continuity of ID?

Issues

• Adding TCP option takes space– Solution: reduce MSS– Must be done in SYN– Introduce inefficiency if TCP hash not used

• Checking every packet adds process overhead– Can streamline through clever iptables rules

Proof-of-Concept #FAIL

Release delayed due to some core issues • DH library issues– keygen ran for many hours without completion– Bad implications for performance

• Really need iptables custom rules– Use 4-tuple for DH secret lookup

• Current PoC uses ipq (only 1 handler)– Should use NFQUEUE (multiple handlers)

Proof-of-Concept Implementation

• Use iptables QUEUE target for userspace processing of packets– http://michael.toren.net/slides/ipqueue/

• Perl script to manipulate packets– Packet manipulation with NetPacket • (NOT Net::Packet)

– Custom code for TCP options• NetPacket doesn’t handle TCP options well

POC – Setup

• SYN– Outbound add DH

• Iptables: outbound SYN

– Inbound detect DH, calculate secret, add iptables rule• Iptables: detect TCP option

• SYN/ACK– Inbound detect DH, calculate secret, add iptables rule

• Iptables: detect TCP option

– Outbound add DH• Iptables: specific (4-tuple) rule

POC - established

• Iptables rule for 4-tuple (src/dst for IP/TCP)• Outbound: add TCP option– Hash TCP payload using DH shared secret

• Inbound: verify– Hash TCP payload using DH shared secret– Compare to hash in inbound packet– Fail -> Drop

POC – tear-down

• RST: simple– Sign & send, then decommission iptables rule

• FIN: more complicated– 1st FIN: remember, sign & send– 2nd FIN: remember, sign & send• ACK: sign & send & decommission iptables rule

“The Dream”

• Design is incrementally deployable– Add to individual machines, not all-at-once

• Design is backwards compatible– Won’t prevent other services from running

• “Minor performance impact”– Clever use of iptables limits computations to

protected sessions

The Real Dream

• Assured ID with DNSSEC• NAT “should” go away after IPv6• Maybe this tool will be useful until then

Questions?

• Jim MacLeod• Twitter: @shewfig• Blog: shewfig.blogspot.com