SlideShare ist ein Scribd-Unternehmen logo
1 von 47
Downloaden Sie, um offline zu lesen
BLACK OPS OF
TCP/IPSpliced NAT2NAT And Other
Packet-Level Misadventures
Dan Kaminsky, CISSP
DoxPara Research
www.doxpara.com
Where I’m Coming From…
 Black Hat / DefCon 0x7D1
 Impossible Tunnels through Improbable Networks
with OpenSSH
 Getting Out:
ProxyCommands for Non-TCP comm layers
 HTTP, SOCKS, UDP, Packet Radio*, AIM/Yahoo*
 Coming In:
Active Connection Brokering for NAT2NAT
 One host exports SSHD to broker
 Other host imports access from broker
 Passing Through:
Dynamic Forwarding for Psuedo-VPN Work
 Web Browsing, Dialpad(Split-H323), etc.
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?”
On Possibility
 Restraint Free Engineering
 “Abandon All Practicality, Ye Who Enter Here”
 “It’s amazing what you can do once security is no
longer a concern.”
 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.
On Packet Structure
 Packets are “strangely ordered”
 Where it’s ending up next, where it came from
recently, how it’s hopping from one place to the
next, how it’s hopping to its final destination,
checksum, where the packet came from originally,
where it’s going to end up, what app it came from,
what app it’s going to, checksum, god knows
what, ANOTHER checksum
 Why not sort everything; put all the “came
from” and “going to’s” Why so much
redundancy? Isn’t it inefficient?
 WHO CARES?
Layers: Not What, But Who
 One medium, many messages
 Listeners reconstruct meanings relevant to
themselves, ignore the rest
 Managed (ir)responsibility
 Fields are out of order, occasionally because
they’re addressed to different entities
 Name and address repeated inside a business
letter and on the envelope
 Messages at one layer can modulate
messages received at another
 Insufficient postage will prevent a correctly
addressed letter from getting sent
 Incorrect internal address has unknown effects
Error Recovery Per Layer
 Layer 2 (Point to Point)
 Errors are quickly recoverable, but error
generation can occur at same layer as layer
control
 Data is destroyed and recreated each frame
 Corporate Fertilizer
 Layer 3 (Router to Router)
 Many more sources of personally irrelevant error
 Highest Traffic Link
 Data is modulated – minimum change possible
 Layer 4 (End to End)
 Lowest traffic, highest personal relevance
 Errors here actually matter
 This slide intentionally left blank
TCP Connection Traits: Flags
 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.
TCP (and UDP)
Connection Traits: Ports
 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
 IP handles who we’re talking to; Ports handle what
we want from them
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
Connection Summary
 Flag determines phase
 Asymmetric
 Port determines process
 Sequence “secures session”
 Prevents trivial spoofing attacks
 Also used to manage connection speed,
identify which bytes are being
acknowledged
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
 Same local port
 SYN cookies
 Receiving
 Kernel filter packets arriving to local port
 Record connection phase: Port up(SYN|ACK) or host
up, port down(RST|ACK)
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
 Developed in ’96, when SYN floods became
common
 ACK reflects ACK# of SYN|ACK(incremented by
one)
 Encrypts connection state into the SYN|ACK’s
ACK#
 Therefore, you can use legitimate remote hosts –
instead of kernel memory – to store handshake
state
 Ahhh…but 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
Implementation: Scanrand 1.0
 Element of: Paketto Keiretsu
 384 lines of libnet and libpcap, w/ trivial
MD4 include
 No state stored
 Scans at ~11-20mbit
 Possibly even portable
 100% complete, release imminent
Bh us-02-kaminsky-blackops
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
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)
 This is the heart of kleptography
 Elegant solutions sometimes can be
reapplied elsewhere
 SYN(really SYN|ACK) cookies made SYN
reception more efficient
 Inverse SYN cookies make SYN transmission
Layer Redundancy
 L2: Broadcast MAC Address
 FF:FF:FF:FF:FF:FF
 Absolute
 L3: Broadcast IP Address
 Last IP of Subnet
 Relative
 Sending to it is known as a Directed Broadcast
 Often blocked, if it can be detected
 Detection can be…suppressed.
Broadcast GHosts
 Guerrila Multicast
 “Is it possible to send a single packet to multiple
recipients, using today’s multicast-free Internet?”
 Answer: Yes, barely.
 Link a unicast IP to a broadcast MAC
address; all responses to that IP will 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
 DHCP for an IP
 May or may not use broadcast MAC in DHCP
request – just trying to validate that nobody else is
using the IP
 Answer ARP requests for that IP with
Broadcast MAC (or Multicast MAC)
 At L2, w/o IGMP Snooping working, Multicast =
Broadcast
 Issue L4 requests against a remote host,
unicasted via layer 3, with responses
broadcasted locally at layer 2
 Elegance has left the building
Firewall Issues
 NAT
 100% NAT penetration, as long as the
implementation doesn’t refuse to NAT for a
broadcast MAC
 PIX, which accepts…Multicast MACs!
 Multicast through NAT!
 UDP
 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
 Without any listeners, stream dies
 With one listener, stream can operate
normally
 With many listeners, only one should
participate in acknowledging the stream
 If that one dies, another should take its place
 Solution: Random delays
 On reception of a packet to be acknowledged,
queue a response within the next 50-1500ms
 Broadcast response
 If another host broadcasted a response before you
had the chance to, unschedule your response
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
 Other Uses
 “All hosts” could also include “Many hosts” using
L2 Multicast packets
 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
 Already munging IP, might as well munge ports
too
 Some implementations make best efforts to match
local port inside the network w/ local port outside
 Birthday Paradox: Collision chance = 1 /
sqrt(range_of_local_ports) = 1/256
 If we can always match IP and Port, then we
can always maintain end-to-end correctness
 Only have a problem 1/256 connections to the
same host
 Alternate strategies exist – munge the SEQ#(problems
w/ Window overlap), MTU decrement, TIMESTAMPS
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
 Maintains L3 end-to-end integrity
Implementation: AllNewt 1.0
 “All New Translation Engine”
 Another part of Paketto Keiretsu
 Translates arbitrary local IP addresses into
globally routable IP addresses
 Instead of just storing IP_SRC, stores IP_SRC,
ETHER_DHOST, and ETHER_SHOST
 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
Pizza Protocol A La Mode
 “Anyone order a pizza?”
 Stateless approach: Ask everybody, drop
RST|ACK, forward everything else.
 Just broadcast to the IP
 Actually works behind NATs, but you need to
catalog all the local IPs
 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
Incoming State
 Stateful Approach (“you ordered the last one”)
 Ask everyone, but remember who’s hosting
 Send to the first host that replies
 Increment the timer every time a packet is emitted
from the serving host for that port
 If no packets are emitted after a certain amount of
time, allow open registration once more
 “It’s amazing what you can do once security
is not an issue.”
TCP Splicing
 NAT Deadlock Resolution
 “Is it possible to establish a TCP connection
between two hosts, both behind NATs?”
 Answer: Yes…but it ain’t pretty.
 Convince each firewall that the other accepted the
connection
 Layers will need to be played against eachother to
prevent certain otherwise desirable messaging behaviors
from going too far
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
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 match
 SEQ#’s must match
 Total outgoing trust, zero 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
 Negative reply, entry in state table
destroyed
 Can we get the former without the
latter?
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 state table from closing the
hole
 Alice SYNs w/ Doomed TTL
 Bob SYNs w/ Doomed TTL
 Both firewalls have a hole open for eachother
Packets, Ports, Problems
 Three way handshake – SYN, SYN|ACK,
ACK
 Outgoing connections have SYNs and ACKs but
no SYN|ACKs
 Ports
 Need to agree on which ports are linking up
 Need to discover firewall multiplexing rules
 Timing
 Need to know when to attempt connection
 Solution to all three: Handshake Only
Connection Broker
 Involved only in setting up connection
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.”
 Need to generate packets, though
Local Port Strategies
 Some firewalls do best effort to match
 Some increment from a fixed counter
 Some use random local ports
 Entropy cannot be differentiated – rule
from kleptography
 As long as it’s translated back…
 Need to discover what strategy is being
used
Full Broker Discovery
 Alice and Bob SYN Charlie 2x
 Charlie NFO Alice and Bob
 Alice and Bob SYN Charlie
 Alice and Bob DoomSYN Bob and Alice
 Alice and Bob SYN Charlie
 Charlie SYN|ACK Alice and Bob
 Throw details about port selection in IPID
 Alice and Bob DoomACK Bob and Alice
 Alice and Bob begin normal TCP session to
eachother, as if the other acknowledged
correctly
Much easier strategies
 Source route through connection broker, drop
the route once the connection goes live
 UDP NAT2NAT
 Works all over the place in games
 UDP is symmetrical – just spew packets at
eachother with opposite local port / source port,
and eventually the state system will assume the
other’s outgoing packet is a response to its own
outgoing packet
 You can run TCP over UDP
 Far less fun though
TTL-Based Firewall Analysis
 Emit a SYN with a low TTL
 SYN spawns ICMP error, hits local
firewall, which rewrites IP header and
forwards to local host
 Firewall doesn’t rewrite ICMP data
 Original outgoing header
 Can discover how firewall is munging
our datastream
State of Disarray
 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: Yup. (Thanks, Spence.)
 IP Timestamps Mode 3
 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
Abusing IP Timestamps
 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
 Damn source routers ;-)
 Possibilities with TCP Timestamps too
 Reply field contains 32 bits of user specified stamp
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
Interesting things are possible
 All code to be released at
http://www.doxpara.com

Weitere ähnliche Inhalte

Was ist angesagt?

Network tunneling techniques
Network tunneling techniquesNetwork tunneling techniques
Network tunneling techniquesinbroker
 
internetworking operation
internetworking operationinternetworking operation
internetworking operationSrinivasa Rao
 
Tcp Ip Overview
Tcp Ip OverviewTcp Ip Overview
Tcp Ip OverviewAmir Malik
 
CapAnalysis - Deep Packet Inspection
CapAnalysis - Deep Packet InspectionCapAnalysis - Deep Packet Inspection
CapAnalysis - Deep Packet InspectionChris Harrington
 
Chapter 6 - The Link Layer: Links, Access Networks and LANs
Chapter 6 - The Link Layer: Links, Access Networks and LANsChapter 6 - The Link Layer: Links, Access Networks and LANs
Chapter 6 - The Link Layer: Links, Access Networks and LANsAndy Juan Sarango Veliz
 
Exploiting Network Protocols To Exhaust Bandwidth Links 2008 Final
Exploiting Network Protocols To Exhaust Bandwidth Links 2008 FinalExploiting Network Protocols To Exhaust Bandwidth Links 2008 Final
Exploiting Network Protocols To Exhaust Bandwidth Links 2008 Finalmasoodnt10
 
Sample Network Analysis Report based on Wireshark Analysis
Sample Network Analysis Report based on Wireshark AnalysisSample Network Analysis Report based on Wireshark Analysis
Sample Network Analysis Report based on Wireshark AnalysisDavid Sweigert
 
Copy of a simple tcp spoofing attack
Copy of a simple tcp spoofing attackCopy of a simple tcp spoofing attack
Copy of a simple tcp spoofing attackVishal Gurujuwada
 
Packet analyzing with wireshark-basic of packet analyzing - Episode_03
Packet analyzing with wireshark-basic of packet analyzing - Episode_03Packet analyzing with wireshark-basic of packet analyzing - Episode_03
Packet analyzing with wireshark-basic of packet analyzing - Episode_03Dhananja Kariyawasam
 
Quantifying the impact of flood attack on
Quantifying the impact of flood attack onQuantifying the impact of flood attack on
Quantifying the impact of flood attack onijcsa
 
Entropy based DDos Detection in SDN
Entropy based DDos Detection in SDNEntropy based DDos Detection in SDN
Entropy based DDos Detection in SDNVishal Vasudev
 
Dotnet network prog_chap07
Dotnet network prog_chap07Dotnet network prog_chap07
Dotnet network prog_chap07Truong NGUYEN
 

Was ist angesagt? (20)

TCPIP
TCPIPTCPIP
TCPIP
 
Network tunneling techniques
Network tunneling techniquesNetwork tunneling techniques
Network tunneling techniques
 
Bh eu 05-kaminsky
Bh eu 05-kaminskyBh eu 05-kaminsky
Bh eu 05-kaminsky
 
Lecture9
Lecture9Lecture9
Lecture9
 
Wireshark Lab HTTP, DNS and ARP v7 solution
Wireshark Lab HTTP, DNS and ARP v7 solutionWireshark Lab HTTP, DNS and ARP v7 solution
Wireshark Lab HTTP, DNS and ARP v7 solution
 
internetworking operation
internetworking operationinternetworking operation
internetworking operation
 
Tcp Ip Overview
Tcp Ip OverviewTcp Ip Overview
Tcp Ip Overview
 
CapAnalysis - Deep Packet Inspection
CapAnalysis - Deep Packet InspectionCapAnalysis - Deep Packet Inspection
CapAnalysis - Deep Packet Inspection
 
Chapter 3 - Transport Layer
Chapter 3 - Transport LayerChapter 3 - Transport Layer
Chapter 3 - Transport Layer
 
Chapter 6 - The Link Layer: Links, Access Networks and LANs
Chapter 6 - The Link Layer: Links, Access Networks and LANsChapter 6 - The Link Layer: Links, Access Networks and LANs
Chapter 6 - The Link Layer: Links, Access Networks and LANs
 
Exploiting Network Protocols To Exhaust Bandwidth Links 2008 Final
Exploiting Network Protocols To Exhaust Bandwidth Links 2008 FinalExploiting Network Protocols To Exhaust Bandwidth Links 2008 Final
Exploiting Network Protocols To Exhaust Bandwidth Links 2008 Final
 
Skype
SkypeSkype
Skype
 
Sample Network Analysis Report based on Wireshark Analysis
Sample Network Analysis Report based on Wireshark AnalysisSample Network Analysis Report based on Wireshark Analysis
Sample Network Analysis Report based on Wireshark Analysis
 
Ba25315321
Ba25315321Ba25315321
Ba25315321
 
Copy of a simple tcp spoofing attack
Copy of a simple tcp spoofing attackCopy of a simple tcp spoofing attack
Copy of a simple tcp spoofing attack
 
Packet analyzing with wireshark-basic of packet analyzing - Episode_03
Packet analyzing with wireshark-basic of packet analyzing - Episode_03Packet analyzing with wireshark-basic of packet analyzing - Episode_03
Packet analyzing with wireshark-basic of packet analyzing - Episode_03
 
Wireshark lab ssl v7 solution
Wireshark lab ssl v7 solutionWireshark lab ssl v7 solution
Wireshark lab ssl v7 solution
 
Quantifying the impact of flood attack on
Quantifying the impact of flood attack onQuantifying the impact of flood attack on
Quantifying the impact of flood attack on
 
Entropy based DDos Detection in SDN
Entropy based DDos Detection in SDNEntropy based DDos Detection in SDN
Entropy based DDos Detection in SDN
 
Dotnet network prog_chap07
Dotnet network prog_chap07Dotnet network prog_chap07
Dotnet network prog_chap07
 

Andere mochten auch

YIT internal magazine - ing 01/2011
YIT internal magazine - ing 01/2011YIT internal magazine - ing 01/2011
YIT internal magazine - ing 01/2011YIT Slovakia
 
Kreoaula: Badania usability
Kreoaula: Badania usabilityKreoaula: Badania usability
Kreoaula: Badania usabilityguest2d8f65
 
Extreme Networks: MUK: UA-IX
Extreme Networks: MUK: UA-IXExtreme Networks: MUK: UA-IX
Extreme Networks: MUK: UA-IXMUK
 
The gold and silver of zadar+ st. francis sacral art exhibits
The gold and silver of zadar+ st. francis sacral art exhibitsThe gold and silver of zadar+ st. francis sacral art exhibits
The gold and silver of zadar+ st. francis sacral art exhibitsmelita23
 
Ideal Network - Cause Partners PowerPoint
Ideal Network - Cause Partners PowerPointIdeal Network - Cause Partners PowerPoint
Ideal Network - Cause Partners PowerPointIdealNetwork
 
ScrumDay France 2014 - My product is a james bond movie - The James Bond Movi...
ScrumDay France 2014 - My product is a james bond movie - The James Bond Movi...ScrumDay France 2014 - My product is a james bond movie - The James Bond Movi...
ScrumDay France 2014 - My product is a james bond movie - The James Bond Movi...Pierre E. NEIS
 
Fun Activities from a Project-based On-line Ecology Course
Fun Activities from a Project-based On-line Ecology CourseFun Activities from a Project-based On-line Ecology Course
Fun Activities from a Project-based On-line Ecology CourseSteven BREWER
 
Der Bundesverband Deutsche Startups e.V. stellt sich vor
Der Bundesverband Deutsche Startups e.V. stellt sich vorDer Bundesverband Deutsche Startups e.V. stellt sich vor
Der Bundesverband Deutsche Startups e.V. stellt sich vorDaniel Bartel
 
Second Life als E-Learning Plattform - Chancen und Nebenwirkungen
Second Life als E-Learning Plattform - Chancen und NebenwirkungenSecond Life als E-Learning Plattform - Chancen und Nebenwirkungen
Second Life als E-Learning Plattform - Chancen und NebenwirkungenMatthias Rückel
 

Andere mochten auch (11)

YIT internal magazine - ing 01/2011
YIT internal magazine - ing 01/2011YIT internal magazine - ing 01/2011
YIT internal magazine - ing 01/2011
 
Kreoaula: Badania usability
Kreoaula: Badania usabilityKreoaula: Badania usability
Kreoaula: Badania usability
 
Can ufo doc_13
Can ufo doc_13Can ufo doc_13
Can ufo doc_13
 
Extreme Networks: MUK: UA-IX
Extreme Networks: MUK: UA-IXExtreme Networks: MUK: UA-IX
Extreme Networks: MUK: UA-IX
 
HTML w 10 prostych krokach
HTML w 10 prostych krokachHTML w 10 prostych krokach
HTML w 10 prostych krokach
 
The gold and silver of zadar+ st. francis sacral art exhibits
The gold and silver of zadar+ st. francis sacral art exhibitsThe gold and silver of zadar+ st. francis sacral art exhibits
The gold and silver of zadar+ st. francis sacral art exhibits
 
Ideal Network - Cause Partners PowerPoint
Ideal Network - Cause Partners PowerPointIdeal Network - Cause Partners PowerPoint
Ideal Network - Cause Partners PowerPoint
 
ScrumDay France 2014 - My product is a james bond movie - The James Bond Movi...
ScrumDay France 2014 - My product is a james bond movie - The James Bond Movi...ScrumDay France 2014 - My product is a james bond movie - The James Bond Movi...
ScrumDay France 2014 - My product is a james bond movie - The James Bond Movi...
 
Fun Activities from a Project-based On-line Ecology Course
Fun Activities from a Project-based On-line Ecology CourseFun Activities from a Project-based On-line Ecology Course
Fun Activities from a Project-based On-line Ecology Course
 
Der Bundesverband Deutsche Startups e.V. stellt sich vor
Der Bundesverband Deutsche Startups e.V. stellt sich vorDer Bundesverband Deutsche Startups e.V. stellt sich vor
Der Bundesverband Deutsche Startups e.V. stellt sich vor
 
Second Life als E-Learning Plattform - Chancen und Nebenwirkungen
Second Life als E-Learning Plattform - Chancen und NebenwirkungenSecond Life als E-Learning Plattform - Chancen und Nebenwirkungen
Second Life als E-Learning Plattform - Chancen und Nebenwirkungen
 

Ähnlich wie Bh us-02-kaminsky-blackops

Ähnlich wie Bh us-02-kaminsky-blackops (20)

Simplified Networking and Troubleshooting for K-12 Teachers
Simplified Networking and Troubleshooting for K-12 TeachersSimplified Networking and Troubleshooting for K-12 Teachers
Simplified Networking and Troubleshooting for K-12 Teachers
 
Introduction to networking
Introduction to networkingIntroduction to networking
Introduction to networking
 
Mitm
MitmMitm
Mitm
 
lis508p02a-10.ppt
lis508p02a-10.pptlis508p02a-10.ppt
lis508p02a-10.ppt
 
I pv6 mechanism
I pv6 mechanismI pv6 mechanism
I pv6 mechanism
 
Internetworking
InternetworkingInternetworking
Internetworking
 
Tcpip
TcpipTcpip
Tcpip
 
TCP/IP For Engineers
TCP/IP For EngineersTCP/IP For Engineers
TCP/IP For Engineers
 
3.Network
3.Network3.Network
3.Network
 
There and back again
There and back againThere and back again
There and back again
 
Tcp
TcpTcp
Tcp
 
Networking
NetworkingNetworking
Networking
 
PyNet
PyNetPyNet
PyNet
 
Mod9
Mod9Mod9
Mod9
 
class12_Networking2
class12_Networking2class12_Networking2
class12_Networking2
 
Network Security - Layer 2
Network Security - Layer 2Network Security - Layer 2
Network Security - Layer 2
 
Vlan
VlanVlan
Vlan
 
Physical And Data Link Layers
Physical And Data Link LayersPhysical And Data Link Layers
Physical And Data Link Layers
 
TCP/IP 3RD SEM.2012 AUG.ASSIGNMENT
TCP/IP 3RD SEM.2012 AUG.ASSIGNMENTTCP/IP 3RD SEM.2012 AUG.ASSIGNMENT
TCP/IP 3RD SEM.2012 AUG.ASSIGNMENT
 
07 - TCP_IP and the DoD Model.ppt
07 - TCP_IP and the DoD Model.ppt07 - TCP_IP and the DoD Model.ppt
07 - TCP_IP and the DoD Model.ppt
 

Mehr von Dan Kaminsky

Bugs Aren't Random
Bugs Aren't RandomBugs Aren't Random
Bugs Aren't RandomDan Kaminsky
 
Wo defensive trickery_13mar2017
Wo defensive trickery_13mar2017Wo defensive trickery_13mar2017
Wo defensive trickery_13mar2017Dan Kaminsky
 
Move Fast and Fix Things
Move Fast and Fix ThingsMove Fast and Fix Things
Move Fast and Fix ThingsDan Kaminsky
 
A Technical Dive into Defensive Trickery
A Technical Dive into Defensive TrickeryA Technical Dive into Defensive Trickery
A Technical Dive into Defensive TrickeryDan Kaminsky
 
I Want These * Bugs Off My * Internet
I Want These * Bugs Off My * InternetI Want These * Bugs Off My * Internet
I Want These * Bugs Off My * InternetDan Kaminsky
 
Yet Another Dan Kaminsky Talk (Black Ops 2014)
Yet Another Dan Kaminsky Talk (Black Ops 2014)Yet Another Dan Kaminsky Talk (Black Ops 2014)
Yet Another Dan Kaminsky Talk (Black Ops 2014)Dan Kaminsky
 
Chicken Chicken Chicken Chicken
Chicken Chicken Chicken ChickenChicken Chicken Chicken Chicken
Chicken Chicken Chicken ChickenDan Kaminsky
 
Some Thoughts On Bitcoin
Some Thoughts On BitcoinSome Thoughts On Bitcoin
Some Thoughts On BitcoinDan Kaminsky
 
Black Ops of TCP/IP 2011 (Black Hat USA 2011)
Black Ops of TCP/IP 2011 (Black Hat USA 2011)Black Ops of TCP/IP 2011 (Black Hat USA 2011)
Black Ops of TCP/IP 2011 (Black Hat USA 2011)Dan Kaminsky
 
Showing How Security Has (And Hasn't) Improved, After Ten Years Of Trying
Showing How Security Has (And Hasn't) Improved, After Ten Years Of TryingShowing How Security Has (And Hasn't) Improved, After Ten Years Of Trying
Showing How Security Has (And Hasn't) Improved, After Ten Years Of TryingDan Kaminsky
 
Domain Key Infrastructure (From Black Hat USA)
Domain Key Infrastructure (From Black Hat USA)Domain Key Infrastructure (From Black Hat USA)
Domain Key Infrastructure (From Black Hat USA)Dan Kaminsky
 
232 md5-considered-harmful-slides
232 md5-considered-harmful-slides232 md5-considered-harmful-slides
232 md5-considered-harmful-slidesDan Kaminsky
 
Dmk sb2010 web_defense
Dmk sb2010 web_defenseDmk sb2010 web_defense
Dmk sb2010 web_defenseDan Kaminsky
 
Bh us-02-kaminsky-blackops
Bh us-02-kaminsky-blackopsBh us-02-kaminsky-blackops
Bh us-02-kaminsky-blackopsDan Kaminsky
 

Mehr von Dan Kaminsky (20)

Bugs Aren't Random
Bugs Aren't RandomBugs Aren't Random
Bugs Aren't Random
 
Wo defensive trickery_13mar2017
Wo defensive trickery_13mar2017Wo defensive trickery_13mar2017
Wo defensive trickery_13mar2017
 
Move Fast and Fix Things
Move Fast and Fix ThingsMove Fast and Fix Things
Move Fast and Fix Things
 
A Technical Dive into Defensive Trickery
A Technical Dive into Defensive TrickeryA Technical Dive into Defensive Trickery
A Technical Dive into Defensive Trickery
 
Chicken
ChickenChicken
Chicken
 
I Want These * Bugs Off My * Internet
I Want These * Bugs Off My * InternetI Want These * Bugs Off My * Internet
I Want These * Bugs Off My * Internet
 
Yet Another Dan Kaminsky Talk (Black Ops 2014)
Yet Another Dan Kaminsky Talk (Black Ops 2014)Yet Another Dan Kaminsky Talk (Black Ops 2014)
Yet Another Dan Kaminsky Talk (Black Ops 2014)
 
Chicken Chicken Chicken Chicken
Chicken Chicken Chicken ChickenChicken Chicken Chicken Chicken
Chicken Chicken Chicken Chicken
 
Black ops 2012
Black ops 2012Black ops 2012
Black ops 2012
 
Some Thoughts On Bitcoin
Some Thoughts On BitcoinSome Thoughts On Bitcoin
Some Thoughts On Bitcoin
 
Black Ops of TCP/IP 2011 (Black Hat USA 2011)
Black Ops of TCP/IP 2011 (Black Hat USA 2011)Black Ops of TCP/IP 2011 (Black Hat USA 2011)
Black Ops of TCP/IP 2011 (Black Hat USA 2011)
 
Showing How Security Has (And Hasn't) Improved, After Ten Years Of Trying
Showing How Security Has (And Hasn't) Improved, After Ten Years Of TryingShowing How Security Has (And Hasn't) Improved, After Ten Years Of Trying
Showing How Security Has (And Hasn't) Improved, After Ten Years Of Trying
 
Domain Key Infrastructure (From Black Hat USA)
Domain Key Infrastructure (From Black Hat USA)Domain Key Infrastructure (From Black Hat USA)
Domain Key Infrastructure (From Black Hat USA)
 
Interpolique
InterpoliqueInterpolique
Interpolique
 
232 md5-considered-harmful-slides
232 md5-considered-harmful-slides232 md5-considered-harmful-slides
232 md5-considered-harmful-slides
 
Confidence web
Confidence webConfidence web
Confidence web
 
Dmk sb2010 web_defense
Dmk sb2010 web_defenseDmk sb2010 web_defense
Dmk sb2010 web_defense
 
Interpolique
InterpoliqueInterpolique
Interpolique
 
Black opspki 2
Black opspki 2Black opspki 2
Black opspki 2
 
Bh us-02-kaminsky-blackops
Bh us-02-kaminsky-blackopsBh us-02-kaminsky-blackops
Bh us-02-kaminsky-blackops
 

Bh us-02-kaminsky-blackops

  • 1. BLACK OPS OF TCP/IPSpliced NAT2NAT And Other Packet-Level Misadventures Dan Kaminsky, CISSP DoxPara Research www.doxpara.com
  • 2. Where I’m Coming From…  Black Hat / DefCon 0x7D1  Impossible Tunnels through Improbable Networks with OpenSSH  Getting Out: ProxyCommands for Non-TCP comm layers  HTTP, SOCKS, UDP, Packet Radio*, AIM/Yahoo*  Coming In: Active Connection Brokering for NAT2NAT  One host exports SSHD to broker  Other host imports access from broker  Passing Through: Dynamic Forwarding for Psuedo-VPN Work  Web Browsing, Dialpad(Split-H323), etc.
  • 3. 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?”
  • 4. On Possibility  Restraint Free Engineering  “Abandon All Practicality, Ye Who Enter Here”  “It’s amazing what you can do once security is no longer a concern.”  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.
  • 5. On Packet Structure  Packets are “strangely ordered”  Where it’s ending up next, where it came from recently, how it’s hopping from one place to the next, how it’s hopping to its final destination, checksum, where the packet came from originally, where it’s going to end up, what app it came from, what app it’s going to, checksum, god knows what, ANOTHER checksum  Why not sort everything; put all the “came from” and “going to’s” Why so much redundancy? Isn’t it inefficient?  WHO CARES?
  • 6. Layers: Not What, But Who  One medium, many messages  Listeners reconstruct meanings relevant to themselves, ignore the rest  Managed (ir)responsibility  Fields are out of order, occasionally because they’re addressed to different entities  Name and address repeated inside a business letter and on the envelope  Messages at one layer can modulate messages received at another  Insufficient postage will prevent a correctly addressed letter from getting sent  Incorrect internal address has unknown effects
  • 7. Error Recovery Per Layer  Layer 2 (Point to Point)  Errors are quickly recoverable, but error generation can occur at same layer as layer control  Data is destroyed and recreated each frame  Corporate Fertilizer  Layer 3 (Router to Router)  Many more sources of personally irrelevant error  Highest Traffic Link  Data is modulated – minimum change possible  Layer 4 (End to End)  Lowest traffic, highest personal relevance  Errors here actually matter
  • 8.  This slide intentionally left blank
  • 9. TCP Connection Traits: Flags  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.
  • 10. TCP (and UDP) Connection Traits: Ports  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  IP handles who we’re talking to; Ports handle what we want from them
  • 11. 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
  • 12. Connection Summary  Flag determines phase  Asymmetric  Port determines process  Sequence “secures session”  Prevents trivial spoofing attacks  Also used to manage connection speed, identify which bytes are being acknowledged
  • 13. 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  Same local port  SYN cookies  Receiving  Kernel filter packets arriving to local port  Record connection phase: Port up(SYN|ACK) or host up, port down(RST|ACK)
  • 14. Issue: Spoofed Responses  Easy to spoof hosts being up if the scanner isn’t tracking who (or how it scanned)  Solution: Invert SYN Cookies!
  • 15. SYN Cookies  Developed in ’96, when SYN floods became common  ACK reflects ACK# of SYN|ACK(incremented by one)  Encrypts connection state into the SYN|ACK’s ACK#  Therefore, you can use legitimate remote hosts – instead of kernel memory – to store handshake state  Ahhh…but 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
  • 16. Implementation: Scanrand 1.0  Element of: Paketto Keiretsu  384 lines of libnet and libpcap, w/ trivial MD4 include  No state stored  Scans at ~11-20mbit  Possibly even portable  100% complete, release imminent
  • 18. 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
  • 19. 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)  This is the heart of kleptography  Elegant solutions sometimes can be reapplied elsewhere  SYN(really SYN|ACK) cookies made SYN reception more efficient  Inverse SYN cookies make SYN transmission
  • 20. Layer Redundancy  L2: Broadcast MAC Address  FF:FF:FF:FF:FF:FF  Absolute  L3: Broadcast IP Address  Last IP of Subnet  Relative  Sending to it is known as a Directed Broadcast  Often blocked, if it can be detected  Detection can be…suppressed.
  • 21. Broadcast GHosts  Guerrila Multicast  “Is it possible to send a single packet to multiple recipients, using today’s multicast-free Internet?”  Answer: Yes, barely.  Link a unicast IP to a broadcast MAC address; all responses to that IP will be broadcast throughout a subnet  No individual client need duplicate the datastream – the switch will issue copies of the data to all downstream hosts
  • 22. IP Incorporated  DHCP for an IP  May or may not use broadcast MAC in DHCP request – just trying to validate that nobody else is using the IP  Answer ARP requests for that IP with Broadcast MAC (or Multicast MAC)  At L2, w/o IGMP Snooping working, Multicast = Broadcast  Issue L4 requests against a remote host, unicasted via layer 3, with responses broadcasted locally at layer 2  Elegance has left the building
  • 23. Firewall Issues  NAT  100% NAT penetration, as long as the implementation doesn’t refuse to NAT for a broadcast MAC  PIX, which accepts…Multicast MACs!  Multicast through NAT!  UDP  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
  • 24. TCP w/ Guerrila Multicast  Without any listeners, stream dies  With one listener, stream can operate normally  With many listeners, only one should participate in acknowledging the stream  If that one dies, another should take its place  Solution: Random delays  On reception of a packet to be acknowledged, queue a response within the next 50-1500ms  Broadcast response  If another host broadcasted a response before you had the chance to, unschedule your response
  • 25. 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  Other Uses  “All hosts” could also include “Many hosts” using L2 Multicast packets  Do we have another other situation where one IP “stands in” for many hosts?
  • 26. NAT: Splitting IPs For Fun and Profit  NAT multiplexes several hosts into one IP address by splitting on local port  Already munging IP, might as well munge ports too  Some implementations make best efforts to match local port inside the network w/ local port outside  Birthday Paradox: Collision chance = 1 / sqrt(range_of_local_ports) = 1/256  If we can always match IP and Port, then we can always maintain end-to-end correctness  Only have a problem 1/256 connections to the same host  Alternate strategies exist – munge the SEQ#(problems w/ Window overlap), MTU decrement, TIMESTAMPS
  • 27. 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  Maintains L3 end-to-end integrity
  • 28. Implementation: AllNewt 1.0  “All New Translation Engine”  Another part of Paketto Keiretsu  Translates arbitrary local IP addresses into globally routable IP addresses  Instead of just storing IP_SRC, stores IP_SRC, ETHER_DHOST, and ETHER_SHOST  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
  • 29. Pizza Protocol A La Mode  “Anyone order a pizza?”  Stateless approach: Ask everybody, drop RST|ACK, forward everything else.  Just broadcast to the IP  Actually works behind NATs, but you need to catalog all the local IPs  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
  • 30. Incoming State  Stateful Approach (“you ordered the last one”)  Ask everyone, but remember who’s hosting  Send to the first host that replies  Increment the timer every time a packet is emitted from the serving host for that port  If no packets are emitted after a certain amount of time, allow open registration once more  “It’s amazing what you can do once security is not an issue.”
  • 31. TCP Splicing  NAT Deadlock Resolution  “Is it possible to establish a TCP connection between two hosts, both behind NATs?”  Answer: Yes…but it ain’t pretty.  Convince each firewall that the other accepted the connection  Layers will need to be played against eachother to prevent certain otherwise desirable messaging behaviors from going too far
  • 32. 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
  • 33. 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 match  SEQ#’s must match  Total outgoing trust, zero incoming trust
  • 34. 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
  • 35. 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?
  • 36. 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 state table from closing the hole  Alice SYNs w/ Doomed TTL  Bob SYNs w/ Doomed TTL  Both firewalls have a hole open for eachother
  • 37. Packets, Ports, Problems  Three way handshake – SYN, SYN|ACK, ACK  Outgoing connections have SYNs and ACKs but no SYN|ACKs  Ports  Need to agree on which ports are linking up  Need to discover firewall multiplexing rules  Timing  Need to know when to attempt connection  Solution to all three: Handshake Only Connection Broker  Involved only in setting up connection
  • 38. 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.”  Need to generate packets, though
  • 39. Local Port Strategies  Some firewalls do best effort to match  Some increment from a fixed counter  Some use random local ports  Entropy cannot be differentiated – rule from kleptography  As long as it’s translated back…  Need to discover what strategy is being used
  • 40. Full Broker Discovery  Alice and Bob SYN Charlie 2x  Charlie NFO Alice and Bob  Alice and Bob SYN Charlie  Alice and Bob DoomSYN Bob and Alice  Alice and Bob SYN Charlie  Charlie SYN|ACK Alice and Bob  Throw details about port selection in IPID  Alice and Bob DoomACK Bob and Alice  Alice and Bob begin normal TCP session to eachother, as if the other acknowledged correctly
  • 41. Much easier strategies  Source route through connection broker, drop the route once the connection goes live  UDP NAT2NAT  Works all over the place in games  UDP is symmetrical – just spew packets at eachother with opposite local port / source port, and eventually the state system will assume the other’s outgoing packet is a response to its own outgoing packet  You can run TCP over UDP  Far less fun though
  • 42. TTL-Based Firewall Analysis  Emit a SYN with a low TTL  SYN spawns ICMP error, hits local firewall, which rewrites IP header and forwards to local host  Firewall doesn’t rewrite ICMP data  Original outgoing header  Can discover how firewall is munging our datastream
  • 43. State of Disarray  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
  • 44. 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: Yup. (Thanks, Spence.)  IP Timestamps Mode 3  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
  • 45. Abusing IP Timestamps  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  Damn source routers ;-)  Possibilities with TCP Timestamps too  Reply field contains 32 bits of user specified stamp
  • 46. 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
  • 47. Interesting things are possible  All code to be released at http://www.doxpara.com