Subject: [Ice] Missing amplification attack in RFC 5245

From: Nils Ohlmeier <[email-masked]>
Date: Tue, 22 Nov 2016 23:55:27 -0800

Hi,

After reading about the STUN amplification attack described in section 13.4.1 of 5245bis I think that paragraph is actually missing a small variation. My reading of the section is that the inside attacker uses the signaling to send bogus candidates to the responding ICE agent. I think even easier would it be for an inside attacker to simply send tons of fake check requests from the transport address of the victim. If the responding ICE agent receives these check requests (through NAT and/or firewall) it will create peer reflexive candidates, which causes binding response to be send to the victim. Followed by triggered check requests, which get highest priority on the next free cycles for new check requests.

   Agents SHOULD limit the
   total number of connectivity checks they perform to 100.
   Additionally, agents MAY limit the number of candidates they'll
   accept.
Theoretically an ICE implementation which limits the over all number of connectivity checks to 100 should limit the peer reflexive amplification attack as well. But I could easily see that implementers tried to implement the recommended protection here by limiting the number of candidates received via signaling, which would then be bypassed by this attack.

Best
  Nils Ohlmeier

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 23 Nov 2016 08:31:51 +0000

Hi,

>After reading about the STUN amplification attack described in section
>13.4.1 of 5245bis I think that paragraph is actually missing a small
>variation. My reading of the section is that the inside attacker uses the
>signaling to send bogus candidates to the responding ICE agent. I think
>even easier would it be for an inside attacker to simply send tons of
>fake check requests from the transport address of the victim. If the
>responding ICE agent receives these check requests (through NAT and/or
>firewall) it will create peer reflexive candidates, which causes binding
>response to be send to the victim.

Not only that - currently, as was indicated in another e-mail, MEDIA can
also be sent.

My suggestion would be to say that media must only be sent on valid
candidate pairs. Now, that may not prevent the attack, but at least it
requires a little more work as a pair has to be nominated.

Regards,

Christer

---

From: Nils Ohlmeier <[email-masked]>
Date: Wed, 23 Nov 2016 11:55:33 -0800

> On Nov 23, 2016, at 00:31, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

Good point.

> requires a little more work as a pair has to be nominated.

I’m not sure if you are suggesting to require nomination in general before sending media?!

To me it would make sense to not allow sending media over peer reflexive candidates until they are nominated. But for pairs which have been learned from signaling the valid status is enough to start sending media. Although that makes things obviously more complex. This would also raise the question if another state between ‘valid’ and ‘nominated’ is needed which indicates that sending media on this pair is permitted.

Best
  Nils

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 23 Nov 2016 20:11:07 +0000

Hi,

>>> variation. My reading of the section is that the inside attacker uses 
>>> the signaling to send bogus candidates to the responding ICE agent. I 
>>> think even easier would it be for an inside attacker to simply send 
>>> tons of fake check requests from the transport address of the victim. 
>>> If the responding ICE agent receives these check requests (through 
>>> NAT and/or
>>> firewall) it will create peer reflexive candidates, which causes 
>>> binding response to be send to the victim.
>> 
>> Not only that - currently, as was indicated in another e-mail, MEDIA 
>> can also be sent.
>
> Good point.
>

No.

The spec currently says that media can be sent on a valid pair, and my suggestion would be to say that media should also only be accepted on a valid pair.

>To me it would make sense to not allow sending media over peer reflexive candidates until they are nominated. But for pairs which have been learned from signaling the >valid status is enough to start sending media.

What do you mean by "signalling the valid status"?

>Although that makes things obviously more complex. This would also raise the question if another state between ‘valid’ and ‘nominated’ is needed which indicates that >sending media on this pair is permitted.

Keep in mind that, according to 5245bis, there is no need to nominate before sending media.

Also, as a side note, "nominated" only means that the controlling endpoint has set the nominate flag in the STUN request - not that the controlled pair has sent a STUN response. Once the controlled endpoint has accepted the nomination, the pair becomes "selected" :)

Regards,

Christer

---

From: Nils Ohlmeier <[email-masked]>
Date: Wed, 23 Nov 2016 16:47:58 -0800

> On Nov 23, 2016, at 12:11, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

“Accepted” sound like the receiving side to me. But to limit the amplification we need to restrict the sender side at the amplifier, agreed?

Everything I write below is from the amplifiers point of view.

> What do you mean by "signalling the valid status”?

Sorry I did not realize that my sentence could be parsed wrong. Here is hopefully a better breakdown which avoids confusion.

There are three ways to learn about remote candidates:
1) from signaling:
  - they cause check request to be sent to the victim 
  - this is described in section 13.4.1 of the draft
  - but you can’t send media to them as they are not in the valid list yet and the victim hopefully never answers with a valid check response
  - this is non peer reflexive candidate
2) as the STUN server from binding requests (assuming source IP/port are forged):
  - they will cause STUN binding response to be send to the victim
  - this creates a new remote peer reflexive candidate
  - this also causes the new pair to be inserted into the triggered check queue, which results in more STUN traffic for the victim
  - but no media gets send as the pair is not on the valid list (and won’t be unless the victim sends a valid check response)
  - this attack I think is missing from the draft/spec
3) as the STUN client from a binding response:
  - this creates local peer reflexive candidate
  - a valid pair gets created for this, which allows sending media
  - but I don’t see how this applies to the amplification attack

> Also, as a side note, "nominated" only means that the controlling endpoint has set the nominate flag in the STUN request - not that the controlled pair has sent a STUN response. Once the controlled…

After looking at the above list please disregard my suggestion for a new state. I don’t see how media could actually be send as part of the amplification attack.

BTW I got massively confused by the fact that apparently the editor draft on github.io <http://github.io/> is really outdated. Could you either update it or take it down to avoid further confusion?

Thanks
 Nils