Natalie Silvanovich: Signal, Google Duo, Facebook Messenger, JioChat, and Mocha have a logic bug that allow attackers to spy on users

Signal, Google Duo, Facebook Messenger, JioChat, and Mocha have a logic bug that allow attackers to spy on users. It has been discovered by Google Project Zero cybersecurity researcher Natalie Silvanovich. The majority of video conferencing applications are implemented using WebRTC. WebRTC connections are created by exchanging call set-up information in Session Description Protocol (SDP) between peers, a process called signalling. Signalling is not implemented by WebRTC, which allows peers to exchange SDP in whatever secure communication message is available to them, usually WebSockets for web applications, and secure messaging for messaging applications.

The cybersecurity expert: How the video conferencing applications works via WebRTC

According to the cybersecurity expert, there are a few types of SDP that can be exchanged by WebRTC peers. In a typical connection, the caller starts off by sending an SDP offer, and then the callee responds with an SDP answer. These messages contain most information that is needed to transmit and receive media, including codec support, encryption keys and much more. After the offer/answer exchange, peers can send SDP candidates to other peers. Candidates are potential network paths that the two peers can use to connect to each other, and SDP candidates contain information such as IP addresses and TURN servers. Peers usually send more than one candidate to a peer, and candidates can be sent at any time during a connection. WebRTC connections maintain an internal state related to whether an offer or answer has been received and processed, however, applications that use WebRTC usually have to maintain their own state machine to manage the user state of the application.

The apps enable transmission in many different ways. Most of these led to vulnerabilities that allowed calls to be connected without interaction from the callee

Regardless of design, transmitting audio or video from an input device must be directly enabled by application code using WebRTC. This is usually done using a feature called tracks. Every input device is considered a ‘track’, and each specific one must be added to a specific peer connection by calling addTrack (or language equivalent) before audio or video is transmitted. Tracks can also be disabled, which is useful for implementing mute and camera-off features. Each track also has an RTPSender property that can be used to fine-tune the properties of transmission, which can also be used to disable audio or video transmission. Theoretically, ensuring callee consent before audio or video transmission should be a fairly simple matter of waiting until the user accepts the call before adding any tracks to the peer connection. However, the applications enabled transmission in many different ways. Most of these led to vulnerabilities that allowed calls to be connected without interaction from the callee.