Staring Into The Abyss

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 - 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.1254, 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: •

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