Una vez concluida la primera fase, "recopilación de información de nuestro objetivo", dispondremos de un conjunto de información que tendremos que analizar con detenimiento.
El análisis de la documentación nos tiene que dar las pistas
necesarias para centrar la identificación y priorización de las vulnerabilidades con el objetivo final de obtener el mapa de vulnerabilidades de nuestro objetivo.
Normalmente, cuando se realiza un pentesting se pacta inicialmente con el cliente el alcance y objetivo del servicio y la forma de abordarlo, el espectro
es muy amplio y puede abarcar desde servidores y aplicaciones
concretas, hasta una exploración general de los servicios (Web, Red, Bases de Datos, red Wifi, ...).
En general, se identifican y priorizan las vulnerabilidades de los sistemas, dando lugar al mapa de vulnerabilidades.
En general, se identifican y priorizan las vulnerabilidades de los sistemas, dando lugar al mapa de vulnerabilidades.
En nuestro caso nos centrarnos en la búsqueda de una vulnerabilidad o tipo de vulnerabilidad concreta, de tal forma que no hagamos mucho ruido en la exploración.
Herramientas indispensables
En esta fase es muy habitual el uso de frameworks especializados de pentesting.
Mis herramientas
preferidas:
- Kali, antiguo Backtrack y Metasploit.
- Bases de datos en Internet:
Y en función de
hacia donde centremos nuestra búsqueda de vulnerabilidades, tenemos
muchas y diversas herramientas.
Las que utilizo
habitualmente para el análisis de servicios, aplicaciones y bases de datos:
- metasploit: Framework de análisis y explotación.
- nmap: Mucho más que un scaner de puertos.
- netcat: Permite establecer conexiones TCP/UDP.
- Nessus: Herramienta de análisis general de vulnerabilidades.
- Sqlmap: Detectar injecciones SQL.
- OpenVas: Framework de detección de vulnerabilidades.
- Vega: Detectar vulnerabilidades Web.
- Nikto: Detectar vulnerabilidades Web.
- Wireshark: analizador de red.
- Ingeniería social: Aprovechar debilidades húmanas.
Consideraciones importantes a tener en cuenta en esta fase
- Debemos actualizar nuestras herramientas de exploración antes de comenzar esta fase.
- Las herramientas automáticas de detección de vulnerabilidades deben ser tomadas como complemento a acciones manuales.
Una herramienta automática podría decirnos que
un sitio no es vulnerable cuando en realidad si que lo es.
Lo importante es entender lo que hacemos.
Lo importante es entender lo que hacemos.
Detección de vulnerabilidades
Para entender el proceso de detección, expondré un caso real, pero por motivos obvios, mantendré su dominio real en el anonimato.
Durante nuestro proceso de pentesting, tras la fase de recopilación de información, detectamos que muchas de las aplicaciones accesibles
desde Internet corren sobre servidores con Sistema Operativo Redhat,
como servidor web, Apache y como lenguaje de programación, PHP,
posiblemente por estadística, las aplicaciones harán uso de motores
de base de datos MySQL.
Analizando la documentación extraída en la fase de recopilación, comprobamos que en muchas de las cabeceras HTTP intercambiadas con las aplicaciones, obtuvimos la siguiente cabecera:
HTTP/1.1 200 OK
Date: Tue, 27 Oct
2015 12:47:33 GMT
Server:
Apache/2.2.16 (Redhat)
X-Powered-By:
PHP/5.3.3-7+squeeze19
Vary:
Accept-Encoding
Content-Encoding:
gzip
Content-Length:
1830
Keep-Alive:
timeout=15, max=100
Connection:
Keep-Alive
Content-Type:
text/html; charset=utf-8
Con esta
información, podríamos tomar varias vías, por ejemplo podríamos realizar búsquedas en bases de datos filtrando por vulnerabilidades conocidas en las versiones Apache 2.2.16 y php 5.3.3-7, pero vamos a centrarnos en
vulnerabilidades de tipo SQL Injection.
Los resultados obtenidos se prestan a ello.
Los resultados obtenidos se prestan a ello.
¿ Qué es SQL Injection?
Hay extraordinarios recursos en Internet donde podréis
encontrar detalles.
Les recomiendo
revisar antes de proseguir, la siguiente información:
Resumiendo :
Una inyección SQL
es una vulnerabilidad debida a una mala validación de las entradas
de datos de una aplicación, lo que permitirá al atacante
interactuar con una Base de Datos a través de entradas manipuladas.
La idea es detectar
aplicaciones Web que permitan el paso
de parámetros a través de
http (GET – POST), sin validar y sin filtrar de forma adecuada y
que interactuen con la Base de Datos de la aplicación.
Esto nos permitirá crear nuestras sentencias SQL dentro de las sentencias que ha programado el desarrollador.
Esto nos permitirá crear nuestras sentencias SQL dentro de las sentencias que ha programado el desarrollador.
No entraremos a
detallarlas, pero hay que tener en cuenta que existen diferentes
técnicas de detección de vulnerabilidades SQL Injection (blind,
union, error) que podemos aplicar en nuestra búsqueda.
Nosotros buscaremos aplicaciones web Http que trabajen con métodos GET – POST y utilicen bases de datos.
Comencemos por la aplicación http://aplicacion1.dominio.com/ detectada en la fase de reconocimiento y que se soporta con apache+php.
Existen muchas
maneras de ver el tráfico intercambiado entre nuestro navegador
y el servidor que aloja la aplicación, por ejemplo utilizando el plugin de Firefox “Live HTTP Headers”.
El plugin nos permite ver las peticiones GET o POST y las variables que utiliza la
aplicación en sus funciones.
Accedemos a la
aplicación desde el navegador (estaría bien utilizar algún proxy SSL anónimo desde el cual probar):
Examinamos las
cabeceras:
http://aplicacion1.dominio.com/index.php?codigo=10
GET
/index.php?codigo=10
Host:
aplicacion1.dominio.com
User-Agent:
Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:38.0) Gecko/20100101
Firefox/38.0
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language:
en-US,en;q=0.5
Accept-Encoding:
gzip, deflate
Connection:
keep-alive
Cache-Control:
max-age=0
http://aplicacion1.dominio.com/index.php?codigo=10'
Warning:
mysql_fetch_array(): supplied argument is not a valid MySQL result
resource in/etc/apache/www/index.php on
line 120.
En
la última petición, hemos introducido un carácter especial “'”
con el objetivo de verificar si la variable "codigo" es vulnerable a una
inyección.
Nos
devuelve un error, esto es porque la comilla simple ha
sido interpretada como un delimitador de la sentencia SQL
y esto genera un tratamiento erróneo por el motor de Base de Datos. Por lo tanto, la BD
devuelve un error.
Esto
quiere decir que la “'”
no
esta filtrada adecuadamente y podremos utilizarla para incrustar
nuestras operaciones SQL dentro de las que el programador ha
definido.
Es
importante en estos casos, detectar si la variable vulnerable es de
tipo string o entero, para saber con exactitud la forma de incrustar
nuestras sentencias dentro del código de la aplicación.
Por
lo tanto, la aplicación aplicación1.dominio.com/index.php
es vulnerable a SQL Injection.
Como
complemento, podríamos utilizar una de mis herramientas preferidas
para la detección de SQL injection, SQLMap.
SQLMap nos permite detectar vulnerabilidades SQLInjection, soporta los tipos boolean-based blind, time-based
blind, error-based, union querey, stacked queries y out-of-band.
Pero además permite su explotación.
Pero además permite su explotación.
./sqlmap.py
-u http://aplicacion1.dominio.com/index.php?
codigo=10 (por defecto utiliza GET).
Place:
GET
Parameter:
codigo
Type:
boolean-based blind
Title:
AND boolean-based blind - WHERE or HAVING clause
Payload:
codigo=10 AND 4242=4242
Type:
AND/OR time-based blind
Title:
MySQL > 5.0.11 AND time-based blind
Payload:
newsletter=10 AND SLEEP(5)
---
web
server operating system: Linux
web
application technology: Apache 2.2.3, PHP 5.2.0
back-end
DBMS: MySQL 5.0.11
GET
parameter 'codigo' is vulnerable. Do you want to keep testing the
others (if any)? [y/N]
sqlmap
identified the following injection points with a total of 25 HTTP(s)
requests.
Como
se puede observar, la herramienta SQLMap fija unos criterios de
detección (método, técnica, payload ...) y tras realizar 25
peticiones http, detecta que la variable "codigo" es vulnerable a
un SQL injection type boolean-based blind.
En
esté artículo hemos presentado la metodología a seguir en el
proceso de evaluación de las vulnerabilidades de nuestro objetivo.
Esta
fase dará como resultado un mapa de vulnerabilidades de nuestro
objetivo.
En
cualquier caso, el mapa de vulnerabilidades dependerá de los
objetivos y alcance pactados.
La
fase de evaluación debe quedar perfectamente documentada, ya que
será la base con la que trabajaremos en la siguiente fase,
explotación.
No hay comentarios:
Publicar un comentario