Re: [multipathtcp] MPTCP backup flag attack via MP_PRIO message

Hi Zhiyun,

Please bear in mind that the goal of MPTCP with respect to security, as discussed in the original architectural design in RFC6182, is to provide a security model no worse than TCP. So whilst this attack would be possible, it can only be done by an on-path attacker, and if succeeded would allow the on-path attacker to intercept all traffic. Which would be the same for a single-path TCP connection on the same path.

As a side point, the same kind of attack could be launched via REMOVE_ADDR messages, but this would not succeed since this is specified with some protection - ensuring the subflow is really unavailable through the use of TCP keepalive signals. This same protection cannot be used against the MP_PRIO since the referenced subflow is not unavailable.

If the WG considered this risk worth addressing, we could look at adding a nonce + signature to MP_PRIO.

Regards,
Alan

> On 20 Jul 2017, at 08:28, Zhiyun Qian <zhiyunq@cs.ucr.edu> wrote:
> 
> Dear all,
> 
> We are a group of researchers (cc:ed on the email) who recently
> discovered a security flaw in the MP_PRIO messge that allows a
> man-in-the-middle attacker on a single path to divert all traffic to
> its own path, effectively hijacking the entire MPTCP connection. Below
> we describe the problem in brief (more details will be found in our
> upcoming ICNP paper. We also hope to submit an Internet draft soon).
> We thank Olivier Bonaventure for his valuable feedback.
> 
> ---------------------------------------------------------------
> 
> MPTCP supports using sub-connections as backup  i.e., using a
> sub-connection to send data only if there is no other sub-connection
> available. Specifically, an MPTCP host can send a request to the other
> host to set any sub-connection as a backup by using the MPTCP MP_PRIO
> option. Hosts can request change in the priority to use a
> subconnection as regular or backup.  To set a sub-connection as
> backup, a host can request a change in the sub-connection priority by
> sending MPTCP MP_PRIO option to the other host with the corresponding
> address identifier. The key property of MP_PRIO messages is that they
> can be sent on any sub-connection. The reason is that if a
> sub-connection is already congested, it may not be possible to deliver
> the message to pause itself. After receiving such a control packet,
> the sender will stop sending data and the corresponding
> sub-connections throughput will drop to zero.
> 
> Unfortunately, unlike MP_JOIN, such a MP_PRIO option has no
> authentication required by the specification whatsoever, allowing an
> attacker controlling only one path to set any sub-connection as backup
> and launch traffic divergence and connection hijack attacks. The
> backup flag vulnerability allows an attacker to divert traffic among
> MPTCP sub-connections. An attacker can offload traffic from the
> eavesdropped sub-connection to other MPTCP sub-connections by sending
> forged packets with the MP_PRIO option to set the eavesdropped
> sub-connection as a backup. An attacker can also onload traffic from
> non-eavesdropped sub-connections to the eavesdropped sub-connection by
> sending forged packets with the MP_PRIO option to set all other
> sub-connections as backup. This attack is similar to connection hijack
> attack, where an attacker diverts all the traffic to pass through the
> sub-connection on the eavesdropped path.
> 
> 
> Connection Hijack Example:
> 
> Consider a scenario where two sub-connections of an MPTCP connection
> pass through paths p1 and p2. An attacker can hijack the
> non-eavesdropped subconnection on p2 by dynamically changing the
> priority of a sub-connection and declaring it as backup.
> 
> To launch this attack an attacker only needs to know the address
> identifier of the host , which can be obtained by eavesdropping other
> paths or easily guessed as they are set incrementally in current Linux
> implementation of MPTCP. Since the identifier has only 8 bits, it can
> even be brute forced. To set a non-eavesdropped sub-connection as
> backup between hosts A and B, an attacker can request a change in the
> sub-connection priority by sending MPTCP MP_PRIO option to host B with
> the address identifier of host A. Since by design the MP_PRIO messages
> can be sent on any sub-connection, the attacker eavesdropping on any
> path capable of sending such a forged backup message can pause any
> other path. Note that a backup MPTCP sub-connection may still be used
> for data transmission later, which can be detected by the attacker by
> observing the overall MPTCP throughput.
> 
> Effectively, this attack degrades an MPTCP connection to a regular TCP
> connection as all traffic will be routed through the
> attacker-controlled path. We argue that this vulnerability makes MPTCP
> less secure than TCP, because the entire MPTCP connection can be
> compromised (fully controlled by an attacker) as long as any one of
> the communication paths is compromised. Unfortunately, MPTCP
> specification does not include any authentication mechanism whatsoever
> regarding the MP_PRIO message.
> 
> We discuss several solutions in a forthcoming paper [ICNP2017], but a
> simple approach to cope with this attack would be to reconsider the
> utilisation of the address identifier in the MP_PRIO option. This
> option allows a host to set/change the priority of all the subflows
> associated to a given address identifier on another subflow. It could
> have use cases, such as sending MP_PRIO over a WiFi subflow to put the
> cellular subflow in backup mode without sending a packet over the
> cellular interface, but this looks like an edge case. Looking at the
> attack that we have identified, the working group should evaluate the
> removal of the address identifier in rfc6824bis. If the MP_PRIO option
> does not include an address identifier, then it becomes impossible for
> an attacker who is on-path of a given subflow to change the priority
> of the other subflows.
> 
> Best,
> -Zhiyun
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp