| S . G . D . S . N Agence nationale de la sécurité des systèmes d'information |
![]() |
Paris, le 10 novembre 2011 No CERTA-2011-ACT-045 |
Affaire suivie par :
CERTA
Objet : Bulletin d'actualité
2011-45
| Conditions d'utilisation de ce document : | http://www.certa.ssi.gouv.fr/certa/apropos.html |
| Dernière version de ce document : | http://www.certa.ssi.gouv.fr/site/CERTA-2011-ACT-045 |
Le bulletin d'actualité est disponible dans son intégralité et au format PDF à l'adresse suivante :
http://www.certa.ssi.gouv.fr/site/CERTA-2011-ACT-045.pdf
Un extrait du bulletin, ne reprenant que les articles de la semaine, se trouve en HTML à l'adresse suivante :
http://www.certa.ssi.gouv.fr/site/CERTA-2011-ACT-045/
Le CERTA constate de nombreuses tentatives et des réussites dans les attaques par injection SQL. Cet article présente le principe des outils et des motifs permettant de déceler ces attaques et ces tentatives.
Le langage SQL (Structured Query Language) est un langage utilisé pour manipuler les bases de données. Le principe est d'envoyer une requête SQL à un système de gestion de base de données (SGBD), ce qui permet d'extraire, d'ajouter, de modifier ou de supprimer des données dans la base de données.
Une application web, comme un serveur web doté d'un interpréteur PHP, utilise parfois une base de données pour fonctionner. Lorsque la manipulation de la base de données est effectuée à l'aide d'une requête SQL construite avec des données entrées par un utilisateur et que ces données ne sont pas vérifiées correctement, l'application web est potentiellement vulnérable à une attaque de type injection SQL.
Une attaque de type injection SQL consiste à fournir en paramètre d'une requête HTTP des données qui, une fois intégrées dans la requête SQL, seront interprétées par le SGBD et auront pour conséquence de construire une requête malveillante. La requête SQL aura ainsi, sur la base de données, un effet autre que celui attendu par l'auteur de l'application web.
Une telle faille peut être exploitée à plusieurs fins dont voici une liste non exhaustive :
De nombreux sites sont la cible d'outils cherchant à exploiter de façon automatique des vulnérabilités de type injection SQL. L'utilisation la plus simple de ce type d'outil consiste généralement à entrer une URI vulnérable et laisser le programme trouver comment l'exploiter en laissant les paramètres par défaut. Cependant, pour des cas moins évident à exploiter, il est souvent possible de paramétrer l'outil manuellement.
Il existe quelques moyens simples pour tenter de déterminer si un site a été la cible d'un outil d'injection SQL automatique. Ainsi en inspectant les journaux d'un serveur web, certaines caractéristiques peuvent alerter :
Voici un format typique d'une ligne suspecte apparaissant dans un journal de serveur web :
<ip_source> - - <date_et_heure> "GET /uri/vulnerable.php?Submit=Submit&id= 999999.9%27+union+all+select+<...>2C0x31303235343830303536+and+%27x%27%3D%27x HTTP/1.1" 200 4567 "-" <User-Agent_suspect>
Ici deux caractéristiques peuvent attirer notre attention :
http://www.certa.ssi.gouv.fr/site/CERTA-2004-INF-001/index.html
Cette semaine, Microsoft a publié quatre bulletins de sécurité pour ses produits. Parmi ces bulletins, deux traitent de vulnérabilités permettant de l'exécution de code arbitraire à distance. Une vulnérabilité dans la pile TCP/IP de Windows est considérée comme critique.
Il est important de noter qu'aucun de ces bulletins ne corrige la vulnérabilité mentionnée dans l'alerte CERTA-2011-ALE-006 publiée la semaine dernière. Le CERTA recommande donc le maintien du contournement provisoire, proposé par Microsoft, en attendant que cette vulnérabilité soit corrigée ; sous réserve de test avant déploiement.
http://www.microsoft.com/fr-fr/security/bulletin/ms11-nov
Parmi les vulnérabilités corrigées, certaines, jugées critiques par l'éditeur, autorisent une exécution de code arbitraire à distance. Il est donc important d'effectuer la migration vers cette nouvelle version au plus vite.
La gestion des modules complémentaires (add-ons) a, elle aussi, été revue. Tout module de ce type ayant été installé par des programmes tiers est désormais désactivé jusqu'à la validation explicite de l'installation par l'utilisateur. Une fenêtre permettant la désactivation des modules déjà installés est aussi présentée à l'utilisateur lors de la mise à jour. Ces différentes mesures devraient permettre une meilleure gestion des add-ons par les utilisateurs et notamment empêcher l'installation d'extensions non désirées.
https://www.mozilla.org/en-US/firefox/8.0/releasenotes/
http://www.mozilla.org/security/known-vulnerabilities/firefox.html
Dans la période du 04 au 10 novembre 2011, le CERTA a émis les publications suivantes :
Durant la même période, les publications suivantes ont été mises à jour :