Ajuster l'Agressivité des Scans avec Level et Risk dans sqlmap

Introduction

sqlmap est un puissant outil de test de pénétration open-source qui automatise le processus de détection et d'exploitation des failles d'injection SQL. Lors de la réalisation d'un scan, deux des paramètres les plus importants que vous pouvez contrôler sont --level et --risk. Ces paramètres déterminent la minutie et l'agressivité du scan.

• Level : Contrôle le nombre de tests à effectuer. Il varie de 1 à 5, les niveaux supérieurs effectuant des tests plus approfondis sur plus de points d'injection (comme les en-têtes HTTP).
• Risk : Contrôle le niveau de risque des charges utiles (payloads) utilisées. Il varie de 1 à 3, les risques supérieurs utilisant des charges utiles potentiellement perturbatrices (comme les requêtes basées sur le temps qui peuvent ralentir une base de données).

Dans ce laboratoire, vous apprendrez à utiliser ces deux paramètres pour affiner vos scans sqlmap. Vous commencerez par un scan par défaut et augmenterez progressivement le niveau et le risque pour observer leur impact sur la portée, la durée et les types de charges utiles utilisées lors du scan.

Comprendre le Niveau (1) et le Risque (1) par Défaut

Dans cette étape, vous allez effectuer un scan sqlmap de base sans spécifier le level ou le risk. Par défaut, sqlmap utilise --level=1 et --risk=1. C'est le scan le moins complet et le plus sûr.

Le Level 1 teste uniquement les paramètres GET et POST. Le Risk 1 utilise des charges utiles généralement inoffensives pour une application web, telles que des tests d'injection basés sur des booléens et des erreurs.

Exécutons le scan par défaut sur l'application vulnérable qui a été configurée pour vous. L'option --batch répond automatiquement à toutes les questions avec le choix par défaut, rendant le scan non interactif.

Exécutez la commande suivante dans votre terminal :

sqlmap -u "http://127.0.0.1:8000/index.php?id=1" --batch

Vous verrez sqlmap démarrer son processus de test. Portez attention au résumé à la fin, qui indique le nombre de requêtes effectuées et les vulnérabilités trouvées.

...
[INFO] testing 'Boolean-based blind - WHERE or HAVING clause'
[INFO] testing 'Error-based - WHERE or HAVING clause'
[INFO] testing 'Time-based blind'
...
[INFO] GET parameter 'id' is vulnerable. Do you want to keep testing the others (if any)? [y/N] N
sqlmap identified the following injection point(s) with a total of XXX HTTP(s) requests:
---
Parameter: id (GET)
    Type: boolean-based blind
    Title: AND boolean-based blind - WHERE or HAVING clause
    Payload: id=1 AND 2129=2129

    Type: error-based
    Title: SQLite OR error-based - CUME_DIST
    Payload: id=1 OR 1 GROUP BY CUME_DIST(1)

    Type: time-based blind
    Title: SQLite > 2.0 AND time-based blind
    Payload: id=1 AND 7415=CASE WHEN (substr(sqli,1,1)='S') THEN 7415 ELSE 0 END
---
[INFO] fetched data logged to text files under '/home/labex/.local/share/sqlmap/output/127.0.0.1'
...

Ce scan initial est relativement rapide et confirme la vulnérabilité du paramètre id.

Augmenter la Profondeur du Scan avec --level=3

Dans cette étape, vous allez augmenter la profondeur du scan en définissant le niveau à 3. Un niveau plus élevé indique à sqlmap d'effectuer plus de tests et de vérifier les vulnérabilités dans des emplacements supplémentaires.

• --level=2 ajoute des tests pour les en-têtes HTTP Cookie.
• --level=3 ajoute des tests pour les en-têtes HTTP User-Agent et Referer.

En augmentant le niveau, vous demandez à sqlmap d'être plus minutieux. Cela augmentera naturellement le nombre de requêtes et la durée du scan.

Exécutez maintenant le scan à nouveau, mais cette fois ajoutez l'option --level=3 :

sqlmap -u "http://127.0.0.1:8000/index.php?id=1" --level=3 --batch

Observez la sortie. Vous remarquerez que sqlmap mentionne maintenant explicitement le test des en-têtes comme Cookie et User-Agent.

...
[INFO] testing for SQL injection on GET parameter 'id'
...
[INFO] testing for SQL injection on HTTP Cookie header
...
[INFO] testing for SQL injection on HTTP User-Agent header
...
sqlmap identified the following injection point(s) with a total of YYY HTTP(s) requests:
---
Parameter: id (GET)
    Type: boolean-based blind
    Title: AND boolean-based blind - WHERE or HAVING clause
    Payload: id=1 AND 2129=2129
...
---
[INFO] fetched data logged to text files under '/home/labex/.local/share/sqlmap/output/127.0.0.1'
...

Bien que notre application simple ne soit pas vulnérable via ces en-têtes, une application du monde réel pourrait l'être. Vous devriez remarquer que le nombre total de requêtes HTTP (YYY) est supérieur à celui de l'étape précédente (XXX).

Augmenter l'Invasivité du Scan avec --risk=2

Dans cette étape, vous allez explorer le paramètre --risk. Ce paramètre contrôle le "danger" des charges utiles utilisées.

• --risk=1 (Par défaut) : Utilise des charges utiles principalement inoffensives.
• --risk=2 : Ajoute des tests d'injection "time-based blind" (basés sur le temps) avec des requêtes lourdes. Ceux-ci peuvent imposer une charge significative sur le serveur de base de données.
• --risk=3 : Ajoute des tests d'injection SQL basés sur OR et d'autres charges utiles potentiellement destructrices qui pourraient modifier des données.

Un risque plus élevé peut découvrir des vulnérabilités que des tests plus sûrs pourraient manquer, mais il augmente également le risque de perturber le système cible. Il doit être utilisé avec prudence.

Exécutons un scan avec un risque accru. Nous reviendrons au niveau par défaut (1) pour isoler l'effet du paramètre de risque.

sqlmap -u "http://127.0.0.1:8000/index.php?id=1" --risk=2 --batch

Pendant ce scan, vous verrez sqlmap employer des techniques "time-based" plus agressives. Ces charges utiles fonctionnent en faisant en sorte que la base de données effectue une opération longue (comme un benchmark ou une fonction sleep) puis en mesurant le temps de réponse du serveur pour en déduire des informations.

...
[INFO] testing 'Boolean-based blind - WHERE or HAVING clause'
[INFO] testing 'Error-based - WHERE or HAVING clause'
[INFO] testing 'Time-based blind (heavy query)'
...
[INFO] GET parameter 'id' appears to be 'Time-based blind' injectable
...

Le scan avec --risk=2 est plus intensif que le scan par défaut, même au même niveau, car les charges utiles elles-mêmes sont plus complexes.

Exécuter un Scan Combinant --level=5 et --risk=3

Dans cette étape, vous allez combiner les réglages de niveau et de risque les plus élevés pour un scan aussi complet et agressif que possible.

• --level=5 : Le niveau le plus élevé. Il teste tous les points d'injection possibles, y compris l'en-tête HTTP Host.
• --risk=3 : Le risque le plus élevé. Il utilise des charges utiles qui peuvent potentiellement modifier les entrées de la base de données. Ceci est dangereux et ne doit être utilisé que sur des systèmes pour lesquels vous avez une autorisation explicite de tests destructeurs.

Cette combinaison entraîne un scan très long et intensif. C'est l'approche "tout y compris" (kitchen sink), qui applique tous les tests connus à la cible.

Exécutez la commande suivante. Sachez que ce scan prendra considérablement plus de temps que les précédents.

sqlmap -u "http://127.0.0.1:8000/index.php?id=1" --level=5 --risk=3 --batch

Vous verrez sqlmap exécuter un nombre massif de tests sur tous les points d'injection imaginables avec ses charges utiles les plus puissantes.

...
[INFO] testing for SQL injection on GET parameter 'id'
...
[INFO] testing for SQL injection on HTTP Cookie header
...
[INFO] testing for SQL injection on HTTP User-Agent header
...
[INFO] testing for SQL injection on HTTP Referer header
...
[INFO] testing for SQL injection on HTTP Host header
...
[CRITICAL] OR-based injection tests might result in an update of all table rows. Continue? [y/N] y
...

Ce scan démontre la capacité maximale de sqlmap mais souligne également l'importance de comprendre les compromis. Un tel scan est souvent peu pratique et trop risqué pour des engagements standards.

Observer l'Augmentation des Charges Utiles et de la Durée du Scan

Dans cette dernière étape, vous allez réfléchir aux résultats des scans précédents. Il n'y a pas de nouvelles commandes à exécuter. L'objectif est de comprendre l'impact de l'ajustement de level et risk en comparant les résumés des scans.

Si vous examinez la sortie du terminal de chaque étape, vous remarquerez un schéma clair :

1. Scan par Défaut (--level=1, --risk=1) : La référence. Il était rapide et a envoyé le moins de requêtes.
2. Niveau Augmenté (--level=3) : Le nombre de requêtes a augmenté car sqlmap a testé plus de points d'injection (Cookie, User-Agent). La durée a augmenté en conséquence.
3. Risque Augmenté (--risk=2) : La durée du scan a augmenté, pas nécessairement en raison de plus de requêtes, mais parce que les charges utiles basées sur le temps sont intrinsèquement lentes.
4. Agressivité Maximale (--level=5, --risk=3) : Ce scan a envoyé un nombre considérablement plus élevé de requêtes et a pris le plus de temps pour s'achever, et ce, de manière significative.

Voici un résumé du comportement attendu :

Le point clé à retenir est qu'il existe un compromis direct. Augmenter level et risk permet des tests plus approfondis et une plus grande chance de trouver des vulnérabilités obscures, mais cela se fait au prix d'un temps de scan considérablement augmenté et d'un risque plus élevé de perturber le système cible.

Résumé

Dans ce laboratoire, vous avez exploré avec succès comment ajuster l'agressivité des scans sqlmap en utilisant les paramètres --level et --risk.

Vous avez appris que :

• --level contrôle la portée du scan, déterminant quelles parties d'une requête HTTP sont testées pour les vulnérabilités. Des niveaux plus élevés sont plus complets.
• --risk contrôle l'intrusivité du scan, déterminant les types de charges utiles SQL utilisées. Des risques plus élevés sont plus susceptibles de trouver des vulnérabilités mais peuvent être dangereux pour la base de données cible.
• Les paramètres par défaut (level=1, risk=1) sont conçus pour être rapides et sûrs.
• L'augmentation de ces valeurs entraîne des temps de scan plus longs et nécessite plus de prudence.

Comme meilleure pratique, commencez toujours par des paramètres level et risk plus bas. N'augmentez-les que si les scans initiaux échouent et que vous avez l'autorisation appropriée pour effectuer des tests plus agressifs. Félicitations pour avoir terminé ce laboratoire !