[multipathtcp] MPTCP backup flag attack via MP_PRIO message

[Zhiyun Qian <[e-mail]>]

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-connection’s 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