; Black_Ops_Hivercon
Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Black_Ops_Hivercon

VIEWS: 4 PAGES: 81

  • pg 1
									BLACK OPS OF TCP/IP
Hivercon [Preview]
Nov. 26-27, 2002
Dublin, Ireland

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
    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
   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
 Stateless   HTTP
      it possible to statelessly host a web
   “Is
    page, possibly with dynamic content?”
 GigaFLOP    Networking
   “Isit possible to tap newly available GPU
    resources to do useful things for a
    network?”
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)
   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
 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
   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
    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
   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
 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 (1)
Phase Viz (2)
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”
Phentropy: Bash $RANDOM
Phentropy: BSD Kernel
Phentropy: Photograph
Phentropy: Photograph (2)
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
   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
 Easy  to spoof hosts being up if the
  scanner isn‟t tracking who (or how it
  scanned)
 Solution: Invert 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
   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
 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”
Scanrand (1)
Scanrand (2)
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
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)
Scanrand MassTrace (Class
C)
Scanrand MassTrace (Class
B[1])
Scanrand MassTrace (Class
B[2])
Scanrand MassTrace (Class
B[3])
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)
   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)
   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
   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
   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
   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
   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
   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
 TCPHarder 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
       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
 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 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
   “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
   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!
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 (1)
Minewt (2)
Minewt (3)
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
 NAT  makes outgoing connectivity easy,
  incoming connectivity really hard
 Can we fix this? Can Minewt fix this?
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
   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
   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
   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
   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
   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
 Aliceand 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
   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
 Good
   Entry   in firewall state table, awaiting a reply
 Bad
   Negativereply, entry in state table
   destroyed
 Can  we get the former without the
 latter?
   phear
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
   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
   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
   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
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
 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
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
 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
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 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
 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
   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
 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
   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: 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(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
 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
   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
   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
       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

								
To top
;