💉SQLMap - Ajuste del ataque
En la mayoría de los casos, SQLMap debería ejecutarse de inmediato con los detalles del objetivo proporcionados. Sin embargo, existen opciones para ajustar los intentos de inyección de SQLi para ayudar a SQLMap en la fase de detección. Cada carga útil enviada al objetivo consta de:
Vector (por ejemplo,
UNION ALL SELECT 1,2,VERSION()): parte central del payload, que lleva el código SQL útil que se ejecutará en el destino.Límites (por ejemplo
'<vector>-- -): formaciones de prefijo y sufijo, utilizadas para la inyección adecuada del vector en la declaración SQL vulnerable.
Prefijo/Sufijo
En casos excepcionales, no contemplados por la ejecución normal de SQLMap, se requieren valores de prefijo y sufijo especiales. Para dichas ejecuciones, se pueden utilizar las opciones --prefix y --suffix de la siguiente manera:
sqlmap -u "www.example.com/?q=test" --prefix="%'))" --suffix="-- -"Esto dará como resultado un encierro de todos los valores vectoriales entre el prefijo estático %'))y el sufijo -- -. Por ejemplo, si el código vulnerable en el objetivo es:
$query = "SELECT id,name,surname FROM users WHERE id LIKE (('" . $_GET["q"] . "')) LIMIT 0,1";
$result = mysqli_query($link, $query);El vector UNION ALL SELECT 1,2,VERSION(), delimitado por el prefijo %'))y el sufijo -- -, dará como resultado la siguiente declaración SQL (válida) en el destino:
SELECT id,name,surname FROM users WHERE id LIKE (('test%')) UNION ALL SELECT 1,2,VERSION()-- -')) LIMIT 0,1Nivel/Riesgo
De forma predeterminada, SQLMap combina un conjunto predefinido de límites más comunes (es decir, pares de prefijo/sufijo), junto con los vectores que tienen una alta probabilidad de éxito en caso de un objetivo vulnerable. Sin embargo, existe la posibilidad de que los usuarios utilicen conjuntos más grandes de límites y vectores, ya incorporados en SQLMap.
Para tales casos se deberán utilizar las opciones --level y --risk:
La opción
--level(1-5, predeterminada1) extiende tanto los vectores como los límites que se utilizan, en función de su expectativa de éxito (es decir, cuanto menor sea la expectativa, mayor será el nivel).La opción
--risk(1-3, predeterminada1) extiende el conjunto de vectores usado en función de su riesgo de causar problemas en el lado de destino (es decir, riesgo de pérdida de entrada de base de datos o denegación de servicio).
La mejor manera de comprobar las diferencias entre los límites y los payloads utilizados para diferentes valores de --level y --risk es el uso de la opción -v para establecer el nivel de verbosidad. En el nivel de verbosidad 3 o superior (por ejemplo, -v 3), se mostrarán los mensajes que contienen el [PAYLOAD] , de la siguiente manera:
Por otro lado, los payloads utilizados con el valor --level predeterminado tienen un conjunto de límites considerablemente más pequeño:
En cuanto a los vectores, podemos comparar los payloads utilizados de la siguiente manera:
En cuanto al número de payloads, de forma predeterminada (es decir, --level=1 --risk=1), el número de payloads utilizados para probar un solo parámetro sube hasta 72, mientras que en el caso más detallado ( --level=5 --risk=3) el número de payloads aumenta a 7.865.
Como SQLMap ya está configurado para comprobar los límites y vectores más comunes, se recomienda a los usuarios habituales no tocar estas opciones porque harán que todo el proceso de detección sea considerablemente más lento. Sin embargo, en casos especiales de vulnerabilidades de SQLi, donde el uso de payloads OR es obligatorio (por ejemplo, en el caso de las páginas de login), es posible que tengamos que aumentar el nivel de riesgo nosotros mismos.
Esto se debe a que los payloads OR son inherentemente peligrosas en una ejecución predeterminada, donde las declaraciones SQL vulnerables subyacentes (aunque con menos frecuencia) modifican activamente el contenido de la base de datos (por ejemplo, DELETEo UPDATE).
Ajuste avanzado
Para afinar aún más el mecanismo de detección, hay un conjunto considerable de opciones y parámetros. En casos normales, SQLMap no requerirá su uso. Aun así, debemos familiarizarnos con ellos para poder usarlos cuando sea necesario.
Códigos de estado
Por ejemplo, cuando se trata de una respuesta de objetivo enorme con mucho contenido dinámico, se podrían utilizar diferencias sutiles entre las respuestas TRUE y FALSE con fines de detección. Si la diferencia entre respuestas TRUE y FALSE se puede ver en los códigos HTTP (por ejemplo, 200 para TRUE y 500 para FALSE), la opción --code podría usarse para fijar la detección de respuestas TRUE a un código HTTP específico (por ejemplo, -- código = 200).
Title
Si la diferencia entre las respuestas se puede ver inspeccionando los títulos de las páginas HTTP, el interruptor --titles podría usarse para indicar al mecanismo de detección que base la comparación en el contenido de la etiqueta HTML <title>.
Strings
En caso de que un valor de cadena específico aparezca en las respuestas TRUE (por ejemplo, success), pero esté ausente en las respuestas, se podría usar la opción FALSE para fijar la detección basándose únicamente en la aparición de ese único valor (por ejemplo , ).--string--string=success
Text-only
Cuando trabajamos con mucho contenido oculto, como ciertas etiquetas de comportamiento de páginas HTML (por ejemplo <script>, <style>, , <meta>, etc.), podemos usar la flag --text-only, que elimina todas las etiquetas HTML y basa la comparación solo en el contenido textual (es decir, visible).
Técnicas
En algunos casos especiales, tenemos que limitar los payloads utilizados a un tipo determinado. Por ejemplo, si las cargas útiles ciegas basadas en el tiempo están causando problemas en forma de tiempos de espera de respuesta, o si queremos forzar el uso de un tipo específico de payload SQLi, la opción --technique puede especificar la técnica SQLi que se utilizará.
Por ejemplo, si queremos omitir los payloads SQLi ciegas basadas en tiempo y de apilamiento y solo probar los payloads ciegas basadas en booleanos, basadas en errores y de consulta UNION, podemos especificar estas técnicas con --technique=BEU.
Ajuste de SQLi de UNION
En algunos casos, los payloads de SQLi UNION requieren información adicional proporcionada por el usuario para funcionar. Si podemos encontrar manualmente el número exacto de columnas de la consulta SQL vulnerable, podemos proporcionar este número a SQLMap con la opción --union-cols(por ejemplo --union-cols=17, ). En caso de que los valores de relleno "ficticios" predeterminados utilizados por SQLMap ( NULLy el entero aleatorio) no sean compatibles con los valores de los resultados de la consulta SQL vulnerable, podemos especificar un valor alternativo en su lugar (por ejemplo, --union-char='a').
Además, en caso de que exista un requisito para utilizar un apéndice al final de una consulta UNION en forma de FROM <table>(por ejemplo, en el caso de Oracle), podemos configurarlo con la opción --union-from(por ejemplo --union-from=users). El hecho de no utilizar el apéndice FROM correcto de forma automática podría deberse a la incapacidad de detectar el nombre del DBMS antes de su uso.
Ejercicio
Pregunta 1
¿Cuál es el contenido de la tabla flag5? (Caso n.° 5)
Si ejecutamos un escaneo normal con sqlmap no obtenemos ningún resultado, por lo que tenemos que aumentar el --level y --risk:
Pregunta 2
¿Cuál es el contenido de la tabla flag6? (Caso n.° 6)
Pregunta 3
¿Cuál es el contenido de la tabla flag7? (Caso n.° 7)
Última actualización
¿Te fue útil?