BADSTORE 1.2.3
Última actualización
Última actualización
0- Introducción - Reconocimiento
1- Sanitización del servidor web
2- Inyección XSS(Cross-Site Scripting)
3- Inyección SQL
4- CSRF(Cross-Site Request Forgery)
Empezaremos por el reconocimiento de la máquina con diferentes herramientas para luego analizar lo encontrado y encontrar vulnerabilidades existentes en la máquina, subrayando y marcando lo más importante para encontrar vulnerabilidades:
Nmap
# Nmap 7.94SVN scan initiated Wed Nov 13 17:06:03 2024 as: nmap -p- -sS -sC -sV -vvv -n --min-rate 5000 -oN nmap_badstore 192.168.8.11 Nmap scan report for 192.168.8.11 Host is up, received arp-response (0.00012s latency). Scanned at 2024-11-13 17:06:04 -03 for 16s Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE REASON VERSION 80/tcp open http syn-ack ttl 64 Apache httpd 1.3.28 ((Unix) mod_ssl/2.8.15 OpenSSL/0.9.7c) |_http-server-header: Apache/1.3.28 (Unix) mod_ssl/2.8.15 OpenSSL/0.9.7c 443/tcp open ssl/http syn-ack ttl 64 Apache httpd 1.3.28 ((Unix) mod_ssl/2.8.15(HTTPs) 3306/tcp open mysql syn-ack ttl 64 MySQL 4.1.7-standard
Dirb - Fuzzing web
---- Scanning URL: http://192.168.8.11/ ---- ==> DIRECTORY: http://192.168.8.11/backup/ + http://192.168.8.11/cgi-bin/ (CODE:403|SIZE:275) + http://192.168.8.11/favicon.ico (CODE:200|SIZE:1334) ==> DIRECTORY: http://192.168.8.11/images/ + http://192.168.8.11/index (CODE:200|SIZE:3583) + http://192.168.8.11/index.html (CODE:200|SIZE:3583) + http://192.168.8.11/robots (CODE:200|SIZE:316) + http://192.168.8.11/robots.txt (CODE:200|SIZE:316) ==> DIRECTORY: http://192.168.8.11/supplier/
Whatweb - Reconocimiento de tecnologías utilizadas
http://192.168.8.11 [200 OK] Apache[1.3.28][mod_ssl/2.8.15], Country[RESERVED][ZZ], HTTPServer[Unix][Apache/1.3.28 (Unix) mod_ssl/2.8.15 OpenSSL/0.9.7c], IP[192.168.8.11], OpenSSL[0.9.7c], Title[Welcome to BadStore.net v1.2.3s]
Se puede observar versiones obsoletas, MySQL 4.1.7(Puerto 3306), Apache 1.3.28(Puerto 80 y 443), también se puede ver que el servidor web cuenta con un certificado SSL para utilizar HTTPS y encriptar las consultas al servidor enviadas por un usuario y viceversa(Aunque aparentemente, el certificado no tiene validez por la fecha de expiración).
A su vez también se puede observar que se trata una máquina Linux, debido al TTL en el escaneo de Nmap.
El proceso de sanitización de un servidor web es eliminar toda información confidencial expuesta dentro del servidor web, como puede ser documentos confidenciales, backups, registros, entre otros.
Como pudimos observar en la utilización de la herramienta Dirb para realizar fuzzing del servidor web, este no es el caso de una sanitización correcta.
Vemos que hay dentro de los directorios y ficheros dentro del servidor web que encontró Dirb:
Archivo robots.txt
El archivo robots.txt es un archivo de texto que indica a los rastreadores de los buscadores qué páginas de un sitio web pueden o no rastrear, osea mostrarse ante la búsqueda de un usuario mediante Google por ejemplo(Facilita mucho el uso de Google Dorks para este tipo de casos).
Directorio supplier
Se puede ver dentro del directorio supplier un archivo llamado “accounts”, si entramos dentro del mismo para chequear que hay:
Podemos verificar que a simple vista parecen cuentas por el nombre del fichero y que están cifradas en el algoritmo de cifrado Base64:
Si procedemos con el descifrado a texto claro utilizando la herramienta base64 de Kali, una vez descargado el recurso accounts con wget, este sería el resultado:
Si observamos la página web, podemos notar que a la izquierda encontramos un campo de búsqueda
Si realizamos una inyección XSS básica introduciendo código HTML para evaluar una posible inyección XSS, por ejemplo:
Como podemos visualizar en la imagen, este sitio web es vulnerable a inyecciones XSS y podemos insertar código HTML dentro de los campos(dependiendo como el desarrollador del sitio web haya gestionado como texto las entradas del campo o como código HTML). Este tipo de ataques son peligrosos por una sencilla razón, se pueden utilizar varios payloads(carga útil) en HTML para insertarlos en el campo y obtener diversos resultados, por ejemplo redirigir a un usuario a una página web maliciosa de phishing que pida datos, entre otros tipos de payloads. (Se puede montar un servidor Apache en Kali para alojar un sitio web malicioso de Phishing con SEToolkit y redirigir al usuario con código HTML en algún campo donde posteriormente quede registrado la entrada(Código HTML malicioso que redirige a sitio web malicioso) en la página.
Podemos encontrar varios repositorios en GitHub con payloads y explotar la vulnerabilidad XSS
Como podemos verificar en la imagen a continuación, dentro de este sitio web, hay formularios de login
Lo que tratamos de realizar con una inyección SQL es alterar la consulta que recibe la base de datos en simples palabras. Vamos a probar una inyección SQL básica para alterar la consulta y logearnos con el primer usuario que se presenta en la tabla de usuarios de la base de datos(Por lo general suele ser el administrador)
Hemos iniciado sesión sin la necesidad de ninguna contraseña
Vamos a ver estas consultas de fondo con la herramienta Burp Suite de Portswigger
Pero antes vamos a configurar nuestro navegador Firefox de Kali para que Burp Suite haga de intermediario con su proxy
Probemos crearnos una cuenta en el sitio web interceptando el tráfico mediante el proxy de Burp:
Este es el resultado al momento de darle al botón de Register:
Podemos notar que entre los parámetros que estamos enviando en la consulta, uno de ellos es: “role=U”, si usamos el sentido común, estamos definiendo el rol que va a tener ese usuario, en este caso es U de Usuario, ahora bien.
¿Qué pasaría si lo cambiamos por una A de Administrador y dejamos que siga adelante la consulta con el botón de “Forward”?
Dejamos de interceptar una vez que dejamos pasar las consultas que llegan a Burp Suite y vemos que nos creo el usuario correctamente:
Tendremos una cuenta de Administrador alterando la consulta realizada a la base de datos
¿Y AHORA?
Realizando una investigación dentro del manual de “Badstore Manual v1.2”, en busca de un panel de administración que conecte con alguna base de datos del servidor.
El manual de Badstore lo podemos encontrar en las referencias como se ve en la imagen:
Leyendo el manual nos encontramos con esto:
Si volvemos al sitio web y vamos a “Mi cuenta”, vemos que la URL es algo así como esto:
“192.168.8.11/cgi.bin/badstore.cgi?action=myaccount”
Vamos a cambiar el ?action=myaccount por ?action=admin dentro de la URL:
Obtenemos un panel secreto de administración, vamos a seleccionar en la lista desplegable “Show Current Users” y darle en “Do It”, obtendremos la base de datos de todos los usuarios:
Una vez ya obtenido acceso al panel de administración, podremos resetear la contraseña de los usuarios interactuando con la base de datos, agregar y eliminar usuarios, mirar la base de datos donde se encuentran los datos de los usuarios, etc
El CSRF es una vulnerabilidad de un sitio web en el que comandos no autorizados son transmitidos por un usuario en el cual el sitio web confía mediante la modificación de los métodos POST a GET para generar una URL.
Este tipo de ataques por lo general es muy frecuente verlos en formularios de cambio de contraseña en donde para realizar el cambio de contraseña no te exige la contraseña actual de la cuenta
Vamos a poner BurpSuite en escucha de consultas que pasen por el proxy y vamos a cambiar el usuario y la contraseña
Vemos que la consulta se está transmitiendo con el método POST, vamos a cambiar la consulta a método GET para generar un link malicioso para que solo con entrar a la URL, si el usuario se encuentra logueado, se le cambie la contraseña y el correo por el que nosotros le indiquemos a la URL
Obtendremos un resultado como este:
Como podremos ver, en la primera línea de la consulta nos encontramos con algo como esto:
“/cgi-bin/badstore.cgi?action=moduser&fullname=&newemail=asd%40gmail.com&newpasswd=hola&vnewpasswd=hola&role=A&email=tomz%40gmail.com&DoMods=Change+Account”
Ahora, ¿Qué pasaría si a esta parte de la primera línea que parece ser una URL, le agregamos la IP del servidor web?
Resulta en algo como esto:
“http://192.168.8.11/cgi-bin/badstore.cgi?action=moduser&fullname=&newemail=asd%40gmail.com&newpasswd=hola&vnewpasswd=hola&role=A&email=tomz%40gmail.com&DoMods=Change+Account”
Lo que sucedería es que esta URL que generamos, cambiaría la contraseña de nuestra cuenta por la que le especifiquemos dentro de la URL si accedemos.
Hagamos la prueba:
Ahora vamos a cambiar la contraseña por 2 hola con el enlace malicioso que creamos con Burp. Una vez ya modificada la contraseña en el enlace y ya entrado al mismo, veremos algo como esto:
Hagamos la prueba de logearnos con la contraseña “hola”:
Nos da contraseña incorrecta
Y si probamos con la contraseña que pusimos en el enlace malicioso, “holahola”
Nos inicia correctamente:
Esto resulta útil para realizar algún phishing en webs que son vulnerables, para cambiarle la contraseña a un usuario que ya se encuentre logueado en ese mismo sitio
Bibliografía:
**
