Ir al contenido principal

Android Stagefright Exploit / POC (II)

Pero ¿Qué vectores podemos/debemos seguir para localizar este tipo de vulnerabilidades?


A priori, yo me decantaría principalmente por dos vectores muy distintos y, para los cuales se tendrán que emplear técnicas muy diferentes.


VECTOR de búsqueda 1


Ante todo hay que tener en cuenta que Android es un proyecto Open Source, lo que significa que tenemos acceso a su código fuente. Así, un claro vector de búsqueda sería por esta vía, es decir, analizando el código fuente en busca de aquellos 'Bugs', descuidos y metodologías, técnicas y funciones inseguras utilizadas por los ingenieros del software.

Por tanto, un poco para empezar a buscar es el repositorio del código fuente de Android, el cual podemos encontrar en la siguiente URL:


Como podemos ver en dicho repositorio, la cantidad de código fuente con la que tendremos que lidiar es claramente INMENSA, entonces ¿por qué camino debemos ir? En el caso que nos ocupa sobre StageFright, una vía clara de búsqueda, es la ruta que nos lleva directamente al framework de audio y video nativo del StageFright, el cual está ubicado aquí (para android-5.1.1 r8):


En caso de querer tener acceso al framework de otra reléase, podemos entrar desde esta otra URL:


Por ejemplo, para ir directos al código fuente en C++ de parte de Stagefright podríamos comenzar por aquí:



VECTOR de búsqueda 2

En este caso, como digo, las cosas serán muy diferentes. Ahora no se trata de analizar el código fuente en búsqueda de funciones 'sensibles' o estructuras mal definidas, etc. Aquí de lo que se trata es de utilizar un dispositivo "vivo", es decir, actuar sobre un dispositivo Android en tiempo real.

Nuevamente, en el caso que nos ocupa de StageFright y, en concreto en las vulnerabilidades que hacen referencia a la recepción de MMS, la técnica que se utilizará será la "Fuzzy Data Mining", básicamente el envío de datos mal-formados al dispositivo, con el fin de provocar algún tipo de error.

Está claro que el envío/recepción de mensajes de tipo MMS debe regirse por algún tipo de estándar con su correspondiente especificación, la cual se encarga de definir entre otras cosas las características, formatos de los datos, de las cabeceras, etc. que deben tener dichos mensajes.

Y entre otras cosas, algo que diferencia a un MMS de un SMS común, es que el MMS precisamente soporta el envío/recepción de archivos multimedia (audio y video). Archivos que pueden ser de diversos formatos y, los cuales nuevamente se deben regir por una especificación de formato, en la mayoría de los casos claramente definida.

Por ejemplo, para que os hagáis una idea StageFright, a priori es capaz de identificar las siguientes extensiones de archivos:

".mp3", ".mp4", ".m4a", ".3gp", ".3gpp", ".3g2", ".3gpp2", ".mpeg", ".ogg", ".mid", ".smf", ".imy", ".wma", ".aac", ".wav", ".amr", ".midi", ".xmf", ".rtttl", ".rtx", ".ota", ".mkv", ".mka", ".webm", ".ts", ".fl", ".flac", ".mxmf", ".avi", ".mpeg", ".mpg", ".awb", ".mpga"

Esto, que de entrada podría no significar gran cosa, ya nos está dando una idea aproximada de la cantidad de CODECs con los que tiene que lidiar Android y su complejo framework multimedia.

Por lo tanto y dicho esto, ¿qué pasaría si en lugar de enviar un MMS como el dispositivo Android espera recibir, le enviamos un MMS mal-formado o erróneo? Pues la respuesta es sencilla, si el software no está correctamente diseñado para la detección de este tipo de situaciones tipo excepciones no controladas y demás, se producirá algún error.

Esos errores serán precisamente los que convertirán en vulnerable al dispositivo, pudiendo permitir la ejecución de código remoto no deseado o mal intencionado.


Comentarios

Entradas populares de este blog

Como usar el TL431 (muy facil)

En este artículo, no vamos a entrar en el funcionamiento interno de este IC, ni tampoco en sus características técnicas, puesto que para esos fines ya existe su hoja de datos correspondiente. Más bien, lo que pretendo aquí es dejar constancia de como podemos utilizar este IC desde un punto de vista práctico, útil y sobre todo de una manera sencilla, con el objetivo de que cualquiera pueda utilizarlo. Si has llegado hasta aquí, probablemente ya sabes que por internet hay mucha información sobre este IC, pero también bastante confusa o excesivamente técnica, sin mostrar tan siquiera un ejemplo de funcionamiento, o como calcular sus pasivos. Pues se acabó, a partir de hoy y después de leer este post, ya te quedará claro como utilizar el TL431 para obtener una tensión de referencia estable y precisa. Vamos al grano y que mejor que empezar aclarando que el TL431 NO ES EXACTAMENTE UN ZENER como se empeñan en decir en muchos sitios, es verdad que se le conoce como el Zener Progra

Expresión Regular para números en Notación Científica (1.5e-10)

No cabe duda que las expresiones regulares tienen un potencial de mucho valor a la hora de analizar textos, ya sea para marcado, búsqueda de patrones, o incluso la programación de un compilador, un analizador de frases, de expresiones matemáticas, etc.   En esta ocasión he tenido que echar mano de ellas para el análisis de textos matemáticos en los cuales aparecen números en Notación Científica (con exponentes del tipo 1.5E-10). Pues bien, una expresión regular que me está funcionando bastante bien es la siguiente:   [-+]?[0-9]*\.?[0-9]+([eE][-+]?[0-9]+)?    Esta expresión regular se puede descomponer en los siguientes bloques, para poder interpretarla con mayor facilidad:  El primer bloque [-+]? está indicando que el número podría estar precedido opcionalmente de un signo - o un signo + El segundo bloque [0-9]* indica que podría aparecer un número de 0 o más dígitos del 0 al 9  El tercer bloque indica que también de manera opcional podría aparecer un pun

Programadores de Malware ¿Malas prácticas?

Cuando uno se enfrenta al análisis de un nuevo malware, son muchos los frentes que podemos abrir y los enfoques que podemos darle. Como es lógico, un primer paso será identificar que es un malware de aquello que no lo es, y en ocasiones esto es preciso hacerlo con la mayor rapidez posible. Muchas veces no contamos con el tiempo necesario para hacer un análisis completo a priori, y lo único que necesitamos es tomar decisiones tempranas para iniciar todos los protocolos oportunos ante una nueva muestra "maléfica". Parece lógico pensar, que un código que inicialmente está ofuscado, empaquetado, o que hace uso de determinadas APIs del sistema, ya tiene una cierta probabilidad de ser malware y por lo tanto empezar a tratarlo de manera especial. Durante estos días he estado analizando un nuevo malware, posiblemente una variante de tantas que andan circulando en estos días por internet. En concreto, lo que tengo entre manos es un Ransomware, si compañeros, un especimen