En enero de 2019, se informó una falla crítica en la función de chats grupales FaceTime de Apple que permitía a los usuarios iniciar una videollamada FaceTime y escuchar a escondidas a los objetivos agregando su propio número como una tercera persona en un chat grupal incluso antes de que la persona en el chat. otro extremo aceptó la llamada entrante.

La vulnerabilidad se consideró tan grave que el fabricante del iPhone eliminó por completo la función de chats grupales de FaceTime antes de que el problema se resolviera en una actualización posterior de iOS.

Desde entonces, se han descubierto una serie de deficiencias similares en múltiples aplicaciones de chat de video como Signal, JioChat, Mocha, Google Duo y Facebook Messenger, todo gracias al trabajo de la investigadora de Google Project Zero, Natalie Silvanovich.

«Tiempo [the Group FaceTime] El error se solucionó pronto, el hecho de que una vulnerabilidad tan grave y fácil de alcanzar se produjera debido a un error lógico en una máquina de estado de llamada, un escenario de ataque que nunca había visto considerado en ninguna plataforma, me hizo preguntarme si otras máquinas de estado tenían problemas similares. vulnerabilidades también «, escribió Silvanovich en una inmersión profunda del martes de su investigación de un año.

¿Cómo funciona la señalización en WebRTC?

Aunque la mayoría de las aplicaciones de mensajería de hoy en día dependen de WebRTC para la comunicación, las conexiones en sí se crean mediante el intercambio de información de configuración de llamadas mediante el Protocolo de descripción de sesión (SDP) entre pares en lo que se denomina señalización, que generalmente funciona mediante el envío de una oferta SDP desde el el extremo de la persona que llama, a la que la persona que llama responde con una respuesta SDP.

Dicho de otra manera, cuando un usuario inicia una llamada WebRTC a otro usuario, se crea una descripción de sesión llamada «oferta» que contiene toda la información necesaria para establecer una conexión: el tipo de medios que se envían, su formato, el protocolo de transferencia utilizado y la dirección IP y el puerto del endpoint, entre otros. Luego, el destinatario responde con una «respuesta», que incluye una descripción de su punto final.

Todo el proceso es una máquina de estado, que indica «en qué parte del proceso de señalización del intercambio de oferta y respuesta se encuentra actualmente la conexión».

También se incluye opcionalmente como parte del intercambio de oferta/respuesta la capacidad de los dos pares de intercambiar candidatos SDP entre sí para negociar la conexión real entre ellos. Detalla los métodos que se pueden usar para comunicarse, independientemente de la topología de la red: un marco WebRTC llamado Establecimiento de conectividad interactiva (ICE).

Una vez que los dos pares acuerdan un candidato mutuamente compatible, cada par utiliza el SDP de ese candidato para construir y abrir una conexión, a través de la cual los medios comienzan a fluir.

De esta forma, ambos dispositivos comparten entre sí la información necesaria para intercambiar audio o vídeo a través de la conexión peer-to-peer. Pero antes de que ocurra esta retransmisión, los datos multimedia capturados deben adjuntarse a la conexión mediante una función llamada pistas.

Si bien se espera que se brinde el consentimiento de la persona que llama antes de la transmisión de audio o video y que no se compartan datos hasta que el receptor haya interactuado con la aplicación para responder la llamada (es decir, antes de agregar pistas a la conexión), Silvanovich observó un comportamiento contrario. .

Múltiples aplicaciones de mensajería afectadas

Las fallas en las aplicaciones no solo permitieron que las llamadas se conectaran sin la interacción de la persona que llama, sino que también permitieron potencialmente que la persona que llama obligara a un dispositivo de la persona a la que llama a transmitir datos de audio o video.

¿La causa raíz común? Los errores lógicos en las máquinas de estado de señalización, que según Silvanovich, «son una superficie de ataque preocupante y poco investigada de las aplicaciones de videoconferencia».

• Señal (corregido en septiembre de 2019): una falla de llamada de audio en la aplicación de Android de Signal hizo posible que la persona que llama escuchara los alrededores de la persona que llama debido al hecho de que la aplicación no verificó si el dispositivo que recibía el mensaje de conexión de la persona que llama era la persona que llama. dispositivo.

• jiochat (fijado en julio de 2020) y Moca (corregido en agosto de 2020) – Adición de candidatos a las ofertas creadas por Reliance JioChat y las aplicaciones de Android Mocha de Viettel que permitían a una persona que llamaba obligar al dispositivo de destino a enviar audio (y video) sin el consentimiento del usuario. Las fallas surgieron del hecho de que la conexión punto a punto se había configurado incluso antes de que el destinatario respondiera la llamada, lo que aumentó la «superficie de ataque remoto de WebRTC».

• Facebook Messenger (corregido en noviembre de 2020): una vulnerabilidad que podría haber otorgado a un atacante que haya iniciado sesión en la aplicación iniciar simultáneamente una llamada y enviar un mensaje especialmente diseñado a un objetivo que haya iniciado sesión tanto en la aplicación como en otro cliente de Messenger como como el navegador web y comience a recibir audio desde el dispositivo de la persona a la que llama.

• dúo de Google (corregido en diciembre de 2020): una condición de carrera entre la desactivación del video y la configuración de la conexión que, en algunas situaciones, podría provocar que la persona que llama filtrara paquetes de video de llamadas no respondidas.

Se descubrió que otras aplicaciones de mensajería como Telegram y Viber no tenían ninguno de los defectos anteriores, aunque Silvanovich señaló que los importantes desafíos de ingeniería inversa al analizar Viber hicieron que la investigación fuera «menos rigurosa» que las demás.

«La mayoría de las máquinas de estado de llamadas que investigué tenían vulnerabilidades lógicas que permitían que el contenido de audio o video se transmitiera de la persona que llama a la persona que llama sin el consentimiento de la persona que llama», concluyó Silvanovich. «Esta es claramente un área que a menudo se pasa por alto al proteger las aplicaciones WebRTC».

«La mayoría de los errores no parecían deberse a que los desarrolladores no entendieron las características de WebRTC. En cambio, se debieron a errores en la forma en que se implementan las máquinas de estado. Dicho esto, la falta de conocimiento de este tipo de problemas probablemente fue un factor». , «ella añadió.

«También es preocupante notar que no observé ninguna característica de llamadas grupales de estas aplicaciones, y todas las vulnerabilidades reportadas se encontraron en llamadas entre pares. Esta es un área para trabajo futuro que podría revelar problemas adicionales».