Mauvaise configuration de sécurité

1. Principe

Cette faille de sécurité regroupe toutes les vulnérabilités laissées ouvertes aux différents niveaux de l'architecture de l'application Web. Pour chacun des serveurs impliqués dans l'activité de l'application, le problème concerne le système d'exploitation ainsi que les outils installés pour servir l'application.

Pour chacun de ces composants, des failles sont connues du domaine public, ce qui facilite les attaques. S'ils ne sont pas mis à jour, l'attaquant peut exploiter les failles non corrigées.

Pour de nombreux outils, des options sont installées par défaut alors qu'elles ne sont pas nécessaires au bon fonctionnement de l'application. Cette situation offre plus d'opportunités pour un attaquant.

De même de nombreuses applications sont installées avec des comptes créés avec des mots de passe par défaut. Ces comptes et mots de passe sont les cibles privilégiées des usurpations d'identité.

2. Exemples d'attaque

J. Scambray, V. Liu et C. Sima [7] donnent un exemple d'attaque. En 2007 une faille est découverte dans l'extension mod_jk du serveur HTTP Apache. Ce module permet de renvoyer les requêtes HTTP reçues par le serveur HTTP au serveur de Servlet Apache Tomcat pour qu'il exécute les Servlets Java. Le problème détecté est un dépassement de mémoire tampon (buffer overflow). Le module ne gérait pas correctement les adresses trop longues contenues dans les requêtes HTTP. Cela permettait à un attaquant de faire ouvrir un port d'écoute spécifique utilisable pour prendre la main sur le serveur. Tant que le correctif n'était pas publié et installé, les systèmes restaient vulnérables. Le seul moyen de se protéger était de désactiver le module s'il n'était pas utilisé.

Les codes sources des applications Web Open Source sont disponibles aussi bien pour les développeurs légitimes que pour les attaquants. En parcourant ces fichiers, il est possible de lire des commentaires laissés par les développeurs indiquant qu'il y a un problème dont ils ont conscience mais qu'ils traiteront plus tard. Dans ce cas l'attaquant n'a plus qu'à exploiter cette faiblesse.

Les pages d'erreurs des serveurs HTTP contiennent par défaut des informations sur l'erreur et sur le serveur HTTP lui-même. En tentant d'accéder à une page inexistante, une erreur de type « 404 page not found » est retournée à l'attaquant, de même que la version du serveur HTTP. Dans ce cas il suffit à l'attaquant d'étudier cette version pour en connaitre les vulnérabilités et de les exploiter.

3. Parade et bonnes pratiques

L'ANSSI et l'OWASP font les recommandations suivantes.

Il faut désactiver les options inutiles des composants afin de diminuer le nombre de vulnérabilités potentielles que ce soit au niveau du système d'exploitation, du système de gestion de bases de données ou du serveur HTTP.

Il faut mettre à jour les différents composants de l'architecture autant que possible en installant les correctifs dès qu'ils sont publiés. De plus, à l'installation il est préférable de choisir la version anglaise plutôt qu'une autre langue. En effet, lors du développement de correctifs c'est toujours la version anglaise qui est privilégiée, les autres versions étant corrigées plus tardivement.

Après l'installation il faut désactiver voire supprimer tous les comptes inutiles. Le mot de passe des autres comptes doit être modifié dès que possible. Les comptes d'administration par défaut doivent être verrouillés. Il faut préférer l'utilisation de comptes d'administration créés manuellement.