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

[Zhiyun Qian <[e-mail]>]

Hi Alan,

I'd argue this vulnerability does make MPTCP worse than TCP in the
sense of increased risk or attack surface:

The key problem is that this vulnerability allows an attacker on *any*
path to direct all traffic in other paths to the path it sits on. In
contrast, for TCP the attacker has to sit on *a specific* path to be
able to observe and control all traffic.

-Zhiyun


On Thu, Jul 20, 2017 at 8:00 AM, Alan Ford <[e-mail]> wrote:
> 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 <[e-mail]> 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-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
>>
>> _______________________________________________
>> multipathtcp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/multipathtcp
>