In January 2019, a critical flaw was reported in Apple’s FaceTime group chat feature that enabled users to start a FaceTime video call and spy on targets by adding their own number as a third person in a group chat, even before the person at the other end accepted the call.
The vulnerability was considered so severe that the iPhone manufacturer removed the FaceTime group chat feature completely before the problem was resolved in a subsequent iOS update.
Since then, a number of similar deficiencies have been discovered in several video chat apps, such as Signal, JioChat, Mocha, Google Duo and Facebook Messenger – all thanks to the work of Google Project Zero researcher Natalie Silvanovich.
“While [the Group FaceTime] bug was fixed soon, the fact that such a serious and easy-to-reach vulnerability occurred due to a logical bug in a calling state machine – an attack scenario that I had never considered on any platform – made me wonder if other machines of state had similar vulnerabilities as well, “wrote Silvanovich in a deep dive into his year-long investigation.
How does WebRTC signaling work?
Although most messaging applications today rely on WebRTC for communication, connections themselves are created by exchanging call configuration information using the session description protocol (SDP) between peers in what is called signaling, which normally works by sending an offer number of the caller’s end, to which the receiver responds with an SDP response.
In other words, when a user initiates a WebRTC call to another user, a session description called “offer” is created containing all the information needed to set up a connection – the type of media being sent, its format, the transfer protocol used and the IP address and port of the endpoint, among others. The recipient then responds with a “reply”, including a description of his terminal.
The entire process is a state machine, which indicates “where the current connection and offer exchange signaling process is located”.
Also optionally included as part of the offer / response exchange is the ability of the two pairs to exchange SDP candidates with each other in order to negotiate the real connection between them. It details the methods that can be used to communicate, regardless of the network topology – a WebRTC structure called the Interactive Connectivity Establishment (ICE).
Once the two pairs agree on a mutually compatible candidate, that candidate’s SDP is used by each pair to build and open a connection, through which the media then begins to flow.
In this way, the two devices share with each other the information needed to exchange audio or video over a point-to-point connection. But before this retransmission can take place, the captured media data must be attached to the connection using a feature called tracks.
Although it is expected that the receiver’s consent will be guaranteed before the audio or video transmission and that no data will be shared until the receiver has interacted with the application to answer the call (that is, before adding any track to the connection), Silvanovich observed a contrary behavior.
Multiple messaging apps affected
Not only do application failures allow calls to be connected without receiver interaction, but they also allow the caller to force a receiver device to transmit audio or video data.
The common root cause? Logic errors in signaling state machines, which Silvanovich said “are a worrying and under-investigated attack surface for videoconferencing applications.”
- Signal (fixed in September 2019) – An audio call failure in Signal’s Android app made it possible for the caller to hear the receiver’s surroundings due to the fact that the app did not check whether the device receiving the connection message from the receiver was the caller device.
- JioChat (corrected in July 2020) and Mocha (corrected in August 2020) – Adding candidates to offers created by Reliance JioChat and Viettel’s Mocha Android apps that allowed a caller to force the target device to send audio (and video) without user consent. The failures stem from the fact that the point-to-point connection was set up even before the receiver answered the call, thereby increasing the “WebRTC remote attack surface”.
- Facebook Messenger (fixed in November 2020) – A vulnerability that could have allowed an attacker who is connected to the app to simultaneously initiate a call and send a specially crafted message to a target who is connected to the app and another Messenger client, such as how browser and starts receiving audio from the called device.
- Google Duo (corrected in December 2020) – A race condition between disabling the video and configuring the connection which, in some situations, can cause the receiver to leak video packets from missed calls.
Other messaging apps, like Telegram and Viber, did not have any of the above flaws, although Silvanovich noted that significant reverse engineering challenges when analyzing Viber made the investigation “less rigorous” than the others.
“Most of the calling state machines that I investigated had logical vulnerabilities that allowed audio or video content to be transmitted from the receiver to the caller without the caller’s consent,” concluded Silvanovich. “This is clearly an area that is often overlooked when protecting WebRTC applications.”
“Most of the bugs did not appear to be due to the developer’s misunderstanding of WebRTC’s features. Instead, they were due to errors in the way state machines are implemented. That said, the lack of awareness of these types of problems was probably a factor, “she added.
“It is also worrying to note that I have not seen any group calling features in these applications, and all reported vulnerabilities have been found in peer-to-peer calls. This is an area for future work that may reveal additional problems.”