WebRTC DoS
Este problema se encontró en esta publicación de blog: https://www.rtcsec.com/article/novel-dos-vulnerability-affecting-webrtc-media-servers/
La vulnerabilidad descrita en los servidores de medios WebRTC surge de una condición de carrera durante la inicialización de sesiones de medios, específicamente entre la verificación de consentimiento de medios ICE y la iniciación de tráfico DTLS. Aquí hay un desglose detallado:
Origen de la Vulnerabilidad
Asignación de Puertos UDP: Cuando un usuario inicia una llamada WebRTC, el servidor de medios asigna puertos UDP para manejar los flujos de medios, con la IP y el puerto comunicados a través de señalización.
Procesos ICE y STUN: El navegador del usuario utiliza ICE para la verificación de consentimiento de medios, utilizando STUN para determinar la ruta de conexión al servidor de medios.
Sesión DTLS: Tras la verificación exitosa de STUN, se inicia una sesión DTLS para establecer claves maestras SRTP, cambiando a SRTP para el flujo de medios.
Mecanismo de Explotación
Explotación de Condición de Carrera: Un atacante puede explotar una condición de carrera enviando un mensaje DTLS ClientHello antes que el usuario legítimo, potencialmente utilizando un conjunto de cifrado no válido como
TLS_NULL_WITH_NULL_NULL. Esto provoca un error DTLS en el servidor, impidiendo que se establezca la sesión SRTP.
Proceso de Ataque
Escaneo de Puertos: El atacante necesita adivinar qué puertos UDP están manejando sesiones de medios entrantes, enviando mensajes ClientHello con el conjunto de cifrado nulo a estos puertos para activar la vulnerabilidad.
Diagrama del Ataque: La secuencia implica múltiples mensajes ClientHello enviados por el atacante al servidor, intercalados con señalización legítima y mensajes DTLS, lo que lleva a un fallo en el apretón de manos debido al conjunto de cifrado erróneo.
Pruebas y Mitigación
Pruebas Seguras: Usando herramientas como Scapy, los atacantes reproducen mensajes DTLS ClientHello dirigidos a puertos de medios específicos. Para pruebas éticas, se utilizaron modificaciones en Chromium (por ejemplo,
JsepTransport::AddRemoteCandidates) para imitar el comportamiento de la víctima de manera segura.Medidas de Mitigación: Las soluciones implican descartar paquetes de direcciones no verificadas, como se implementa en versiones más nuevas de bibliotecas como libnice. La solución principal enfatiza confiar en el proceso de verificación ICE y solo procesar paquetes de combinaciones de IP y puerto validadas.
Escenarios No Vulnerables
Configuraciones del Servidor DTLS: Las instancias en las que el navegador actúa como un servidor DTLS o cuando el servidor de medios no utiliza puertos efímeros para sesiones de medios no son susceptibles a esta vulnerabilidad.
Conclusión
Esta vulnerabilidad destaca el delicado equilibrio en los procesos de inicialización de sesiones de medios y la necesidad de mecanismos de temporización y verificación precisos para prevenir la explotación. Se aconseja a los desarrolladores implementar las correcciones de seguridad recomendadas y asegurar procesos de verificación robustos para mitigar tales vulnerabilidades.
Last updated
