Dan Kaminsky, CISSP DoxPara Research doxpara

1. BLACK OPS OF TCP/IP Hivercon Instant Network Auditing Spread Spectrum Tracing Guerilla Multicasting Advanced NAT/MAT/NAT2NAT Sideband Crypto Phentropy: Entropy Viz Parasitic Traceroute PAKETTO KEIRETSU 1.0 What’s New What’s Coming Dan Kaminsky, CISSP DoxPara Research www.doxpara.com

2. Interesting Problems • Instant Portscan • “Is it possible to discover instantaneously what network services have been made available, even on massive networks?” • Guerrila Multicast • “Is it possible to send a single packet to multiple recipients, using today’s multicast-free Internet?” • “NATless NAT” • “Is it possible to share a globally addressable IP address without translating private IP ranges a la NAT?” • Is it possible to allow incoming connections to an IP multiplexed in this manner? • NAT Deadlock Resolution • “Is it possible to establish a TCP connection between two hosts, both behind NATs?”

3. More interesting problems • Spread Spectrum Mapping • “It it possible to quickly discover traits of the exponentially branching routes accessible from a given point on a network?” • Non-Covert Capacity Sidebands • “Is it possible to send more than a few bits per packet of ‘extra data’ not associated with the original payload, without breaking existing systems?” • Sideband Crypto Signatures • “Is is possible to sign outgoing data in such a fashion that those who can not verify experience no interference?”

4. New For nVidia • Stateless HTTP • “Is it possible to statelessly host a web page, possibly with dynamic content?” • GigaFLOP Networking • “Is it possible to tap newly available GPU resources to do useful things for a network?”

5. On Possibility • Restraint Free Engineering • “Abandon All Practicality, Ye Who Enter Here” • You’ve got what you’ve got. Make interesting things happen. • It might end up practical. • It might end up secure. • Right now, it’s impossible. Fix that first. • Maybe.

6. How To Do Impossible Things (AKA Practical Impracticality) • Five Party Model for Technology Migration: Client, Client Network, “Internet”, Server Network, Server • Each have different goals, administrators, skill levels, efficiency requirements, concern for error recovery, profit from a given technology • Generally, the fewer parties must be tapped to deploy a new technology, and the more direct benefit to the parties actually deploying it, the more likely it’ll see the light of day • Opposite is true – the more pain, the less gain, the less chance it’ll get used • Client Network and Server Network have become much more relevant w/ Firewalls

7. Layers: Not What, But Who • One medium, many messages • Listeners reconstruct meanings relevant to themselves, ignore the rest • Listeners decide for themselves what’s important and what’s not to them • These decisions can change – firewalls, load balancers, etc. increase role of client/server networks, assume roles once reserved only to endpoints

8. Message Modulation • Messages at one layer can modulate messages received at another • Parties in the middle can be made to change messages received at either end • Firewalls drop packets • Insufficient postage will prevent a correctly addressed letter from getting sent • One way to create new functions is to use inter-layer modulation to expose new functionality • We’re going to modulate TCP in interesting ways

9. TCP (and UDP) Connection Traits: Ports • IP handles who we’re talking to; Ports handle what we want from them • Local Port: What application requested the connection. Usually a random number, 0-65535. • 0 is a valid port • Remote Port: What application accepted the connection. Usually a “known number” • 80 for HTTP • 143 for IMAP • 443 for HTTP/SSL

10. TCP Connection Traits: Sequences • Sequence Numbers • 32 bit number, randomly generated, must be reflected by the opposite party in a TCP handshake • After initial reflection, used to relay information about successful packet acquisition • What if Sequence Number Isn’t Random? • You can hijack and kill arbitrary connections! • How do you detect that?

11. Zalewski’s Phase Space Visualization • Phase Space • Take a 1D stream of numbers • Get four numbers from it • s[n-3], s[n-2], s[n-1], s[n] • Plot points in a volume • x=s[n-3]-s[n-2] • y=s[n-2]-s[n-1] • Z=s[n-1]-s[n] • Drop a point!

12. Phase Viz (1)

13. Phase Viz (2)

14. Phase Viz w/ Pixel Shaders • Using OpenQVIS, insanely powerful volumetric viewer • GPL • Does all that nice funky MRI rendering • 20-40fps for 256x256x256 • Pixel Shaders Are A Good Thing • Phentropy: Compiles arbitrary data to phase space format for OpenQVIS • “Putting GigaFLOPS To Work”

15. Phentropy: Bash $RANDOM

16. Phentropy: BSD Kernel

17. Phentropy: Photograph

18. Phentropy: Photograph (2)

19. TCP Connection Traits: Flags • The Famous Three Way Handshake • Connection Request (Alice -> Bob) • SYN: I want to talk to you • Connection Response (Bob -> Alice) • SYN|ACK: OK, lets talk. • RST|ACK: I ain’t listening • Connection Initiation (Alice -> Bob) • ACK: OK, beginning conversation. • Portscan Types • Normal: Send one, wait for its response • Fast: Send many, wait for every response • Usually keep track of who was scanned

20. Stateless Pulse Scanning • Instant Portscan • “Is it possible to discover instantaneously what network services have been made available, even on massive networks?” • Answer: Yes, practically, even securely • Separate scanner and listener processes • Sending • Directly send n SYN packets from same local port • Receiving • Kernel filter packets arriving to that local port • Extract from received packets IP, Remote Port, and whether that Port was up (SYN|ACK) or Down(RST|ACK) • Why do we need to remember who we scanned? Everything we want to know is included in their response.

21. Issue: Spoofed Responses • Easy to spoof hosts being up if the scanner isn’t tracking who (or how it scanned) • Solution: Invert SYN Cookies!

22. SYN Cookies • By DJB in ’96, defense against SYN floods • Attack • Spoof many SYNs from invalid IP’s. Kernel sends SYN|ACKs, wastes large amounts of memory waiting for ACKs that will never come. Kernel eventually dies • Defense Mechanism • ACK reflects 32 bit SEQ# of SYN|ACK(+1) in ACK# • Defense Implementation • Receive SYN packet • Respond with SYN|ACK • Encrypt connection state into the SYN|ACK’s SEQ# • Receive ACK • Decrypt connection state from ACK’s ACK# • If IP is being spoofed, attacker never receives SYN|ACK, so cannot receive cookie from SYN|ACK

23. Inverse SYN Cookies • SYN|ACK also reflects SEQ# of SYN in its ACK# • Instead of tracking SYN|ACK reflections in the ACK, track SYN reflections in the SYN|ACK • Encrypt “I scanned you” instead of “you connected to me, here’s how” • Implementation • Send SYN packet • Encrypt “connection state” into SYN’s SEQ# • Presently not including time – this prevents stateless latency detection • Receive SYN|ACK or RST|ACK • Decrypt connection state from return packet’s ACK#-1. If doesn’t match, don’t accept packet.

24. Implementation: Scanrand 1.0 • Element of: Paketto Keiretsu • Couple hundred lines of libnet and libpcap • No per-host state stored • Scans at ~11-20mbit • Moderately portable • HMAC-SHA1 truncated at 32 bits • Actually simply authenticating message against stored secret instead of encrypting/decrypting • Out “Real Soon Now”

25. Scanrand (1)

26. Scanrand (2)

27. Observed Results • Since no state is maintained within the scanner, we can send SYNs at wire speed • Implementation can get faster • Found ~8300 web servers on a corporation’s Class B • Time spent: ~4 Seconds • Collisions • Initial SYNs might collide, but SYN|ACKs resend • SYN|ACKs are given RSTs by present kernels automatically • The SYNs were generated in userspace – the kernel has no idea the connection request was ever sent

28. Spread Spectrum Traceroute • Mass Scan: Iterate Across IPs/Ports • Traceroute: Iterate Across TTLs • MassTrace: Iterate Across IPs/Ports/TTLs • “Take me one hop there, take me two hops there, etc”, send me back an ICMP Error • Usually UDP or ICMP Ping • We do TCP – statelessly • ICMP contains original IP/TCP packets • Can use it to reconstruct • Inverse SYN cookies still work, but fail behind SEQ# modulating firewalls (SEQ# not changed back to local-valid)

29. Scanrand MassTrace (Class C)

30. Scanrand MassTrace (Class B[1])

31. Scanrand MassTrace (Class B[2])

32. Scanrand MassTrace (Class B[3])

33. Advanced Scanrand Usage • Multiparty Scanning • Multiple hosts may send scans, spoofing their sending address as the collector. • Scanrand supports explicit key synchronization – important to vary keys over time or scans, or replay attacks become (long term) trivial • Weaver: Source Route Network Analysis • Traceroute to point, discover TTL distance • Source route through point to faraway networks, use TTL+1 to TTL+3 to discover neighbors • Source route through immediate neighbors to other immediate neighbors to determine mesh • Source Routes not supported yet – but very soon

34. Future of Scanrand (1) • Temporal Host Identification (RING) • TCP is a reliable protocol – retransmits if it thinks a packet was dropped • Retries x times • Waits yn milliseconds between retransmits • X and yn vary from OS to OS • If SYN|ACK never elicits a RST, remote host will provide detectable signature of what operating system it’s running • Requires RST suppression – probably by using an alternate IP, possibly by using Dug Song’s generic firewall interface

35. Future of Scanrand (2) • Stateless Content Download • Suppress normal RST to unknown SYN|ACK • ACK incoming SYN|ACKs, send arbitrary payload (HEAD / HTTP 1.1 ^M^M) • ACK all incoming responses • Result: Lots and lots of packets • Postprocess with LibNIDS to convert raw packets to usable information • Repurposing LibNIDS back into a network stack, albeit unidirectional! • Code required to prevent remote host from keeping connection state indefinitely based on our responses to keepalives

36. Implications • Userspace manipulation of packets can lead to less overhead • Kernels are optimized to talk to other hosts, not simply to scan them • Packet content can be overloaded • A random field can always be replaced with encrypted data (and vice versa) • Elegant solutions sometimes can be reapplied elsewhere • SYN(really SYN|ACK) cookies made SYN reception more efficient • Inverse SYN cookies make SYN transmission more efficient

37. A New Problem • Scanrand • How does one host learn about many? • With lots and lots of traffic! • What if we don’t want to send lots of traffic? • What if we want to send data to lots of hosts, using only one single packet? • Multicast: All Five Parties Must Cooperate • Internet only speaks Unicast • Client and Server networks speak Unicast and Broadcast • If Destination MAC = FF:FF:FF:FF:FF:FF or 01:00:5E:xx:xx:xx [multicast], packet should be broadcast to all ports • Usually, last IP in subnet maps to broadcast. Usually.

38. Broadcast GHosts • Guerrila Multicast • “Is it possible to send a single packet to multiple recipients, using today’s multicast-free Internet?” • Answer: Yes, barely. • ARP-Link a unicast IP to the broadcast MAC address; all responses to that IP will then be broadcast throughout a subnet! • No individual client need duplicate the datastream – the switch will issue copies of the data to all downstream hosts

39. IP Incorporated • Retrieve an IP • Possibly via DHCP, possibly not • May or may not use broadcast MAC in DHCP request – just trying to validate that nobody else is using the IP (can also ARP Ping) • Answer ARP requests for that IP with Broadcast MAC (or Multicast MAC) • At L2, w/o IGMP Snooping working, Multicast = Broadcast • Issue standard TCP/UDP requests from this broadcast-linked IP • Responses will go to anyone listening!

40. Firewall Issues • NAT • 100% NAT penetration, as long as the implementation doesn’t refuse to NAT for a broadcast MAC • PIX refuses FF’s, but accepts Multicast MACs! • Multicast through NAT! • UDP • No mandatory acknowledgments for firewall state machines to latch onto • Remote side can send data forever – as long as it keeps packets coming in before the UDP state expires, no further data is required from behind the wall

41. TCP w/ Guerrila Multicast • TCP Harder problem – listeners need to acknowledge incoming data • Without any listeners, stream dies • With one listener, stream should operate normally • With many listeners, only one should participate in acknowledging the stream • If any one dies, another should take its place

42. Solution: Random Delays • Solution: Random delays • On reception of a packet to be acknowledged, queue a response within the next 50-1500ms • Broadcast response, public notification of response (Everyone – I ACKed) • If another host broadcasted a response before you had the chance to, unschedule your response • If another host sent data, sync SEQ# using info from broadcast • Someone’s timer will expire first – if they fail, someone else will take place

43. Recontextualizing L2/L3 • One IP, normally linked to one host, can be transformed at L2 into all hosts at a given subnet • This transformation is undetectable outside the subnet • Do we have another other situation where one IP “stands in” for many hosts?

44. NAT: Splitting IPs For Fun and Profit • NAT multiplexes several hosts into one IP address by splitting on local port • Behind the NAT, everyone has a private IP; in front of the NAT, nobody knows exactly what local port they’re sending from • NAT destroys end-to-end packet integrity • Like a postal service opening all mail and transferring it into a new envelope – it can be made to work, but has side effects

45. MAC Address Translation • “NATless NAT” • “Is it possible to share a globally addressable IP address without translating private IP ranges a la NAT?” • Is it possible to allow incoming connections to an IP multiplexed in this manner? • Answer: Yes. Oh yes. • NAT: L4->L3 • ARP: L3->L2 • MAT: L4->(L3,L2) • Multiplex with L2/L3 instead of just L3 • Make ARP Table dynamic, based on each individual L4 connection

46. Packet Integrity • If we can always match IP and Port, then we can always maintain end-to-end correctness • May be adaptable to IPSec security associations • Only have a problem 1/256 connections to the same host • Decent chance that two hosts will randomly pick the same local port number • Birthday Paradox: Collision chance = 1 / sqrt(range_of_local_ports) = 1 / sqrt(65K) = 1/256 • Alternate strategies exist – maybe switch on SEQ#, force remote window to vary during periods of near-sequence-overlap • Actively researching new techniques! • P0f – Passive Fingerprinting – shows promise

47. Implementation: MiNewt 1.0 • “My New Translation Engine” • Another part of Paketto Keiretsu • Translates arbitrary local IP addresses into globally routable IP addresses • Complete userspace implementation – an IP just “shows up” on your network • Makes for an excellent testbed

48. Minewt (1)

49. Minewt (2)

50. Minewt (3)