Une bonne partie de ces failles sont corrigées par le SP3 de SQL-server 2000, mais d'autres restent cependant toujours d'actualité, et sont considérées par Microsoft comme des "limitations fonctionnelles" ou des faiblesses intrinsèques du produit. Au-delà des failles ainsi mises en évidence, cet exposé est également intéressant par la démarche de recherche de vulnérabilité qu'il présente.

Obtenir un accès

La réflexion initiale est basée sur le fait que, comme des outils de l’environnement SQL server ont besoin d’accéder "en différé" à la base de donnée (par exemple "SQL agent", qui permet d'exécuter des commandes "en différé", ou la fonction de réplication), des mots de passe du serveur SQL doivent être stockés quelque part sur la machine. Effectivement, après analyse, plusieurs mots de passe mal protégés ont ainsi été trouvés : stockés en base dans des tables mal protégées, ou accessibles via des procédures stockées en base ("stored procedures") exécutables par tous, ou stockés dans la base de registres sur des entrées mal protégées.

Nota : Ce problème de mots de passe mal protégés est partiellement résolu par le SP3. Certaines configurations sont cependant encore vulnérables è des attaques par force brute. Il est donc recommandé d'utiliser des mots de passe "forts" (difficiles à "craquer" par force brute).

Augmenter ses privilèges

Dans une seconde étape, "Application Security" recherche des moyens d'augmenter les privilèges initialement obtenus sous "SQL-server", c'est-à-dire de passer d'un compte sans privilège, à un compte "administrateur de la base de données". Après recherche, plusieurs moyens ont été trouvés pour arriver à cette fin :

• Modifier une "GTSP" (Global Temporary Stored Procedure) existante (n'importe quel utilisateur a le droit de le faire), et attendre qu'un utilisateur privilégié l'exécute à son insu. Il s'agit donc ici d'une attaque de type "cheval de Troie". Il n'existe pas de solution pour ce type d'attaque (elle n'est pas corrigée par le SP3), et elle constitue une faiblesse intrinsèque aux GTSP. Le seul moyen de s'en protéger est donc de ne pas utiliser de GTSP.

• Obtenir un accès illégal à certaines tables en utilisant des "vues" ou des "procédures stockées en base" mal protégées. Ce problème est lui corrigé par le SP3.

Prendre le contrôle de la plate-forme

La dernière étape constitue à utiliser les privilèges obtenus sous "SQL-server" pour tenter d'obtenir aussi les pouvoirs "administrateur" au niveau de la plate-forme elle-même. Plusieurs "solutions" sont proposées par "Application Security" :

• Utiliser des débordements de pile trouvés dans des procédures stockées en base (cf. CERT-IST/AV-2002.121). Les différents cas de débordement de pile ont été corrigés dans le SP3.

• Utiliser un vieux "OLEDB provider" (composant permettant d'accéder depuis SQL-server à des données externes à la base de données) pour outrepasser les protections normalement appliquées lors des appels aux fonctions systèmes. Il n'existe apparemment pas de solution à ce problème (il n'est pas corrigé par le SP3).

Conclusion

Les résultats présentés par "Application Security" sont préoccupants. La facilité (au moins apparente) avec laquelle les différentes tentatives d'attaques ont réussi montre qu'un utilisateur ayant la possibilité d'accéder interactivement au serveur "Microsoft SQL-server" a de fortes chances d'outrepasser les droits qui lui ont été accordés, jusqu'à éventuellement prendre le contrôle de la plate-forme. Et si le SP3 de "Microsoft SQL-server" (ou le SP3a sorti en mai) améliore grandement la situation constatée, tous les problèmes ne sont pas pour autant résolus. Il est donc indispensable de protéger au maximum ce type de serveur. On veillera en particulier à ne pas autoriser les connexions directes à une base SQL-server depuis Internet, et à contrôler fortement les requêtes "utilisateurs" provenant des systèmes frontaux (serveurs web par exemple).

Pour plus d'information

Hunting Flaws in Microsoft SQL Server Presentation :

• Présentation détaillée à BlackHat : http://www.appsecinc.com/news/briefing.html#hunting2
• Article plus généraliste sur le même sujet : http://www.appsecinc.com/news/briefing.html#hunting