viernes, 23 de septiembre de 2016

Hacking Ético Mondragon - Unidad 2, Tarea 2

Hola chicos, continuamos con la segunda tarea de la unidad 2 del curso.

Se trata de acceder a la aplicación web vulnerable DVWA contenida en una máquina virtual con un servidor web que la sirve. Contiene una serie de páginas con ejercicios relacionados con el hacking web, como XSS, Command Execution o SQL Injection; esta última técnica es la que utilizaremos.

Una vez levantada la máquina en un entorno de máquinas virtuales (VirtualBox en este caso), podemos acceder a la misma desde cualquier navegador web accediendo a la dirección IP indicada.

Máquina con DVWA corriendo
En el navegador podremos acceder ya a los diferentes ejercicios utilizando el usuario y contraseña predeterminados en la máquina, que pueden consultarse de forma pública (admin, password) o bien, si nos sentimos motivados, mediante un ataque de fuerza bruta (por ejemplo, con Hydra).

Pantalla principal de la aplicación web
Para esta práctica, siendo algo básico, configuraremos la aplicación para que ofrezca un nivel bajo de seguridad. Podemos hacerlo accediendo al área DVWA Security.

Configuración de seguridad a nivel bajo
Podemos ir ya al apartado de la inyección SQL. Introduciendo en el campo User ID un número, nos muestra los datos del usuario cuyo ID coincide con dicho número.

Funcionamiento de la aplicación para SQL Injection
Podemos realizar muchos tipos de inyección. La más sencilla es:

1' or '1'='1

De esta manera, nos arrojará los datos de los usuarios cuyo ID sea 1, o en los que el carácter '1' sea igual al carácter '1'. Al cumplirse siempre esa condición, nos devuelve los datos de todos los usuarios.

Resultado de la primera inyección
Lo siguiente que podemos hacer es conseguir la versión del gestor de bases de datos que maneja la aplicación. Podemos hacerlo introduciendo:

1' union select null,version() #

Lo que indicamos es que, de nuevo, nos devuelva los usuarios cuyo ID es 1, y que además agregue (union) un campo vacío (null) y la versión del sistema gestor (version()). El campo vacío se requiere, dado que para una unión es necesario que se muestren dos campos, igual que en la consulta original, o habrá error. Por último, el carácter # hace que se ignore el resto de la línea de consulta, evitando errores al haber más código tras el inyectado.

Resultado de la segunda inyección
De la misma manera, podemos averiguar el usuario con el que la aplicación maneja el gestor de base de datos, sustituyendo la función que devuelve la versión (version()) por la de usuario (user()).

1' union select null,user() #

Resultado de la tercera inyección
De nuevo, variando el mismo campo de la consulta, podemos averiguar el nombre de la base de datos, utilizando la función database().

1' union select null,database() #

Resultado de la cuarta inyección
Moviéndonos a consultas algo más avanzadas, podemos recuperar mediante la siguiente inyección todas las tablas contenidas dentro del gestor de bases de datos:

 1' union select null,table_name from information_schema.tables #

Estamos, en combinación con los campos ya explicados, recopilando el campo table_name de la tabla tables en la base de datos information_schema, que contiene datos sobre todas las tablas contenidas en el gestor.

Resultado de la quinta inyección
Pero aún podemos "afinar" más aún la consulta. Especificando con una cláusula where, podemos pedir solamente las tablas cuyo nombre comience por la cadena user, intentando averiguar tablas que contengan datos de usuarios.

 1' union select null,table_name from information_schema.tables where table_name like 'user%' #

Resultado de la sexta inyección
Como vemos, el resultado son un par de tablas que nos indican los privilegios de cada usuario, y una que contiene datos de los mismos usuarios. Podemos indagar en las columnas que forman esta última tabla con una inyección más enrevesada:

 1' union select null,concat(table_name,0x0a,column_name) from information_schema.columns where table_name = 'users' #

Estamos indicando que, pese a que necesitamos que los campos devueltos sean dos, el segundo sea la concatenación del nombre de la tabla users, un salto de línea (representado en hexadecimal como 0x0a) y el nombre de cada columna.

Resultado de la séptima inyección
Por último, y teniendo ya los campos de la tabla, podemos pedir un listado de todos los datos de cada usuario. Utilizaremos de nuevo una concatenación para mostrar múltiples resultados.

 1' union select null, concat(first_name, 0x0a, last_name, 0x0a, user, 0x0a, password) from users #

Resultado de la octava inyección
El resultado muestra todos los datos relevantes de cada usuario: nombre, apellido, nombre de usuario y contraseña cifrada (hash).

Obtenidos estos hashes, podemos copiarlos a un fichero de texto para poder realizar un ataque de fuerza bruta con diccionario sobre ellos y así obtener las contraseñas en plano. Los introduciremos en dicho fichero de la siguiente manera:

Fichero de texto con los usuarios y hashes
Utilizaremos la herramienta Hashcat para realizar el crackeo de los hashes. En concreto, descargaremos también la herramienta Hashcat GUI para que el proceso sea algo más gráfico. Descomprimiremos en cualquier lugar ambas herramientas y ejecutaremos esta última. (¡Necesitaremos saber dónde está la otra para introducir su binario en la GUI!)

Uso de Hashcat GUI para el crackeo de los hashes
Introduciremos el diccionario rockyou.txt en la pestaña Wordlists and Markov. En la pestaña Hashcat introduciremos el archivo con los hashes en el campo Hash File, el binario de Hashcat actualizado en Binary y opcionalmente un lugar donde guardar los resultados en Output. 

Cambiaremos además el Hash Type a MD5, formato en el que se suelen guardar las contraseñas en las bases de datos. Podemos verificarlo utilizando alguna página de comprobación del tipo de hash, como puede ser ésta. Finalmente, marcamos las opciones Disable Pot File e Ignore Usernames, de manera que ignora hashes anteriormente encontrados e ignora los nombres de usuario del fichero de texto.

Hecho esto podemos pulsar el botón enorme I'm a HashKiller y tener los resultados en apenas segundos, pudiendo seguir el proceso en la ventana de consola en la que se mostrará Hashcat funcionando.

Seguimiento del crackeo en Hashcat
Podemos apreciar los resultados del crackeo en el fichero de resultados, viendo que ha sido todo un éxito; todas las contraseñas pudieron obtenerse.

Resultados del crackeo

Y hasta aquí el ejercicio de hoy. Un saludo y espero que os sirva, pronto seguiremos trabajando!!


jueves, 22 de septiembre de 2016

Hacking Ético Mondragon - Unidad 2, Tarea 1

Hola a todos. Seguimos recorriendo el curso online de hacking ético con la primera tarea de la segunda semana.

Primera parte: analizando un protocolo inseguro - Telnet

A partir de una captura de paquetes de red recogida en un archivo .pcap realizaremos un análisis de las operaciones realizadas mediante el protocolo Telnet. Este protocolo, al carecer de cifrado, permite que la escucha de red revele todo lo intercambiado en la conexión. 

Podemos abrir el fichero con cualquier analizador de paquetes, como puede ser Wireshark, el cual utilizaremos. 

Lectura del fichero con Wireshark
Como puede verse en la imagen, es muy fácil filtrar el protocolo a mostrar escribiendo simplemente telnet en el campo de filtros del programa.

Podemos ver en texto plano en los campos de análisis de cada paquete los datos intercambiados entre los dos hosts, desplegando la pestaña Telnet. Podemos responder asíl fácilmente a varias preguntas:

  • ¿Qué usuario y contraseña se ha utilizado para acceder al servidor de Telnet?
    • El usuario es fake, y la contraseña user
  • ¿Qué sistema operativo corre en la máquina?
    • Utiliza un OpenBSD 2.6-beta.
  • ¿Qué comandos se ejecutan en esta sesión?
    • Se ejecutaron cuatro comandos en la sesión:
ls
ls -a
/sbin/ping www.yahoo.com
(ctrl-c)
exit


Segunda parte: analizando SSL

En la siguiente parte, realizaremos un análisis muy similar con una traza que ha recogido una sesión SSH. A diferencia de Telnet, el protocolo SSH realiza un cifrado de la conexión, de forma que hace imposible que apreciemos a primera vista los datos que se intercambian. 

Lectura del fichero con Wireshark (2)
Aunque no podemos discernir las operaciones realizadas en la sesión, podemos responder a algunas preguntas: 
  • ¿Puedes identificar en qué paquete de la trama el servidor envía el certificado?
    • Sí. Los certificados se envían en los paquetes enviados por el servidor y que contienen la información marcada como Certificate. Si abrimos dicha información, se puede ver el certificado. 
Certificado encontrado en la sesión
  • ¿El certificado va en claro o está cifrado? ¿Puedes ver, por ejemplo, qué autoridad ha emitido el certificado?
    • Para que el cliente pueda ver el certificado antes de realizar una conexión completa mediante SSH y así verificar la identidad del servidor a priori, el certificado se envía en plano, sin cifrar. 
Información del certificado en Wireshark
    • Si queremos ver la información algo más clara, podemos exportar el certificado clicando con el botón derecho en la pestaña del certificado y en Export Packet Bytes..., para entonces guardarlo como un fichero .der. Podemos ver este certificado entonces haciendo doble clic sobre él. Entre otras cosas, podemos ver los datos acerca de la autoridad de certificación. 
Visualización de datos del certificado
  • ¿Qué asegura el certificado, la identidad del servidor o del cliente?
    • El certificado asegura la identidad del servidor. 

Tercera parte: analizando SSH

Por último para esta tarea, analizaremos otra captura del protocolo SSH para responder a otra serie de preguntas respecto a la misma. 
  • ¿Puedes ver a partir de qué paquete comienza el tráfico cifrado?
    • Sí. Aunque en la captura solamente se muestran los paquetes enviados desde el lado cliente, puede apreciarse que el tráfico cifrado comienza en el paquete marcado como 13, después de haber intercambiado las claves. 
Primer paquete cifrado de la sesión
  • ¿Qué protocolos viajan cifrados, todos (IP, TCP...) o alguno en particular?
    • Algunos protocolos viajan cifrados, otros no. Tanto TCP como IP son protocolos de capas inferiores a la de aplicación, la cual es la que suele ofrecer funciones de cifrado. Por ejemplo, el protocolo FTP viaja sobre TCP/IP, pero no está cifrado; su derivado seguro, FTPS, también viaja sobre TCP/IP, pero está cifrado.
  • ¿Es posible ver alguna información de usuario como contraseñas de acceso?
    • No es posible (al menos de forma matemáticamente rentable) recuperar ningún tipo de dato de la sesión una vez pactadas las claves de cifrado. 


Hasta aquí la tarea de hoy, chicos. Un saludo y pronto publicaré el resto!


Hacking Ético Mondragon - Unidad 2, Tarea 1

Hola a todos. Seguimos recorriendo el curso online de hacking ético con la primera tarea de la segunda semana.

Primera parte: analizando un protocolo inseguro - Telnet

A partir de una captura de paquetes de red recogida en un archivo .pcap realizaremos un análisis de las operaciones realizadas mediante el protocolo Telnet. Este protocolo, al carecer de cifrado, permite que la escucha de red revele todo lo intercambiado en la conexión. 

Podemos abrir el fichero con cualquier analizador de paquetes, como puede ser Wireshark, el cual utilizaremos. 

Lectura del fichero con Wireshark
Como puede verse en la imagen, es muy fácil filtrar el protocolo a mostrar escribiendo simplemente telnet en el campo de filtros del programa.

Podemos ver en texto plano en los campos de análisis de cada paquete los datos intercambiados entre los dos hosts, desplegando la pestaña Telnet. Podemos responder asíl fácilmente a varias preguntas:

  • ¿Qué usuario y contraseña se ha utilizado para acceder al servidor de Telnet?
    • El usuario es fake, y la contraseña user
  • ¿Qué sistema operativo corre en la máquina?
    • Utiliza un OpenBSD 2.6-beta.
  • ¿Qué comandos se ejecutan en esta sesión?
    • Se ejecutaron cuatro comandos en la sesión:
ls
ls -a
/sbin/ping www.yahoo.com
(ctrl-c)
exit


Segunda parte: analizando SSL

En la siguiente parte, realizaremos un análisis muy similar con una traza que ha recogido una sesión SSH. A diferencia de Telnet, el protocolo SSH realiza un cifrado de la conexión, de forma que hace imposible que apreciemos a primera vista los datos que se intercambian. 

Lectura del fichero con Wireshark (2)
Aunque no podemos discernir las operaciones realizadas en la sesión, podemos responder a algunas preguntas: 
  • ¿Puedes identificar en qué paquete de la trama el servidor envía el certificado?
    • Sí. Los certificados se envían en los paquetes enviados por el servidor y que contienen la información marcada como Certificate. Si abrimos dicha información, se puede ver el certificado. 
Certificado encontrado en la sesión
  • ¿El certificado va en claro o está cifrado? ¿Puedes ver, por ejemplo, qué autoridad ha emitido el certificado?
    • Para que el cliente pueda ver el certificado antes de realizar una conexión completa mediante SSH y así verificar la identidad del servidor a priori, el certificado se envía en plano, sin cifrar. 
Información del certificado en Wireshark
    • Si queremos ver la información algo más clara, podemos exportar el certificado clicando con el botón derecho en la pestaña del certificado y en Export Packet Bytes..., para entonces guardarlo como un fichero .der. Podemos ver este certificado entonces haciendo doble clic sobre él. Entre otras cosas, podemos ver los datos acerca de la autoridad de certificación. 
Visualización de datos del certificado
  • ¿Qué asegura el certificado, la identidad del servidor o del cliente?
    • El certificado asegura la identidad del servidor. 

Tercera parte: analizando SSH

Por último para esta tarea, analizaremos otra captura del protocolo SSH para responder a otra serie de preguntas respecto a la misma. 
  • ¿Puedes ver a partir de qué paquete comienza el tráfico cifrado?
    • Sí. Aunque en la captura solamente se muestran los paquetes enviados desde el lado cliente, puede apreciarse que el tráfico cifrado comienza en el paquete marcado como 13, después de haber intercambiado las claves. 
Primer paquete cifrado de la sesión
  • ¿Qué protocolos viajan cifrados, todos (IP, TCP...) o alguno en particular?
    • Algunos protocolos viajan cifrados, otros no. Tanto TCP como IP son protocolos de capas inferiores a la de aplicación, la cual es la que suele ofrecer funciones de cifrado. Por ejemplo, el protocolo FTP viaja sobre TCP/IP, pero no está cifrado; su derivado seguro, FTPS, también viaja sobre TCP/IP, pero está cifrado.
  • ¿Es posible ver alguna información de usuario como contraseñas de acceso?
    • No es posible (al menos de forma matemáticamente rentable) recuperar ningún tipo de dato de la sesión una vez pactadas las claves de cifrado. 


Hasta aquí la tarea de hoy, chicos. Un saludo y pronto publicaré el resto!


jueves, 15 de septiembre de 2016

Hacking Ético Mondragon - Unidad 1, Tarea 3

Hola chicos! Aquí dejo la realización de la tercera tarea de la primera unidad del curso de Hacking Ético de Mondragon Unibersitatea.

El proceso que he seguido podéis encontrarlo en el blog en el que soy colaborador, Follow The White Rabbit (https://fwhibbit.blogspot.com.es/). Las dos siguientes entradas contienen la información paso a paso para configurar y utilizar el cifrado PGP utilizando el cliente de correo Thunderbird y la extensión Enigmail para el mismo, que utiliza Gpg4win para realizar el cifrado, firmado y descifrado de los correos.

https://fwhibbit.blogspot.com.es/2016/06/encripta-y-firma-tu-correo-thunderbird.html
https://fwhibbit.blogspot.com.es/2016/06/encripta-y-firma-tu-correo-ii-el.html

El primer enlace enseñará a configurar todo el entorno y crear nuestro par de claves, así como cifrar, firmar y descifrar nuestros correos. El segundo enlace enseña a subir nuestra clave pública a un servidor de claves para ponerla a disposición de quienquiera contactarnos de forma privada.

Con un buen amigo colaborador de nuestro mismo blog (él lo muestra en su blog del curso, http://portucan46.blogspot.com.es/2016/09/unidad-1-tarea-3.html), realicé algunas pruebas para poder mostraros capturas adicionales con el resultado.

Envío de mi clave pública
Recepción de su clave pública

Recepción de un mensaje cifrado :)
Envío de un mensaje... cifradito

Hasta aquí la tarea chicos, un saludo y disfrutad!









Hacking Ético Mondragon - Unidad 1, Tarea 2

En esta entrada debo recomendar algunos sitios web relacionados con la temática del curso, a modo de compartición de conocimiento con mis buenos compañeros.

El primero de todos es el blog que mantenemos tanto yo como mis compañeros de Follow The White Rabbit (https://fwhibbit.blogspot.com.es/). En él hablamos de diversos temas relacionados con la seguridad y el hacking ético, pasando por protección de comunicaciones, privacidad, cracking, pruebas de concepto, ingeniería social y securización. Mi nick como autor, por si queréis reconocerme, es Hartek. Espero de verdad que os guste!!

El segundo es un clásico, El Lado Del Mal (http://www.elladodelmal.com/). En él, autores muy presentes en la escena de la seguridad informática y el hacking ético, como Chema Alonso o Pablo González, nos informan de las últimas noticias y pruebas de concepto en el mundillo. Altamente recomendado, y la mayoría de las entradas son para todos los públicos, fácilmente entendibles.

Por último, como espacio de encuentro e intercambio de información, tenemos muchas opciones disponibles en la red. Por ejemplo, http://www.elhacker.net/ es un espacio clásico y muy activo. Otro espacio que todo programador, administrador y casi cualquier informático conocerá y consulta más de lo que admitirá es Stack Overflow (http://es.stackoverflow.com/), donde puedes preguntar y responder acerca de programación e informática avanzada en general. Su correspondiente en cuanto a ramas más de sistemas es Super User (http://serverfault.com/).

Hasta aquí la segunda tarea, un saludo!

Hacking Ético Mondragon - Unidad 1, Tarea 1

TAREA 1: Herramientas básicas para obtener información de servidores externos

Utilizaré la herramienta ping para primeramente comprobar la disponibilidad del servidor web accesible en la URL www.euskalert.net

Comprobación de disponibilidad mediante ping
Como se puede comprobar, el servidor no responde a las peticiones ping, pero sí que podemos obtener la dirección IP del servidor: 193.146.78.12

Esto suele indicar que el servidor está caído o bien que bloquea estas peticiones. Para comprobar su disponibilidad mediante protocolo http, podemos utilizar un navegador web para acceder a la página, o bien utilizar wget en consola. 

Comprobación de la disponibilidad http mediante wget
Como podemos comprobar, wget no consigue obtener una respuesta del servidor. El navegador tampoco consigue una respuesta.

Comprobación de la disponibilidad http mediante navegador web
Como veremos más adelante, el servidor sí que está operativo, dado que responde correctamente a un escaneo de puertos con nmap. Puede deducirse que solamente tiene problemas, que sepamos de momento, con los paquetes de escaneo ping y el servicio web.

Siguiendo con las pruebas con ping, otros servidores web, como www.google.es o www.msn.com sí que están operativos y responden a las peticiones. 

Respuesta ping de otros servidores web
Continuaremos explorando la herramienta whois. Aunque de forma predeterminada no se encuentra en nuestro sistema operativo (un Xubuntu 16.04) podemos instalarla fácilmente con el gestor de paquetes apt-get

Instalación de whois en Xubuntu 16.04
Hecho esto podemos comenzar las pruebas comprobando los datos registrados para el dominio euskalert.net en busca de las personas figurantes como contacto técnico y como contacto administrativo. 

Datos de contacto técnico
Datos de contacto administrativo
Como vemos, la información podría arrojar datos más concretos en cuanto a nombre completo del responsable, pero ya son datos que podremos aprovechar. Por ejemplo, tenemos direcciones físicas y de correo electrónico, y números de teléfono de contacto. 

Por último, analizaremos los puertos abiertos en el servidor mediante un escaneo con la herramienta nmap. Primeramente realizamos un escaneo tipo silencioso (SYN stealth scan) para conocer simplemente los puertos abiertos en el objetivo. 

Resultado del escaneo preliminar del objetivo
Como podemos ver, el servidor tiene varios servicios corriendo. Podemos deducir que hace las veces de servidor de correo por los servicios SMTP/SMTPS, POP3/POP3S, IMAP/IMAPS y submission, protocolos de envío y recepción de correo electrónico. También contiene un servidor de contenidos snews y de lectura y publicación de artículos nntp. Por supuesto, esto son suposiciones; simplemente se indica el servicio que típicamente corre en dichos puertos. 

La falta de un servicio web abierto podría explicar la falta de respuesta http que antes comentábamos. 

Podemos concluir realizando un escaneo completo (-A) con verbosidad (-v) del objetivo, evitando tiempos de respuesta altos (-T4). De esta forma intentamos realizar un descubrimiento de versiones de los servicios corriendo y del sistema operativo de la máquina objetivo. 

Para ahorrar espacio en la entrada (la salida del comando es muy larga), podéis consultar el resultado en el enlace: http://pastebin.com/W4s24xAn

Entre otras cosas, descubrimos un servicio http protegido mediante tcpwrapper u otro servicio de protección al programa. Al margen de ello, no se ha podido recoger información relevante de los posibles servicios que ofrece el servidor, ni tampoco una deducción precisa del sistema operativo. 

Es probable que haya un sistema de detección de intrusión, un firewall u otro sistema de protección en medio, dado que los resultados son vagos e inconsistentes en su mayoría. Otra opción es que el servidor esté teniendo un funcionamiento errático en este momento, ya sea por mala configuración o por una saturación de peticiones. Sin saber las versiones de cada servicio, o si de verdad son los que aparecen, no podemos realizar un escáner real de vulnerabilidades, o al menos de forma fácil.