Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-25 06:00:40 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/generic-methodologies-and-resources/pentesting-network/webrtc-dos.md

5.5 KiB
Raw Permalink Blame History

WebRTC DoS

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

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

  1. 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.
  2. 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.
  3. 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.

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}