Home > Security > Staring Into The Abyss, A Bit Before Cansec

Staring Into The Abyss, A Bit Before Cansec

I’m just going to come out and say it:  I miss packet craft.  Sure, we can always pull out Scapy, and slap amusing packets together, but everything interesting is always at the other layers.

Or is it?

For CanSecWest this year, I thought it’d be interesting to take a look at the realm of Deep  Packet Inspectors. It turns out we were doing a lot of this around 2000 through 2002, and then…well, sort of stopped.  So, in this year’s CanSecWest paper, “Staring Into The Abyss:  Revisiting Browser v. Middleware Attacks In The Era Of Deep Packet Inspection” (DOC, PDF), I’m taking another crack at the realm — and I’m seeing really interesting capabilities to fingerprint, bypass, and otherwise manipulate systems that watch from the middle of networks, using protocol emulation abilities that have been part of browsers and their plugin ecosystem from the very beginning.

Ah, but here’s where I need some help.  I’ve worked pretty closely with Robert Auger from Paypal, who just published his own paper, “Socket Capable Browser Plugins Result In Transparent Proxy Abuse”.  We independently discovered the HTTP component of this attack pattern, and as I describe in my paper, we’ve kind of forgotten just how much can be done against Active FTP Application Layer Gateways.

So, if I may ask, take a look, check out my paper, and if you have some thoughts, corrections, or interesting techniques, let me know so I can integrate them into my CanSecWest presentation.  Here’s the full summary, to whet your appetite:

DPI — Deep Packet Inspection — technology is driving large amounts of intelligence into the infrastructure, parsing more and more context from data flows going past. Though this work may be necessary to support important business and even security requirements, we know from the history of security that to parse data is to potentially be vulnerable to that data – especially when the parser is designed to extract context as quickly as possible. Indeed, companies such as BreakingPoint and Codenomicon have made their names building test tools to expose potential faults with DPI engines. But could anyone actually trigger these vulnerabilities? In this paper, we restart an old line of research from several years ago: The use of in-browser technologies to “tweak” Deep Packet Inspection systems.

Essentially, by controlling both endpoints surrounding a DPI system, possibly using the TCP (and sometimes UDP) socket code that plugins add to browsers, what behavior can we extract? We find three lines of attack worth noting.

First, firewalls and NATs — the most widely deployed packet inspectors on the Internet today — can still be made to open firewall holes to the Internet by having the browser trigger the Application Layer Gateway (ALG) for protocols like Active FTP. We extend older work by integrating mechanisms for acquiring the correct internal IP address of a client, necessary for triggering many inspection engines, we survey other protocols such as SIP and H.323 that have their own inspection engines, and we explore better strategies for triggering these vulnerabilities without socket engines from browser plugins. We also explore a potentially new mechanism, “Window Dribbling”, that allows an HTTP POST from a browser to be converted into a full bidirectional conversation by only allowing a remote sender to “dribble” a fixed number of bytes per segment.

Second, we (along with Robert Auger at Paypal) find that transparent HTTP proxies, such as Squid, will “override” the intended destination of browser sockets, allowing a remote attacker to send and receive data from arbitrary web sites. This allows (at minimum) extensive and expensive click fraud attacks, and may expose internal connectivity as well (HTTP or even TCP).

Third, and most interestingly, we find that active DPI’s — those that actually alter the flow of traffic between a client and a server — all seem to expose subtly different parsers and handlers for the protocols they manipulate. These variations of behavior can be remotely fingerprinted, allowing an attacker to identify DPI platforms so as to correctly target his attacks. This capability, understood particularly in light of Felix Lindner’s recent work on generic attacks against Cisco infrastructure, underscores the need for both DPI vendors to test their platforms extensively, and for IT managers to deploy critical infrastructure patches with at least as much vigor as desktop support receives today.

For remediation purposes, we recommend two lines of defense – one policy, one technical. As a matter of policy, we find the most important recommendation of this paper that industry reconsiders patching policies as they apply to infrastructure, especially as that infrastructure starts inspecting traffic at ever higher speeds in ever deeper ways. We are actively concerned that administrators have internalized the need to patch endpoints, but aren’t closely tracking the equipment that binds endpoints together – despite their ever increasing intelligence. This is as much a recommendation to vendors – to build patches quickly, and to code audit and fuzz with software from companies like Breakingpoint and Codenomicon – as it is a plea to IT departments to deploy the patches that are generated. Also from a policy perspective, while this paper does recognize the need for judicious use of DPI technology, systems that are deployed across organizational boundaries have particular need for correctness. There have been incidents in the past that have led to security vulnerability across entire ISPs.

On the technical front, we defend the existence of socket functionality in the browser, recognizing that constraining all networking to that which existed in 2001 is not leading to more stable or more secure networks. We explore a solution that potentially allow firewalls to integrate socket policies into their ALG’s, encouraging plugin developers to eventually join in with browser manufacturers and build a single, coherent, cross-domain communication standard. We also discuss more advanced transparent proxy caching policies, which will prevent the Same Origin Policy bypasses discussed above. Finally, we remind home router developers that browsers are still able to access their web interfaces from the Internet, and that this exposure can be repaired by tying default password effectiveness to either a button on the device or a power cycle.

The firewall fingerprinter should be online shortly, with source code for you to play with as well.  Thanks!

(Incidentally, yep, Source is this week, and I have something rather different in store for that event.  The times, they are busy.)

Categories: Security
  1. March 9, 2009 at 7:58 pm

    Good topic –
    Looking at DPI devices a few years ago we noticed that most if not all inline devices modify the packets. Some change TTLs, others reorder TCP packets some add TCP options to packets.

    Example: TopLayer sets the TTL to 255 and the TCP Options are changed to MSS 1460. It’s spottable for sure.

    Send TCP packets out of order on purpose and you will notice that most IPS’s will reorder them. This makes pattern matching quite a bit easier for them. The amount of reordering can help spot the actual model of the device. There is a difference between an ISS box without a Raza NP and one with it – and you can spot that by the “load balancing” it does internally.

    Generally speaking on most DPI devices you can discover the Ethernet chipset as well. Most DPI vendors just leave the MAC at default setup, probing Ethernet compatibly will usually give you a gem or two.

    Lastly, Regular Expressions are your friends. Some devices leverage PCRE (Juniper), others protocol decoders (IBM/ISS) and some their own unique version (TPTI). By crafting specific regex’s in dud packets you can measure the packet travel time and discover which type of device it is.

    A Netscreen device goes from 4 usecs to 66 usecs on a match of just 100 bytes. If I use a repeating pattern (15k) I can make it take 1.452 seconds. This is spottable – but that same pattern will fly thru the ISS box without a hiccup.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: