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

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Mar 2012 14:24:55 -0700

I want to make sure I understand this attack correctly.

Alice is making a call to Zed and either Zed is the attacker or the attacker
somehow captures Alice's media parameters. The attacker then uses
Alice's offer (and her parameters) to start ICE handshaking on a pile
of Web browsers that he controls. They all start ICE and since the
checks with Alice will succeed, then the attacker has apparent consent
to send as much traffic as he wants to Alice from each machine.
Do I have this right?

If I understand this correctly, then the severity of the attack seems to
be limited since Alice has to actually be calling someone that is
malicious or that has very tight control of the network, and soon
after Alice hangs up the phone, the problem goes away. (Assuming
consent freshness).

As Dan notes, the interaction with consent freshness seems like a key
mitigation here. Moreover, I think this suggests that even if integrity
is not used, as in draft-muthu, the ufrags should both be present
(and unmodifiable from the JS). This would allow a client to discard
ICE associations with ufrags that do not match whichever ICE
association got selected for the call.

-Ekr

On Mon, Feb 6, 2012 at 6:27 AM, Magnus Westerlund
<[email-masked]> wrote:
> On 2012-02-06 11:19, Oscar Ohlsson wrote:
>>
>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Magnus Westerlund
>>> Sent: den 1 februari 2012 23:31
>>> To: [email-masked]
>>> Subject: [rtcweb] DoS attack despite ICE/STUN consent verification
>>>
>>> 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.
>>
>>
>> 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.
>>
>
> 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
>
> ----------------------------------------------------------------------
> 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]
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Mar 2012 14:30:12 -0700

I should also mention that the users will of course have to have
given the attacker's site media access--at least for legacy SIP
clients, the attempt by the zombies to form SCTP-over-DTLS
associations will fail and therefore the data channel cannot
be used here.

-Ekr

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 12 Mar 2012 23:41:55 +0100

Hi,

Yes, your understanding appears correct. I was maybe more considering of
using this attack against SIP clients, especially the kind that can't
move out of the way easily. Like call centers etc. In that context being
able to direct a 1 mbps video stream onto a audio receiver works
excellent if your goal is to just DoS the path.

But I do agree that consent freshness appears to be an important method
for mitigating this. It also seems to create a requirement on that
mechanism. It can't be something that the far end can trick the target
end-point to generate just by default. It needs to be something where
the end-point takes a decision to respond to each.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Mar 2012 15:43:58 -0700

> excellent if your goal is to just DoS the path.

Yep. Though of course in the specific case of a call center, since it
auto-answers you can just mount the attack with independent calls....

> the end-point takes a decision to respond to each.

Yeah. :(
Maybe you, I, Dan, and anyone else who is interested can brainstorm
on this a bit in Paris.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Mar 2012 08:19:18 -0700

Temporary Maximum Media Stream Bit Rate Request (TMMBR, RFC5104)
should address the concerns with bandwidth exceeding expected limits.
That is, if this can be mandated (see below).

Rate limiting ICE nominations should limit the number of hosts that
can send media.  That is, you might have to limit the rate at which
your peer can appear to "move".  Then you only expose yourself to
something like ceil((time between "moves" + 1) / (maximum time between
consent checks, including timeout)) times the bandwidth that a host
can generate in your direction.  In order to do so, you have to fail
to respond to (nominating) connectivity checks under certain
conditions.

All this gets much more sticky and disgusting if you can't reasonably
mandate TMMBR and especially consent freshness checking.  If you are
expecting a SIP end host to be able to take media directly from
browsers - without supporting any of these features - then let the
brainstorming begin.

--Martin

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 13 Mar 2012 12:46:30 -0400

My major question on this thread, which I have been watching with interest:

Why do we care about a DoS attack  against a single client?  (I mean 
specifically DoS, not any other security attack.)

It appears to me that there are somewhat simpler and more effective DoS 
methods for this case: 1) cut the wire to the client's device or 2) jam 
WiFi or other wireless signal.

Or did I misunderstand the problem?

Igor

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Mar 2012 11:02:17 -0700

> specifically DoS, not any other security attack.)

The concern here is that it isn't that hard to get someone to visit
your website.  By the same token, it should be easy to get someone to
call (you).

Once that "call" is up, you can direct the media anywhere.  However,
if the source of the media has some incentive to not send media - and
browsers certainly do - then they want to check that their media is
acceptable before sending it.  Hence the consent mechanisms.

That adds an another challenge: how do you get the target to consent
to receipt of media from your drones?  Obviously, if they consent to
receiving one call, and you can use that to launch the media from
multiple calls toward them, then you have an attack.

> methods for this case: 1) cut the wire to the client's device or 2) jam WiFi
> or other wireless signal.

Stabbing your target with a knife also serves as a reasonable DoS
method too.  It's all about finding an appropriate defense for
plausible threats.

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 13 Mar 2012 15:27:25 -0400

On 3/13/2012 2:02 PM, Martin Thomson wrote:
> ...

Well, this was one option I decided not to list... :)

But, really, I just don't see a reason why anyone would want to waste 
resources on a DoS attack against a /person/.
I am sure I am missing a bigger picture.  I am also sure, I will start 
understanding these things better after a drink or two, or three.

To this end, Eric, please count me among the interested parties  for the 
off-line discussion in Paris!

Igor

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Mar 2012 14:04:35 +0100

Hi,

>> Yes, your understanding appears correct. I was maybe more considering 
>> of using this attack against SIP clients, especially the kind that 
>> can't move out of the way easily. Like call centers etc. In that 
>> context being able to direct a 1 mbps video stream onto a audio 
>> receiver works excellent if your goal is to just DoS the path.
>
> Yep. Though of course in the specific case of a call center, since it auto-answers you can just mount the attack with independent calls....
>
>> But I do agree that consent freshness appears to be an important 
>> method for mitigating this. It also seems to create a requirement on 
>> that mechanism. It can't be something that the far end can trick the 
>> target end-point to generate just by default. It needs to be something 
> where the end-point takes a decision to respond to each.
>
> Yeah. :(
> Maybe you, I, Dan, and anyone else who is interested can brainstorm on this a bit in Paris.

I would also be interested to participate in such brainstorming.

Regards,

Christer

>> Alice is making a call to Zed and either Zed is the attacker or the 
>> attacker somehow captures Alice's media parameters. The attacker then 
>> uses Alice's offer (and her parameters) to start ICE handshaking on a 
>> pile of Web browsers that he controls. They all start ICE and since 
>> the checks with Alice will succeed, then the attacker has apparent 
>> consent to send as much traffic as he wants to Alice from each machine.
>> Do I have this right?
>>
>> If I understand this correctly, then the severity of the attack seems 
>> to be limited since Alice has to actually be calling someone that is 
>> mitigation here. Moreover, I think this suggests that even if 
>> integrity is not used, as in draft-muthu, the ufrags should both be 
>> present (and unmodifiable from the JS). This would allow a client to 
>> discard ICE associations with ufrags that do not match whichever ICE 
>>>>> 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).
>>>>>
>>>>> 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.
>>>>
>>>>
>>> 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
>>>>
>>>> If this interpretation is correct then counter-measure A below 
>>>> would always be a possibility.
>>>>
>>>
>>> Oscar,
>>>
>>> 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.
>>>
>>> --------------------------------------------------------------------
>>> -- Multimedia Technologies, Ericsson Research EAB/TVM
>>> --------------------------------------------------------------------
>>> -- Ericsson AB                | Phone  +46 10 7148287 Färögatan 6                
>>> | Mobile +46 73 0949079
> Ericsson AB                | Phone  +46 10 7148287 Färögatan 6                
> | Mobile +46 73 0949079

---

From: Oscar Ohlsson <[email-masked]>
Date: Thu, 15 Mar 2012 16:12:15 +0100

> > Yep. Though of course in the specific case of a call 
> center, since it auto-answers you can just mount the attack 
> with independent calls....
> >

I would also like to join.

Regards,

Oscar Ohlsson

> >>>> Correct me if I'm wrong, but I believe the webserver 
> must provide 
> >>>> the

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 15 Mar 2012 21:24:47 +0530

|Maybe you, I, Dan, and anyone else who is interested can 
|brainstorm on this a bit in Paris.

I would be interested..please count me in.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Rescorla
|Sent: Tuesday, March 13, 2012 4:14 AM
|To: Magnus Westerlund
|Cc: [email-masked]
|Subject: Re: [rtcweb] DoS attack despite ICE/STUN consent verification
|
|On Mon, Mar 12, 2012 at 3:41 PM, Magnus Westerlund
|<[email-masked]> wrote:
|> Hi,
|>
|> Yes, your understanding appears correct. I was maybe more considering of
|> using this attack against SIP clients, especially the kind that can't
|> move out of the way easily. Like call centers etc. In that context being
|> able to direct a 1 mbps video stream onto a audio receiver works
|> excellent if your goal is to just DoS the path.
|
|Yep. Though of course in the specific case of a call center, since it
|auto-answers you can just mount the attack with independent calls....
|
|
|> But I do agree that consent freshness appears to be an important method
|> for mitigating this. It also seems to create a requirement on that
|> mechanism. It can't be something that the far end can trick the target
|> end-point to generate just by default. It needs to be something where
|> the end-point takes a decision to respond to each.
|
|Yeah. :(
|Maybe you, I, Dan, and anyone else who is interested can brainstorm
|on this a bit in Paris.
|
|-Ekr
|
|> Cheers
|>
|> Magnus
|>
|> On 2012-03-12 22:24, Eric Rescorla wrote:
|>> I want to make sure I understand this attack correctly.
|>>
|>> Alice is making a call to Zed and either Zed is the attacker or the attacker
|>> somehow captures Alice's media parameters. The attacker then uses
|>> Alice's offer (and her parameters) to start ICE handshaking on a pile
|>> of Web browsers that he controls. They all start ICE and since the
|>> checks with Alice will succeed, then the attacker has apparent consent
|>> to send as much traffic as he wants to Alice from each machine.
|>> Do I have this right?
|>>
|>> If I understand this correctly, then the severity of the attack seems to
|>> be limited since Alice has to actually be calling someone that is
|>> malicious or that has very tight control of the network, and soon
|>> after Alice hangs up the phone, the problem goes away. (Assuming
|>> consent freshness).
|>>
|>> As Dan notes, the interaction with consent freshness seems like a key
|>> mitigation here. Moreover, I think this suggests that even if integrity
|>> is not used, as in draft-muthu, the ufrags should both be present
|>> (and unmodifiable from the JS). This would allow a client to discard
|>> ICE associations with ufrags that do not match whichever ICE
|>> association got selected for the call.
|>>
|>> -Ekr
|>>
|>>
|>> On Mon, Feb 6, 2012 at 6:27 AM, Magnus Westerlund
|>> <[email-masked]> wrote:
|>>> On 2012-02-06 11:19, Oscar Ohlsson wrote:
|>>>>
|>>>>
|>>>>> -----Original Message-----
|>>>>> From: [email-masked]
|>>>>> [mailto:[email-masked]] On Behalf Of Magnus Westerlund
|>>>>> Sent: den 1 februari 2012 23:31
|>>>>> To: [email-masked]
|>>>>> Subject: [rtcweb] DoS attack despite ICE/STUN consent verification
|>>>>>
|>>>>> 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.
|>>>>
|>>>>
|>>>> 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.
|>>>>
|>>>
|>>> 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
|>>>
|>>> ----------------------------------------------------------------------
|>>> 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]
|>>> ----------------------------------------------------------------------
|>>>
|>>> _______________________________________________
|>>> rtcweb mailing list
|>>> [email-masked]
|>>> https://www.ietf.org/mailman/listinfo/rtcweb
|>>
|>
|>
|> --
|>
|> 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]
|> ----------------------------------------------------------------------
|>
|_______________________________________________
|rtcweb mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Mar 2012 17:32:01 +0000

Because although we describe things in terms of a single user (Alice in this case), that single "user" could represent a whole Enterprise call-center/IVR system, or an emergency service center (ie, PSAPs), etc.

Of course most such things receive calls not generate them, as in this attack scenario; so for this attack scenario imagine Alice is the Emergency Alert System, or NAWAS, or IPAWS, or whatever.

-hadriel
p.s. not implying that I think this particular attack-type is important, just sayin' why we care about poor old Alice.

On Mar 13, 2012, at 12:46 PM, Igor Faynberg wrote:

> Why do we care about a DoS attack  against a single client?  (I mean specifically DoS, not any other security attack.)
> 
> It appears to me that there are somewhat simpler and more effective DoS methods for this case: 1) cut the wire to the client's device or 2) jam WiFi or other wireless signal.
>

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 15 Mar 2012 16:34:41 -0400

Hadriel, thanks!

My on-going confusion was caused by the (myopic, I admit) interpretation 
of a browser=ONE person on the receiving end.  I never thought of the 
call center, let alone EAS or NAWAS.

Perhaps one thing that I missed was that the situation applies outside 
of a browser-to-browser scenario.

But what you said starts to make a lot of sense to me.  I think you are 
saying that a media gateway itself can be a subject to the attack, 
right?  I had never thought about that before...

Igor