hasan-khalil/cve-2020-6514Exploit para CVE-2020-6514 dirigido a la corrupción de memoria en WebRTC SCTP en aplicaciones Android. Utiliza Frida para enganchar funciones nativas y alterar paquetes SCTP para ejecución remota de código.
El exploit Al escribir el exploit, originalmente alteré los paquetes SCTP enviados al dispositivo objetivo modificando el código fuente de WebRTC y recompilándolo. Esto no era práctico para atacar aplicaciones de código cerrado, así que eventualmente cambié a usar Frida para hookear el binario del dispositivo atacante en su lugar. La funcionalidad de hooking de Frida permite ejecutar código antes y después de que se llame a una función nativa específica, lo que permitió que mi exploit alterara los paquetes SCTP salientes, así como inspeccionar los entrantes. Funcionalmente, es equivalente a modificar el código fuente del cliente atacante, pero en lugar de que las alteraciones se realicen en el código fuente en tiempo de compilación, se realizan dinámicamente por Frida en tiempo de ejecución. El código fuente del exploit está disponible aquí.
Hay siete funciones que el dispositivo atacante necesita hookear, como se indica a continuación.
usrsctp_conninput // recibe SCTP entrante DtlsTransport::SendPacket // envía SCTP saliente cricket::SctpTransport::SctpTransport // detecta cuando el transporte SCTP está listo calculate_crc32c // calcula el checksum para paquetes SCTP sctp_hmac // realiza HMAC para adivinar la clave secreta sctp_hmac_m // firma el paquete SCTP SrtpTransport::ProtectRtp // suprime RTP para reducir el ruido del heap
Estas funciones se pueden hookear como símbolos, o como offsets en el binario.
También hay tres offsets de direcciones del binario del dispositivo objetivo que se necesitan para que el exploit funcione. El offset entre la función system y la función malloc, así como el offset entre el gadget descrito en la publicación anterior y la función malloc son dos de estos. Estos offsets están en libc, que es una biblioteca del sistema de Android, por lo que deben determinarse según la versión de Android del dispositivo objetivo. También se necesita el offset desde la ubicación de la vtable de cricket::SctpTransport hasta la ubicación de malloc en la global offset table. Esto debe determinarse a partir del binario que contiene WebRTC en la aplicación atacada.
Ten en cuenta que los scripts de exploit proporcionados tienen una limitación grave: cada vez que se lee la memoria, solo funciona si el bit 31 del puntero está establecido. Las razones de esto se explican en la Parte 2. El script del exploit tiene un ejemplo de cómo solucionar esto y leer cualquier puntero usando chunks FWD_TSN, pero esto no se implementa para cada lectura. Para fines de prueba, reinicié el dispositivo hasta que la biblioteca WebRTC se asignara en una ubicación favorable. Aplicaciones Android Se determinó una lista de aplicaciones populares de Android que integran WebRTC buscando archivos APK en Google Play para una cadena específica en usrsctp. Aproximadamente 200 aplicaciones con más de cinco millones de usuarios parecían usar WebRTC. Evalué estas aplicaciones para determinar si podrían verse afectadas plausiblemente por las vulnerabilidades del exploit y cuál sería el impacto.
Resultó que las formas en que las aplicaciones usan WebRTC son bastante variadas, pero se pueden separar en cuatro categorías principales.
El impacto de las vulnerabilidades utilizadas en el exploit es diferente para cada una de estas categorías. La proyección es de bajo riesgo, ya que se requiere mucha interacción del usuario para configurar la conexión WebRTC, y el usuario tiene acceso a ambos lados de la conexión en primer lugar, por lo que hay poco que ganar comprometiendo el otro lado.
El streaming también es de riesgo bastante bajo. Si bien es posible que algunas aplicaciones usen conexiones peer-to-peer cuando una transmisión tiene un número bajo de espectadores, generalmente usan un servidor intermediario que termina la conexión WebRTC del peer emisor e inicia nuevas conexiones con los peers receptores. Esto significa que el atacante generalmente no puede enviar paquetes malformados directamente a un peer. Incluso en una configuración donde la transmisión se realiza peer-to-peer, se requiere interacción del usuario para que el objetivo vea la transmisión, y a menudo no hay forma de limitar quién puede acceder a una transmisión. Por esta razón, las aplicaciones de streaming que usan WebRTC probablemente no sean útiles para ataques dirigidos. Por supuesto, es posible que estas vulnerabilidades afecten a los servidores utilizados por los servicios de streaming, pero esto no se investigó en esta investigación.
Los navegadores son casi con certeza vulnerables a la mayoría de los errores en WebRTC, porque permiten un gran control sobre cómo se configura. Para explotar dicho error en un navegador, un atacante necesitaría configurar un host que actúe como el otro peer en la conexión peer-to-peer, y convencer al objetivo de que visite una página web que inicie una llamada a ese host. En este caso, la vulnerabilidad tendría un impacto similar a otras vulnerabilidades de corrupción de memoria en JavaScript.
Las conferencias son el uso de mayor riesgo de WebRTC, pero el impacto real de una vulnerabilidad depende mucho de cómo los usuarios de una aplicación se contactan entre sí. El diseño de mayor riesgo es una aplicación donde cualquier usuario puede contactar a cualquier otro usuario basado en un identificador. Algunas aplicaciones requieren que la persona llamada haya interactuado de una manera específica con la persona que llama antes de que se pueda realizar una llamada, lo que hace que sea más difícil contactar a un objetivo y generalmente reduce el riesgo. Algunas aplicaciones requieren que los usuarios ingresen un código o visiten un enlace para iniciar una llamada, lo que tiene un efecto similar. También hay un gran grupo de aplicaciones donde es difícil o imposible llamar a un usuario específico, por ejemplo, aplicaciones de chat roulette, y aplicaciones que tienen características que permiten a un usuario iniciar una llamada al servicio de atención al cliente.
Para esta investigación, me centré en aplicaciones de conferencias que permiten a los usuarios contactar a otros usuarios específicos. Esto redujo mi lista de 200 aplicaciones a 14 aplicaciones, como se indica a continuación.
