💉SQLMap - Bypass de protección web
En un escenario ideal, no se implementará ninguna protección en el lado objetivo, por lo que no se evitará la explotación automática. De lo contrario, podemos esperar problemas al ejecutar una herramienta automatizada de cualquier tipo contra dicho objetivo. Sin embargo, se incorporan muchos mecanismos en SQLMap que pueden ayudarnos a eludir con éxito dichas protecciones.
Omisión de tokens anti-CSRF
Una de las primeras líneas de defensa contra el uso de herramientas de automatización es la incorporación de tokens anti-CSRF (es decir, Cross-Site Request Forgery) en todas las solicitudes HTTP, especialmente aquellas generadas como resultado del llenado de formularios web.
En términos más básicos, cada solicitud HTTP en un escenario de este tipo debería tener un valor de token (válido) disponible solo si el usuario realmente visitó y utilizó la página. Si bien la idea original era la prevención de escenarios con enlaces maliciosos, donde el simple hecho de abrir estos enlaces tendría consecuencias no deseadas para los usuarios que iniciaron sesión sin saberlo (por ejemplo, abrir páginas de administrador y agregar un nuevo usuario con credenciales predefinidas), esta característica de seguridad también fortaleció inadvertidamente las aplicaciones contra la automatización (no deseada).
Sin embargo, SQLMap tiene opciones que pueden ayudar a eludir la protección anti-CSRF. En concreto, la opción más importante es --csrf-token. Al especificar el nombre del parámetro de token (que ya debería estar disponible en los datos de la solicitud proporcionada), SQLMap intentará analizar automáticamente el contenido de la respuesta de destino y buscar nuevos valores de token para poder usarlos en la próxima solicitud.
Además, incluso en un caso en el que el usuario no especifica explícitamente el nombre del token a través de --csrf-token, si uno de los parámetros proporcionados contiene alguno de los infijos comunes (es decir csrf, xsrf, token), se le preguntará al usuario si desea actualizarlo en futuras solicitudes:
Bypass de Unique ID
En algunos casos, la aplicación web puede requerir únicamente que se proporcionen valores únicos dentro de parámetros predefinidos. Este mecanismo es similar a la técnica anti-CSRF descrita anteriormente, excepto que no es necesario analizar el contenido de la página web. Por lo tanto, con solo asegurarse de que cada solicitud tenga un valor único para un parámetro predefinido, la aplicación web puede evitar fácilmente los intentos de CSRF y, al mismo tiempo, evitar algunas de las herramientas de automatización. Para esto, se debe utilizar la opción --randomize que apunta al nombre del parámetro que contiene un valor que se debe aleatorizar antes de enviarse:
Bypass de parámetro calculado
Otro mecanismo similar es cuando una aplicación web espera que se calcule un valor de parámetro adecuado en función de otros valores de parámetro. La mayoría de las veces, un valor de parámetro debe contener el resumen del mensaje (por ejemplo, h=MD5(id)) de otro. Para evitar esto, se debe utilizar la opción --eval , donde se evalúa un código Python válido justo antes de que se envíe la solicitud al destino:
Ocultar dirección IP
En caso de que queramos ocultar nuestra dirección IP, o si una determinada aplicación web tiene un mecanismo de protección que pone en lista negra nuestra dirección IP actual, podemos intentar utilizar un proxy o la red de anonimato Tor. Un proxy se puede configurar con la opción --proxy(por ejemplo --proxy="socks4://177.39.187.70:33283"), donde debemos agregar un proxy que funcione.
Además de eso, si tenemos una lista de servidores proxy, podemos proporcionárselos a SQLMap con la opción --proxy-file. De esta manera, SQLMap recorrerá secuencialmente la lista y, en caso de que surja algún problema (por ejemplo, la inclusión en la lista negra de direcciones IP), simplemente saltará de la actual a la siguiente de la lista. La otra opción es el uso de la red Tor para proporcionar una anonimización fácil de usar, donde nuestra IP puede aparecer en cualquier lugar de una gran lista de nodos de salida de Tor. Cuando se instala correctamente en la máquina local, debería haber un servicio de proxy SOCKS4 en el puerto local 9050 o 9150. Al usar el interruptor --tor, SQLMap intentará automáticamente encontrar el puerto local y usarlo adecuadamente.
Si quisiéramos asegurarnos de que Tor se está utilizando correctamente, para evitar un comportamiento no deseado, podríamos usar el modificador --check-tor. En tales casos, SQLMap se conectará a https://check.torproject.org/y comprobará la respuesta para el resultado deseado (es decir, que aparezca dentro Congratulations).
Bypass WAF
Siempre que ejecutamos SQLMap, como parte de las pruebas iniciales, SQLMap envía un payload predefinido de aspecto malicioso utilizando un nombre de parámetro inexistente (por ejemplo, ?pfov=...) para probar la existencia de un WAF (firewall de aplicaciones web). Habrá un cambio sustancial en la respuesta en comparación con el original en caso de que exista alguna protección entre el usuario y el objetivo. Por ejemplo, si se implementa una de las soluciones WAF más populares (ModSecurity), debería haber una respuesta 406 - Not Acceptable después de dicha solicitud.
En caso de detección positiva, para identificar el mecanismo de protección real, SQLMap utiliza una biblioteca de terceros identYwaf , que contiene las firmas de 80 soluciones WAF diferentes. Si quisiéramos omitir esta prueba heurística por completo (es decir, para producir menos ruido), podemos utilizar el switch --skip-waf.
Bypass de listas negras de User-agent
En caso de problemas inmediatos (por ejemplo, código de error HTTP 5XX desde el inicio) al ejecutar SQLMap, una de las primeras cosas en las que debemos pensar es en la posible inclusión en la lista negra del User-agent predeterminado utilizado por SQLMap (por ejemplo User-agent: sqlmap/1.4.9 (http://sqlmap.org)).
Esto es fácil de evitar con el modificador --random-agent, que cambia el agente de usuario predeterminado con un valor elegido aleatoriamente de un gran conjunto de valores utilizados por los navegadores.
Nota: Si se detecta algún tipo de protección durante la ejecución, podemos esperar problemas con el objetivo, incluso con otros mecanismos de seguridad. La razón principal es el continuo desarrollo y las nuevas mejoras en dichas protecciones, que dejan cada vez menos margen de maniobra a los atacantes.
Tamper Scripts
Por último, uno de los mecanismos más populares implementados en SQLMap para eludir las soluciones WAF/IPS son los llamados Tamper Scripts o de "manipulación". Los scripts de manipulación son un tipo especial de scripts (Python) escritos para modificar las solicitudes justo antes de enviarlas al destino, en la mayoría de los casos para eludir alguna protección.
Por ejemplo, uno de los scripts de manipulación más populares es reemplazar todas las apariciones del operador mayor que ( >) con NOT BETWEEN 0 AND #, y el operador igual ( =) con BETWEEN # AND #. De esta manera, muchos mecanismos de protección primitivos (enfocados principalmente en prevenir ataques XSS) se pueden eludir fácilmente, al menos para propósitos de SQLi.
Los scripts de manipulación se pueden encadenar, uno tras otro, dentro de la opción --tamper (por ejemplo, --tamper=between,randomcase), donde se ejecutan según su prioridad predefinida. Se predefine una prioridad para evitar cualquier comportamiento no deseado, ya que algunos scripts modifican las cargas útiles modificando su sintaxis SQL (por ejemplo, ifnull2ifisnull ). Por el contrario, algunos scripts de manipulación no se preocupan por el contenido interno (por ejemplo, appendnullbyte ).
Los scripts de manipulación pueden modificar cualquier parte de la solicitud, aunque la mayoría cambia el contenido del payload. Los scripts de manipulación más destacados son los siguientes:
Script de manipulación | Descripción |
| Reemplaza instancias de UNIÓN con e0UNIÓN |
| Codifica en Base64 todos los caracteres en un payload determinado |
| Reemplaza el operador mayor que ( |
| Reemplaza instancias (MySQL) como |
| Reemplaza todas las apariciones del operador igual ( |
| Agrega un comentario versionado (MySQL) antes de cada palabra clave |
| Incluye una consulta completa con comentarios versionados (MySQL) |
| Admite consultas completas con comentarios con versión cero (MySQL) |
| Agrega un signo de porcentaje ( |
| Reemplaza el operador más ( |
| Reemplaza cada carácter de palabra clave con un valor de mayúsculas y minúsculas aleatorio (por ejemplo, SELECT -> SEleCt) |
| Reemplaza el carácter de espacio ( ) con comentarios `/ |
| Reemplaza el carácter de espacio ( ) con un comentario de guión ( |
| Reemplaza (MySQL) las instancias del carácter de espacio ( ) con un carácter de almohadilla ( |
| Reemplaza (MsSQL) instancias del carácter de espacio ( ) con un carácter en blanco aleatorio de un conjunto válido de caracteres alternativos |
| Reemplaza el carácter de espacio ( ) por el signo más ( |
| Reemplaza el carácter de espacio ( ) con un carácter en blanco aleatorio de un conjunto válido de caracteres alternativos |
| Reemplaza los operadores lógicos AND y OR con sus contrapartes simbólicas ( |
| Encierra cada palabra clave que no sea de función con un comentario versionado (MySQL) |
| Encierra cada palabra clave con un comentario versionado (MySQL) |
Para obtener una lista completa de los scripts de manipulación implementados, junto con la descripción que se menciona anteriormente, se puede utilizar el switch --list-tampers. También podemos desarrollar scripts de manipulación personalizados para cualquier tipo de ataque personalizado, como un SQLi de segundo orden.
Bypass varios
Además de otros mecanismos de omisión de protección, hay dos más que se deben mencionar. El primero es la codificación de transferencia Chunked, que se activa mediante el switch --chunked, que divide el cuerpo de la solicitud POST en los llamados "fragmentos". Las palabras clave SQL incluidas en la lista negra se dividen entre fragmentos de manera que la solicitud que las contiene pueda pasar desapercibida.
El otro mecanismo de derivación es el HTTP parameter pollution( HPP), donde los payloads se dividen de manera similar al caso de --chunked entre diferentes valores con el mismo parámetro nombrado (por ejemplo, ?id=1&id=UNION&id=SELECT&id=username,password&id=FROM&id=users...), que son concatenados por la plataforma de destino si la admite (por ejemplo, ASP).
Ejercicios
Pregunta 1
¿Cuál es el contenido de la tabla flag8? (Caso n.° 8)
Tenemos que detectar y explotar un SQLi en el parámetro id que se envía por POST, teniendo en cuenta la protección anti-CSRF:
Pregunta 2
¿Cuál es el contenido de la tabla flag9? (Caso n.° 9)
Tenemos que detectar y explotar un SQLi en el parámetro id que se envía por GET, teniendo en cuenta el UID único:
No olvides especificar el nombre del parámetro que necesitas aleatorizar.
Pregunta 3
¿Cuál es el contenido de la tabla flag10? (Caso n.° 10)
Tenemos que detectar y explotar un SQLi en un parámetro id que se envía por POST:
Capturamos la petición con Burpsuite y guardamos la petición en un archivo case10.req
Pregunta 4
¿Cuál es el contenido de la tabla flag11? (Caso n.° 11)
Según los datos proporcionados en la página, seleccione el script de manipulación adecuado para eludir las protecciones de la página.
Paso 1: Seleccionar un tamper script adecuado
Si encuentras que los caracteres < y > están bloqueados, prueba con un tamper script que transforme la inyección SQL para evitar esos caracteres. Un tamper scripts que podría funcionar es:
between: Usa BETWEEN en lugar de operadores como < o >.
Paso 2: Explotar SQLi con un Tamper Script
Nos encontramos de que la enumeración de esta base de datos es muy lenta al hacer el dump completo, enconces vamos a hacer una query específica para extraer la flag 11:
Última actualización
