Destripando framework2.odex en Android

Hace algunas semanas estuve programando una pequeña herramienta en Python para ayudarme a crackear los hashes de Android. Durante su desarrollo, me di cuenta que los crackeos en hashes de móviles Samsung nunca funcionaban, además de que tenían un aspecto algo diferente (más corto) al de otros fabricantes. Como ya sabéis, los fabricantes de teléfonos móviles realizan modificaciones sobre el sistema operativo original de Google para adaptarlo a su hardware, mejorar rendimiento, o cualquier otra cosa que se les ocurra, por lo que no era descabellado pensar que Samsung hubiera realizado alguna modificación en el algoritmo de hashing. Por desgracia, no encontré por ninguna parte el código fuente propias de Samsung, así que no quedó más remedio que rebuscar un poco.

En primer lugar, necesitamos saber en que parte del código se realiza la acción del Hashing. En el caso de Android, tenemos la suerte de que el código fuente está disponible, así que una búsqueda rápida puede ayudarnos a obtener unos cuantos candidatos.

De los ficheros obtenidos, parece que uno con nombre "LockPatternUtils.java" tiene toda la pinta de poder contener el código que buscamos. Si accedemos a su código fuente y buscamos cadenas como "hash" o similares, y navegamos un poco por el código, acabamos encontrando funciones como "patternToHash()" o "passwordToHash()", que parecen ser las encargadas de generar los hashes de contraseñas y patrones y guardar el resultado en los ficheros "gesture.key" y "password.key" respectivamente.

Como podéis ver, este es el algoritmo habitual, el que coge la contraseña, la concatena con un salt y realiza dos hashes, un SHA-1 y un MD5, que luego concatena y guarda en el fichero. Viendo el path del fichero en el código fuente podemos ver que se encuentra dentro del framework base de Android, así que ahora solo necesitamos un Samsung con ROM original y descargar este fichero a ver que han modificado:

$ adb pull /system/framework .

Concretamente, el fichero que nos interesa es "framework2.odex", pero necesitamos bajarnos todo el framework porque la herramienta smali lo necesita para poder traducir este ODEX a un fichero DEX. El proceso parece un poco confuso, pero básicamente lo que hacemos es obtener el código smali del ODEX, y posteriormente volvemos a montar un DEX para luego convertirlo en JAR con dex2jar ¿Por qué? Porque el JAR podemos abrirlo con cualquier decompilador de Java como JD-GUI, mientras que el código smali puede ser un poco más complicado de leer. Veamos como lo haríamos:

$ java -jar baksmali-1.4.2.jar -a 15 -x framework2.odex -d framework -o framework2
$ java -jar smali-1.4.2.jar --api-level 15 -o classes.dex framework2
$ d2j-dex2jar.sh classes.dex

Ahora que ya tenemos el fichero "classes-dex2jar.jar" (el nombre lo pone la herramienta dex2jar por si misma), podemos abrirlo con nuestro decompilador de java favorito, en mi caso JD-GUI, y buscar la función passwordToHash() que comentábamos antes a ver que ha cambiado:

Pues... parece que sí que la cosa cambia un poco con respecto a la función original de Android. Para empezar no utiliza para nada el algoritmo MD5, sino únicamente SHA-1. En segundo lugar, no realiza una única ronda, sino que realiza 1024 rondas a las que le va añadiendo en cada una el número de iteración del bucle antes de volver a aplicar el algoritmo de hash.

Ahora solo queda programarlo y ya podemos crackear estos hashes, aunque como podéis imaginar será mucho más lento, debido a las múltiples rondas que se deben realizar para cada prueba. Un punto positivo para Samsung en este aspecto (a priori, que luego cuando tocas algoritmos de cifrado... nunca se sabe como puedes afectar a su seguridad).

Covert Channels over Social Networks (II)

En el anterior post hicimos una introducción a lo que son los caneles encubiertos y como están siendo utilizados por el malware en la actualidad, así como las contramedidas que típicamente están siendo utilizadas por los administradores de seguridad.

La pregunta que dejábamos pendiente en el anterior post era ¿Podríamos utilizar un dominio conocido para ocultar mensajes entre un malware y su C&C? Para dar respuesta a esta pregunta le pegué un vistazo superficial a algunas aplicaciones que se me fueron ocurriendo, a ver si tenían algún tipo de protección que impidiera su uso como un canal encubierto. Os recuerdo que esta investigación fue realizada hace algún tiempo, así que es posible que en este tiempo se hayan introducido nuevas protecciones. También os tengo que comentar que esta primera revisión fue superficial, y que únicamente me metí en detalle con FaceBook.

PASTEBIN

Pastebin me parecía un medio de comunicación interesante, sobretodo porque permite introducir información de forma anónima, así que no hay cuentas de usuario que puedan ser bloqueadas ni nada de eso. Sin embargo, bajo determinadas circunstancias, la aplicación te pedía resolver un captcha, con lo que se complicaba un poco su uso.

DROPBOX

Dropbox fue otra de las aplicaciones que pensé que podía resultar útil. Permitía acceder en raw al contenido de los ficheros y además no parecía tener ningún medio de protección ante la subida masiva de ficheros via HTTP, así que era un buen candidato.

GOOGLE SITES

Por supuesto, el tráfico hacia Google es algo que no resultaría extraño en ninguna red, así que era sin duda un buen candidato. En este caso hice algunas pruebas con los comentarios de Google Site, una aplicación tipo "wiki" que Google ofrece para la creación de sitios web sencillos. Entre sus funcionalidades, existe la opción de pone comentarios. Tras algunas pruebas, no pareció que fuera bloqueado o que se me pidiera resolver ningún captcha ante una entrada masiva de comentarios.

TWITTER

Twitter ya había sido usado con anterioridad por malware como "Naz", ya que no ofrecía ninguna protección contra su uso masivo ni nada similar. Sin embargo, es un sistema que por defecto deja toda la comunicación a la vista de todo el mundo, y requería algo más de trabajo adicional.

FACEBOOK

FaceBook es, sin duda, la red social por antonomasia, por lo que era un excelente candidato, especialmente pensando en usuarios domésticos (y, sorprendentemente, también muchas empresas). Tras algunas pruebas vimos que FaceBook tiene algunas protecciones, pero que estás están pensadas en proteger la privacidad de sus usuarios (como es lógico). Si intentas hacer un crawling para obtener información de otros usuarios sí que eres detectado y bloqueado, pero no encontramos ningún impedimento para leer escribir de nuestro propio muro, o del de otro usuario, siempre que no fuéramos cambiando de usuario.

Al final, nos quedamos con FaceBook, y desarrollamos una prueba de concepto a la que llamamos FaceCat, llamado así porque funciona de forma muy similar a un NetCat tradicional, pero encapsulando el canal de comunicación a través de FaceBook.

En el próximo post veremos en detalle los pasos que se siguieron para el desarrollo de esta herramienta.

Covert Channels over Social Networks (I)

Hace unas pocas semanas comentaba en un post sobre el informe de Mandiant sobre APT1 el tema de los Canales Encubiertos. Buscando los enlaces en el propio blog sobre el trabajo "Covert Channels over Social Networks" que publique con el SANS Institute y que comenté tanto en las conferencias SOURCE como en las GSIC, me di cuenta que nunca llegué a publicar en el blog una serie de posts que tenía previstos sobre este tema, pero... más vale tarde que nunca ¿no?

El concepto de "Canales Encubiertos" está muy ligado a la Esteganografía, que significa "escritura oculta". Como muchos de vosotros sabréis, la esteganografía sigue una filosofía distinta al cifrado. El cifrado pretende hacer un mensaje indescifrable para cualquier persona que no sea el receptor del mismo, pero no pretende oculta la existencia de dicho mensaje. La esteganografía, sin embargo, consiste precisamente en la ocultación de un mensaje dentro de un contexto, de tal forma que nadie salvo el receptor se percate ni tan siquiera de su existencia. La forma más típica de esteganografía la hemos encontrado en imagenes, donde por ejemplo podemos substituir los bits menos significativos de cada uno de los puntos de la imagen de tal forma que contengan un mensaje oculto. Al estar modificando los bits menos significativos, la alteración de la imagen es mínima, y por lo tanto es sencillo que nadie se percate de las modificaciones realizadas sobre ella.

Los canales encubiertos aplican este mismo concepto pero en comunicaciones de red, para ocultar transmisiones realizadas por puertas traseras u otros tipos de software similares. Uno de los ejemplos típicos de canales encubiertos era la ocultación de información a través del IPID que se emplea en TCP/IP como identificador único de un paquete en el caso de que se produzca fragmentación de paquetes, pero que no se utiliza para nada en caso de que no se produzca.

La primera columna son IPID's tomados de una captura real de tráfico web con un navegador, mientras que la segunda contiene un canal encubierto con la secuencia "cat /etc/passwd" ¿lo veis? Como podéis imaginar, no resulta fácil de detectar, ya que es necesario hacer estudios estadísticos para determinar si una secuencia es aleatoria o si sigue algún patrón no aleatorio, que podría significar la existencia de un canal encubierto.

Los proxies, NAT y otros mecanismos son de mucha utilidad para neutralizar algunos tipos de canales cubiertos, especialmente aquellos en los que la conexión termina en la frontera y es iniciada una nueva, como es el caso de los proxies. Por ello los atacantes están empleando cada vez más canales de comunicación basados en protocolo HTTP, ya que este es uno de los pocos que habitualmente están permitidos en cualquier organización. Como medida de ocultación, suelen utilizar conexiones HTTPS que impiden la inspección de los paquetes por parte de los detectores de intrusos.

Pero ¿a que servicios HTTP se conectan? Generalmente a servidores comprometidos o alquilados en diferentes lugares del mundo, que les sirven de Command & Control (C&C). Esto hace que los especialistas en seguridad hayan desarrollado listas de negras y de reputación de direcciones IP, redes y nombres de dominio, que sirven para identificar estas conexiones anómalas.

¿Y si el destino de estas conexiones no son anómalas? ¿Y si son conexiones a Google, Facebook o Twitter? Cuando se desarrolló esta investigación (hace ya casi 2 años), muy poco malware hacía uso de estos canales cubiertos. Tan solo se conocían algunos casos en la red Twitter, en la que las direcciones de los servidores de C&C eran publicadas en una cuenta específica. En estos momentos, el uso de canales cubiertos por parte de malware está más extendido, como vimos en el informe de Mandiant, aunque sigue sin ser algo extremadamente común.

En el próximo post entraremos al detalle en algunas de las redes sociales y servicios conocidos que analizamos para el trabajo.