SQLmap est un outil d’exploitation automatisée d’injections SQL.
Il est très pratique en test d’intrusion pour envoyer énormément de payloads, et trouver des injections qui seraient passées inaperçues avec des tests basiques manuels.
Certaines injections SQL nécessitent néanmoins que l’auditeur scripte lui-même l’exploit : injection trop complexe pour être détectée par sqlmap, serveur trop instable, et autres cas limites.
Quelques fonctionnalités méconnues de SQLmap peuvent tout de même permettre son utilisation malgré des cas d’exploitation complexes.
Cet article, à destination d’utilisateurs confirmés, en détaille deux :
Encodage des requêtes SQLmap
Un pentester DSecBypass a rencontré une application web qui n’acceptait que des corps de requêtes HTTP POST encodés en base64.
Dans ce cas précis, SQLmap ne peut rien faire par défaut : modifier le corps de la requête aléatoirement rendrait l’encodage et les données invalides.
Pourtant, les tests manuels montrent que derrière ce bloc de texte base64 se cache un objet JSON dont un des paramètres est vulnérable à une injection SQL.
Pour pallier ce problème, les scripts tamper peuvent être utilisés. Initialement prévus pour modifier les payloads afin de contourner les pare-feu applicatifs (WAF), il est possible de créer son propre script afin de manipuler la donnée générée par SQLmap.
Créer et utiliser un script Python de tamper est simple :
- Dans son répertoire de travail, créer un fichier « __init__.py » vide ;
- Créer un script Python3 « mytamper.py » avec le contenu suivant :
- Utiliser ce script avec la commande suivante en étant dans le même répertoire que les fichiers Python :
sqlmap --random-agent -o -u "https://[...]/application/process/" --data "*" --header "Content-Type: application/octet-stream" --method POST --tamper mytamper.py --random-agent
SQLmap utilise alors notre script pour modifier chaque test effectué avant de l’envoyer au serveur.
Injection en plusieurs étapes
SQLmap propose nativement une solution pour les injections ‘de second ordre‘, c’est à dire les injections SQL qui sont exploitables parce qu’une deuxième requête, vulnérable, utilise le résultat d’une première, non vulnérable.
L’outil propose alors les paramètres ‘–second-url‘ ou ‘–second-req‘ pour aller chercher le résultat de l’injection respectivement par un GET sur une URL ou en rejouant la requête contenue dans un fichier (comme avec ‘-r‘).
Cela couvre déjà beaucoup de cas d’usages, cependant un pentester DSecBypass a rencontré une application avec une injection SQL de second ordre dont la deuxième requête nécessite la mise à jour d’un paramètre.
Première requête POST (la payload est mise en base)
Deuxième requête POST (une requête SQL vulnérable utilise alors le résultat de notre première requête)
La seconde image montre le paramètre ts, dérivé du timestamp Unix. S’il est invalide, la requête n’est pas acceptée et SQLmap n’arrivera pas à correctement exploiter l’injection.
Heureusement, l’outil propose un mécanisme de dernier ressort : les scripts de postprocessing.
C’est encore une fois assez simple à utiliser :
- Dans son répertoire de travail, créer un fichier « __init__.py » vide
- Créer un script Python3 « mypostproc.py » avec le contenu suivant :
- On exploite l’injection avec la commande SQLmap suivante (utilisation de « -r » pour indiquer à SQLmap de travailler depuis un fichier à partir de la première requête HTTP)
sqlmap -r sqli_my_application --force-ssl --dbms postgresql --level 5 --risk 2 --postprocess mypostproc.py --current-user --technique "ST"
Notez que cette technique fonctionne avec tous les types d’injection, même en time-based puisque SQLmap prendra également en compte le délai d’exécution du script de postprocessing.
Si vous utilisez un proxy avec SQLmap, il est également possible de le spécifier dans l’appel Python à requests avec l’argument « proxies ».
🛡️ DSecBypass vous accompagne sur l’audit de sécurité de vos applications Web. N’hésitez pas à nous contacter pour des informations complémentaires et/ou un devis personnalisé 📝.
