Tras unas merecidas vacaciones he decidido volver a escribir una nueva entrada. Esta vez os mostraré la herramienta SQLMap.
SQLMap es una herramienta para la automatización de ataques SQLi, lo cual facilita bastante la tarea del auditor a la hora de buscar este tipo de vulnerabilidades y poder posteriormente explotarlas.
Está desarrollada en python y se encuentra ya instalada en distribuciones como Kali, aunque también podéis descargarla desde https://github.com/sqlmapproject/sqlmap/wiki/Usage. Es bastante completa, pero en esta publicación veremos los aspectos más básicos.
Ejecutamos la plataforma, obtenemos la dirección IP donde se aloja y entramos en ella seleccionando el nivel intermedio.
Nos vamos a la pestaña de "SQL Injection" y probamos a introducir un número cualquiera para comprobar el funcionamiento, a la vez que obtenemos información de la Cookie generada (nos será necesaria más adelante para lanzar SQLMap).
Para obtener la Cookie abrimos el inspector del navegador y accedemos a las pestaña que puede verse en la siguiente imagen:
En este punto (siento por haber ido tan rápido hasta aquí, pero quería centrarme en SQLMap y no en DVWA) empezaremos con lo interesante.
Para ejecutar la herramienta utilizaremos el comando "sqlmap" en una consola con la opción "u" para introducir la URL vulnerable (habiendo introducido antes un ID en la web), con el parámetro "--cookie" insertaremos la sesión que obtuvimos con anterioridad y por último el parámetro "--dbs" para mostrar las bases de datos contenidas en la web.
El resultado será el siguiente:
A partir de aquí, se abrirá ante nosotrxs un abanico de oportunidades para obtener información.
Como era de esperar, podemos indagar un poco más buscando en las tablas de las bases de datos mediante parámetros como "-D" para seleccionar la base de datos y "--tables" para mostrar las tablas contenidas.
Obteniendo como resultado:
Ahora que nos sentimos como auténticos juankers, tras ver lo intuitivo y sencillo que es el manejo de esta herramienta tan potente, el siguiente paso no podría ser otro que mostrar las columnas de una de las tablas obtenidas con los parámetros "-T" para seleccionar la tabla y "--columns" para mostrarlas.
Por cada columna se nos facilitará información sobre el tipo de dato que contiene.
Para sacar la información de las columnas user, first_name, last_name y password, lo haremos de una forma bastante complicada. Sólo algunos juankers como yo podrán hacerlo a través de años de experiencia y estudios... Usando el parámetro "--dump"
Todo esto está muy bien, pero las posibilidades de SQLMap son mas variadas que los gorros de Chema Alonso. ¡No preocuparse primoh!
Algunos parámetros como "--current-user" nos dará información sobre el usuario que se está ejecutando en el servidor.
En nuestro caso, es el usuario "root".
Otra cosa que suele partir ojetes, sería ejecutar el parámetro "--file-read" para leer algo tan interesante como /etc/passwd.
El fichero se guardará en la ruta que nos indica: root/.sqlmap/output/192.168.1.105/files/_etc_passwd
Por último y no menos importante, siempre nos quedará para todo lo demás Mastercard y el parámetro "--help".
No olvidéis que todo esto se trata de información para utilizarla de forma responsable, profesional, académica, blah, blah, blah y debéis NO debéis utilizarlo para liarla pardísima por servidores ajenos sin un permiso correspondiente.
Me ha costado hacerlo en una
semana más o menos y es el tiempo que me puse para hacerlo. No lo he
terminado debido a su dificultad, y aún con ayuda me quede de momento
en el 63%. Tengo que dar agradecimientos al compañero belane que me
resolvió un token, ya que andaba bastante perdido y también a una
persona del canal de telegram en inglés del lab, que me ha ayudado en
el transurso de él. Gracias.
Una vez dicho esto, hay que
conectarse mediante VPN al servidor. Para ello podemos hacerlo de dos
formas, bajarnos la iso que tienen disponible para hacer el lab o
bajarse el archivo de configuracion de la VPN y usar openvpn con
dicho archivo. Usare esta ultima para poder usar parrotOS.
Por tanto solo basta con
descargarnos ese arhivo e irnos luego a network connections y añadir
una nueva conexion VPN, importando una configuracion VPN previamente
guardada. Una vez elegido esto simplemente hay que poner el user y la
pass que nos proporciona la web.
Es muy aconsejable que
miremos el esquema de la red interna del lab, ya que es la estructura
principal por donde nos moveremos en el pentesting. Vemos que hay dos
subredes bien diferenciadas y distintos servidores con software y
sistemas diferenciados, al giaul que los servicios que prestan.
De primeras solo podemos
hacer un descubrimiento de red a la ip del gateway. Una vez conectado
a la VPN necesitamos nmap para ver que puertos del gateway estan
abiertos.
Atención Spoiler!!
Nmap para realizar un
escaneo Con la opción -sV permite ver la versión de los servicios,
con -A permite la deteción de OS, la versión, script scanning, y
traceroute. Con -T4 indica el tiempo de envió de los paquetes, es
decir desde 0-6, la más baja es la más lenta, y también mejor ya
que podría evadir algunos firewall.
Haciendo pruebas en el
navegador, no resuelve el dominio por el protocolo http. Con https
nos dice que es inseguro y en el puerto 8100 vemos que es un servidor
de correo.
"El archivo hosts de
un ordenador es usado por el sistema
operativo para guardar la correspondencia entre dominios
de Internet y direcciones
IP. Este es uno de los diferentes métodos que usa el sistema
operativo para resolver nombres de dominios."Wikipedia.
Así añadimos la dirección
del gateway con su nombre del dominio y guardamos. Vemos dos email
que pueden ser usados como nombres de usuario dentro de la red, así
que es importante tenerlo en cuenta para mas adeltante.
Vemos su código fuente y no
se ve nada de interés, unicamente contenido de wordpress. Si es un
wordpress ¿Por qué no probamos el wp-login? Bien vemos que hay detras
un WAF, detector de intrusos. Probamos dirb para hacer fuzzing de los
directorios (Sin resultados positivos).
Sabiendo que es un
wordpress, vamos a usar wpscan, para poder enumerar diferentes
usuarios y las vulnerabilidades de los plugins.
Probe buscar en searchsploit
symposium para ver algún tipo de exploit para poder ganar algun tipo
de acceso al servidor. En uno de ellos usaremos un SQLi en donde se
aprecia una PoC, por tanto que mejor que usarla. Permite de una forma
muy sencilla usando wget, obtener la base de datos incluyendo datos e
informacion sensinble de usuarios y hashes de las contraseñas. Sin
exito, error 403 Forbbiden. Creo que no se puede explotar ninguna
vulnerabilidad por el puerto 80 debido al WAF. Así que probemos el
puerto 443 https.
Segun Nmap esta abierto el
puerto y la version de nginx esta obsoleta. Vamos a ver que tipo de
SSL se esta usando con sslscan.
Esta herramienta permite
realizar un escaneo para la busca de vulnerabilidad del SSL, y así
poder subsanarla.
Según el resultado nos
indica que es vulnerable a heartbleed. Podemos usar los scripts de
Nmap para poder ver la vulnerabilidad del SSL tambien. Recomiendo
usar la documentación en la web de Nmap en la seccion de NSE para ver
todos los scripts disponibles que tenemos para poder hacer una buena
auditoría de seguridad y pentesting.
Obtenemos un resultado
positivo con un riesgo alto.
Vamos a usar metasploit, un
auxiliar para poder explotar dicha vulnerabilidad en busca de
información. La recoleccion de información es un proceso muy
importante para poder encontrar información sensible como por ejemplo
usuarios.
Seleccionamos la versión del
TLS, rhost y en verbose para poder ver la salida de la ejecucción del
auxiliar.
Encontramos un backup de
usuarios....
Es una dirección web, como
podemos observar en /var/html/_old.....
Lo introduccimos en el
navegador y nos lo descargamos.
Bien tenemos unos usuarios
con sus hashes.
Usaremos hashcat y el
parametro -m
Y el resultado es la
obtención del token bypass y conttraseñas utiles que nos van a
servir para hacer lo que vendrá a continuación.
Una vez obtenido los
usuarios del proxy, ya que vimos el resultado del nmap con un puerto
abierto y su servicio proxy, vamos a usar sqlmap para explotar la
vulnerabilidad anterior con el proxy y con las credenciales de un usuario.
Despues de un tiempo, nos
devuelve dos bases de datos, concretamente MySQL.
Ahora usamos una base de
datos, y obtenemos las tablas de ella
Seguidamente las columnas, y
luego un dump.
Y bien, de esta forma obtenemos el token.
Una vez analizado el puerto
80 y 443, y mediante el uso del proxy pudimos obtener el token, nos
conectaremos mediante el puerto 22 el servicio SSH al servidor. Es
muy importante intentar conseguir acceso mediante este servicio ya
que una vez conseguido podemos hacer pivoting dentro de la red
interna, y a su vez crear un tunel hacia nuestro localhost y auditar
o realizar un test de intrusión en dicho server interno. Por lo visto
la versión del openssh no es vulnerable así que vamos a realizar la
conexion para a ver si podemos obtener iunformacion del banner al
conectarnos. Hice una consulta en el canal de telegram ya que no
sabía por donde tirar y me dijeron que me fijase justamente en el
banner. Podríamos buscar en google el nombre y saber que es. Aun
así probamos contraseñas por defecto y nada. Por lo visto en github
tiene un codigo en C, y podemos ver justamente el string The password en él
y bueno no se programar en C, pero interpretando el código vemos lo
siguiente:
En el código de la
aplicación estaba la clave para pasar.
Muy buenas compañeros, llevaba tiempo ya queriendo estrenarme en el blog y
finalmente he conseguido el tiempo suficiente para traeros este post.
Primeramente comentar que la vulnerabilidad mostrada en esta entrada ya ha
sido comunicada a la empresa auditada, y que por supuesto no se mostrará
información sobre la empresa ni sus clientes. La publicación unicamente tiene
fines educativos, con el proposito añadido de concienciar a los desarrolladores
web a evitar este tipo de fallas de seguridad en sus aplicaciones.
Y sin más os pongo en situación, hoy en día gran parte de las ventas que se
hacen vía telefónica (a través de Contact Center), ya sean de un producto, un
servicio determinado, o la contratación de suministros requiere de la
aceptación de un contrato a través de Internet.
La empresa auditada genera una llamada telefónica hacia el cliente con el
fin de venderle su servicio, cuando el cliente accede a contratar el mismo
recibe un SMS donde se le redirige a una URL con sus datos y el contrato para
aceptar como podemos ver a continuación.
Lógicamente los datos han de ser enviados por GET y podemos apreciar en la
URL que se envía un identificador de cliente (id) y un teléfono (phone),
comprobamos que sucede si alteramos el teléfono:
Hemos descubierto que si el ID y el PHONE no coinciden la
página nos muestra un error de mysql sin controlar. Por lo tanto podemos
hacernos una idea de la consulta SQL que hay en el PHP que genera el contrato.
Llega el momento de comprobar si el desarrollador simplemente olvidó quitar
el Display Error o es que no realiza ningún tipo de control de los datos
recibidos:
Tras realizar varias pruebas y comprobar que es vulnerable a una inyección
SQL (Más sobre SQLi: Enlace) vemos que tenemos acceso a
absolutamente todos los datos de los clientes, incluidas las tarjetas de
crédito y sus datos bancarios, además de poder aceptar los contratos en su
nombre, si bien el Sistema de Detección de Intrusos (IDS) bloquea las
herramientas automatizadas como SQLmap o NinjaSQL, así como las consultas de
gran carga como las que abusan de concat.
Por lo tanto emplearemos "--" para comentar la consulta que
sigue al id y evitar de esta forma tener que introducir el teléfono del
cliente para obtener sus datos.
Es en este momento donde echaremos mano de CURL (empleando un servicio
oculto de TOR), para el que no lo conozca CURL nos permite enviar peticiones a
un servidor web y analizar la respuesta. En este caso concreto hice un pequeño
script para automatizar el envío de peticiones con PHP y almacenar todos los
contratos.
De esta forma tan sencilla es posible acceder a los datos de los clientes de
la Empresa auditada que no pone en peligro sus propios datos sino los que hacen
referencia a sus clientes, incumpliendo la normativa europea y por supuesto la
LOPD.
¿Cómo evitamos esta vulnerabilidad?
La web está generada en PHP por lo tanto el programador puede utilizar la
función mysql_real_escape_string o bien controlar los datos recibidos.
Es importante también implantar un protocolo de transferencia seguro (HTTPS en
vez de HTTP) para evitar que la información llegue al servidor web en texto
plano y evitar que se visualicen los mensajes de error por el cliente.
Espero poder traeros más episodios de Auditando un Entorno Real en breve,
