SQL Injection: Les techniques d’évasion de filtres

Pour minimiser le risque de se faire attaquer via une injection SQL, les administrateurs système mettent souvent en place des modules de protection permettant de bloquer la majorité des attaques basiques et celles effectuées à l’aide d’un outil automatisé. Dans ce billet, j’expliquerai les techniques utilisées pour énumérer l’existence de l’un de ces derniers, ainsi que les limitations et méthodes utilisées pour contourner ces protections.

Je vous rappelle qu’en lisant ceci, vous acceptez que je ne peux être tenu responsable pour toute action prise, les informations que je partage dans ce billet sont à utiliser SEULEMENT pour faire des PENTEST.

Principe des filtres

Certains filtrages sont souvent effectués côté client, le plus souvent avec javascript sur la page Web. Il suffit pour un attaquant d’enregistrer la page localement et supprimer le script pour les évader. Toutefois, la majorité des filtrages dans notre cas se font grâce à une liste noire restrictive et par conséquent, une certaine liste de mots ne peut être exécutée. Les outils les plus couramment utilisés pour cela sont: les systèmes de détection d’intrusion (IDS) et les filtres d’applications Web (WAF).

Les systèmes de détection d’intrusion

Un système de détection d’intrusion surveille l’activité réseau pour essayer de détecter des actions malveillantes et se concentre principalement sur l’exploitation forestière en faisant état de tentatives d’exploiter une application web. ce dernier essaye de répondre aux attaques et les empêche de se produire.

Le principe d’un IDS est de comparer les entrées de l’utilisateur avec des patterns malicieux connus appelés SIGNATURES. En voici un exemple:

alert tcp any any -> $HTTP_SERVERS $HTTP_PORTS (msg: « SQL Injection attempt »;
flow: to_server, established; content: « ‘OR’1′=’1′– »; nocase; sid: 1; rev:1;

D’où le ‘OR’1′=’1′– est ce qui est observé et ce qui provoque l’IDS pour alerter l’administrateur Web en lui envoyant comme message: « SQL Injection attempt ».

Bien entendu ceci n’est qu’un exemple, plusieurs combinaisons peuvent être utilisées pour contourner ce genre de protection, par-contre si l’IDS utilise un bon dictionnaire de SIGNATURES, l’attaquant devrait avoir beaucoup de créativité car il devient de plus en plus difficile de les contourner.

Les filtres d’applications WEB

Un filtre d’application WEB est un logiciel appliquant certaines règles à la requête pour tenter d’empêcher le code malveillant d’atteindre le serveur. Un WAF pourrait mettre en œuvre une liste noire ou blanche pour le contrôle d’entrée ce qui donne à beaucoup d’administrateurs un faux sentiment de sécurité. Pourquoi? la réponse c’est que tout simplement l’essentiel est la sécurité du codage du site Web.

Si vous obtenez une erreur « 501 Method Not Implemented » ou bien « 200 Condition Intercepted » après une tentative de test d’injection SQL avec « union all select » c’est que le serveur surlequel vous effectuez vos pentest utilise un WAF, mod_security par exemple..

En rappelle mod_security est un pare-feu open source d’applications Web qui fonctionne en tant que module du serveur Apache. Il dispose d’un ensemble complet de règles appelé «règles de base ModSecurity» pour bloquer les vecteurs d’attaques d’application web (injections SQL, Cross-Site Scripting etc..)

Contourner un IDS/WAF

Il existe plusieurs méthodes pour tester la fiabilité d’un IDS/WAF et éventuellement pour le contourner, voici une liste non-exhaustive des techniques qui peuvent permettre de surpasser les filtres:

Commentaires avec variables

Cette technique exploite une faille dans la méthode d’interprétation des variables dans Apache, on prends l’exemple suivant :

article.php?id=-1 UNION SELECT 1,2,3,4

  • Interprétation mod_security :
    id=-1 UNION SELECT 1,2,3,4 => BLOQUÉE

article.php?id=-1 UNION/**/SELECT/**/1,2,3,4

  • Interprétation mod_security :
  • id=-1 UNION/**/SELECT 1,2,3,4 => BLOQUÉE
  • Interprétation de l’application : : $_GET['id'] = « -1 UNION/**/SELECT/**/1,2,3,4″
  • article.php?id=-1 UNION/*&test=1*/SELECT/*&pwn=2*/1,2,3,4–

  • Interprétation mod_security :
    • id: -1 UNION/*
    • test: 1/*SELECT/*
    • pwn: 2/*1,2,3,4–
  • aisni => id=-1 UnION/*&test=1*/SELECT/*&pwn=2*/ 1,2,3,4 => PASSE
  • Interprétation de l’application : : $_GET['id'] = « -1 UNION/*&test=1*/SELECT/*&pwn=2*/1,2,3,4″
  • Phrases remplacées par des chaines vides et espace

    Certains filtres, afin d’empêcher l’exécution de requêtes contenant certains mots clés, ils remplacent ces derniers par des espaces/chaines vides ainsi :

    -123 UNION SELECT 1,2,3,4

    devient :

    profile.php?id=-1231,2,3,4

    Ce type de protection est facilement contournable on dupliquant le même mot restreint au milieux de ce dernier:
    exemple :

    -1 UNunionION SELselectCT 1,2,3,4

    ce qui donnera après remplacement

    -1 union select 1,2,3,4

    Dans certains cas, les WAF remplacent également les caractères spéciaux comme « ‘;:(){}/**/&$|?<> .Un attaquant peut s’en servir comme séparateur pour construire des mots clés restreins après suppression de l’un de ces caractères.. exemple :

    profile.php?user_id=-1 un?<ion sel&ect login,password,null,null,null fro}m admin

    Les null-bytes

    Placer un caractère null (%00) après un mot filtré peu dans certains cas contourner le filtre..

    Encodage de caractères

    La majorité des IDS&WAF ne supportent pas tous les types d’encodage, ainsi un attaquant peut encoder les paramètre dans l’URL pour échapper aux filtres:

    • Hex encoding: conversion de chaine en hexadécimal, exemple : load_file(0x2f6574632f706173737764) => load_file(/etc/passwd)
    • Unicode: %uff41%uff42%uff43 = ‘abc’
    • La fonction Char: CHAR(41,42,43) = ‘abc’, utilisable les codes décimales en ASCII
    • Le double Encoding: le principe est d’encoder les caractères deux fois de suite dans le but d’obtenir un caractère restreint après interprétation, exemple : Le signe % est égale à 25 en hexadécimal, quand codé pour les URLs il devient %25. Le «signle quote» ‘ est symbolisé par le chiffre 27 en hexadécimal ainsi dans une URL il ressemble à %27. si on l’encode à nouveau on obtient %2527 qui est interprété comme étant un «single quote» ‘, ce qui peut être en mesure de contourner certains filtres.

    Conclusion

    Utiliser un système de détection d’intrusion ou un par-feux d’application web est une bonne pratique pour minimiser le risque d’être attaqué, toute-fois avec peu de créativité, un attaquant peut réussir à les contourner et compromettre votre application web, ainsi la meilleure solution est de bien sécuriser votre code avant tout!

    Je rappelle que je ne revendique aucune responsabilité des actions que vous prenez en lisant ceci, Le but étant d’attirer l’attention des administrateurs système afin de ne pas avoir un faux sentiment de sécurité :) .

    Merci pour la lecture! Commentaires et critiques constructives sont toujours les bienvenus.