martes, 7 de marzo de 2017

Cracking Windows Passwords

Ya ha pasado casi un año desde la 2ª edición de la Security High School y pronto tendremos la tercera. En el artículo de hoy veremos un tema que tratamos mis compañeros Alfonso Luque, Rafael Santiago y yo en la charla Cracking Windows Password. Os animo a acudir a este tipo de eventos para compartir información donde además de aprender se conoce mucha gente. 



Dicho esto comencemos con el articulo.

¿Cómo se almacenan las claves?
Normalmente cuando se trata de almacenar una contraseñas se almacena en una base de datos cómo MySQL o SQLite, y digo normalmente porque no es raro encontrar programas que almacenen contraseñas en texto plano y lo más importante, sin guardar el hash de la clave en lugar de la misma clave.

¿Qué es un hash?
Un hash es el resultado de aplicarle una operación matemática irreversible a unos datos de entrada (en este caso una contraseña) dando como resultado una cadena de longitud fija.
Por ejemplo:
El resultado de realizar una función hash a la cadena “1234” sería “81dc9bdb52d04dc20036dbd8313ed055” y el resultado de realizar la misma función a la cadena “pepito” sería “c482af336ae81e4634dc84f94e67eed8”.

Como podemos observar las cadenas entrantes son de diferente longitud y como resultado se consiguen cadenas totalmente diferentes salvo por su longitud que es la misma.

Tipos de hash
Existen muchos tipos de hash y cada uno realiza de forma diferente la función matemática que genera la cadena de salida, para una misma cadena de entrada.
Por ejemplo:
El hash  MD5 de “Admin”  sería “21232f297a57a5a743894a0e4a801fc3” mientras que el hash SHA-256 de “Admin” sería “8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918”

Hay tipos de hash más antiguos como el MD5 que ya han sido vulnerados y por lo cual no son seguros, y otros más nuevos como SHA-3 que por el momento son más seguros. Pero en este artículo nos centraremos en dos tipos de hash en concreto, LM y NTLM, que son los que utiliza Microsoft para almacenar las contraseñas de los usuarios de Windows.

LM (LAN Manager)
Es el primer hash que utilizaron los sistemas Windows, sus características y método para realizar el hash son ya muy conocidas, esto sumado a que los métodos que utiliza no son muy buenos lo convierten en carne de cañón vulnerable. Ha sido utilizado por Windows desde el Windows 3.1 hasta el famoso XP, pero a partir de Windows Vista, las contraseñas dejaron de almacenarse con LM como medida de seguridad y fue sustituida por su sucesor NTLM, aunque, esta medida se puede revertir mediante configuración y volverse a activar ya que Windows no la quitó por completo por motivos de retro compatibilidad.
Estas son sus características y los patrones que seguiría si le hiciésemos la función hash a la cadena “Admin1234":
  • - Rellena de “0” hasta llegar a 14 caracteres (admin123400000)
  • - Convierte todas las letras a mayúscula (ADMIN123400000)
  • - Parte la contraseña en dos (ADMIN12 3400000)
  • Utiliza el cifrado DES en las dos partes.

Dado que el propio algoritmo parte en 2 la contraseña antes de realizar la función hash, resulta más fácil aún romper la contraseña ya que es más fácil descifrar 2 cadenas de 7 dígitos en paralelo que 1 de 14 dígitos.

¿Por qué la contraseña debe de ser de más de 7 caracteres?

Por defecto el algoritmo rellena con "0" hasta llegar a 14 caracteres, entonces al aplicar esta operación en una cadena de 7 caracteres, los otros 7 restantes sería "0000000", teniendo en cuenta que el algoritmo también parte en 2 la contraseña, es fácil identificar contraseñas de menos de 8 caracteres ya que siempre terminan igual (con el resultado de hacerle el hash a 0000000).

NTLMv1 y NTLMv2 (NT LAN Manager)


Versión mejorada de LM que incluye algunas mejoras de seguridad con respecto a su antecesor. El proceso de ataque a este tipo de hash conlleva un aumento exponencial de tiempo sobre todo si se utilizan más de 8 caracteres, mezclando mayúsculas, minúsculas, números y caracteres especiales.
  • Diferencia entre mayúscula y minúscula
  • - Más simple que LM
  • Más robusto a su vez
  • Utiliza cifrado MD4

¿Dónde guarda Windows los hash de las contraseñas?
Por defecto Windows guarda los hash de las contraseñas en la ruta %systemdrive%\Windows\System32\config , en un archivo llamado SAM cuyo contenido está cifrado. Pero como Windows no sabe hacer nada a derechas, almacena la “clave” que descifra el contenido del fichero SAM en otro fichero sin cifrar llamado SYSTEM que está en la misma carpeta... 


En las versiones Windows Server con Active directory los hashes se almacenan en la ruta %systemdrive%\Windows\NTDS en un archivo llamado ntds.dit, pero no entraremos en detalles ya que nos centraremos en las versiones antes mencionadas de Windows.

Proceso para obtener los hashes de los usuarios
Ahora pasaré explicar cómo obtener los hash de los usuarios del equipo a auditar. Para ello utilizaremos Kali Linux para exportar los hash a un fichero de texto plano. Por si os preguntáis qué es Kali Linux, es una distribución Linux diseñada para hacer auditorias de análisis forense que incluye multitud de herramientas para ello.

En primer lugar tendremos  que bootear con una versión live de Linux como por ejemplo Kali.


Utilizaremos  el modo forense, que lo que hace es impedir al sistema montar automáticamente cualquier dispositivo de almacenamiento, más adelante veremos el porqué.


Una vez inicie el sistema procederemos a identificar el disco en el que está Windows.


Utilizaremos para ello el comando fdisk, y del resultado de este nos interesa saber cual es el dispositivo donde está Windows, en este caso /dev/sda1 y su formato para posteriormente montarlo.


Ahora que tenemos identificada la partición de Windows la montamos, previamente tendremos que crear una carpeta donde lo montaremos, después utilizamos el comando mount con la opción –t para especificar el formato de la partición y –r para montarlo en modo “solo lectura”, ya que estamos realizando un análisis forense y no podemos modificar nada del disco (de ahí el utilizar el forensic mode al principio).


Como he explicado anteriormente, el fichero SAM es donde se almacenan los hash, y para obtenerlos necesitaremos además de ese fichero, también necesitaremos el archivo SYSTEM para poder descifrar el contenido del SAM.


Para ello nos iremos primero a la ruta Windows/system32/config y nos los copiamos a nuestra carpeta personal. Una vez copiemos ambos ficheros, usaremos la herramienta samdump2 con la sintaxis samdump 2 –o ruta_salida SYSTEM SAM


Como resultado de utilizar samdump2 obtendremos un fichero con este formato,que como podemos observar hay dos hash por cada cuenta.
El de la izquierda es LM y el de la derecha NTLM


Si nos bien fijamos nos daremos cuenta de que el hash de la izquierda se repite en diversas ocasiones, y no, no es porque sean la mísma contraseña. En esta prueba hemos utilizado un windows 7, recordemos que a partir de windows vista el hash LM estaba desactivado como medida de seguridad. Entonces os preguntareis ¿que leches es ese hash? aa3b435b51404eeaa3b435b51404ee es el resultado de aplicarle la función hash a un valor NULO, y como una de las características de LM es partir la contraseña en dos partes el resultado es una cadena con los caracteres “aa3b435b51404ee” repetidos 2 veces (null-null).

 ¿Como crackear los hash?
Existen diferentes modos para obtener la contraseña de los hash, podemos optar por el método online que es el más fácil, y el método offline que es un poco más complejo, ya que tenemos que interactuar con diferentes herramientas.

Método online
Es simple, utilizando BBDD online de las cuales hay miles y con solo escribir el hash nos dirá la contraseña si la tienen en su base de datos.
Ejemplos de páginas que podemos utilizar:




www.somd5.com/  (si sabemos un poquito de japones XD)


Método offline 1: Fuerza bruta
Es el método más simple y a la vez más complicado para obtener resultados ya que consiste en probar TODAS las combinaciones posibles dentro de un charset determinado que nosotros le indiquemos al programa.

Teniendo en cuenta que una contraseña puede tener mayúsculas, minúsculas , números y caracteres especiales abcdfghijklmnñopqrstuvwxyz - ABCDFGHIJKLMNÑOPQRSTUVWXYZ - 1234567890 - (simbolos)  el numero de posibles combinaciones asciende a miles o incluso millones todo dependiendo de la longitud de la contraseña, esto traducido en tiempo... demasiado si somos impacientes.

Así te puedes quedar esperando a que saque la pass...
Método offline 2: Ataque por diccionarios
Este método es parecido al anterior con la diferencia de que en vez de probar TODAS las posibles combinaciones, probará todas las combinaciones que le pasemos a través de un diccionario de palabras clave, el cual podemos crear nosotros mismos o bajarlo desde internet donde hay infinidad de diccionarios, incluso hay webs que ofrecen diccionarios basados en temas concretos, como por ejemplo videojuegos, películas, grupos de música, etc...

Método offline 3: Ataque por tablas RAINBOW


Este será el método que utilicemos en este articulo las tablas rainbow, que resumiendo un poco cómo funcionan lo que hacen, son tablas que almacenan 2 cadenas de caracteres, una palabra inicial y otra final, la palabra inicial es una completamente aleatoria, y la palabra final es el resultado de hacerle la función hash a la palabra inicial y después al resultado de esta operación realizarle una función de reducción, que a su vez se le vuelve a realizar la función hash y después otra función de reducción, así consecutivamente hasta un determinado numero de veces. Al pasarle nosotros el hash, comprobará si la palabra final que da este hash coincide con alguno de los que tiene la tabla.


Para realizar esto utilizaremos un programa llamado OPHCrack, el cual es bastante fácil de utilizar, además tiene una versión live para bootearlo en una memoria USB y realizar todo el proceso anterior de obtención del hash y de forma completamente automática empezar a crackear los hashes que tenga el equipo (todo bien mascadito). Nosotros utilizaremos el programa para windows y lo haremos de forma manual.

Proceso de crackeo con OPHCRACK
El proceso es simple ya que se divide en tres sencillos pasos:




1º: Cargamos los ficheros que hemos obtenido previamente en formato txt con samdump2

Le damos a PWDUMP y seleccionamos nuestro "hashes.txt"




2º: Cargamos las tablas RAINBOW
Simplemente tendremos que seleccionar la tabla que queremos cargar y indicarle la ruta de donde está. El programa viene por defecto con 4 tablas de diferentes tamaños y para diversos sistemas como son Windows XP y Vista.


También podemos utilizar tablas descargadas de internet, que las hay de todo tipo y tamaños,  desde los 2 GB hasta los 500GB o más...

3º: Pulsar crack y esperar...
El resultado después de 1 hora de espera es este. 


Una lista con todos las contraseñas encontradas salvo una… la del usuario SHS2016, y es porque a la hora de crear la contraseña tuvimos en cuenta las recomendaciones típicas.

El objetivo de este articulo era haceros ver lo fácil que resulta vulnerar las contraseñas en el sistema operativo Windows, así que utilizad contraseñas con las recomendaciones de seguridad que ya conocemos.

Ahora os dejaré una POC en video para que veáis todo el proceso paso a paso.


Esto ha sido todo, espero que hayan aprendido tanto como yo aprendí en su día con Eduardo Sánchez "mi profe de seguridad" y que les haya servido de ayuda.

Un saludo :)


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.

martes, 13 de octubre de 2015

Hackeando el 2FA en Android

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

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

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

Nosotros nos vamos a centrar en dos aplicaciones que podemos encontrar en muchos terminales Android, un gestor de correo y el gestor de 2FA. Las aplicaciones en concreto son:
  • Correo (com.android.email)
  • Google Authenticator (com.google.android.apss.authenticator2)
Una de las grandes vulnerabilidades de las aplicaciones Android que podemos encontrar dentro del TOP 10 Owasp Mobile Risks es el almacenamiento inseguro de datos, este tipo de vulnerabilidad es la segunda más encontrada como podemos ver en el esquema de OWASP.


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

Insecure Data Storage en com.android.email

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

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


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


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


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

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

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

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

Paso a paso, haremos lo siguiente:

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

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

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

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


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


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


Conclusión

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

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

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


  • Curso Forense en Android ( 29 Enero y 5 Febrero - Modalidad Online): curso totalmente práctico donde llevaremos a cabo el proceso forense de un terminal Android para obtener el máximo número de pruebas. Tocando directorios claves del sistema operativo como de las aplicaciones más utilizadas que nos brindan gran cantidad de información. Más información aquí.
  • Taller Pentesting de Aplicaciones Android (12 Febrero Cuenca - MorterueloCon): taller de 4 horas sobre auditoría de aplicaciones móviles siguiendo la metodología OWASP. Más información aquí.
  • Curso Pentesting en Android (27 Febrero Valencia): un curso presencial muy completo de 8 horas de duración, donde veremos los diferentes puntos del Pentesting en Android para poder auditar aplicaciones, analizar malware e incluso llevar a cabo un análisis forense de un terminal. Más información aquí.



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

Un handshake


"Comienza haciendo lo que es necesario, después lo que es posible y de repente estarás haciendo lo imposible"
S.F.d.A.










lunes, 27 de julio de 2015

No hace falta que seas un manitas para hacer phishing

No hace falta ser un manitas en esto de la informática para conseguir suplantar la identidad de una empresa y conseguir las credenciales de acceso con un poco de ingenio e ingeniería social. Y sobre todo cuando existen aplicaciones que lo hacen por ti simplemente agregando la URL del sitio web que quieres clonar, como es el caso de HTTrack, una aplicación desarrollada para dos tipos de personas, bien puede servir para un auditor de aplicaciones web que quiera analizar el sitio a auditar de manera offline, o para un cibercriminal que quiera suplantar la identidad de una página para conseguir datos que puedan interesarle como las credenciales de acceso.

Esta aplicación multiplataforma que está disponible para Windows, Linux  y OS X tiene un uso muy sencillo y es que, solamente tendremos que indicarle el nombre del proyecto, la ruta donde guardarlo y la URL del sitio a clonar. Después de esto, tendremos el sitio clonado idéntico al original y ya nosotros tendríamos que configurarlo a nuestro gusto para recibir los datos que el usuario introduzca y añadirle un poco de astucia a la hora de engañar.

HTTrack nos brinda varias opciones a la hora de hacer el clonado, en este caso vamos hacer una copia del sitio web.




También podemos definir una serie de opciones a la hora de realizar el clonado del sitio como puede ser filtrar archivos, modificar cabeceras o especificar el número de conexiones que se hará por si la aplicación contiene algún tipo de control. Tampoco entraré en mucho detalle sobre estas opciones y lo dejaré en vuestras manos para que juguéis con la aplicación.

En mi caso, voy a realizar un clonado de la página web Steam, una plataforma de videojuegos que cuenta con más de 125 millones de usuarios registrados y que es muy común encontrarse con alguien que intente hacer phishin de este sitio para conseguir cuentas y luego venderlas.




Si le echamos un vistazo a la URL que le indico que quiero que haga el clonado http://store.steampowered.com/ podemos comprobar que esta URL no navega por HTTPS por lo que engañar en este caso a un usuario podría ser un más fácil que a la hora de hacer login que lo veremos más adelante. Como dije anteriormente aquí entraría el ingenio del cibercriminal a la hora de engañar al usuario para conseguir que acceda a este sitio web como podría ser, con acortadores de URL estilo https://goo.gl/ y rezar para que cuando el usuario haga click en la URL acortada no mire la barra de direcciones, o también conseguir un nombre de dominio semejante como podrían ser http://store.steampovvered.com/ (nótese las dos "v" en vez de una "w").

Una vez le digamos que empiece al clonar podemos ver como HTTrack va visitando el sitio web completo para descargarse los archivos en el equipo local.




Ya clonado, vamos a comparar los dos sitios a ver si conseguimos ver algo diferente.

Sitio web original de Steam

Sitio web clonado de Steam

Como podemos comprobar el sitio web es idéntico al original. En este caso el login de esta aplicación web si contiene HTTS por lo que navegará por el protocolo SSL y además contiene un certificado EV SSL que explicaré al final del post. En este caso el cibercriminal le sería algo más complicado engañar al usuario pero nunca imposible ya que la mayoría de los usuarios navegan por Internet sin mirar la barra de direcciones por lo que no saben si realmente están el sitio web legítimo o no. En estos casos lo que se suele hacer es, cuando el usuario introduce su usuario y contraseña y le llega al cibercriminal, este le redirige al sitio web original indicándole que las credenciales introducidas no son válidas.

El login en este caso tendrá el siguiente aspecto.

Login original de Steam


Como podemos comprobar la navegación cambian a HTTPS y vemos el cuadrado verde con el candado garantizando la identidad de la empresa Valve, no quedaría duda de que es el sitio web original. Nuestro sitio web clonado quedaría de la siguiente manera.

Login clonado de Steam

De nuevo son idénticos y no se consigue apreciar ningún cambio significativo por lo que el usuario no se daría cuenta realmente de no ser porque mire la URL.


¿Cómo prevenir un ataque de phishing?

Poniendo este caso como ejemplo, lo mejor para prevenir este tipo de ataques es mirar siempre la URL a la que accedemos por terceros en los que desconfiamos como puede ser por email, foros o desconocidos. Verificar el candado verde que nos garantiza la identidad de la empresa y la navegación por HTTPS que nos dice que los datos irán cifrados en todo momento. En el caso de que la URL esté acortada, podemos ver a donde apunta con knowurl.

Tipos de certificados

Como dije antes, el candado verde significa que es un certificado EV, es decir, existe un tercero que verifica y valida la identidad de la aplicación web. También existe el certificado normal que lo que garantiza es que los datos en todo momento van cifrados y no se podrán extraer. Por supuesto, el certificado EV es más caro a la hora de adquirirlo.

Luego podemos encontrarnos y seguro que os habréis topado con alguno, los llamados certificados autofirmados. Estos certificados no tienen un tercero que lo firme y verifique la identidad del sitio web y cuando vamos a navegar por su sitio nos dice "Esta conexión no es de confianza o no está verificada" en mi caso, me ha pasado mucho con la Junta de Andalucía.


En estos casos, tenemos tres opciones. La primera es no confiar en el sitio web y no navegar por él. La segunda sería, entender los riesgos y navegar aunque, podríamos ser vulnerables a un ataque de MiTM (Man-in-the-middle). Y la tercera opción sería importar el certificado en nuestro navegador y poder navegar por el sitio web y que los datos vayan cifrados así evitando un ataque MiTM. Para hacer esta última opción se tendría que confiar plenamente en el sitio web.




Un saludo @Joseliyo_Jstnk.


DISCLAIMER: No me hago responsable del uso que se le de a la aplicación explicada que se ha hecho con fines educativos. Esta aplicación está desarrollada para descargar sitios web y analizarlos de forma offline.