We believe an attacker is using our service to possibly spam DNS requests. We are still investigating but it seems possible they are using a technique similar to the one used in this article Abusing WebRTC to Reveal Coarse Location Data in Signal | by David Wells | Tenable TechBlog | Medium to inject a domain into the ICE candidates list and force our server to perform a DNS resolution for that domain.
Has anyone else run into this? It seems like we would need to patch mediasoup or maybe even libwebrtc to filter out domain based ICE candidates. But this would also likely break our TURN servers so we would need to additionally provide a whitelist mechanism.
Thought I would reach out here before diving in too far to get others thoughts and see if maybe there is a simpler solution.
Yeah it seems like this would need to be patched in the underlying libwebrtc as it is all handled in the peer connection itself so cannot be addressed by patching mediasoup.
This doesn’t make any sense. mediasoup does not use libwebrtc for things related to ICE. Please, reconsider your assumptions. The attack you are suffering cannot be related to mediasoup side.
Apologies. Not sure what I was thinking when I wrote that. I’ve been focused on client-side work lately and got my wires crossed. Of course what I meant is that it would need to be patched in the underlying c++ worker implementation, specifically WebRtcTransport, (assuming it requires patching at all). I am still investigating this from our end, like I said I was just kinda curious if anyone else had run into a problem like this.
Once again, no client-side candidates are sent to the worker at all, there is nothing to patch there. SFU is designed to be running with publicly reachable IP address, so client address is unnecessary and your concerns are not applicable in that particular case. It is different from P2P communication between 2 browsers.
If no client side candidates are sent to the server for negotiation how is a route established? I understand the mediasoup implements ice-lite so this simplifies the process, but there is still negotiation that occurs and I believe also connectivity checks to the candidates in order to select the correct candidate pair. How else does mediasoup determine the correct public IP / port combination to which to send UDP packets?
How is connection established when you send an HTTP request to this forum without telling your ICE candidate?
My point is there is no ICE candidate sent to the server and thus no domain name resolution happens. Of course server knows your IP address and the outgoing port for data to flow, but it is not related in any way to the issue you might have with DNS resolution supposedly done by mediasoup.
Fair enough. I guess I have some more reading to do. Excuse my obvious ignorance on an extremely complex topic.
In regards to:
How is connection established when you send an HTTP request to this forum without telling your ICE candidate?
I feel like this is not an entirely fair comparison. An HTTP request is performed over TCP and the NAT mapping occurs at the protocol level. My ignorance lies on the UDP side and specifically on how STUN binding requests work, but I am gaining some understanding here now.
In UDP + STUN the ICE Lite endpoint just waits for incoming packets and replies to the same source IP:port from which it has received those UDP datagrams. NAT routers do the rest as they do with outgoing TCP connections. Just that.
