In January 2019, a critical bug was reported in Apple’s FaceTime group chat feature that allowed users to initiate a FaceTime video call and eavesdrop on targets by adding their own number as a third person in a group chat, even before the person on the other end accepted the incoming call.
The vulnerability was considered so severe that the iPhone maker removed the Group Chat FaceTime feature completely before the issue was resolved in a subsequent iOS update.
Since then, a number of similar flaws have been discovered in multiple 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 quickly fixed, the fact that such a serious and easily accessible vulnerability had occurred as a result of a logical bug in a calling state machine – an attack scenario I had never seen on a platform – made me wonder if other state machines had similar vulnerabilities too, ”Silvanovich wrote on Tuesday in a deep dive of her year-long research.
How signaling in WebRTC works?
While most messaging apps today rely on WebRTC for communication, the connections themselves are established by exchanging call configuration data using Session Description Protocol (SDP) between peers in so-called signaling, which typically works by offering an SDP offering. send from caller to which the called responds with an SDP response.
In other words, when a user initiates a WebRTC call to another user, a session description called an ‘offer’ is created containing all the information needed to establish a connection – the kind of media being sent, the format, the transmission protocol used and, among other things, the IP address and port of the endpoint. The receiver then responds with a “response”, including a description of the endpoint.
The whole process is a state machine, indicating “where in the process of signaling the offer-response exchange the connection is currently.”
Also optionally included as part of the offer / response exchange is the two peers’ ability to trade SDP candidates to each other to negotiate the actual connection between them. It describes the methods that can be used to communicate regardless of the network topology – a WebRTC framework called Interactive Connectivity Establishment (ICE).
Once the two peers agree on a mutually compatible candidate, that candidate’s SDP is used by each peer to establish and open a connection, which then starts media flowing.
In this way, both devices share with each other the information needed to exchange audio or video through the peer-to-peer connection. But before this relay can take place, the captured media data must be tied to the connection using a feature called tracks.
While the called party’s consent is expected to be guaranteed prior to audio or video transmission and no data will be shared until the recipient has interacted with the application to answer the call (i.e. before there are tracks on the connection added), Silvanovich observed behavior of the opposite.
Multiple messaging apps affected
Not only did the flaws in the apps allow calls to be connected without interaction from the called party, but they also potentially allowed the caller to force a called device to send audio or video data.
The common cause? Logical bugs in the signaling state machines, which Silvanovich said are “a concerning and under-researched attack surface for video conferencing applications.”
- Signal (fixed in September 2019) – An audio call error in Signal’s Android app allowed the caller to hear the called party’s environment due to the app not verifying that the device receiving the caller’s connection message was the caller device.
- JioChat (resolved in July 2020) and Mocha (fixed in August 2020) – Add candidates to Reliance JioChat’s offerings and Viettel’s Mocha Android apps that allowed a caller to force the target device to send audio (and video) without a user’s consent. The shortcomings stemmed from the fact that the peer-to-peer connection was established before the called party answered the call, increasing the “WebRTC remote attack surface”.
- Facebook messenger (fixed in November 2020) – A vulnerability that could allow an attacker logged into the app to simultaneously initiate a call and send a specially crafted message to a target logged into both the app and another Messenger client, such as as the web browser and start receiving audio from the called device.
- Google Duo (fixed in December 2020) – A race condition between turning off the video and setting up the connection that could, in some situations, cause the called video packets to leak from unanswered calls.
Other messaging apps such as Telegram and Viber were found to have none of the above shortcomings, although Silvanovich noted that significant reverse engineering challenges in analyzing Viber made the investigation “less rigorous” than the others.
“The majority of the calling state machines that I examined had logical vulnerabilities that could allow audio or video content to be sent from the called party to the caller without the caller’s consent,” concluded Silvanovich. “This is clearly an area that is often overlooked in securing WebRTC applications.”
“Most of the bugs didn’t seem to be due to the developer’s misunderstanding of WebRTC features. Instead, they were due to flaws in the way the state machines are implemented. That said, was a lack of awareness of problems like this are probably a factor, ‘she added.
“It is also concerning to note that I did not look at the group call characteristics of these applications, and all reported vulnerabilities were found in peer-to-peer calls. This is an area for future work that will address additional issues. might bring light. “