Valid peers can create Prflx candidates for addresses they don't control

[pion]

Valid peers can create Prflx candidates for addresses they don't control

[Sean-Der]

Hey @kixelated

I don't think this is possible anymore, BindRequests are filtered via MessageIntegrity (so if the attacker doesn't know the pwd we are safe)

[kixelated]

Nope, not safe. The attacker in this case will set up a PeerConnection using it's own credentials. It can set up ICE/DTLS/SRTP everything. Except it will suddenly claim to have a different IP address by forging the UDP return address header. This tricks the server to take the attacker's legitimate PeerConnection and redirect it elsewhere.

For example, if Pions gets a STUN binding request that claims to be sent from google.com:80, it will mark it as a validPair and potentially use it as the result from getBestPair. Pions would then proceed to shove SRTP/DTLS traffic at Google which won't know what to do with it. The PeerConnection can be kept alive by the attacker because they can still send RTCP/STUN packets from their valid but lower priority real IP address.

The fix is to require a SuccessResponse from the remote candidate with the same transaction ID as your previously sent BindRequest before you can mark it as valid. That's why the transaction ID exists.

[Sean-Der]

if Pions gets a STUN binding request that claims to be sent from google.com:80

How? Binding requests are discarded unless you know the uPwd

[Sean-Der]

Talked to @kixelated on Slack I understand the issue now.

---

We have to check TransactionIDs and we MUST require success responses from peers. Otherwise a candidate could give us invalid prflx candidates (and we would start sending traffic to 3rd parties unexpectedly)