STUN network injections
Closed this issue · 5 comments
Understandably, STUN is used to address the IP of the clients used to establish the webrtc stream which could be used to deliver Advanced persistence threats since connections to stun servers are not secured over UDP (through network injections). Even if they are owned by signal, ISPs, governments etc can inject malware packets within the STUN-client communication in order to execute arbitrary code and effectively install sophisticated malware on the device.
Does signal provide a mitigation for this such as packet authentication (because even this can be bypassed) or is the connection to the STUN encrypted? Because if not this actively renders a very large attack vector for signal exploitable by advanced threat actors.
This is technical analysis of the captured traffic from a
post on community.signalusers.org
(https://community.signalusers.org/t/stun-servers-network-injections/55981/12?u=shiko)
:I’ve just tested it by running a packet capture on the router. Calling phone connected to turn3.voip.signal.org on port 3478/UDP. That’s the unencrypted STUN port in fact I could see in Wireshark the phone public IP address, the public IP address of the callee and some private addresses. It also spoke TLS on port 443/TCP and exchanged UDP packets on random high ports (this is expected). It did not connect to the encrypted port, 5349/TCP, even though the server is indeed listening for connections on that port.
Effectively, due to the lack of security during the client-STUN communication this essentially opens up the application to man in the middle attacks resulting in zero click exploits. This can be done by any government that has sufficient funding (it’s not difficult).
This renders the entire signal protocol as ineffective at best aside from the exfiltrations on the rest of the device.
TLS being a secure layer or security can be used to encrypt STUN packets between the client-server.
However, Signal need to further the extent of the security in order to prevent any compromised STUN server from making a network injection. This could be done by the tokens used to prevent the server from knowing who is communicating with whom. The same idea could possibly be used with the stun server, in the case that an attacker would have immense difficulty in targeting an individual. All an attacker would be left with is network analysis at best to try and highlight the target device.
This is an example of an attack on STUN parsers conducted on zoom since they were not encrypted:
CVE-2023-22881 Detail
Description
Zoom clients before version 5.13.5 contain a STUN parsing vulnerability. A malicious actor could send specially crafted UDP traffic to a victim Zoom client to remotely cause the client to crash, causing a denial of service.
The whole point of this is to address any unencrypted traffic on the UDP layer in order to prevent any form of MITM/zero-click exploits.
Hello @Striker789,
There appear to be several misunderstandings in the original submission and subsequent comments, and we'd like to help clear up some of the confusion if we can.
It's not the case that sending and receiving a packet is somehow a generic vulnerability that automatically leads to remote code execution. For example, if you look at a diagram of the TLS handshake process, you can see that clients and servers exchange several packets before an encrypted connection is established.
If you have any specific technical information about a vulnerability in Signal, please reach out to us at security@signal.org.
@jim-signal thank you for your reply.
I understand that that receiving packets cannot be a magical vector of attack. However, this is not as simple as 'receiving packets' it's an entire communication that is left unencrypted. Hence the lack of encryption and authentication as I had explained above can lead to network injections which can affect the webrtc/ringrtc parsers. The point is to limit attack vector, hence encrypting the client-stun communication should suffice using TLS.
Signal has since hardened their webrtc protocol. unencrypted SCTP has been removed and whatever header information remains is encrypted. Effectively all data exchanged by client-client is encrypted once the connection is established. This is miles ahead of many applications that claim that they are secure.
Packets are more than enough to deliver exploits:
https://blog.quarkslab.com/attacking-titan-m-with-only-one-byte.html
This is an example of how very few packets were able to locally bypass Titan M's security barriers.
The lack of encryption in the STUN-client protocol is more than enough to execute a RCE. The exact same way network injections can occur over HTTP if the sufficient exploit chain is found.
Please read the above and give it some thought.
If there is anything I am missing kindly tell me in order to make things clearer.
Thank you.