Stagefright explicado: el exploit que cambió Android

Uno de los puntos más fuertes de Android ha sido principalmente su naturaleza de código abierto, que permite a las partes interesadas bifurcar, modificar y redistribuir el sistema operativo de una manera que se adapte a sus necesidades particulares. Pero esta ventaja de ser de código abierto actúa como un arma de doble filo cuando se trata de problemas de malware y seguridad. Es más fácil encontrar y corregir fallas cuando tienes muchos colaboradores capaces en un proyecto cuyo código fuente está disponible libremente. Sin embargo, solucionar el problema en el nivel de origen a menudo no se traduce en que el problema se solucione en manos del consumidor final. Como tal, Android no es la mejor opción cuando se trata de elegir un sistema operativo para las necesidades empresariales sensibles a los datos.

En Google I / O 2014, Google dio su primer impulso hacia un ecosistema más seguro y amigable para la empresa con el lanzamiento del programa Android For Work. Android For Work adoptó un enfoque de perfil doble para las necesidades empresariales, mediante el cual los administradores de TI podían crear perfiles de usuario distintos para los empleados, uno centrado en el trabajo, dejando otros perfiles para uso personal de los empleados. Mediante el uso de cifrado basado en hardware y políticas administradas por el administrador, los datos personales y de trabajo permanecieron distintos y seguros. Posteriormente, Android For Work recibió más atención en los últimos meses, con un gran enfoque en la seguridad del dispositivo contra el malware. Google también planeó habilitar el cifrado completo del dispositivo para todos los dispositivos que se lanzarían con Android Lollipop fuera de la caja, pero esto se descartó debido a problemas de rendimiento con el movimiento opcional para que los OEM lo implementen.

El impulso para un Android seguro no es completamente el trabajo de Google, ya que Samsung ha desempeñado un papel bastante significativo en esto a través de sus contribuciones de KNOX a AOSP, que finalmente fortaleció Android For Work. Sin embargo, las vulnerabilidades y vulnerabilidades de seguridad recientes en Android apuntan a una tarea cuesta arriba cuando se trata de popularidad para la adopción empresarial. Un ejemplo es la vulnerabilidad reciente de Stagefright.

Contenido:

  • ¿Qué es Stagefright?
  • ¿Qué tan serio es Stagefright?
  • ¿Qué diferencia a Stagefright de otras "vulnerabilidades masivas"?
  • El dilema de la actualización
  • Android, Post-Stagefright
  • Notas de cierre

¿Qué es Stagefright?

En términos simples, Stagefright es un exploit que utiliza la biblioteca de códigos para la reproducción de medios en Android llamada libstagefright. El motor libstagefright se utiliza para ejecutar el código que se recibe en forma de video malicioso a través de MMS, por lo que solo se requiere el número móvil de la víctima para llevar a cabo un ataque exitoso.

Nos comunicamos con nuestro experto interno, Desarrollador reconocido senior y Administrador de desarrolladores pulser_g2 para proporcionar una explicación más detallada.

Mientras escribo esto, el exploit [Stagefright] debía explicarse en BlackHat [Link], aunque todavía no hay diapositivas o detalles de papel blanco disponibles.

Por lo tanto, doy esta explicación más como una idea aproximada de lo que está sucediendo, en lugar de como una explicación muy profunda con total precisión, etc.

Hay varios errores diferentes que componen Stagefright, y estos tienen sus propios números CVE [Vulnerabilidades y exposiciones comunes] para el seguimiento:

  • CVE-2015-1538
  • CVE-2015-1539
  • CVE-2015-3824
  • CVE-2015-3826
  • CVE-2015-3827
  • CVE-2015-3828
  • CVE-2015-3829

Lamentablemente, los parches disponibles no están vinculados directamente a cada CVE (como deberían ser), por lo que será un poco complicado de explicar.

1. [CVE-2015-1538]

En el código de manejo MPEG4, los metadatos de 3GPP (el material que describe el formato y otra información adicional, cuando un video está en formato 3GPP) tienen errores. No rechazó los metadatos, donde los datos eran excesivamente grandes, sino que solo verificaba si eran demasiado pequeños. Esto significaba que era posible que un atacante creara un archivo "modificado" o "dañado", que tendría una porción de metadatos más larga de lo que debería.

Uno de los grandes desafíos al escribir código para manejar datos "no confiables" (es decir, de un usuario o de cualquier otro tipo de lugar externo a su código) es manejar datos de longitud variable. Los videos son un ejemplo perfecto de esto. El software necesita asignar memoria dinámicamente, dependiendo de lo que esté sucediendo.

En este caso, se crea un búfer como puntero a alguna memoria, pero la longitud de la matriz a la que apunta era un elemento demasiado corto. Luego, los metadatos se leyeron en esta matriz y fue posible que la última entrada en esta matriz no fuera "nula" (o cero). Es importante que el último elemento de la matriz sea cero, ya que así es como el software le dice que la matriz está terminada. Al poder hacer que el último valor no sea cero (dado que la matriz era potencialmente un elemento demasiado pequeño), el código malicioso podría ser leído por otra parte del código y leer demasiados datos. En lugar de detenerse al final de este valor, podría seguir leyendo en otros datos que no debería leer.

(Ref: OmniROM Gerrit)

2. [CVE-2015-1539]

El "tamaño" más corto posible de los metadatos debe ser de 6 bytes, debido a que es una cadena UTF-16. El código toma el tamaño del valor entero y le resta 6. Si este valor fuera menor que 6, la resta se "desbordaría" y se envolvería, y terminaríamos con un número muy grande. Imagínese si solo puede contar de 0 a 65535, por ejemplo. Si toma el número 4 y resta 6, no puede ir por debajo de cero. Entonces regresas a 65535 y cuentas desde allí. ¡Eso es lo que está pasando aquí!

Si se recibió una longitud inferior a 6, podría provocar que los cuadros se decodifiquen incorrectamente, ya que el proceso de intercambio de bytes utiliza la variable len16, cuyo valor se obtiene de un cálculo que comienza con (tamaño-6). Esto podría causar una operación de intercambio mucho más grande de lo previsto, lo que cambiaría los valores en los datos del marco de una manera inesperada.

(Ref: OmniROM Gerrit)

3. [CVE-2015-3824]

Un problema! Este es desagradable. Existe exactamente lo contrario de este último problema: un desbordamiento de enteros, donde un entero puede ser "demasiado grande". Si llega a 65535 (por ejemplo) y no puede contar más, ¡rodaría y pasaría a 0 a continuación!

Si está asignando memoria basándose en esto (¡que es lo que está haciendo Stagefright!), Terminaría con muy poca memoria asignada en la matriz. Cuando los datos se pusieron en esto, podría sobrescribir los datos no relacionados con los datos controlados por el creador del archivo malicioso.

(Ref: OmniROM Gerrit)

4. [CVE-2015-3826]

Otro desagradable! Muy similar al último: otro desbordamiento de enteros, donde una matriz (utilizada como búfer) se haría demasiado pequeña. Esto permitiría que se sobrescribiera la memoria no relacionada, lo que de nuevo es malo. Alguien que pueda escribir datos en la memoria puede corromper otros datos que no están relacionados, y potencialmente usar esto para que el teléfono controle algún código que controlen.

(Ref: OmniROM Gerrit)

5. [CVE-2015-3827]

Muy similar a estos últimos. Se usa una variable cuando se salta un poco de memoria, y esto podría hacerse negativo durante una resta (como arriba). Esto daría como resultado una longitud de "salto" muy grande, desbordando un búfer, dando acceso a la memoria a la que no se debe acceder.

(Ref: OmniROM Gerrit)

También hay algunas correcciones (potencialmente) relacionadas que parecen haber llegado a [Android] 5.1 también.

(Ref: OmniROM Gerrit)

Esto agrega comprobaciones para detener problemas con una corrección de seguridad anterior para agregar comprobaciones de límites, que pueden desbordarse. En C, los números que se pueden representar como un int con signo se almacenan como un int con signo. De lo contrario, permanecen sin cambios durante las operaciones. En estas comprobaciones, algunos enteros podrían haberse firmado (en lugar de no firmado), lo que reduciría su valor máximo más adelante y permitiría que se produjera un desbordamiento.

(Ref: OmniROM Gerrit)

Algunos desbordamientos de enteros más (donde los números son demasiado bajos, y luego se restan esos números, lo que les permite ser negativos). Esto nuevamente conduce a un gran número, en lugar de uno pequeño, y eso causa los mismos problemas que anteriormente.

(Ref: OmniROM Gerrit)

Y finalmente, otro desbordamiento de enteros. Igual que antes, está a punto de usarse en otro lugar y podría desbordarse.

(Ref: OmniROM Gerrit) "

¿Qué tan serio es Stagefright?

Según la publicación de blog publicada por la compañía investigadora principal, Zimperium Research Labs, el exploit Stagefright expone potencialmente el 95% de los dispositivos Android, aproximadamente 950 millones, a esta vulnerabilidad, ya que afecta a los dispositivos con Android 2.2 y versiones posteriores. Para empeorar las cosas, los dispositivos anteriores a Jelly Bean 4.3 están en el "peor riesgo", ya que no contienen mitigaciones adecuadas contra esta vulnerabilidad.

Con respecto al daño que Stagefright podría causar, pulser_g2 comentó:

““ En sí mismo, Stagefright le daría acceso al usuario del sistema en el teléfono. Sin embargo, tendría que omitir ASLR (aleatorización del diseño del espacio de direcciones) para abusar de él. Se desconoce si esto se ha logrado o no en este momento. Este exploit permite que se ejecute "código arbitrario" en su dispositivo como usuario del sistema o de los medios. Esos tienen acceso al audio y la cámara en el dispositivo, y el usuario del sistema es un gran lugar para lanzar un exploit raíz. ¿Recuerdas todas las increíbles hazañas de root que solías rootear tu teléfono?

¡Esos potencialmente podrían usarse silenciosamente para obtener root en su dispositivo! El que tiene raíz posee el teléfono. Tendrían que pasar por alto SELinux, pero TowelRoot lo logró, y PingPong también lo logró. Una vez que obtienen la raíz, todo en su teléfono está abierto para ellos. Mensajes, llaves, etc. ""

pulser_g2

Hablando de los peores escenarios, solo se necesita un MMS para entregar el código y desencadenar esta vulnerabilidad. El usuario ni siquiera necesita abrir el mensaje, ya que muchas aplicaciones de mensajería preprocesan MMS antes de que el usuario interactúe con él. Esto es diferente de los ataques de phishing, ya que el usuario podría ser completamente ajeno a un ataque exitoso, comprometiendo todos los datos presentes y futuros en el teléfono.

¿Qué diferencia a Stagefright de otras "vulnerabilidades masivas"?

““ Todas las vulnerabilidades presentan algún riesgo para los usuarios. Este es particularmente arriesgado, ya que si alguien encuentra una manera de atacarlo de forma remota (lo cual es posible, si se encuentra una forma de evitar ASLR), podría activarse incluso antes de darse cuenta de que está bajo ataque ""

pulser_g2

Las vulnerabilidades más antiguas como Android Installer Hijacking, FakeID y las vulnerabilidades de root como TowelRoot y PingPong requieren la interacción del usuario en algún momento para poder ejecutarse. Si bien todavía son "hazañas" en el hecho de que se pueden originar muchos daños si se usan maliciosamente, el hecho es que Stagefright teóricamente solo necesita el número de teléfono móvil de una víctima para convertir su teléfono en un troyano y, por lo tanto, se le está prestando mucha atención en los últimos años. dias.

Sin embargo, Android no está completamente a merced de esta hazaña. El ingeniero principal de seguridad de Android, Adrian Ludwig, abordó algunas preocupaciones en una publicación de Google+:

"" Hay una suposición común y errónea de que cualquier error de software puede convertirse en una vulnerabilidad de seguridad. De hecho, la mayoría de los errores no son explotables y Android ha hecho muchas cosas para mejorar esas probabilidades ...

Aquí se incluye una lista de algunas de esas tecnologías que se han introducido desde Ice Cream Sandwich (Android 4.0). El más conocido de estos se llama Address Space Layout Randomization (ASLR), que se completó completamente en Android 4.1 con soporte para PIE (Position Independent Executables) y ahora está en más del 85% de los dispositivos Android. Esta tecnología hace que sea más difícil para un atacante adivinar la ubicación del código, que es necesario para que pueda construir una explotación exitosa ...

No nos detuvimos con ASLR, también hemos agregado NX, FortifySource, Relocalizaciones de solo lectura, Apilar Canarios y más ".

Adrian Ludwig

Sin embargo, todavía no se puede negar que Stagefright es un asunto serio para el futuro de Android, y como tal está siendo tomado en serio por las partes interesadas involucradas. Stagefright también destacó a los elefantes blancos en la sala: el problema de la fragmentación y las actualizaciones finalmente llegaron al consumidor.

El dilema de la actualización

Hablando de actualizaciones, es bueno ver que los fabricantes de equipos originales se hacen responsables de la seguridad de los usuarios, ya que muchos han prometido mejorar el proceso de actualización específicamente para incorporar correcciones de seguridad y parches para exploits como Stagefright.

Entre los primeros en lanzar una declaración oficial, Google ha prometido actualizaciones de seguridad mensuales (además de las actualizaciones planificadas del sistema operativo y la plataforma) para la mayoría de sus dispositivos Nexus, incluido el Nexus 4. de casi 3 años de edad. Samsung también ha seguido su ejemplo. anunciando que trabajará con operadores y socios para implementar un programa de actualización de seguridad mensual, pero no especificó los dispositivos y los detalles de la línea de tiempo de esta implementación. Esto es interesante ya que menciona un enfoque de "vía rápida" para las actualizaciones de seguridad en colaboración con los operadores, por lo que podemos esperar actualizaciones más frecuentes (aunque basadas en la seguridad, pero con suerte también acelerará las actualizaciones de firmware) en los dispositivos del operador.

Otros OEM que se unen al paquete incluyen a LG, que se unirá con actualizaciones de seguridad mensuales. Motorola también ha anunciado la lista de dispositivos que se actualizarán con las correcciones Stagefright, y la lista incluye casi todos los dispositivos que la compañía ha fabricado desde 2013. Sony también ha dicho que sus dispositivos pronto recibirán los parches también.

Por una vez, los operadores también están llegando con actualizaciones. Sprint ha emitido una declaración de que algunos dispositivos ya han recibido el parche Stagefright, con más dispositivos programados para la actualización. AT&T también ha seguido el ejemplo al emitir el parche a algunos dispositivos. Verizon también ha emitido parches, aunque este es un lanzamiento lento que prioriza los teléfonos inteligentes de gama alta como Galaxy S6 Edge y Note 4. El T-Mobile Note 4 también recibió una actualización de parche Stagefright.

Como usuario final, hay algunos pasos de precaución que se pueden tomar para disminuir sus posibilidades de ser atacado. Para empezar, desactive la recuperación automática de mensajes MMS en las aplicaciones de mensajería presentes en su teléfono. Esto debería mantener el control de los casos en los que no se requirió la interacción del usuario para que el exploit funcione. Después de esto, tenga cuidado de evitar descargar medios de mensajes MMS de fuentes desconocidas y no confiables.

Como usuario avanzado, también puede realizar ediciones en su accesorio de compilación para deshabilitar Stagefright. Esta no es una forma completa y segura de salvarse de Stagefright, pero puede aprovechar la posibilidad de disminuir la probabilidad de un ataque exitoso si está atascado en una versión anterior de Android. También hay soluciones ROM personalizadas, la mayoría de las cuales sincronizan fuentes con AOSP de forma regular y, por lo tanto, tendrán incorporadas las correcciones Stagefright. Si está ejecutando una rom basada en AOSP, se recomienda encarecidamente que actualice a una versión más reciente de la ROM que incorpora los parches Stagefright. Puede usar esta aplicación para verificar si Stagefright afecta a su conductor diario actual.

Android, Post-Stagefright

Stagefright no ha sido más que una llamada de atención hacia Android y su problema de fragmentación y actualizaciones. Destaca cómo no existe un mecanismo claro por medio del cual tales soluciones críticas se puedan implementar de manera oportuna en numerosos dispositivos. Si bien los fabricantes de equipos originales están tratando de implementar parches para dispositivos, la cruda realidad es que la mayoría de estas correcciones se limitarán solo a los buques insignia recientes. Otros dispositivos no emblemáticos y más antiguos, mucho menos de los OEM más pequeños, seguirán expuestos a los efectos de Stagefright.

Esta hazaña tiene un lado positivo : volvió a llamar la atención sobre el proceso de actualización de Android y lo lanzó a la luz que no atraerá a tantas compañías corporativas futuras hacia la adopción de Android para uso empresarial. A medida que Google trabaja para lograr una mayor adopción empresarial, se verá obligado a repensar su estrategia de actualización y la cantidad de control que permite a los OEM.

Con Android M acercándose cada día al lanzamiento en el mercado, no sería una sorpresa si Google eligiera separar cada vez más componentes de AOSP a favor de su paquete de servicios Play. Después de todo, esa es un área sobre la cual Google aún conserva el control total sobre si un dispositivo se enviará con Google Play Store. Esto tiene sus propios inconvenientes en la forma de reemplazar áreas de fuentes abiertas con paredes de fuentes cercanas.

Al especular sobre el futuro de Android, existe la posibilidad (muy pequeña) de que Google también pueda limitar los cambios que los OEM pueden hacer a AOSP. Con el marco RRO presente en un estado funcional en Android M, Google podría restringir a los OEM para que solo realicen cambios cosméticos en forma de máscaras RRO. Esto debería permitir una implementación de actualización más rápida, pero sería a costa de que a los OEM se les niegue la oportunidad de personalizar completamente Android.

Otra ruta que podría ser una posibilidad sería hacer obligatorio que todos los dispositivos que se envían con Google Play Store reciban actualizaciones de seguridad garantizadas por un período de tiempo fijo, posiblemente dos años. El marco de Play Services podría usarse para verificar la presencia de actualizaciones y parches de seguridad importantes, y el acceso a Play Store se anularía en caso de incumplimiento.

Notas de cierre

Esto sigue siendo especulación en el mejor de los casos, ya que no hay una forma elegante de solucionar este problema. A falta de un enfoque muy totalitario, siempre habrá algunas deficiencias en el alcance de las soluciones. Debido a la gran cantidad de dispositivos Android que existen, realizar un seguimiento del estado de la seguridad de cada dispositivo sería una tarea muy gigantesca. La necesidad de la hora es repensar la forma en que Android se actualiza, ya que la forma actual ciertamente no es la mejor. En Developers, esperamos que Android continúe siendo fiel a sus raíces de código abierto mientras trabaja junto con los planes de código cerrado de Google.

¿Su teléfono es vulnerable a Stagefright? ¿Crees que tu teléfono recibirá un parche Stagefright? ¡Háganos saber en los comentarios a continuación!