Stagefright: 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 misma ventaja de ser de código abierto actúa como un arma de doble filo cuando se trata de cuestiones 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 gratuitamente. Sin embargo, solucionar el problema en el nivel de origen no suele traducirse 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 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 las empresas con el lanzamiento de

Programa Android para el trabajo. Android For Work adoptó un enfoque de doble perfil para las necesidades empresariales, mediante el cual los administradores de TI podían crear un Perfiles de usuario distintos para los empleados: uno centrado en el trabajo, dejando otros perfiles para el personal de los empleados. usar. Mediante el uso de cifrado basado en hardware y políticas administradas por el administrador, los datos personales y laborales se mantuvieron diferenciados y seguros. Posteriormente, Android For Work recibió más atención en los últimos meses, centrándose principalmente en la seguridad del dispositivo contra malware. Google también planeó habilitar el cifrado completo del dispositivo para todos los dispositivos que se iban a lanzar con Android Lollipop listo para usar, pero se descartó debido a problemas de rendimiento y el movimiento se hizo opcional para que lo implementaran los OEM.

La lucha por un Android seguro no es enteramente obra de Google, ya que Samsung ha desempeñado un papel bastante importante en ello a través de su Contribuciones de KNOX a AOSP, que finalmente Android reforzado para el trabajo. Sin embargo, los recientes ataques de seguridad y vulnerabilidades en Android apuntan a una tarea ardua en lo que respecta a la popularidad para la adopción empresarial. Un ejemplo de ello es la reciente vulnerabilidad Stagefright.

Contenido:

• ¿Qué es el miedo escénico?
• ¿Qué tan serio es el miedo al escenario?
• ¿Qué diferencia a Stagefright de otras "vulnerabilidades masivas"?
• El dilema de la actualización
• Android, post-miedo escénico
• Notas finales

¿Qué es el miedo escénico?

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

Nos comunicamos con nuestro experto interno, el desarrollador senior reconocido de XDA y el administrador de desarrolladores. pulsador_g2 para dar una explicación más detallada.

"Mientras escribo esto, el exploit [Stagefright] debía ser explicado en BlackHat [Enlace], aunque aún no hay diapositivas ni detalles del documento técnico disponibles.

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

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

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

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

1. [CVE-2015-1538]

En el código de manejo de MPEG4, el código de manejo de metadatos 3GPP (lo que describe el formato y otra información adicional, cuando un video está en formato 3GPP) tiene errores. No rechazó los metadatos, cuando los datos eran excesivamente grandes, sino que solo comprobó si eran demasiado pequeños. Esto significaba que era posible que un atacante creara un archivo "modificado" o "corrupto", 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 vídeos 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 un puntero a cierta memoria, pero la longitud de la matriz a la que apunta era un elemento demasiado corta. Luego, los metadatos se leyeron en esta matriz y fue posible que la última entrada de 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 indica que la matriz está terminada. Al poder hacer que el último valor sea distinto de cero (ya que la matriz era potencialmente un elemento demasiado pequeña), 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 otros datos que no debería leer.

(Árbitro: OmniROM Gerrit)

2. [CVE-2015-1539]

El "tamaño" más corto posible de los metadatos debe ser de 6 bytes, ya que se trata de 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 daría vueltas, y terminaríamos con un número muy grande. Imagínese si sólo pudiera contar del 0 al 65535, por ejemplo. Si tomas el número 4 y le restas 6, no puedes bajar de cero. Entonces regresas a 65535 y cuentas desde allí. ¡Eso es lo que está pasando aquí!

Si se recibe una longitud inferior a 6, podría provocar que las tramas se decodifiquen incorrectamente, ya que el El proceso de intercambio de bytes utiliza la variable len16, cuyo valor se obtiene de un cálculo que comienza con (talla-6). Esto podría provocar que se produjera una operación de intercambio mucho mayor de lo previsto, lo que cambiaría los valores en los datos del marco de forma inesperada.

(Árbitro: OmniROM Gerrit)

3. [CVE-2015-3824]

¡Un gran problema! Éste es desagradable. Existe exactamente lo contrario de este último problema: un desbordamiento de enteros, donde un número entero puede volverse "demasiado grande". Si llegas a 65535 (por ejemplo) y no puedes contar más, deberás rodar y pasar 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 se ingresaban datos en esto, potencialmente se sobrescribían datos no relacionados con datos controlados por el creador del archivo malicioso.

(Árbitro: 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 sobrescribir la memoria no relacionada, lo cual nuevamente es malo. Alguien que pueda escribir datos en la memoria puede corromper otros datos que no estén relacionados y potencialmente usarlos para que algún código que controle se ejecute en su teléfono.

(Árbitro: OmniROM Gerrit)

5. [CVE-2015-3827]

Bastante similar a estos últimos. Se utiliza una variable cuando se omite algo de memoria, y esto podría volverse negativo durante una resta (como arriba). Esto daría como resultado una longitud de "salto" muy grande, desbordando un búfer, dando acceso a una memoria a la que no se debería acceder.

(Árbitro: OmniROM Gerrit)

También hay algunas correcciones (potencialmente) relacionadas que parecen haberse incluido también en [Android] 5.1.

(Árbitro: OmniROM Gerrit)

Esto agrega controles para detener problemas con una solución de seguridad anterior para agregar controles de límites, que a su vez pueden desbordarse. En C, los números que pueden representarse 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 números enteros podrían haberse hecho con signo (en lugar de sin signo), lo que reduciría su valor máximo más adelante y permitiría que se produjera un desbordamiento.

(Árbitro: OmniROM Gerrit)

Algunos desbordamientos de números enteros más (donde los números son demasiado bajos y luego se realiza una resta en esos números, lo que les permite volverse negativos). Nuevamente, esto conduce a un número grande, en lugar de uno pequeño, y eso causa los mismos problemas que los anteriores.

(Árbitro: OmniROM Gerrit)

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

(Árbitro: OmniROM Gerrit)"

¿Qué tan serio es el miedo al escenario?

Según el entrada en el blog publicado por la empresa de investigación matriz, Zimperium Research Labs, el exploit Stagefright expone potencialmente El 95% de los dispositivos Android (aproximadamente 950 millones) sufren esta vulnerabilidad, ya que afecta a los dispositivos que ejecutan Android 2.2 y arriba. Para empeorar las cosas, los dispositivos anteriores a Jelly Bean 4.3 corren el "peor riesgo", ya que no contienen mitigaciones adecuadas contra este exploit.

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

[blockquote Author="pulser_g2"]"En sí mismo, Stagefright daría acceso al usuario del sistema en el teléfono. Sin embargo, tendrías que omitir ASLR (aleatorización del diseño del espacio de direcciones) para abusar de él. En este momento se desconoce si esto se ha logrado o no. Este exploit permite ejecutar "código arbitrario" en su dispositivo como usuario del sistema o de medios. Estos tienen acceso al audio y a la cámara del dispositivo, y el usuario del sistema es un excelente lugar desde donde iniciar un exploit de raíz. ¿Recuerdas todos los increíbles exploits de root que usaste para rootear tu teléfono?

¡Estos podrían potencialmente usarse silenciosamente para obtener root en su dispositivo! El que tiene root es dueño del teléfono. Tendrían que pasar por alto SELinux, pero TowelRoot lo logró, y PingPong también lo logró. Una vez que obtengan acceso root, todo lo que haya en su teléfono estará abierto para ellos. Mensajes, claves, etc."[/blockquote]Hablando del peor de los casos, sólo se necesita un MMS para entregar el código y activar este exploit. 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 ignorar por completo 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 suponen algún riesgo para los usuarios. Este es particularmente riesgoso, ya que si alguien encuentra una manera de atacarlo de forma remota (que es posible, si se encontrara una forma de sortear ASLR), podría activarse incluso antes de que te des cuenta de que estás bajo ataque"

Los exploits más antiguos, como el secuestro del instalador de Android, FakeID, así como los exploits de raíz como TowelRoot y PingPong, requieren la interacción del usuario en algún momento para poder ejecutarse. Si bien siguen siendo “hazañas” en el sentido de que pueden originarse muchos daños si se usan maliciosamente, el hecho es que Stagefright En teoría, sólo se necesita el número de móvil de la víctima para convertir su teléfono en un troyano y, por eso, se le está prestando tanta atención en los últimos tiempos. días.

Sin embargo, Android no está completamente a merced de este exploit. El ingeniero jefe de seguridad de Android, Adrian Ludwig, abordó algunas inquietudes en un publicación de Google+:

[blockquote Author="Adrian Ludwig"]"Existe la suposición errónea y común de que cualquier error de software puede convertirse en un exploit de seguridad. De hecho, la mayoría de los errores no son explotables y hay muchas cosas que Android ha hecho para mejorar esas probabilidades...

Se enumera una lista de algunas de las tecnologías que se han introducido desde Ice Cream Sandwich (Android 4.0). aquí. El más conocido de ellos se llama Address Space Layout Randomization (ASLR), que se completó por completo en Android 4.1 con soporte para PIE (Position Independent Executables) y ahora está en más del 85% de Android dispositivos. Esta tecnología hace que sea más difícil para un atacante adivinar la ubicación del código, que es necesario para crear un exploit exitoso...

No nos detuvimos con ASLR, también agregamos NX, FortifySource, Read-Only-Relocations, Stack Canaries y más".[/blockquote]

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

El dilema de la actualización

Hablando de actualizaciones, es bueno ver que los OEM se están responsabilizando de la seguridad de los usuarios, como 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 emitir 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. Samsung también hizo lo mismo al anunciar que trabajará con operadores y socios para implementar un programa de actualización de seguridad mensual pero no especificó los dispositivos ni los detalles del cronograma 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, para que podamos espere actualizaciones más frecuentes (aunque basadas en seguridad, pero con suerte también acelerará las actualizaciones de firmware) en el operador dispositivos.

Otros OEM que se unirán al grupo incluyen a LG, que se unirá a actualizaciones de seguridad mensuales. Motorola también ha anunciado la lista de dispositivos que se actualizarán con 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 dispuestos a presentar actualizaciones. Sprint tiene emitió una declaración que algunos dispositivos ya recibieron el parche Stagefright, y que hay más dispositivos programados para la actualización. AT&T también ha hecho lo mismo emitiendo el parche a algunos dispositivos. Verizon también ha publicado parches, aunque se trata de un lanzamiento lento que prioriza los teléfonos inteligentes de alta gama como el Galaxy S6 Edge y el Note 4. El T-Mobile Note 4 también recibió una actualización del parche Stagefright.

Como usuario final, existen algunas medidas de precaución que se pueden tomar para reducir las 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 bajo control los casos en los que no se requirió la interacción del usuario para que el exploit funcionara. Después de esto, tenga cuidado de evitar descargar medios de mensajes MMS de fuentes desconocidas y no confiables.

Como usuario avanzado de XDA, también puedes realice modificaciones en su accesorio de compilación para desactivar Stagefright. Esta no es una forma completa y segura de salvarte de Stagefright, pero puedes arriesgarte a disminuir la probabilidad de un ataque exitoso si estás atrapado en una versión anterior de Android. También existen 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 incorpore los parches Stagefright. Puedes usar Esta aplicación para comprobar si su conductor diario actual se ve afectado por Stagefright.

Android, post-miedo escénico

Stagefright no ha sido más que un toque de atención hacia Android y su problema de fragmentación así como de actualizaciones. Destaca cómo no existe un mecanismo claro mediante el cual estas correcciones críticas puedan implementarse de manera oportuna en numerosos dispositivos. Si bien los OEM están intentando implementar parches para dispositivos, la dura verdad es que la mayoría de estas correcciones se limitarán únicamente a los buques insignia recientes. Otros dispositivos no emblemáticos y más antiguos, y mucho menos los OEM más pequeños, seguirán expuestos a dispositivos como Stagefright.

Hay un lado positivo en esta hazaña: Volvió a llamar la atención sobre el proceso de actualización de Android y lo presentó de una manera que no atraerá a tantas empresas corporativas futuras a adoptar 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.

Dado que Android M se acerca cada día más al lanzamiento al mercado, no sería una sorpresa que Google decidiera separar cada vez más componentes de AOSP en favor de su paquete de servicios Play. Después de todo, esa es un área sobre la que Google aún conserva control total si un dispositivo se envía con Google Play Store. Este tiene sus propias desventajas en forma de reemplazo de áreas de fuentes abiertas con paredes de fuentes cercanas.

Al especular sobre el futuro de Android, existe una posibilidad (muy pequeña) de que Google también limite los cambios que los OEM pueden hacer en AOSP. Con el Marco de RRO Al estar presente en un estado funcional en Android M, Google podría restringir a los OEM para que realicen solo cambios cosméticos en forma de máscaras RRO. Esto debería permitir una implementación de actualizaciones más rápida, pero tendría el costo de negar a los OEM la oportunidad de personalizar completamente Android.

Otra ruta que podría ser una posibilidad sería hacerla obligatoria para todos los dispositivos que se envían con Google Play Store recibirá actualizaciones de seguridad garantizadas durante un período de tiempo fijo, posiblemente dos años. El marco de Play Services podría utilizarse para comprobar la presencia de actualizaciones y parches de seguridad importantes, rescindiendo el acceso a Play Store en caso de incumplimiento.

Notas finales

En el mejor de los casos, esto sigue siendo una especulación, ya que no existe una forma elegante de solucionar este problema. A menos que se adopte un enfoque muy totalitario, siempre habrá alguna deficiencia en el alcance de las soluciones. Debido a la gran cantidad de dispositivos Android que existen, realizar un seguimiento del estado de seguridad de cada dispositivo sería una tarea gigantesca. La necesidad del momento es repensar la forma en que se actualiza Android, ya que la forma actual ciertamente no es la mejor. En XDA Developers esperamos que Android siga manteniéndose fiel a sus raíces de código abierto mientras trabaja junto con los planes de código cerrado de Google.

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