SQL Smuggling : l'attaque sournoise contre les bases de donnéesA l’occasion de la RSA Conference 2008 à Londres, une présentation a détaillé l’attaque de SQL Smuggling, ou comment faire passer une injection SQL sous le nez du pare-feu applicatif web.
C’est parce que le pare-feu applicatif web (WAF) offre un contexte d'exécution totalement différent de l’application qu’il est censé protéger qu’une attaque par smuggling (contrebande) est possible. Le WAF ne fait bien même souvent qu’observer, et non interpréter, les requêtes. Il ne peut alors anticiper l’effet réel qu'elles produiront sur le serveur applicatif derrière lui. Le principe du smuggling consiste alors à soumettre une requête formatée d’une manière tout à fait légitime aux yeux du WAF mais dont l’interprétation sur le serveur produira des effets néfastes. Si les premières applications de smuggling concernaient les serveurs web (voir les travaux d’Amit Klein au sujet des attaques par HTTP Response Splitting), la présentation d'Avi Douglen (ComSec Consulting) à l’occasion de la RSA Conference Europe en applique le principe aux bases de données SQL. La partie la plus intéressante de la présentation concerne l’usage des homoglyphes : ces symboles qui à l’écran ressemblent fortement à des lettres de l’alphabet occidental mais qui ont, bien entendu, une représentation Unicode différente. La technique est déjà bien connue pour maquiller des URL lors de campagnes de phishing, mais elle peut aussi être exploitée dans le cadre du SQL smuggling, en profitant du fait que certaines bases de données opèrent automatiquement une traduction des caractères unicodes non supportés vers le jeu de caractères local. “Lorsqu’un caractère présent dans la requête n’existe pas dans le jeu de caractères local de la base, certaines bases de données l’ignorent, d’autres lèvent une erreur, mais d’autres encore le traduisent par le caractère le plus proche”, explique Avi Douglen. Il cite ainsi l’exemple de U+02BC, qui ressemble de très près à un guillemet simple (U+0027), et qui pourra passer outre un filtrage applicatif tout en étant convertit automatiquement par la base de données en son équivalent le plus proche... un véritable guillemet simple ! Enfin, la présentation d’Avi Douglen offre d’autres exemples moins originaux mais tout aussi problèmatiques, pour l’essentiel basés sur une utilisation “créative” des espaces et des caractères de commentaires (par exemple le fameux exec(‘INS’ + ‘SERT INTO’). L’auteur recommande, bien entendu, de ne pas autoriser la traduction automatique des caractères unicode non supportés, mais aussi de privilégier une approche par liste blanche des caractères supportés. Mots clés : ComSec, Avi Douglen, Amit Klein, RSA Conference, SQL, Unicode, SQL Smuggling Plus d'informations sur : http://www.comsecglobal.com/FrameWork/U ... ggling.pdf
Articles similaires
Bien choisir son Firewall Applicatif Web (WAF)
MHAISSAR, AlexandreOTTER, KarimM, SR, SOmnes, VincentDG, KM, Littleshark, jcayssol, HerveL, Lub, Sylvain, ERL, OJ, norman, vbach, pprados, Fdc, pjoyez, nruff, Freddy, BC, NM, Dimitri, Sasha, squastana, mestrade, JSOLEIL, VenitaMaupou, manudupont, Jean, BrunoRasle, Athos99, JeromePoggi, Alain, sdesbordes, JSaiz, S, ebrouder, christophe, erwan, tev, pleothaud, acz ...
CommentsVous devez vous enregistrer afin de pouvoir commenter cet article. Cliquez ici pour créer un compte gratuitement! |
Derniers Articles
Commentaires récents |
#1 - Il y a 2 mois
Pleothaud
BeeWare
Vibes : 100%
Votes : 3 votes
L'idée est intéressante, on va se mettre dessus
#2 - Il y a 2 mois
JSaiz
LesNouvelles.net
Vibes : 100%
Votes : 11 votes
#3 - Il y a 2 mois
BrunoRasle
ARCA
Vibes : 100%
Votes : 5 votes
Ce module fonctionne directement sur la mémoire de la base - donc après que le flux ait été "déwrappé" ou déchiffré. Il détecte donc bien toutes attaques de ce type, de même que les attaques internes à la base de données (bombes logiques)- ce dont est incapable une solution frontale.
Le support de sa présentation (avec démonstration de telles attaques) sera prochainement en ligne sur
http://www.ossir.fr/windows/supports/li ... 2008.shtml
A noter que le développeur a indiqué avoir codé un fuzzer conçu spécifiquement pour cibler les bases de données...
#4 - Il y a 2 mois
Mestrade
Beeware
Vibes : 100%
Votes : 4 votes
Pour mysql:
www.greensql.net
www.dbproxy.org
Ou avec plus de base de donnees:
sqlrelay.sourceforge.net
A l'inverse de Sentrigo, ces projets se placent en mode reverse proxy comme peut etre un waf, et permettent de detecter ou d'appliquer des politiques de securite sur les query SQL a partir de l'utilisateur ou de la syntaxe.
DBProxy permet aussi de detecter des comportements bizarre en analysant les volumes de donnees en fonction des requetes.
#5 - Il y a 2 mois
Mestrade
Beeware
Vibes : 100%
Votes : 4 votes
http://www.greensql.net/public/presenta ... rewall.ppt
#6 - Il y a 2 mois
JSaiz
LesNouvelles.net
Vibes : 100%
Votes : 11 votes
http://www.01net.com/editorial/368442/s ... formances/
#7 - Il y a 2 mois
Nruff
EADS
Vibes : 100%
Votes : 3 votes
Toutes les solutions de protection "en coupure" pour Oracle vont se heurter à ce problème d'analyse.
#8 - Il y a 2 mois
Mestrade
Beeware
Vibes : 100%
Votes : 4 votes
Dans les solutions opensource, j'ai aussi oublie mysql qui a commence une solution de type reverse proxy: http://dev.mysql.com/downloads/mysql-pr ... sql-proxy/
Si on devait faire une comparaison, je trouve que ces produits prennent la meme direction que les waf, colles a l'application comme un mod_security peut l'etre a apache, ou en tant qu'interception de flux comme peut l'etre un reverse proxy beeware. Le besoin client viendra ensuite determiner quelle solution sera la plus adaptee.