31 marzo 2014

HighSecCon III


El 12 de Septiembre de 2013 se celebró la primera HighSecCon en Madrid, a finales del pasado año la segunda edición, y a finales de esta semana le toca el turno a ya la tercera edición de este evento gratuito. Se han anunciado ya las siguientes cuatro charlas repartidas en dos sesiones:

Sesión 1 - 16:00 - 17:50
Sesión 2 - 18:10 - 20:00
  • Analizando binarios e ingeniería inversa por Simón Roses (@simonroses)
  • From Kernel Space to WhatsApp Nightmare por Jaime Sanchez (@segofensiva)

El evento tendrá lugar este próximo viernes 4 de abril a partir de las 15:45, con hora estimada de finalización de las 20:00 de la tarde, y tendrá lugar en el Salón de Actos de la Escuela Politécnica Superior de la Universidad Autónoma de Madrid.


Se ha publicado el cartel del evento a través de su twitter, y que podréis ver a continuación:



Si no tienes ningún plan para la tarde del viernes, aprovecha la oportunidad de asistir a charlas de ponentes de lujo totalmente gratis registrándote a través de este enlace. Puedes seguir la HighSecCon III a través de su twitter @highseccon

[+] HighSecCon III
Leer más...

3.2  ¿Dónde se crea la ventana?

El problema es que no sabemos a dónde queremos que el programa salte. Tenemos la pista del nombre de la ventana “test_app”. También sabemos que seguramente debamos saltar a una función que no sea referenciada por otra (ahí está la gracia del reto). Debemos suponer que primero el binario deberá hacer una llamada para crear la ventana y después otra para pintar el cuadrado (o lo que sea que sea eso).

Otra forma de resolver el reto es ver que hacen cada una de esas tres funciones que he mostrado antes y ver quien las está llamando. Yo opté por una mezcla de esta última opción con la anterior.

Veamos primero la función llamada por IDA sub_4020B0. En un bloque de la función vemos:



¡Vaya! Si tenemos una llamada a la API “CreateWindowExA”. Qué suerte la nuestra que hemos encontrado precisamente lo que buscábamos. Siguiente paso es saber quien está llamando a esta función.

Veamos que trozos del código no son referenciados por el flujo de código que estamos siguiendo simplemente pulsando la letra “x” en IDA al principio de la función. Si nadie referencia a esta función ya sabremos a donde debemos hacer que se produzca el CALL EAX:



Vemos que la dirección 402012(402000+12) está haciendo un CALL a la función que crea la ventana donde más tarde se debe pintar el susodicho cuadrado. Vayamos allí a ver que vemos:



¡Perfecto! Parece que está llamando a nuestra función create_window (así la he llamado yo pero es la antigua sub_4020B0) y en caso de que la respuesta de la misma sea 0 (error) nos mostrará un mensaje con el texto “error”.
Veamos ahora si alguna parte del código está llamando a la dirección 402000.



¡Ya tenemos nuestra dirección deseada del CALL para crear la ventana!

Otra forma de encontrar la función “huérfana” a la que debemos saltar es abrir la vista de IDA que pinta el “CALL flow” del programa (Ctrl+F12):



Como podemos ver todas las funciones son referenciadas excepto dos de ellas: sub_4022E0 y sub_402000. Si recordamos del punto 3.1, el programa cogía los 4 primeros bytes del fichero “key.txt” y los sumaba al valor 7A40B660.

Por tanto: X+7A40B660=402000 => X=402000-7A40B660. Usamos la misma calculadora de Windows para calcular nuestra X y obtenemos: 85FF69A0. Estos deberán ser los primeros 4 bytes del fichero “key.txt”. Recordemos que estamos bajo una arquitectura Little Endian por lo que el orden de los bytes es de derecha a izquierda (inverso a la escritura occidental) y por tanto los cuatro primeros bytes serán: A069FF85.

Debugueamos la aplicación con IDA y vemos como el CALL EAX se produce con el valor de EAX=402000 y podemos observar como se ha creado una nueva ventana con el nombre “test_app”. ¡Perfecto!


3.3  Pintar el cuadrado

Ahora solo nos falta que se pinte el cuadrado en la ventana creada. Para ello deberemos de saltar en algún momento a alguna parte del código que se encargue de pintar dicho cuadrado. Intentemos identificar las opciones que tenemos para saltar a una zona que nosotros queramos como hicimos anteriormente:



Como vemos solo tenemos dos opciones que a priori no parecen muy prometedoras:
  • CALL [EBP+4]: En ningún momento llegamos a controlar EBP por lo que no podemos contar con ello para dirigir el flujo de ejecución a donde queramos.
  • JMP loc_402360: En principio parece que la dirección a la que salta es estática y no depende de ningún registro (y lo es), sin embargo si nos fijamos en las instrucciones desde el CALL EAX hasta el PUSH previo al siguiente CALL podemos observar lo siguiente:



Vemos que tenemos el control de EDI y que en EDI se escriben ciertos bytes de los cuales también tenemos nosotros el control. Por tanto, lo que podemos hacer es modificar a donde debe el JMP pegar el salto para hacer que ese salto sea al trozo de código que se encargue de pintar el cuadrado y solucionar el reto. Por tantoEntonces deberemos hacer que se modifiquen los bytes de la dirección del JMP (4010BD).

Del byte 4 al byte 8 (Teniendo en cuenta que el primer byte es el 0) de nuestro “key.txt” es sumado a “0D1BE0114C” y almacenado en EDI. Luego el byte 8 del fichero es almacenado en BL. Por último del byte 9 al 13 del fichero se mueven a EAX.

Los siguientes dos MOV modificarán la zona de memoria a donde apunta EDI (y que nosotros controlamos):
  •  El primer MOV mueve a donde apunte EDI el byte octavo de nuestro “key.txt”.
  • El segundo MOV mueve EAX (los bytes de “key.txt” de la posición 9 a la 13) a donde apunte EDI+1.

Como queremos modificar la zona de memoria del JMP (4010BD) tendremos que hacer que esta sea igual a la suma de “0D1BE014C” (harcodeado por el programador) con los bytes del 4º al 8º de nuestro “key.txt. Por tanto:
0D1BE014C + X = 4110BD => X = 2E830F71 (710F831E en Little Endian).

3.4  Dónde saltar para pintar el cuadrado


¡Perfecto! Ahora que podemos modificar a donde salta el JMP solo nos queda saber a qué dirección queremos que dé el salto. Debemos hacer que salte a alguna zona de código que se encargue de pintar el cuadrado en la ventana que ya hemos creado.

Para encontrar dicha zona echemos un vistazo a las otras dos funciones que nos enseñaba IDA (sub_402040 y sub_4023A0):
  • sub_402040: Parece que lo que hace es eliminar la ventana creada por lo que no debe ser la encargada de pintar el cuadrado.


Además si vemos que partes de código la llaman nos encontramos con que se llama justo antes de mostrar un mensaje con el string “error”. 



Por esta información podemos decir que esta llamada es el destructor de la ventana.
  • sub_4023A0: Solamente viendo las APIs que está utilizando podemos darnos cuenta de que está función se encarga de crear una figura geométrica a la cual le establece ciertos colores:



Veamos quien llama a esta función:



Vemos que la dirección 402324 está llamando a dicha función. Si miramos por encima la estructura del código anterior y posterior veremos que es un bucle:



Podemos ver (resaltado en naranja) como se almacena en EDI, EBP y EBX las direcciones de tres funciones (“PeekMessageA”, “DispatchMessageA” y “SwapBuffers”) que más tarde son usadas en el bucle y también la típica estructura de prólogo de una función reservando 28 bytes (1Ch) de espacio en la pila: SUB ESP,1Ch.

Yo cree una función en la dirección 4022FC en IDA presionando la letra “P” para poder verlo gráficamente más fácilmente:



Como podemos ver ninguna parte del código accede a este bucle (que pinta el dichoso cuadrado en la ventana) y por tanto, debemos hacer que nuestro flujo de instrucciones salte a la dirección 4022E0.


Ya tenemos donde queremos saltar para pintar el cuadrado. 


Artículo cortesía de: Alberto García Illera

Leer más...

30 marzo 2014

Enlaces de la SECmana - 220


Leer más...

28 marzo 2014

Windows XP: Consumir preferentemente antes de: 8 de Abril



Una de las muchas noticias de seguridad que han sido la comidilla de los últimos días, con repercusión internacional, es el ataque que se ha descubierto para extraer dinero, de determinados cajeros automáticos, cuya aplicación funciona sobre un sistema operativo Windows XP.

El ataque tiene cierta complejidad puesto que, para su éxito se necesita conectar físicamente un teléfono móvil al puerto USB de la máquina que gestiona el cajero, e inyectar el malware Ploutus, tal y como publicó Symantec. A partir de aquí, mediante el envío de mensajes de texto, es posible decirle al ATM cuánto dinero debe dispensar, ir al cajero y recoger el dinero. Es decir, que se puede hacer en remoto y enviar diferentes “mulas” a “cargar con la cosecha”.

En este sentido, hay que tener en cuenta que Windows XP termina su soporte para cualquier tipo de parche por parte del propio fabricante, Microsoft, el 8 de Abril de 2014 (es decir, que quedan menos de dos semanas). Me gustó mucho la reflexiones que hacía ayer Chema Alonso en El Lado del Mal, en las que calificaba muy acertadamente, a mi parecer, como "negligencia" que determinados puestos de trabajo como los de Administración Pública y empresas que manejan nuestros datos sigan utilizando Windows XP, más allá de la fecha prevista. Coincido con él que en cuanto a sistema operativo de escritorio, es sangrante que no se haya hecho una migración total a Winodws 7 (que en mi opinión, es como Windows Vista, pero sin el proceso que se come todo el sistema).

Sin embargo, para sistemas tan herméticos como un cajero automático, me asaltan las siguientes dudas:

1.-) ¿ Qué han estado haciendo los fabricantes de cajeros automáticos durante este tiempo? 

Siendo que la fecha del fin de soporte y publicación de actualizaciones y parches de seguridad para Windows XP era más que conocida desde hacía años ¿por qué empresas serias como Nixdorf, Bull o NCR no han tenido a bien poner en producción, con tiempo suficiente, nuevos cajeros basados en otro sistema operativo. ¿Van a esperar al 9 de Abril para hacerlo? Lo normal sería que, si tienen pensado poner en producción el sistema en un sistema operativo con soporte, se hubiesen distribuido ya a las diferentes entidades

2.-) ¿ Por qué utilizar un sistema operativo generalista, conocido, accesible por millones de usuarios de todo el mundo? 

Sé de buena tinta que los sistemas operativos que utilizan son versiones más securizadas, y no la versión genérica del mismo. Recuerdo que en el Ethical Hacking Conference en Santa Cruz de la Sierra en Bolivia, asistí a una charla en la que se hablaba de los cajeros de uno de estos fabricantes. Entre otras cosas se hablaba de un módulo intermedio, y cómo a partir de una vulnerabilidad con parches publicados por Microsoft mucho tiempo atrás,  se llegaba a tener control total del mismo. Es decir, que desde este punto de vista, y siendo el sistema operativo Windows como es, que cada parche que se publica, no es posible saber con anterioridad qué ficheros va a modificar y si va a sobrescribir alguna librería que deje inoperativos los cambios que haya hecho cada suministrador de cajeros automáticos. Se presupone que cada entidad bancaria ya protege el ATM a nivel físico de manera que no sea posible su manipulación, más allá de la pantalla táctil para las operaciones del ATM,… y si no hay fallos ahí, no se aplican otros parches.

Ya habló Yago, tiempo atrás, sobre su punto de vista ante la utilización de sistemas operativos “generalistas” o “no especializados”, para el control de determinados elementos de infraestructuras críticas, y dejaba abierta la oportunidad a partir de un sistema operativo que sea más específico, personalizable, modular y que disponga de una base más sólida que un Windows XP: es decir, algo basado en alguna distribución Linux con soporte (¿alguien ha dicho RedHat?) o algún BSD.

3.-) ¿Cuántos exploits 0-Day habrá para Windows XP escondidos esperando al 9 de Abril?

Tengo claro que si tuviese un 0-Day “de alto impacto” para XP, me lo guardaría para el 9 de Abril, cuando estos cajeros se encontrarán "sólos ante el peligro” sin posibilidad que el fabricante solucione un problema gordo. ¿Cuántos de vosotros esperáis solucionar vuestras deudas a partir del 9 de Abril? 

4.-) ¿Han tenido en cuenta los bancos este hecho en su provisión anual de fraude? 

Las entidades financieras, todos los años disponen de un presupuesto destinado a pagar el fraude que tengan que asumir. Normalmente, los bancos disponen de medidas de seguridad elevadas, procesos revisados, redundancia de sistemas, altas inversiones en auditoría y desarrollo seguro. Sin embargo, con el tema de los cajeros, supongo que la responsabilidad final ante un fraude de las características descritas con los ATMs, será responsabilidad de ambas partes, puesto que si la entidad bancaria no aplica las medidas necesarias a la protección física de los cajeros, ataques como Ploutus será igualmente viable. En cualquier caso, ¿habrán tenido en cuenta las entidades financieras que la negligencia de seguir usando Windows XP en los cajeros puede incrementar el coste del presupuesto de fraude? 

5.-) Al igual que hacen los gobiernos ¿Se rendirá Microsoft a los encantos de la banca?


Leí hace unos días (no recuerdo dónde) que había varias empresas que estaban proponiendo pagar a Microsoft por un soporte extra para sus infraestructuras. Al final, es siempre el dinero que hay encima de la mesa quien toma estas decisiones, y si a Microsoft le parece rentable, estoy seguro que “hará la excepción necesaria” para seguir manteniendo el que parece que se va a consolidar como el COBOL de los sistemas operativos.
Leer más...

27 marzo 2014

Intrusión en los servidores de Cerberus anti-robo (Android)

Uno de los peores correos que puedes recibir en la actualidad es en el que se te anuncia que uno de los servicios en los que estás registrado ha sido comprometido, y que tus credenciales se encuentran dentro de un listado de "hashes pendientes de crackear" de algún grupo de graciosillos de cualquier lugar del mundo.

Aún más crítico es si al servicio en cuestión le has delegado una parte de la seguridad de tu dispositivo Android, en la que ibas a confiar para localizarlo en caso de pérdida (al más puro estilo Find My iPhone de iOS)

Cerberus anti-robo es una aplicación de Android que permite localizar un dispositivo registrado en caso de que lo pierdas o te lo roben. La versión gratuita de prueba permite un registro de una semana, y por 3 euros aproximadamente se podría obtener la licencia de por vida. Luis Delgado habló ya de vulnerabilidades en esta aplicación en su serie de posts sobre la actualidad del malware en Android.


Para posteriormente localizar tu dispositivo móvil y gestionarlo, es necesario utilizar un servicio centralizado en los servidores de Cerberus para acceder al panel de control personal.


El equipo de seguridad de Cerberus ha enviado un aviso de seguridad a todos los usuarios (que podréis consultar también en el Google+ de Cerberus) anunciando que unos intrusos, tras comprometer servidores de la red externa, han accedido a más de 90000 cuentas de usuarios, incluyendo los hashes SHA-1 de las contraseñas, y que automáticamente han procedido a la reinicialización de las contraseñas de todos los usuarios afectados. Dichas credenciales se encontraban en un fichero de log, el cual fue rápidamente eliminado. No se accedió a la base de datos, las credenciales en ellas, según cuentan, tienen salt y varias iteraciones de cifrado, y comentan que pronto migrarán a bcrypt. Cuidado con los logs que almacenáis en vuestras aplicaciones, aunque sean temporales, pueden contener información que pudiera ser accesible por terceros.

Lo más curioso es que se ha detectado el acceso por parte de usuarios ajenos a 3 de las cuentas obtenidas.

¿Se tratará de un ataque dirigido, para obtener la localización de un conjunto de dispositivos concretos sobre los que se tenía constancia que estaban utilizando esta aplicación anti-robo? ¿O quizás al obtener todo el listado de usuarios, justamente esas 3 cuentas las identificaron como interesantes? 

Nunca lo sabremos.

Leer más...

26 marzo 2014

Mi experiencia personal en RootedCON 2014 #rooted2014




Al igual que he hecho los otros cuatro años, aunque ya sé que este año llevo bastante retraso, quiero dejar constancia de cómo he vivido, en primera persona, lo que ha sido la quinta edición de RootedCON, uno de los Congresos de Seguridad “de referencia” del panorama nacional español.

Si las tres primeras ediciones me teníais haciendo crónicas diarias de las diversas charlas, incluso estrenándome en 2012 como ponente en un evento de magnitud tal, el año pasado decidí vivir la Rooted como un asistente más, disfrutando cada momento, sorprendiéndome con cada frase de las excelentes charlas cuidadosamente seleccionadas.

Este año, en la quinta edición de Rooted, con la intención de tener “espacio de almacenamiento” suficiente para más de 1000 asistentes, además se visitó de gala en el Hotel Auditorio, famoso por ser el lugar de celebración de los premios Goya. Y,… no me preguntéis por qué, pero mi experiencia fue distinta. No sé si es que Rooted es el evento que congrega a profesionales de la Seguridad que vienen desde todas partes de España, e incluso de mucho más allá, como mi amigo Claudio y Maxi Soler desde Argentina, Ezequiel o Pedro Laguna desde Londres, entre otros que recuerde haber visto…


No sé si es por la cantidad de amigos que he hecho en estos últimos años, la cantidad de gente que he conocido entre eventos, clientes, cenas, bautizos y comuniones,… que me resultaba complicado hasta poder acceder a la sala de actos sin encontrarme con alguien con quien no me quedara hablando. 

A muchos de vosotros os había visto hacía una semana,… pero a otros de Rooted en Rooted. Así como el año pasado viví la Rooted como asistente, este año estuve más en el hall del hotel, que en el propio salón de actos, haciendo networking, hablando y riendo con gente hasta el punto de quedarme totalmente afónico.


Sin embargo, me gustaría resaltar varios puntos, de las charlas que ví. Me atrevería a decir que la charla mejor puntuada de este año será la de "Hacking de Aviones" de Hugo Teso. Sin desmerecer a los demás, de las que ví, fue sin duda la que más me impactó, tanto por lo candente del tema (recordemos que justo el día de la charla “se perdió” el Boeing 777 de Malaysia Airlines) como por lo bien expuesto por parte de Hugo.

Un ponente que no defrauda es el gran Raúl Siles, aunque he de decir que me quedé con las ganas de que de verdad hubiera sido capaz de instalar una versión anterior de IOS en un iPhone. Hubo más de una ocasión en la que dije… y ahora es cuando el tío dice cómo lo ha hecho y nos quedamos todos con la boca abierta. Una pena que eso nunca llegara, aunque el ataque Back to the Future, fuese igualmente ingenioso. Como dije por Twitter, Siles es uno de los ponentes que más admiro dentro del panorama español, y pienso que tiene una puesta en escena, así como un arte para contar las cosas, que te enganchan desde el principio hasta el fin.

Otra de las charlas que me pareció impresionante, pero que lamentablemente sé que no fue bien valorada es la de Joaquín Moreno, cuyo tema principal era Análisis Forense en Mac OS X “en profundidad”. No sé si la coletilla del título tiene algo que ver con el curso online de Análisis Forense que hemos estado impartiendo en Securízame, y que hemos definido como #forenseenprofundidad. En cualquier caso, el tema me pareció sumamente interesante. Joaquín quiso contar todo en una charla de una hora y quizá lleno el buffer de un alto porcentaje de los asistentes. Reconozco que había que estar con los 5 sentidos a la explicación para no perderse, pero reconozco un trabajo de investigación excepcional.

Pese a que la charla de Chema Alonso la había visto un par de veces, me hizo mucha ilusión ver en primicia en Rooted V, la web de eGarante integrada, en primicia, con Latch.

Otras charlas que me resultaron curiosas fueron la del fiscal Jorge Bermudez, poniendo un toque “legal” al asunto con un humor que hizo las delicias del público. Me gustaría destacar también las charlas de Pepeluxx y Victor Seva proponiendo un sistema seguro de comunicaciones VoIP, o la de los amigos de @fluproject, que también me hicieron permanecer "pegado al Televisor" del escenario.




Es más que loable la progresión que ha tenido este evento, fruto del esfuerzo llevado a cabo por el ejército de organizadores y, cada vez más voluntarios, que hacen posible un despliegue ingente de gente... 

Nos vemos en la RootedCON VI ó 6 ó "110",... 
Leer más...

25 marzo 2014

Muy buenas a todos. En los siguientes cuatro post expondré como resolví y posteriormente conseguí ejecutar código en un reto de cracking que me envió un amigo. Escribí un writeup ya que me parece interesante la protección anti-cracking que tiene y sobretodo porque la ejecución de código no viene supeditada a un buffer overflow (de ningún tipo), format string, use after-free o demás formas de explotación documentadas.

El writeup es largo y por eso hemos decidido dividirlo en varias entregas ya que al ser un tema denso con mucho ensamblado de por medio, es fácil perderse si se publicase del tirón. La primera parte es la más corta y básica pero a partir de la segunda ya se “intensifica” la questión.

Para los que no tengan conocimientos previos de ensamblador recomiendo un paper muy claro y aclarador que escribió mi amigo, a pesar de ser del Barça, Daniel Romero hace cosa de un año. ¡Espero que os guste!

1 Resolviendo el reto de forma “oficial”

1. Primer vistazo

Hace cosa de un mes mi amigo y compi de trabajo Martín Vigo (@martin_vigo) me envió un reto de reversing que había codeado un amigo suyo (http://www.iquilezles.org/). El binario se puede descargar desde el siguiente link: http://goo.gl/tLKlsu
El reto consistía en hacer que un binario de Windows compilado para x86 mostrara una ventana. Un archivo png con dicha ventana venía adjunto al propio archivo del reto:

image

Lo más relevante de esto, que podremos usar posteriormente, es el nombre de la ventana que podemos ver que es “test_app”. Este nombre salvo que esté ofuscado o cifrado en el binario puede darnos una idea de qué función debemos alcanzar para pintar dicha ventana y por tanto solucionar el reto.
Lo primero que hice fue ejecutar el binario para ver que ocurría y esta ventana es la que obtuve.

image

Por tanto, parece ser que el binario está esperando, bien en un archivo o como argumento, una licencia.

2. Strings y desensamblado

El siguiente paso es cargar el binario en vuestro desensamblador favorito para ver que funciones y librerías carga. En mi caso he usado IDA PRO:

image

Tenemos muy pocas funciones, por lo que no debería ser demasiado difícil encontrar en el ensamblado  lo que el programa espera o lo que está haciendo. Tras mirar los strings vemos que existe una referencia al anterior nombre de ventana comentado “test_app”:

image

De algún modo debemos conseguir que nuestro flujo de ejecución acceda a cierta parte del ensamblado que lea esa dirección de memoria ya que será utilizado para crear la ventana con la que resolveremos.
Rápidamente vemos que el binario intenta leer un fichero de nombre “key.txt” en el mismo path donde se encuentra el binario.

image

Podemos ver en la documentación de CreateFileA (http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx) que se está usando el argumento 3 como “dwCreationDisposition” por lo tanto solo se abrirá un descriptor del fichero en caso de que el archivo exista.

Si el fichero “key.txt” existe la función CreateFileA devolverá un descriptor del fichero en el registro EAX. En caso de no existir devolverá FFFFFFFF y por tanto al hacer INC EAX, OR EAX EAX, activará el flag ZF y saltará a “loc_402360”.

3. Debugueando y entendiendo el código

3.1  Crear la ventana

El primer objetivo parece que será crear la ventana que presumiblemente tendrá el nombre “test_app”. Para saber cómo hacerlo lo más cómodo es debuguear el binario.
Crearemos un fichero “key.txt” cuyo contenido es “AAAAAAA”. Pondremos un breakpoint tras  el CALL a CreateFileA y enseguida llegamos al segmento de código que realmente nos interesa:

image

He comentado un par de detalles que nos interesan:
  • El primer CALL es una llamada a la función ReadFile que toma 5 parámetros.
  • El tercer parámetro pusheado es el número de bytes del fichero que se van a leer del fichero “key.txt”. En este caso solo 14h (20) bytes.     
El resultado de la lectura se almacena en una zona de memoria apuntada por ESI. Ahora veremos instrucción a instrucción lo que se está haciendo:
  • Se mueve 7A40B660 a EAX.
  • Se suma a dicho valor lo existente en los primeros 4 bytes a los que apunta ESI que en este caso son los 4 primeros bytes de nuestro “key.txt” (“41414141” = “AAAA”). La suma se almacena en EAX.
  • Se llama a la dirección resultante.
Por tanto los primeros 4 bytes del fichero “key.txt” serán los que se utilizarán para decidir a qué dirección haremos el CALL tras sumar “7A40B660”.


Artículo cortesía de: Alberto García Illera

Leer más...

24 marzo 2014

Creando un entorno de análisis de aplicaciones Android (Parte 3)

En el artículo anterior vimos las posibilidades a nuestro alcance cuando trabajamos con un entorno virtualizado para realizar el análisis de una aplicación Android.

En este artículo vamos a acercarnos a algunas técnicas y herramientas que nos servirán para obtener unos buenos resultados en el análisis del ejemplo de App SMS, whatsapp, LLAMADA - SPY .

Analizando la información recuperada


Al final de la entrega anterior recuperamos cierta información que nos puede ser útil durante el resto del análisis, por ejemplo si revisamos el listado de procesos que realizamos al reiniciar el sistema tras instalar la aplicación nos encontraremos con que una nueva aplicación se ha iniciado automáticamente:


Por otro lado y a través de los ficheros modificados podemos ver los APKs instalados y como se ha descargado en la SD un paquete light.apk:


Si generamos un resumen con MD5 a los paquetes de spy2mobile y light veremos que se tratan del mismo fichero:


Y como vimos en las trazas de las comunicaciones del artículo anterior podemos deducir el proceso que ha seguido el troyano: a través de la aplicación com.supportcaptcha se realizó la descarga en la SD del paquete light.apk, que posteriormente se instaló bajo el nombre com.spy2mobile.light y el cual se inicia con el arranque del dispositivo.

Pero continuemos obteniendo información con otras herramientas.

apktoolkit


Nos sirve para extraer los recursos de la aplicación. Para usarla es necesario copiar el APK que queremos analizar en el directorio /usr/share/apktoolkit/ , en nuestro caso vamos a centrarnos en el troyano que se descargó vía Internet una vez instalada la aplicación:



El resultado de esta aplicación nos permitirá inspeccionar el código smali (código ensamblador para el formato dex) sobre el que podremos localizar comportamientos anómalos a través de comandos en el sistema:



Además utilizando el explorador del sistema de ficheros podremos revisar los recursos recuperados del APK donde encontraremos las imágenes, definición de pantallas, textos, ficheros incluidos en la aplicación (tenéis más información acerca de las estructuras de directorios utilizadas por Android aquí)...


Dentro de los recursos que encontraremos cabe destacar el fichero AndroidManifest.xml. donde se definen versiones, permisos, servicios, actividades... información esencial para que Android tenga conocimiento de cuándo y cómo ejecutar los componentes de la aplicación.
En el caso de la aplicación que estamos analizando podemos ver como nos hacen un all-in de permisos:


En ese mismo fichero también se reflejarán los broadcast receivers:


Como podemos ver la aplicación se declara a la escucha de llamadas salientes y del arranque del dispositivo. Cualquiera de estas dos acciones desencadenará que la clase com.source.MainReceiver gestione el evento, dato que en términos del arranque ya habíamos identificar al listar los procesos al inicio del sistema.

Herramientas d2j


Esta herramienta se utiliza de forma habitual para convertir un fichero en formato dex (los APK) en un fichero en formato jar:


Una vez realizado el paso anterior es posible decompilar el contenido del jar con las herramientas jd-gui o jad.
Es interesante comentar también que este conjunto de herramientas dispone de otras utilidades que nos permitirán:

Modificar el contenido de un APK a través de código Jasmin.
No profundizo en esta opción ya que se escapa del objetivo del artículo, aunque podéis imaginar el uso de esta herramienta para modificar aplicaciones y publicarlas en mercados alternativos.

Des-ofuscar código bajo un criterio establecido de forma manual.
Vamos a ver esta opción más en detalle. Primero abrimos el fichero jar generado con jd-gui:


Si exploramos las clases encontraremos que el código que nos interesa se encuentra ofuscado:


El siguiente paso será extraer los nombres de paquetes, clases, métodos y atributos para editarlos:


Modificamos su contenido para hacerlo más legible (aunque con sólo extraerlos se generarán nombres aleatorios que serán algo más sencillos de identificar que los ofuscados):



A continuación insertaremos estos nombres dentro del fichero jar y volveremos a abrirlo desde jd-gui:


El resultado que veremos será el siguiente:


sqlitebrowser


Con esta herramienta podremos ver de forma gráfica las bases de datos de tipo SQLite, de modo que lo primero que haremos será instalar el paquete en la máquina de análisis con:

apt-get install sqlitebrowser

Una vez instalada la herramienta la encontraremos en Applications > Programming > SQLite Database Browser.
El siguiente paso es disponer de la base de datos que queremos analizar, de modo que continuando con el ejemplo que teníamos entre manos vamos a intentar localizar su base de datos.

En Android lo habitual es que para gestionar las bases de datos se cree una clase que herede de la clase SQLiteOpenHelper, de modo que vamos a intentar localizar esta cadena en el código:


Tenemos una clase ganadora: com.source.b.f . Esta misma búsqueda la podemos realizar desde jd-gui para ver el código de forma más clara:


Si curioseamos esa clase nos encontraremos el siguiente método:


De modo que todo apunta a que tendremos una base de datos con nombre system.bd, la descargamos desde su directorio por defecto (/data/data/com.spy2mobile.light/databases/) y la abrimos con sqlitebrowser:


Y aunque ya sabíamos desde el principio que estábamos analizando una aplicación para espiar el uso del dispositivo, confirmamos a través de la base de datos las múltiples tablas preparadas para capturar la información del usuario.

Conclusiones

Como veis tenemos a nuestro alcance múltiples herramientas que nos permitirán transformar la aplicación para que la podamos analizar desde distintas perspectivas, haciendo que los resultados del proceso de análisis se reduzcan a una cuestión de habilidad, experiencia y el tiempo que le queramos/podamos dedicar.

Finalmente os dejo una captura de la pinta que tiene el panel de administración Web del software espía que al final he podido configurar desde un dispositivo físico:




Artículo cortesía de Miguel Ángel García
Twitter: @nodoraiz
Leer más...