Multipath TCP Introduces Security Blind Spot

msm1267 (2804139) writes If multipath TCP is the next big thing to bring resilience and efficiency to networking, then there are some serious security issues to address before it goes mainstream. An expert at next week's Black Hat conference is expected to explain how the TCP extension leaves network security gear blind to traffic moving over multiple network streams. Today's IDS and IPS, for example, cannot correlate and re-assemble traffic as it's split over multiple paths. While such attacks are not entirely practical today, as multipath TCP becomes a fixture on popular networking gear and mobile devices, the risks will escalate. "[Multipath TCP] solves big problems we have today in an elegant fashion," said Catherine Pearce, security consultant and one of the presenters, along with Patrick Thomas. "You don't have to replace hardware or software; it handles all that stuff behind the scenes. But security tools are naïve [to MPTCP], and make assumptions that are no longer valid that were valid in the past."

Comments

News to be filed under "duh..."

[Assmasher]

Seriously, the second somebody proposed this it should have been (and surely was) clear what the authentication and security implications were. This doesn't mean multi-path is a bad thing, it just means it will likely be used in the appropriate places as opposed to 'everywhere in the tubes.'

Re:News to be filed under "duh..."

[Anonymous Coward]

Seriously, the second somebody proposed this it should have been (and surely was) clear what the authentication and security implications were.

It's not like multi-homed protocols based on IP are new. SCTP has been around about a decade (half a decade as a real Internet standard).

Re:News to be filed under "duh..."

[KiloByte]

For me, some extra resiliency against snooping is a bonus rather than a "critical vulnerability".

Re:News to be filed under "duh..."

[Assmasher]

I certainly understand the sentiment, but multi-path just changes the chokepoints.

Re:News to be filed under "duh..."

[disposable60]

it will likely be used in the appropriate places as opposed to 'everywhere in the tubes.'

Appropriate meaning, in practical terms, any place it might save the operator of a given network segment a couple of bucks.

Re:News to be filed under "duh..."

[WaffleMonster]

It's not like multi-homed protocols based on IP are new. SCTP has been around about a decade (half a decade as a real Internet standard).

SCTP does not do what a lot of people think it does. Additional paths are used only for redundancy.

Re:News to be filed under "duh..."

[Anonymous Coward]

So what, just lay you OpenVPN tunnel over the multipath flows.

And if you had read TFA you would know it isn't about vulnerabilities inside the MPTCP protocol but about the fast that current DPI appliance are oblivious to this new protocol's behavior.

You should only be worried if your concern is maintaining the ability of an eavesdropper to listen to your traffic, most people hate that.

Re:News to be filed under "duh..."

[mellon]

The irony is that the article mentions that mptcp makes surveillance harder, as if that's a bad thing. Really tells you where the author(s) are coming from...

Re:News to be filed under "duh..."

[Anonymous Coward]

Yawn. This isn't even ''news''; the issue (security related to complete objects must be applied to "objects in their entirety", not fragments thereof) was covered starting on page one (1) of RFC 2480, published January 1999.

Damned ignorant kids; get off my lawn!

Great!

[Anonymous Coward]

What you're saying is that Multipath-TCP will make deep packet inspection less useful? That's a win in my book. The net shouldn't be looking at packet contents anyway.

Re:Great!

[BitZtream]

Not really.

'The bad guys' have multiple options. Comcast will do DPI at the edge where you have only one path, so multipathing won't effect them and throttling your torrents will still be trivial. The NSA/CIA will just recombine the streams in their data center from the multiple taps they have. Its not really difficult if you have enough CPU and they have the budget to ensure they have enough CPU ... and if they don't have the budget, they have enough dirty on congress to get their budget upped until they do.

Re:Great!

[Lennie]

I'm not sure what you mean, but MultiPath-TCP is about combining different technologies.

So one part of the stream will run over Comcast, sure. But an other part will be transfered of 3G/LTE/whatever...

In that case Comcast isn't going to get the whole stream. Good luck with your IDS and deep packet inspection.

Al though most deep packet inspection problem looks for port-numbers, HTTP Host-headers, HTTPS SNI names and destination IP-addresses anyway. So impact in that case might not be that bad.

An other use case for MultiPath-TCP is roaming without dropping a connection. So for example, going from one WiFi to an other Wifi network without interruption.

If that is a different provider again Comcast won't see the whole stream.

Re:Great!

[Bengie]

Al though most deep packet inspection problem looks for port-numbers

IPv6+IPSEC. Port numbers are also encrypted.

Design Issue

[sociocapitalist]

It's a design issue.

IDS and IPS can still intercept traffic taking muliple paths so long as those paths converge at the security device somewhere along the way.

i.e. traffic can be split across a WAN (MPLS / Internet IPSec paths for example) and be reassembled on the DMZ incoming to the destination site or hub site of a regional network.

Re:Design Issue

[Anonymous Coward]

But that's the point: it doesn't have to.

Say you have a phone on corporate WiFi and 4G. The phone handles MPTCP, but the corporate firewall only sees the part of traffic that goes over WiFi.

Re:Design Issue

[sociocapitalist]

But that's the point: it doesn't have to.

Say you have a phone on corporate WiFi and 4G. The phone handles MPTCP, but the corporate firewall only sees the part of traffic that goes over WiFi.

First off, it seems unlikely as the phone will either be a corporate device, including BYOD, or a personal device. In the first case the traffic will have to flow across the network (including the firewall) and in the second it will not cross the firewall anyway.

Second, if the firewall sees traffic it doesn't understand it's just going to drop it. Security is not compromised.

Re:Design Issue

[amorsen]

First off, it seems unlikely as the phone will either be a corporate device, including BYOD, or a personal device. In the first case the traffic will have to flow across the network (including the firewall)

What stops a BYOD from using multipath? It will have to use the 4G connection when it isn't on the corporate wifi, so what keeps it from using both?

Re:Design Issue

[Anonymous Coward]

The firewall sees another TCP connection. Everything looks great.

Lets say... a malware binary is downloaded with a dynamic load balancing across 2 tcp streams. Everything looks fine to your NG firewall, no malware detected.

This is definitely a game changer. The old security inspections are successfully evaded. Add on the ability to open a stream in the opposite direction.

The countermeasure is to enable deep protocol inspection (and HTTPS inspection!) and your NG firewall and have it try and understand MPTCP and correlate multiple streams. Try doing that with an active/active firewall cluster.

As another poster commented, we are definitely moving towards per-host IPS, hopefully in the hypervisor for your VMs.

Re:Design Issue

[petermgreen]

Lets say... a malware binary is downloaded with a dynamic load balancing across 2 tcp streams. Everything looks fine to your NG firewall, no malware detected.

Mind you the same applies if someone downloads a malware binary across an encrypted protocol

The countermeasure is to enable deep protocol inspection (and HTTPS inspection!)

To inspect https traffic you have to force proxy it. Force proxying should be an effective measure to prevent multipath TCP as well.

Re:Design Issue

[karnal]

Corporate policies can be pushed to a non BYOD device. Obviously (as you point out) the BYOD device - if it's using both paths - could be blocked on the corporate WiFi environment due to the IPS policy but continue chugging along on 4G and effectively negating the bonus of multipath.

There's never a clear solution for BYOD unless it can be centrally managed, which is the security concern for most (all?) companies, I'd think.

Re:Design Issue

[Shatrat]

What's to stop it from using only the 4G connection and being completely undetectable by the firewall/IDS/IPS? That scenario is already broken.

Re:Design Issue

[sociocapitalist]

First off, it seems unlikely as the phone will either be a corporate device, including BYOD, or a personal device. In the first case the traffic will have to flow across the network (including the firewall)

What stops a BYOD from using multipath? It will have to use the 4G connection when it isn't on the corporate wifi, so what keeps it from using both?

It's the destination that comes into play. If it's a personal destination it's not going to use the corporate network. If it's a corporate destination then it will.

If it tries to do both - ie to a personal destination across the corporate network + 4G then the firewall will drop the packets and either it won't work at all or the upper level protocol will have to realize that one path is down and not use it.

In any case, the security model is not broken.

Re:Design Issue

[TemporalBeing]

The firewall sees another TCP connection. Everything looks great.

Lets say... a malware binary is downloaded with a dynamic load balancing across 2 tcp streams. Everything looks fine to your NG firewall, no malware detected.

This is definitely a game changer. The old security inspections are successfully evaded. Add on the ability to open a stream in the opposite direction.

The countermeasure is to enable deep protocol inspection (and HTTPS inspection!) and your NG firewall and have it try and understand MPTCP and correlate multiple streams. Try doing that with an active/active firewall cluster.

As another poster commented, we are definitely moving towards per-host IPS, hopefully in the hypervisor for your VMs.

So I worked on a file transfer product some years ago that basically did the same thing - it transferred using multiple TCP connections to reliably overcome certain network conditions (e.g satcom, network drops, etc). Our clients built IDS/IPS rules to handle the whole thing without any issue, and we didn't have to provide documentation of our network protocol for them to do it. Of course, it was helped by the fact that we used the same port to open all the connections.

So ultimately I don't see this as an issue from that aspect.

What will be an issue is when people can get two disparate networks to do the transfer - e.g a previous posters WiFi+4G (cell data network) example. Even then, it won't likely be an issue.

Re:Design Issue

[Bengie]

if the firewall sees traffic it doesn't understand it's just going to drop it.

MPTCP is backwards compatible with stateful firewalls, so unless your firewall knows about MPTCP, it will think it's just another TCP stream for an unknown Layer7 protocol and nothing will look wrong.

Re:Design Issue

[sociocapitalist]

if the firewall sees traffic it doesn't understand it's just going to drop it.

MPTCP is backwards compatible with stateful firewalls, so unless your firewall knows about MPTCP, it will think it's just another TCP stream for an unknown Layer7 protocol and nothing will look wrong.

Sure, but if (due to MPTCP) the firewall only sees part of the flow (sequence number problem) or does not see the first packet of the flow as some packets are taking a path that does not flow through the firewall, it will drop the traffic.

This is why I said this whole topic is a design issue. All paths must go through the firewall or traffic will be dropped.

Heuristics

[Anonymous Coward]

My assumption is that IPS & IDS systems will have to begin accounting for forward & reverse pattern matching segments based on current rule sets to be even somewhat efficient at detecting and preventing unwanted traffic but will more than likely beging flagging valid traffic.

Network-based IPS and IDS are obsolete

[mysidia]

Security is not meant to be, and now can't be a bolt-on feature without disrupting performance of the network. Nor is security what dictates the design of your protocols --- IP traffic is not meant to be intercepted, and more and more of it is becoming encrypted. Your IDS/IPS cannot look inside SSL traffic, either, which could contain exploit code (conveniently packed and encrypted by the SSL container).

You now need to move and have multiple IDS or IPS security agents on the end devices themselves; perhaps on the NIC, where you most certainly could have access to disparate MP-TCP sessions, with some software engineering.

I'm so sorry, it seems hard that you will now need to manage 1000 IPSes on all your endpoints which is less convenient than one centralized IPS, but the centralized IPS was always a hack and likely to be compromised or circumvented, for example, by tunneling, or leveraging a secondary WiFi network, as it's a ripe target.

In principle, the only sound thing to do is going to be to move your detectors.

Re:Network-based IPS and IDS are obsolete

[Anonymous Coward]

What's the solution, convert multistreams back to a single stream to run existing network protocol shaping tools?

Re:Network-based IPS and IDS are obsolete

[amorsen]

Your IDS/IPS cannot look inside SSL traffic

Sure it can. You just push a new root certificate to your devices and intercept away.

Re:Network-based IPS and IDS are obsolete

[thermowax]

"Your IDS/IPS cannot look inside SSL traffic, either, which could contain exploit code (conveniently packed and encrypted by the SSL container)."

You might want to go read up on SSLStrip before you make that assertion. There are a bunch of other utilities that do basically the same thing, but their names escape me at the moment.

Admittedly, SSLStrip relies (generally) on the target ignoring the bad cert warning, but if you've compromised the target and inserted your root CA into the "trusted" list, well... no more warning. And, as someone else mentioned, if you're a netadmin and control the end nodes, there are lots of companies that will sell you inline appliances that will do exactly the same thing- completely transparently.

WebSense and PaloAlto 6.0- and probably others- will even let you take the cleartext off-box for DLP, or "archiving".

How much you want to bet that one of the trusted root CAs distributed with all browsers (eg, VeriSign) is an NSA plant? Trust no one.

Re:Network-based IPS and IDS are obsolete

[Anonymous Coward]

The BlueCoat appliance (which can be required for regulatory compliance) definitely will look into SSL traffic, as it actively MITMs it.

The last thing we need are IDS/IPS agents on endpoints. In the 1990s, we tried host based security, but in general, especially when Windows 98/ME machines were the staple on the desktop, it failed. So, the best bang per buck is focused on the network.

In fact, the IDS/IPS on a segment may be the -only- thing that catches some machine phoning home.

Moving the detectors is pure idiocy. First, we already have "detectors". Those are called AV programs, and they are bypassed on a minute to minute basis by the bad guys. In fact, most have a "HIPS/NIPS" feature... and gee, that seems to get bypassed.

Of course, there is going to "smart" NICs, and placing the IDS/IPS on the vPro layer or the NIC chips... but then it will encounter the same exact problems a centralized IDS/IPS does.

The fix? Whitelists of traffic, or at the minimum, having the IDS/IPS that detects multipath traffic, send an alert to pull the box from the subnet, then another alert to a person onsite to deal physically with the offending machine.

Re:Network-based IPS and IDS are obsolete

[Anonymous Coward]

perhaps on the NIC

It'll have to be higher level than that: one of the benefits is that I can use 2 separate antennae. Belongs right above the TCP stack after the streams have been interleaved, probably.

Re:Network-based IPS and IDS are obsolete

[mysidia]

Sure it can. You just push a new root certificate to your devices and intercept away.

Issuance of a bogus certificate to fool one of the parties to a SSL conversation is called a Man-in-The-Middle attack which is fraudulent conduct; pushing a fraudulently issued a certificate document claiming to be the other party and that this false thing was the other party's key.

This is nothing to base a security model on, as the attack actually compromises encrypted data --- the parties to a legitimate conversation have no way of knowing who the "security appliance" will be leaking the sensitive information contained in their encrypted conversation to.

Whoever put the code into production should be going to jail. There is no mitigating circumstance against falsely issuing a certificate and presenting it claiming to be someone else's domain name.

It doesn't matter whether you are a global CA, an Enterprise CA, or someone's given you a locally trusted root... anyone doing such is going to be going to jail, and again, nothing to base an IPS or IDS on.

Blind TCP

[Anonymous Coward]

Does it have a NetBEui service animal?

Really???

[Jaime2]

Is this article suggesting that new communication paradigms are a bad idea because the security gear optimized for the old paradigm won't work? Should we wait for the security industry to invent multipath TCP? BTW, this is the same security gear that can already be thwarted by end-to-end encryption. How is this any different?

Re:Really???

[jrumney]

BTW, this is the same security gear that can already be thwarted by end-to-end encryption. How is this any different?

It's different because the agencies with security as their middle name don't have a backdoor for this.

For actual security purposes, making sensitive data more difficult to spy on is a feature.

Re:Really???

[BitZtream]

... Right, because they can't just recombine the data from their multiple taps back in their data center.

Because ... they don't do this already to correlate data from different single path streams or anything ...

Those agencies will have no problem for dealing with this particular issue.

Re:Really???

[Jaime2]

It's different because the agencies with security as their middle name don't have a backdoor for this.

That's why I was careful to say "end-to-end encryption" instead of "https". If you aren't using the public CA infrastructure, your data may be private.

Re:Really???

[Anonymous Coward]

The article is only looking at security from one point of view. Hell, when I read the article, I replaced security with advertising and profiling. DPI is used far more against users than for users.

Already an issue

[Anonymous Coward]

Async routing happens all the time and is already an issue. This shouldn't hold up the benefits that multipath tcp would give us. /sigh

Three duh's from the article:

[malakai]

Three duh's from the article:

Trust models users and networks have fostered with Internet providers are also changed—and in some cases broken. Contrary to that, providers will no longer be able to sniff traffic—under court order for example—unless they work hand in hand with other providers handling split traffic sessions.

They lost me at "Trust models users .... have fostered with Internet providers".... Duh.

“Technology like MPTCP makes it much harder for surveillance states,” Pearce said. “If I split traffic across my cell provider and an ISP I may not trust, in order for a surveillance state to snoop they have to collaborate with all these parties. It’s a much harder proposition.”

Who cares? And if you really care enough, and you are a suveilance state, you can sniff from the soruce, or a common route in between in which all the data flows. Will you have to spend a little extra CPU and Memmory to piece together the full stream? yeah, duh.

Finally, Pearce said, there will be ambiguity for firewalls about what incoming and outgoing traffic looks like. She said that MPTCP enables endpoints to tell servers there are other addresses to which the server may connect, but the firewall may not necessarily interpret that as an outgoing connection.

And not very hard to fix for the firewall vendors. Will you have to patch your FW? Probably. Is that a problem? No, duh.

Re:Three duh's from the article:

[flyingfsck]

Exackitilly - trunking, traffic shaping and load sharing has been with us since the age of the dinosaurs. Reordering packets to assemble a stream from multiple routes is not a big deal.

Re:Three duh's from the article:

[MightyMartian]

Christ, it was one of the first lessons I learned that one could not simply sniff incoming packets and assume there was any order to them. People have been writing UDP protocols for decades now that require reassembly of packets into proper order.

I get that multipath TCP means a lot more traffic will be sent in odd fashion, but really, if the recipient TCP stack can grab and reorder them, then that's what counts.

Re:Three duh's from the article:

[Bengie]

With a 40Gb stream, there is about 5MB of data per millisecond. You're going to need some large network buffers to handle out of order packets.

The biggest issue is you went from firewalls that didn't need to know about each other's state to not only sharing state, but every packet. Essentially you went from a lock-free design to a giant lock.

I assume this would be way too much load for the firewalls, so you'd be better off mirroring all edge traffic to a central server to demultiplex the streams. Imagine you're a company with several 100gb connections, with a total of 1tb of bandwidth, and you have a central server that needs to somehow handle 1tb of mirrored packets getting forwarded to it. That'll be interesting.

Not a design issue, it's a game changer

[Anonymous Coward]

You seem to have missed the ability to open a connection in the reverse direction.

This is a game changer that breaks existing stream engines.

exposes leaves

[Anonymous Coward]

typo

These assumptions were never valid actually

[exabrial]

And it's stupid to assume they still are. An IP address is _not_ an identity, even in IPv6.

Vendors need to get a clue

[WaffleMonster]

I am sick of IDS/firewall vendor corner cutting and laziness being wielded as an excuse to impede progress or otherwise nerf IP.

This is the same cast of characters who get caught naively mishandling IP layer fragmentation, option headers and hell even nested 802.1q.

Instead of owning up to it sit there like a bunch of two year olds and either complain their jobs are too hard or have the audacity to throw their weight at nerfing protocols themselves.

If people think multipath TCP is useful then they will deploy it and if IDS/firewall vendors don't step up with solutions they can step aside as their competitors win over their business.

The real security issue...

[Anonymous Coward]

...is that the traffic is not always encrypted & secured end-to-end.

Security is subjective

[Anonymous Coward]

Today's IDS and IPS, for example, cannot correlate and re-assemble traffic as it's split over multiple paths

It sounds like things have become more secure. If a middleman can do things like that, you've got a vulnerability that needs to be fixed.

It's all about your point of view. If you and I are adversaries, then things that make me more secure, make you less secure, and vice-versa.

Cap

[tepples]

What stops a BYOD from using multipath?

The 4G carrier's monthly cap.

Good.

[Anonymous Coward]

This is by design. Middleboxes are now potential attackers, and are not our friend.

Which are the appropiate places?

[gwolf]

Of course, this technology is just begging the Tor network to adopt it!

Endpoint security FTW!

[eyegone]

Hopefully this will lead to an increased emphasis on endpoint security, rather than the current "we have firewalls" attitude that's far too pervasive.

(For people who actually care about real security, that is. I've got no sympathy for those who just want to control/censor/monitor Internet traffic.)

I break that easily (before you can get it)... apk

[Anonymous Coward]

"Lets say... a malware binary is downloaded with a dynamic load balancing across 2 tcp streams. Everything looks fine to your NG firewall, no malware detected." - by Anonymous Coward on Friday August 01, 2014 @10:15AM (#47581081)

I block the sources of said malware BEFORE you can get them via APK Hosts File Engine 9.0++ 32/64-bit http://start64.com/index.php?o... & even *IF* you had it "inside already", cutting off communication "back to malware HQ" is impossible also (especially for the most advanced types of botnets, ala "DGA", "FastFlux", & DynDNS utilizing types which have HEAVY DEPENDENCY on host-domain names, which of course, hosts block perfectly!)

APK

P.S.=> After all: "Prevention IS the best medicine" & the cure? Gotta do it, as-per-usual is above, ala -> "The premise is quite simple: Take something designed by nature & reprogram it to make it work for the body rather than against it..." - Dr. Alice Krippen: "I am legend"

...apk

Absolutely (been @ it for decades since 1997)

[Anonymous Coward]

Per my latest creation (which stalls 1 point others made here on botnet design) -> http://tech.slashdot.org/comme...

AND (per my subject-line above), these security guides I wrote (which originated on NTCompatible.com in 1997 & grew to their current versions shown in the link next (all about "layered-security"/"defense-in-depth", for ENDPOINTS on PC desktops) -> http://www.bing.com/search?q=%... )

APK

P.S.=> It works... apk

So, Where are the vulnerabilities?

[Anonymous Coward]

Seems to me that having multiple paths carrying various pieces of a data stream would actually provide much better security. There is no man-in-the-middle attack vulnerabilities. BTW - Delangis has three patents on this technology dating back to 2002. Check out U.S. Patents 7606156 and 8228801 for starters.

Security Trying To Hold Back Progress, Again

[Zan Lynx]

So here we have security vendors trying YET AGAIN to hold back progress in Internet protocols. They did it with window scaling, ECN and IPv6. Each new invention doesn't work with their snake oil so they either disable it or tell people not to use it.

They like to lock down HTTP too, preventing anything that doesn't "look right." As if a server would respond to PUT or OPTION if it didn't intend to support that.

Enven better!

[Anonymous Coward]

who cares IDS stop working!

Breaks Traffic Inspection ?

[Pascal Sartoretti]

From TFA : Breaks Traffic Inspection

One good reason to use it !