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:
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.
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 Androidpara el análisisde seguridaden las redes inalámbricasy la captura deFacebook, Twitter,LinkedIn yotras cuentas.
También dispone de otra aplicación en su web DroidSheep Guard la cual trata de detectarARP-Spoofing en la red, talescomo un ataque deDroidSheep, FaceNiffy 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 aAplicaciones enlaPlay Store.
Los enlaces aaplicacionesque no están enlaPlay Store
Los enlaces acódigo fuentede aplicaciones
Enlaces asitios webde la aplicación.
Los enlaces aGoogleelnombre de la aplicaciónola aplicacióndel paquete.
Alternativasenlaces aGoogle 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.
Todos sabemos, tanto aquellos que nos dedicamos al mundillo de la seguridad informática, como los que estan empezando que permanecer en el anonimato es uno de los aspectos más importantes de la Seguridad Informáticasi deseallevar a cabopruebas de penetraciónen un equipo remotoentonces se requiereconexión activaque seguramenterevelar su identidad, a veces es necesariopara ocultarsu identidadmientras se hacela evaluación de vulnerabilidaddebido asu anonimatoy la seguridad.
Proxychains basa su funcionamiento en ProxyChaningque ess un conceptoque es muy útilpara ocultaruna identidaden Internet.
Pero veamos qué es Proxy Chaining
El funcionamiento normal de un proxy es cómo el siguiente gráfico:
Pero el funcionamiento de Proxy Chaining es el siguiente:
Así que podemos decir que Proxy Chaining es el proceso de usar varios proxys en cadena.
Aclarado este concepto, vamos a ver cómo funciona Proxychains.
Todos sabemos que proxychains es una aplicación Open Source que nos permite realizar conexiones TCP y DNS usando un proxy, como por ejemplo TOR
Ahora bien, TOR no es requisito indispensable para usar proxychains ya que podemos usar cualquier tipo de proxy SOCKS4, SOCKS5 y HTTPS.
Ya sabemos el conjunto que hace proxychains con proxy chaining y su alcance, como bien se describió en el post anterior
Tan sólo añadir una cosilla más, en el fichero de configuración de proxychains vemos tres posibles usos del mismo:
Dynamic Chain: muy útil si estás usando proxys públicos. Su funcionamiento es recorrer los proxys en el orden escrito y saltarse los proxys caidos (muertos)
Strict Chain: igual que el anterior, pero no se salta los proxys caidos (muertos)
Random Chain: toma los proxys en orden aleatorios
Espero haberos aclaro un poco más el concepto de funcionamiento, así como la forma de trabajar proxychains :)
Cada día son más los juristas que intervienen en ponencias de Seguridad, prueba de ello es la magnífica intervención del Fiscal de Delitos Informáticos en Gipuzkoa, Jorge Bermudez, en lapasada RootedCon 2014. Esto ha hecho ver a muchos las necesidades que se encuentran a día de hoy en la justicia en el campo de la Seguridad de la Información .
El artículo de hoy va dirigido a un profesional de la materia, uno de nuestros amigos que no falta nunca a una cita de Seguridad en las Hack&Beers, él es nuestro abogado particular, Rafael Perales Cañete, el cual nos ha contestado muy amablemente a unas serie de preguntas.
Rafael se define como un abogado 2.0, lleva ejerciendo en su despacho - Derecho más Informática D+I - desde 1996. Dentro de su extenso curriculum podemos dectacar que es miembro de la APEP (Asociación Profesional Española de Privacidad) y de ENATIC (Expertos nacionales de la Abogacía TIC). Entre sus especialidades se encuentran el Derecho Administrativo, Privacidad y Protección de Datos y actualmente está ampliando su campo a la seguridad de la información.
Rafael nos cuenta que "no pierde contacto con el resto del derecho, ya que la seguridad de la información y todas las ramas del derecho tienen que ver con las tecnologías de la información y la comunicación".
Sus comienzos en la Seguridad Informática.
"Desde que vi un ordenador. Un compañero en la mili me enseñó a modificar el antiguo comand.com en formato hexadecimal y a cambiar la orden copy por delete" - menudo compañero peligroso - "A partir de ahí ya empecé a ver la primigenia ingeniería social que incitaba a ejecutar archivos ocultos en los antiguos disquetes de 3.5"
"Mi preocupación por la seguridad ha ido pareja a la progresiva adquisición de conocimientos informáticos: mientras más sabía más comprendía las vulnerabilidades, y de igual forma me daba cuenta de que los usuarios solamente usaban la tecnología parcial e inconscientemente" - Rafael se planteó estudiar informática pero al final se decidió por el derecho. Los códigos, las leyes y la jurisprudencia sustituyeron a los libros de informática.
Percepción de la realidad de los colegas de profesión.
Según Rafael habría que distinguir entre dos tipos de abogados: los que utilizan la tecnología TIC "voluntariamente" y a los que “se les ha obligado” a utilizarla. Nos comenta que "El grupo que le gusta y usa las nuevas tecnología tiene un nivel bajo y sólo a nivel de usuario" - no llegan al aprobado - "El resto literalmente se queja constantemente de la 'modernidad' " - los puntúa con un valores por debajo de cero -.
Las necesidades que Rafael percibe entre colegas de profesión son totales, nos comenta que no hacen copias de seguridad, tienen ordenadores antiguos con programas desactualizados - apuesto que XP forever -, envían sentencias penales por cuentas de correo públicas y sin cifrar y un largo etcétera.
Comenta sobre sus colegas que "No tienen percepción de la realidad, temen de forma difusa 'lo que te pueden hacer' pero prefieren ignorarlo". Un abogado le comentó literalmente "he dejado de leer lo que pones en la revista porque me da miedo y parece que no puedo hacer nada de lo que hago".
Medidas de Seguridad que utiliza Rafael.
Las medidas de seguridad que utiliza Rafael son dignas de admiración, más de un administrador de sistemas debería recapacitar. Aquí van algunas de las que utiliza:
Copias del sistema.
Discos clonados.
Cifrado de discos.
Copias en Usb y hd de portátiles.
Antivirus de pago.
Firewall.
Antimalware
Nos comenta que hace caso de las medidas que pone el RD 1720/2007, las que le aconsejan sus informáticos y las que le damos el equipo de Hack&Beers. Como dice Rafael, "Todas son pocas, no se puede asegurar nunca al 100%" y hace alusión a una frase muy conocida en el mundo de la seguridad y que he utilizado en alguna jornada de Hack&Beers "una frase que te oído y que me parece genial es 'la seguridad de un sistema es igual a la seguridad de su punto más débil'"
Otra de las medidas que también utiliza Rafael, y en los tiempos que corren me parece fenomenal, es la siguiente, y cito sus palabras textuales ante la pregunta de por qué no utiliza Whatsapp: "Respecto a lo de Whatsapp lo utilizo con un dispositivo con número de tarjeta y con tres contactos en la libreta del teléfono"
El abogado de la Hack&Beers y las vulnerabilidades presentes en su profesión.
"Me encanta que me llaméis el abogado de H&B, quiero aprender más sobre tecnología y quiero enseñaros más sobre derecho: nuestra simbiosis será perfecta, y es la nueva filosofía de mi despacho (Derecho más Informática)"
Las vulnerabilidades que ve presentes en el ámbito de su profesión son todas las que nos podamos imaginar:
Envio de la declaración de un imputado por whatsapp.
Redes inalámbricas desprotegidas o con configuración por defecto.
Ausencia de copias de seguridad.
Ausencia de antivirus.
Encuentra también mucha falta de formación en aspetos como certificados digitales y nos comenta que "ya mismo tendremos que firmar mucho digitalmente para relacionarnos con la Administración electrónica y con los juzgados vía LexNet y PenalNetyni siquiera saben lo que es eso". Curiosamente "algunos llaman 'la tarjetita' al certificado ACA –Autoridad de la Certificación de la Abogacía- presente en el chip criptográfico de nuestro carnet colegial"
El derecho siempre va por detrás de la sociedad.
Respecto a vacíos legales y necesidades presentes en la actualidad, Rafael nos comenta la ponencia del fiscal Jorgue Bermudez comentada anteriormente, donde nos dice: "Ha definido muy bien el problema del 197.3 del Código Penal que penaliza a todos los hackers sin distinción". Rafael encuentra incongruencias en la legislación, "como la de la Ley 25/2007, de conservación de datos, que la hace inoperante al tratar solo de delitos graves".
También explica que existe mucha normativa: firma digital, administración electrónica, protección de datos, etc … y que algunas leyes nacen ya antiguas, como ejemplo nos comenta la regulación del RLOPD de los soportes informáticos.
Sin embargo hay un poco de esperanza y comenta que "Surgen y aparecen tímidamente las TICs en la legislación: por ejemplo en la LAU se incorpora la posibilidad de que arrendador y arrendatario puedan notificarse por correo electrónico, en la ley de sociedad de capital se regula la convocatoria web de una junta general..."
Todos estos temas son objeto de estudio en su despacho Derecho más Informática D+I, podéis encontrar mucha más información en su Web http://derechomasinformatica.es/
Curiosidades en un caso real con un dispositivo Android.
Rafael nos comenta uno de los últimos casos en los que ha estado trabajando: "caso de mula de paypal, con una conexión WiFi y usando ingeniería social hicieron que instalasen un programa en un dispositivo Android para pagar la cuota de Whatsapp y tomaron su número de cuenta corriente para realizar estafas en su nombre"
Necesidad de formación en Seguridad de la Información.
Rafael comenta que la formación sobre Seguridad de la Información "Es uno de mis caballos de batalla en la comisión para los alumnos del Máster de la Abogacía y de la Escuela de Prácticas, obviamente también en la Universidad de Córdoba. En nuestra ciudad no son receptivos a ningún tipo de formación ni en seguridad informática ni en el uso de TICs. Los abogados ven esencialmente al ordenador como una máquina de escribir y al correo electrónico como un sustituto del fax"
Nos comenta un caso curioso de una joven abogada , la cual le preguntó hace unos meses que dónde compraba los códigos (Código Penal, Civil, Estatuto Trabajadores, etc) "¡Ella no tenía base de datos de legislación y no sabía manejar la que pone el Colegio de Abogados en la Biblioteca. No saben buscar por Internet ni los boletines oficiales..."
Casos de delitos informáticos más comunes.
"Por ahora lo que más me consultan son sobre aportación de pruebas en soportes digitales. Surgen casos sobre injurias, ciberacoso, difusión de pornografía infantil... Los compañeros me consultan y ni siquiera me pasan los asuntos porque no consideran que sea necesario un abogado especialista en TICs"
Conclusiones.
"Venimos del siglo XIX, continuamos en dicho siglo y caminamos hacia el precipicio."
Pues con esas palabras se despide Rafael y le damos la enhorabuena porque es un placer tratar con personas tan interesadas y comprometidas con la seguridad de la información. Espero os haya resultado interesante.
Un handshake desde el equipo de Hack&Beers !!
"Todavía no he visto un abogado que defienda y asesore a los hackers"
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.
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:
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.
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 !!
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:
El desarrollador de la aplicación: ¿quién es? ¿qué tipo de aplicaciones ha desarrollado?
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.
Otras aplicaciones del mismo desarrollador, para así analizar su código y encontrar posibles similitudes.
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 apktoolque 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:
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:
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:
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.
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:
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.
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:
Falta de cifrado o cifrado débil.
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.
Uso de texto plano tras fracasar en el cifrado de los datos.
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:
Almacenar datos sensibles en ficheros de texto plano.
Desproteger los Content Provider, de tal forma que se permita el acceso desde cualquier aplicación.
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:
Las actividades pueden verse comprometidas por código o apps maliciosas y poder acceder a la comunicación IPC.
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 !!
