Subject: [rtcweb] DoS attack despite ICE/STUN consent verification

From: Magnus Westerlund <[email-masked]>
Date: Wed, 1 Feb 2012 14:31:13 -0800

Hi,

As I brought up in yesterdays meeting I think there exist an attack that
should be considered. I don't think it is super strong, but not without
issues.

Setting:

Webserver is evil and have a target Alice. Alice can be a legacy device,
like a SIP/SDP video phone. It knows the target is doing ICE and have
Alice's ufrag and password and candidates. The server would like to
hammer this target by utilizing its set of connected WebRTC clients
(bob, charlie etc.). Thus it would like to ensure that it gets the
browser to start sending RTP media when creating a PeerConnection in the
clients.

So the server gets the client to open PeerConnections towards the ICE
parameters from the target (Alice).

In default ICE behavior there is an optimization to allow the Offerer
(Alice) to respond to STUN binding requests from Bob without having
received an SDP answer from Bob. The STUN binding request must only have
the Alice's ufrag and its password. This enables that Webrtc clients can
get passed the data consent step with ICE capable end-point for which
the ICE parameters can be retrieved.

So from Alice perspective this attack will look like its offer got
forked to many peers based on the many different peers that send STUN
messages. The webserver could even provide SIP/SDP answers to alice with
the webclients. But that is not necessary but is one variation of this.

So what are the mitigations.

A) If Alice receives SIP/SDP answers it can start triaging the many
response and decide which it shouldn't answer to based on SIP/SDP
information and the ignore in STUN layer based on the far side ufrag.

B) Alice can stop answering to the STUN binding requests. However, that
opens her up to denial of service attack if the method for Evil to
acquire here ICE parameters is to snoop a legitimate intentional call.
By not responding to a STUN binding response from different peers after
having seen N peers allows evil to block the intended call. This
mitigation may not work in cases where we can't enforce the browser to
generate the ufrag on the WebRTC client side. Like what I objected to
allow the ICE parameters to be set by SetLocalDescription.

C) Continued Data consent: This can work but each WebRTC client will
send for 30 s at least until it stops sending. The reason it may work is
that default SIP/SDP ICE capable end-points may not support STUN binding
responses during the call as that is not specified. It may however work
if the implementation doesn't intentionally blocks binding responses
after ICE processing has ceased. If Alice intentionally wants to block
the media flows it can ensure that it doesn't send.

D) RTP media adaptation / Congestion control. Alice can either refuse to
send RTCP feedback or intentional feedback to reduced the transmission
rate to a minimal. However, there is some lower limit where just basic
probing traffic, low rate audio is sent over the media channel. However,
it is not certain that this stops media transmission completely.

E) If DTLS-SRTP is used then that handshake must complete. So if Alice
doesn't support DTLS-SRTP it will not answer, thus preventing the WebRTC
client to start sending media. If alice supports DTLS-SRTP then alice
has some potential to refuse to respond based on the WebRTC clients used
certificate. However, if it doesn't check that against an answer in the
middle of the DTLS handshake, the WebRTC client could succeed in the
DTLS-SRTP keying and start sending media, while Alice realizes that this
is not the client it wants to talk to.

So from my perspective, this is an attack that provides some potential
for an overload / denial of service attack on Alice with the benefit
that the one generating the traffic to Alice is the WebRTC clients. It
will require some work from the webserver to keep the clients connect to
some ICE candidate address which they expose or can get to expose.

Comments on the strength of the attack and the weakness/strengths of the
mitigations

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 1 Feb 2012 15:13:20 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Magnus Westerlund
> Sent: Wednesday, February 01, 2012 2:31 PM
> To: [email-masked]
> Subject: [rtcweb] DoS attack despite ICE/STUN consent verification
> 
> Hi,
> 
> Webserver is evil and have a target Alice. Alice can be a legacy
> device, like a SIP/SDP video phone. 

Today I believe we reached tentative consensus to use un-authenticated
STUN connectivity checks for 'continued consent' every 30 seconds.  This 
means an un-modified legacy device, such as Alice, will not authenticate 
those incoming STUN connectivity checks (because they are not 
authenticated) and will not respond to them.  So, media will cease after 
30 seconds --completely unrelated to the attack described in this email.

So, I believe for Alice to work at all, Alice needs:

  * a slight upgrade, so Alice responds to the 'continued consent'
    connectivity checks.

  * a media-handling device in front of her (e.g., SBC)
    to handle the 'continued consent' connectivity checks on
    her behalf.

  * a way to signal in SDP that 'continued consent' messages need 
    to be authenticated (or, rather, we need a way to indicate in
    SDP that the 'continued consent' messages can be unauthenticated).

> It knows the target is doing ICE and have

That mitigation does not help much, because the attacker can cause 
Bob, Charlie, etc., to all send back SIP answers and all send ICE 
connectivity checks.

> acquire here ICE parameters is to snoop a legitimate intentional call.

http://tools.ietf.org/html/rfc5245#section-18.4 suggests that signaling
be encrypted with TLS (it says "SIPS") to protect against that attack.

> doesn't support DTLS-SRTP it will not answer, thus preventing the
> WebRTC client to start sending media.

That somewhat depends on if we decide to allow RTP, and if the
attackers (Bob, Charlie, etc.) have RTP media to send.  

(Note:  By allowing RTP, or allowing SDESC-keyed SRTP, we avoid 
  one of the worries of DTLS-SRTP which is its delayed media
  establishment (due to additional round trips of DTLS).  But we
  also increase complexity.  Just something I thought I might throw
  into this thread.)

> If alice supports DTLS-SRTP then alice

If Bob, Charlie, etc., all send back SDP Answers, Alice will most
responsibly do DTLS-SRTP handshakes with all of them -- in order
to reduce the eventual media cut-through delay.

What is said now, about Alice's expected behavior in that
regard, is http://tools.ietf.org/html/rfc5763#section-6.2

> Comments on the strength of the attack and the weakness/strengths of
> the mitigations

It seems a legacy device, Alice, cannot work without software upgrade
or a media device in front of it.  

I don't have any great ideas to solve the attack, though.  Will think
about it more.

-d

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 1 Feb 2012 18:06:37 -0800

> 30 seconds --completely unrelated to the attack described in this email.

Yes, I think that is the most likely. Unless Alice has done a poor
implementation and left her STUN servers with configured ufrag and
password after the ICE processing concluded.

Secondly, I think 30 seconds of media gives a reasonably high
amplification factor.

>     SDP that the 'continued consent' messages can be unauthenticated).

My point is that Alice is not supposed to accept this media data as they
where not intended to communicate with the WebRTC client. That is a
result of the evil webserver's attack.

But, if they where intending to communicate I agree that something like
what you list would be needed.

> be encrypted with TLS (it says "SIPS") to protect against that attack.

Yes, agreed. However, there seems to be multiple methods to get hold of
Alice's ICE parameters. Different depending on Alice role and
communication patterns.

One is clearly to snoop the SIP communication.

Another is to actually start up a call with Alice.

>   also increase complexity.  Just something I thought I might throw

Yes, I however wanted to point out that DTLS-SRTP is a second barrier
for consent establishment prior to media transmission. If one has plain
RTP then media transmission could start directly after ICE nominates the
candidate pair to Alice.

> regard, is http://tools.ietf.org/html/rfc5763#section-6.2

Yes, and this points to a security issue that needs to be specifically
discussed in the context of WebRTC.

> or a media device in front of it.  

I think it does in fact works in the sense that one may end up in a
state where RTP media flows to a legacy device without actually having
provided the level of consent that we desire for WebRTC due to the early
media optimizations in these end-points.

> I don't have any great ideas to solve the attack, though.  Will think

Thanks, for the feedback.

Cheers

Magnus Westerlund

---

From: Randell Jesup <[email-masked]>
Date: Fri, 03 Feb 2012 14:19:24 -0500

If we require WebRTC-enabled gateways to connect to "legacy" 
devices/gateways, then continuing consent is something that could be 
dealt with via an SCTP HEARTBEAT, instead of un-authenticated STUN 
connectivity checks.  This would require an SCTP association to be 
created at each PeerConnection connection, but the SCTP handshake 
probably could be backgrounded and not slow down the connection process.

(We'll probably want that backgrounding of SCTP handshake anyways, in 
order to open media channels ASAP.)

This of course only handles continuing consent (and keeping the port 
propped open) only in the case of a native PeerConnection connection, 
not any form of interop to "legacy" devices, and having a second 
mechanism may not make sense if we end up connecting directly, so this 
ties into the DTLS-SRTP vs SDES vs plain-RTP discussion.  If the answer 
is DTLS-SRTP, then we have to decide if we expect to be able to talk to 
a non-WebRTC client that supports DTLS-SRTP (and ICE) directly.  If the 
answer is "only directly to WebRTC clients", then this is a good option; 
if the answer is not that (or if SDES/plain RTP is needed), then this 
could not be the only mechanism, which reduces the utility (though 
perhaps not to zero).

There's a minor plus to having the association already created if we 
want to add data channels, but that's quite minor.

Just a thought while reading SCTP specs...

-- 
Randell Jesup
[email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Feb 2012 11:44:24 -0800

On 3 February 2012 11:19, Randell Jesup <[email-masked]> wrote:
> continuing consent is something that could be dealt
> with via an SCTP HEARTBEAT

I don't see why you would want to create a data channel without having
been asked for one.  And the cost of supporting the data channel on a
legacy gateway that isn't using the data stream seems a little
excessive.

--Martin

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 3 Feb 2012 20:57:50 +0100

On Feb 3, 2012, at 8:19 PM, Randell Jesup wrote:

> If we require WebRTC-enabled gateways to connect to "legacy" devices/gateways, then continuing consent is something that could be dealt with via an SCTP HEARTBEAT, instead of un-authenticated STUN connectivity checks.  This would require an SCTP association to be created at each PeerConnection connection, but the SCTP handshake probably could be backgrounded and not slow down the connection process.
> 
> (We'll probably want that backgrounding of SCTP handshake anyways, in order to open media channels ASAP.)
> 
> This of course only handles continuing consent (and keeping the port propped open) only in the case of a native PeerConnection connection, not any form of interop to "legacy" devices, and having a second mechanism may not make sense if we end up connecting directly, so this ties into the DTLS-SRTP vs SDES vs plain-RTP discussion.  If the answer is DTLS-SRTP, then we have to decide if we expect to be able to talk to a non-WebRTC client that supports DTLS-SRTP (and ICE) directly.  If the answer is "only directly to WebRTC clients", then this is a good option; if the answer is not that (or if SDES/plain RTP is needed), then this could not be the only mechanism, which reduces the utility (though perhaps not to zero).
> 
> There's a minor plus to having the association already created if we want to add data channels, but that's quite minor.
> 
... or you could use DTLS HEARTBEATS as specified in
http://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-04
which is currently in AUTH48 and implemented in OpenSSL 1.0.1 (currently in beta2).

This does not require the setup of a DATA channel, but does only work if you have
DTLS. So it applies to DTLS-SRTP, not to SDES.

On the other hand, I agree: Setting up the SCTP association as soon as possible,
minimizes the setup time of the data channel.

Maybe another issue (I'm not that familiar with media transport (especially video):
Does the media channel need path MTU discovery? It is clear that this is needed by
the data channel and SCTP provides it. But how is it done if it is needed also
by the media channel?

Best regards
Michael

---

From: Oscar Ohlsson <[email-masked]>
Date: Mon, 6 Feb 2012 11:19:21 +0100

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: den 1 februari 2012 23:31
> To: [email-masked]
> As I brought up in yesterdays meeting I think there exist an 
> attack that should be considered. I don't think it is super 
> strong, but not without issues.
> 
> Setting:
> 
> Webserver is evil and have a target Alice. Alice can be a 
> legacy device, like a SIP/SDP video phone. It knows the 
> target is doing ICE and have Alice's ufrag and password and 
> candidates. The server would like to hammer this target by 
> utilizing its set of connected WebRTC clients (bob, charlie 
> etc.). Thus it would like to ensure that it gets the browser 
> to start sending RTP media when creating a PeerConnection in 
> the clients.
> 
> So the server gets the client to open PeerConnections towards 
> the ICE parameters from the target (Alice).
> 
> (Alice) to respond to STUN binding requests from Bob without 
> having received an SDP answer from Bob. The STUN binding 
> request must only have the Alice's ufrag and its password. 
> This enables that Webrtc clients can get passed the data 
> consent step with ICE capable end-point for which the ICE 
> parameters can be retrieved.
> 
> So from Alice perspective this attack will look like its 
> offer got forked to many peers based on the many different 
> peers that send STUN messages. The webserver could even 
> provide SIP/SDP answers to alice with the webclients. But 
> that is not necessary but is one variation of this.

Correct me if I'm wrong, but I believe the webserver must provide the SIP/SDP answers. As far as I can tell there are always two connectivity checks, one for each direction (Section 2.2 RFC 5245):

   L                        R
   -                        -
   STUN request ->             \  L's
             <- STUN response  /  check

              <- STUN request  \  R's
   STUN response ->            /  check

Alice would automatically respond to the remote side's check. However, in order to genereate her own check (R's check in the diagram) she would need to have received the remote side's password. According to Section 7.1.2.3. in RFC 5245:

"A connectivity check from R to L utilizes the username LFRAG:RFRAG and a password of LPASS."

If this interpretation is correct then counter-measure A below would always be a possibility.

> A) If Alice receives SIP/SDP answers it can start triaging 
> the many response and decide which it shouldn't answer to 
> based on SIP/SDP information and the ignore in STUN layer 
> based on the far side ufrag.
> 
> B) Alice can stop answering to the STUN binding requests. 
> However, that opens her up to denial of service attack if the 
> method for Evil to acquire here ICE parameters is to snoop a 
> legitimate intentional call.
> By not responding to a STUN binding response from different 
> peers after having seen N peers allows evil to block the 
> intended call. This mitigation may not work in cases where we 
> can't enforce the browser to generate the ufrag on the WebRTC 
> client side. Like what I objected to allow the ICE parameters 
> to be set by SetLocalDescription.
> 
> C) Continued Data consent: This can work but each WebRTC 
> client will send for 30 s at least until it stops sending. 
> The reason it may work is that default SIP/SDP ICE capable 
> end-points may not support STUN binding responses during the 
> call as that is not specified. It may however work if the 
> implementation doesn't intentionally blocks binding responses 
> after ICE processing has ceased. If Alice intentionally wants 
> to block the media flows it can ensure that it doesn't send.
> 
> D) RTP media adaptation / Congestion control. Alice can 
> either refuse to send RTCP feedback or intentional feedback 
> to reduced the transmission rate to a minimal. However, there 
> is some lower limit where just basic probing traffic, low 
> rate audio is sent over the media channel. However, it is not 
> certain that this stops media transmission completely.
> 
> E) If DTLS-SRTP is used then that handshake must complete. So 
> if Alice doesn't support DTLS-SRTP it will not answer, thus 
> preventing the WebRTC client to start sending media. If alice 
> supports DTLS-SRTP then alice has some potential to refuse to 
> respond based on the WebRTC clients used certificate. 
> However, if it doesn't check that against an answer in the 
> middle of the DTLS handshake, the WebRTC client could succeed 
> in the DTLS-SRTP keying and start sending media, while Alice 
> realizes that this is not the client it wants to talk to.
> 
> So from my perspective, this is an attack that provides some 
> potential for an overload / denial of service attack on Alice 
> with the benefit that the one generating the traffic to Alice 
> is the WebRTC clients. It will require some work from the 
> webserver to keep the clients connect to some ICE candidate 
> address which they expose or can get to expose.
> 
> Comments on the strength of the attack and the 
> weakness/strengths of the mitigations
> 
> Cheers
> 
> Magnus Westerlund
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 6 Feb 2012 15:27:52 +0100

On 2012-02-06 11:19, Oscar Ohlsson wrote:
> Correct me if I'm wrong, but I believe the webserver must provide the
SIP/SDP answers. As far as I can tell there are always two connectivity
checks, one for each direction (Section 2.2 RFC 5245):

>    L                        R
>    -                        -
>    STUN request ->             \  L's
>              <- STUN response  /  check
> 
>               <- STUN request  \  R's
>    STUN response ->            /  check
> 
> Alice would automatically respond to the remote side's check.
> However, in order to genereate her own check (R's check in the
> diagram) she would need to have received the remote side's password.
> According to Section 7.1.2.3. in RFC 5245:
> 

Oscar,

>From L's perspective, the process of nomination and validation can
complete without R having succeeded. Thus L (WebRTC Browser) can start
send media to R without R having successfully validated any return path
from R to L.

Thus, I don't see how A could be made to reliably work as a mitigation.

In addition are there anyone who actually have this type of attack
protection in their SIP stacks or SIP proxies?

Cheers

Magnus Westerlund