slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Dan Kaminsky, CISSP DoxPara Research doxpara PowerPoint Presentation
Download Presentation
Dan Kaminsky, CISSP DoxPara Research doxpara

Loading in 2 Seconds...

play fullscreen
1 / 81

Dan Kaminsky, CISSP DoxPara Research doxpara - PowerPoint PPT Presentation


  • 93 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Dan Kaminsky, CISSP DoxPara Research doxpara' - toya


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

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

interesting problems
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?”
more interesting problems
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?”
new for nvidia
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?”
on possibility
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.
how to do impossible things aka practical impracticality
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
layers not what but who
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
message modulation
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
tcp and udp connection traits ports
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
tcp connection traits sequences
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?
zalewski s phase space visualization
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!
phase viz w pixel shaders
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”
tcp connection traits flags
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
stateless pulse scanning
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.
issue spoofed responses
Issue: Spoofed Responses
  • Easy to spoof hosts being up if the scanner isn’t tracking who (or how it scanned)
  • Solution: Invert SYN Cookies!
syn cookies
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
inverse syn cookies
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.
implementation scanrand 1 0
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”
observed results
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
spread spectrum traceroute
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)
advanced scanrand usage
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
future of scanrand 1
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
future of scanrand 2
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
implications
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
a new problem
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.
broadcast ghosts
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
ip incorporated
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!
firewall issues
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
tcp w guerrila multicast
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
solution random delays
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
recontextualizing l2 l3
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?
nat splitting ips for fun and profit
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
mac address translation
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
packet integrity
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
implementation minewt 1 0
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
minewt state model
Minewt State Model
  • Instead of just storing IP_SRC, stores IP_SRC, ETHER_DHOST, and ETHER_SHOST
  • Whoever you think you are, Minewt dynamically returns your traffic to you
    • If IP_SRC == External IP, packets will retain end-to-end integrity
    • If IP_SRC == RFC1918 IP, packets will be NATted normally
    • If IP_SRC == Yahoo/Microsoft/Whatever, packets will be NATted a little less normally
    • Multiple hosts can share the same IP address, if MAC is different(and vice versa – Proxy ARP)
nat2nat
NAT2NAT
  • NAT makes outgoing connectivity easy, incoming connectivity really hard
  • Can we fix this? Can Minewt fix this?
nat2nat standard upnp
NAT2NAT Standard: uPNP?
  • Upcoming Standard: Client + Client Network + Server Network + Server: uPNP
      • Standard based on HTTP-over-UDP
      • Part of observed on-installation cracks for net-aware XP
  • uPNP somewhat unrealistic for NAT penetration – no real security model, which is a dealbreaker for firewall cooperation
    • Physical connectivity implies a property relationship; no such property relationship is implied by network connectivity
incoming nat l3 flooding
Incoming NAT: L3 Flooding
  • Switches flood if they don’t know – IP can too
    • Only Server Network Needs Patch
  • Stateless approach: Ask everybody, drop RST|ACK, forward everything else.
    • Everybody = All
    • Drop all RSTs, pass all streams/ACKs
    • Breaks down when two people are listening on the same port
      • Can split port range(1022, 2022, 3022, etc. all being different instances of 22/ssh)
      • Apply host-level heuristics – priority for incoming selection based on outgoing sessions
    • Floods every packet – not just initialization
incoming state
Incoming State
  • Stateful Approach
    • Flood all hosts w/ any unknown packet
      • Not just ones that match established sessions
    • Allow NAT state to be created by any valid response that returns
      • Normal NAT just establishes state on SYN
    • Minewt implements response mode, but no incoming host flooder (yet)
      • Minewt able to reconstruct state, even if the hosting machine changes, when backend hosts send TCP keepalives
    • Minewt is a proof of concept
      • OpenBSD PF in userspace much better idea
      • Networks not likely to install Minewt as a gateway!
nat2nat w existing networks
NAT2NAT w/ Existing Networks
  • NAT Deadlock Resolution
    • “Is it possible to establish a TCP connection between two hosts, both behind NATs, without modifying the client or server network?”
  • Answer: Yes…but it ain’t pretty.
    • Problem: Both firewalls want to make outgoing connections, neither firewall wants to accept incoming connections
      • Firewalls have no means of noticing they have mutually opposing entries in their state tables (yet)
        • Spec later
    • Solution: Convince each firewall that the other accepted the connection
nat2nat after this is completely academic
NAT2NAT AFTER THIS IS COMPLETELY ACADEMIC
  • Just use UDP!!!
    • Both sides flood eachother w/ oppositely ported UDP packets
    • Eventually, both firewalls will have a packet floating out on the internet addressed to eachother
      • Each will assume when they receive the other’s that it’s a response to their own
    • Game developers figured this out years ago
    • Encapsulate FULL TCP STREAM (not just TCP payload via UDP), and TCP handles unreliability as normal
  • Networked TCP is harder. Why?
trust relationship an analogy
Trust Relationship: An Analogy
  • Bill Gates ‘n Larry Ellison
    • Why? They can call anyone they want – their secretaries won’t stop ‘em.
    • None of us can call them – their secretaries will stop us.
    • If Bill or Larry did call us, they’d actually be able to hear us reply.
    • Asymmetry is in the initiation
      • UDP has no inherent asymmetry, while TCP has SYN/SYN|ACK/ACK
      • Once initiation is done, TCP and UDP are symmetrical
setting up
Setting Up
  • Alice and Bob both behind NATting firewalls
    • Firewalls authorize all outgoing sessions, block all incoming sessions
      • Block w/ state – no faking
      • Only accept fully validated responses to outgoing messages
        • Ports must oppose
        • SEQ#/ACK# must oppose
      • Total outgoing trust, minimal incoming trust
the attempt
The Attempt
  • Alice tries to send a message to Bob
    • SYN hits Alice’s firewall, is given global IP + entry in state table “connection attempted”
    • SYN travels across Internet
    • SYN hits Bob’s firewall, RST|ACK sent
    • RST|ACK hits Alice’s firewall, entry in state table torn down, RST|ACK readdressed to Alice
    • Alice gets nowhere
  • Bob does the same thing
analysis
Analysis
  • Good
    • Entry in firewall state table, awaiting a reply
  • Bad
    • Negative reply, entry in state table destroyed
  • Can we get the former without the latter?
    • phear
doomed ttls
Doomed TTLs
  • Packet first hits local firewall, gets NAT entry, travels across Internet, hits remote firewall, gets shot down.
    • Good stuff closer to us, bad stuff farther away
  • TTL: Time To Live – SET TO ~4
    • Maximum number of hops packet is allowed to travel along the network before being dropped
    • Used by IP to prevent routing loops
    • Used by us to prevent other firewall from modifying our state table just yet
ttl results
TTL Results
  • Alice SYNs w/ Doomed TTL
    • Alice’s Firewall expects response
    • Internet returns TTL Time Exceeded
    • Bob’s Firewall never returns RST|ACK
  • Bob SYNs w/ Doomed TTL
    • Same as Alice
  • Both firewalls have a hole open for eachother
    • Both waiting for SYN|ACK
      • Opposite Source/Destination IPs
      • Opposite Source/Destination Ports
      • Opposite 32 bit SEQ#/ACK# Sequence Numbers
  • Neither firewall can supply SYN|ACK
the other shoe drops
The Other Shoe Drops
  • Now you add a connection broker
    • HANDSHAKE ONLY.
  • Sends the SYN|ACK Host/Port/SEQ# combination “virtually added” to firewall packet acceptance rules
    • Larry Ellison: “Bill Gates is going to call here in the next two minutes, please put his call through.”
  • Broker spoofs Alice to Bob, and Bob to Alice
  • Broker requires significant cooperation from Alice and Bob
    • “What ports did you send on? What SEQ# did you use? How might your firewall have changed these values?”
local port strategies
Local Port Strategies
  • Some firewalls do best effort to match
    • Just have clients use chosen ports
  • Some use random local ports
    • If both sides random, can’t do anything
    • If one side random, can use Birthday Paradox – both sides send 256 TTL-limited attempts at eachother; one should collide
    • 53 bytes * 256 = 13Kbyte
  • Some increment from a fixed counter
    • Find minimum difference between two ports, flood send that many connections
    • No TTL manipulation – we just want to sync counters
  • Need to discover what strategy is being used
discovery strategies
Discovery Strategies
  • Broker-Query
    • Send test SYNs to broker, broker returns values detected over legitimate TCP session
    • Usually necessary for IPs
  • Broker Source-Route
    • Source route through connection broker, drop the route once the connection goes live
    • Should be very effective, possibly can be implemented without libpcap/libnet
    • Needs much testing though
ttl based firewall analysis
TTL-Based Firewall Analysis
  • Emit a SYN with a low TTL
  • SYN spawns ICMP time exceeded error
    • From scanrand traceroute, we know these contain limited amounts of data about the original scan
    • Commonly “corrects” scan IP, but since Time Exceeded messages usually came from UDP/ICMP traceroutes, usually TCP ports and sequence numbers aren’t “corrected”
  • Lowers the amount of Broker-based firewall analysis, allows clients to be aware even
    • Requires firewall to pass ICMP time exceeded messages
  • Some issues with ICMP error mangling
    • Scanrand parses ICMP errors in verbose mode, “Φspy” tool coming to actively audit
tricking firewalls idss
Tricking Firewalls/IDSs
  • Alice can forge a connection from an arbitrary IP by cooperating with Charlie
    • Alice looks like she’s connecting to Yahoo, but is informing Charlie of the specifics of the connection attempt
    • Charlie replies as if he was Yahoo, and begins a TCP stream of arbitrary data to Alice from “Yahoo”
    • Alice acknowledges all data to “Yahoo” with the doomed TTL – we continue low TTL count through the data stream
  • Really messy in terms of ICMP time exceeded messages, BUT logging systems might drop these messages
other nat strategies
Other NAT Strategies
  • State Management
  • State = Buffers
    • Buffers need to be searched
    • Buffers need to be allocated
    • Buffers need to be overflown
      • If your name is Gobbles
  • NAT normally needs to be stateful
    • A packet comes in, and given the Source IP, the Source Port, and the Destination Port, we check our tables to rewrite on the internal interface the Destination IP(not firewall) and maybe the destination port too
      • The MAC address is always rewritten, but with MAT we extract the correct MAC from the state table
stateless nat possible
Stateless NAT: Possible?
  • State is all about things we have to remember
    • Stateless scanning is about extracting what we need from what we get back
  • “Can we embed the NAT state in every outgoing IP packet such that every response received will contain the full NAT state”?
    • Answer: Yes, with a dozen bytes per packet reflective side channel
      • Whatever I send is sent back to me
      • “Cookie”
ip timestamps for reflection
IP Timestamps For Reflection
  • IP Timestamps Mode 3 (courtesy Jason Spence)
    • IP Option against each host along the route. Up to four 4 byte IP addresses are specified, with space for up to four 4 byte timestamps to be added
    • If IP in the timestamp request matches IP of the router, the router replaces the timestamp with its own
    • If IP doesn’t match, pass along the timestamps of others
ip timestamps 32 bytes of reflected state
IP Timestamps: 32 Bytes Of Reflected State
  • Insert timestamps from invalid IP’s containing not actual timestamps but NAT state
  • Encrypt NAT state so it may not be modified en route
  • Decrypt NAT state upon packet return
  • Problems
    • Need to insert IP options – may overflow packet, may need to fragment, etc.
    • IP options are sometimes blocked by firewalls
  • Possibilities with TCP Timestamps too
    • Reply field contains 32 bits of user specified stamp
fragmentation handling
Fragmentation Handling
  • No Paketto Code Presently Handles Fragmented Responses
    • Stateless fragment handling is a Hard Problem
    • NAT must reassemble – or keep old assembly – to direct L4->L3
  • Massively Experimental Solution: Nonfragmentable Reflective IP Options
    • IP Options can copy-on-fragment
      • It’s a bit you set
    • Only IP Timestamps are supposed to reflect
      • Stream ID’s might, but are small (ongoing research)
    • IP Timestamps have capacity, but no frag protection.
force defragmented ip timestamps
Force-Defragmented IP Timestamps
  • Supported by Minewt
  • Set the high bit, see if people treat it right
  • Linux/BSD drop it (but they often fail to reflect at all)
  • Windows reflects happily!
    • Don’t know if fragment rule holds
more options for options
More Options for Options
  • Options: Optional footers that are ignored unless stacks explicitly coded to support them
    • Often used for side channels
  • Header-Length Options:
    • TCP: Explicit length field(th_off * 4) describes header length, anything left over is options
      • 40 bytes max
    • IP: Explicit length field(ip_hl * 4) describes header length, anything in excess of fixed length(LIBNET_IP_H) is options. Anything left over, up to the length in ip_len, is the L4 header + Payload.
      • 40 bytes max
udp trailer ops
UDP Trailer Ops
  • UDP: Explicit length field(uh_len) describes payload, anything left over – up to the limit described in ip_len -- is options
    • Option data appears to be ignored – but this may not be true for all platforms
    • If length is less than data in header, or extends header past ip_len, all known platform reject packet
  • Trailer Strategy Works For More Than UDP
ethernet trailers
Ethernet Trailers
  • Ethernet(encapsulating IP): Explicit length field(ip_len) describes payload – the IP packet. Anything left over, up to the limit described in the Out Of Band frame length(pkthdr->caplen), is options
    • SHOULDN’T route, but does?
      • Probably switches
    • Huge capacity, up to the frame limit(MTU)
      • Technically, no limit, though libnet probably enforces MTU limitations
  • Ethernet(encapsulating ARP): ARP has fixed length, with minor variability for hardware addressed. Anything extra is your options.
uses for ethernet trailers
Uses for Ethernet Trailers
  • Obviously an excellent covert channel
    • Most sniffers drop the trailer, due to its common “randomness”
    • (It’s not actually random – it’s whatever was left over in the network card’s buffer)
      • This…can be attacked.
  • Less obviously, a perfect channel for local, experimental cryptographic signatures
ethernet options for crypto
Ethernet Options for Crypto
  • Sign every frame
    • Sign your ARPs
    • Opportunistic – anyone who doesn’t support doesn’t notice signatures
      • Obviously can only sign/identify – encrypt/decrypt pollutes genuine data
      • Intermediate hardware can identify, even append extra signature
      • Does waste bandwidth somewhat – hosts are sending data that may never be parsed!
  • Distribute keys/certs either in every frame(high bw) or in each ARP
    • Resolves some MTU overflow issues
      • IPSec has been suffering with these
crypto signature algorithms
Crypto Signature Algorithms
  • RSA/DSA
    • Most trusted
    • Way too big for normal option usage
      • 40 byte capacity in TCPo/IPo
      • There exists a “Secure TCP” spec w/ oversized options for key exchange
  • ECC
    • Moderately trusted
    • 366 bit signatures, 192 bit keys
    • Works well for Ethernet
weil pairing possibilities
Weil Pairing Possibilities
  • Weil Pairing
    • 159 bit signatures, equivalent to RSA1024
    • Heart of new “Identity-Based Encryption” system from Dan Boneh @ Stanford
      • Excellent if oversold crypto
      • Clients may compute a “subset” from a master public key, encrypt to it such that only the full master private key or the matching subset of that key may decrypt.
      • Works for signing too
    • 159 bits is small enough to opportunistically add to TCP options
      • IP options slow routing and get irrevocably blocked by PIX
  • More work on this coming soon