miércoles, 29 de julio de 2015

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.


No hay comentarios:

Publicar un comentario