Discussion :

[Katleen Erna]

MAJ du 07.09.2009

Microsoft s'est enfin exprimé officiellement sur cette faille SQL et réfute en être à l'origine. L'entreprise se refuse donc a élaborer un correctif.

La firme américaine se dédouane totalement d'une quelconque responsabilité dans l'affaire, déclarant simplement que ce mode d'authentification est fortement déconseillé, en s'appuyant sur la 6ème loi immuable sur la sécurité informatique qu'elle avait publié en 2000 : "Un ordinateur n'est sécurisé que si son administrateur est digne de confiance".

Face à la passivité de Microsoft, Sentrigo a développé l'outil gratuit Passwordizer, permettant de chiffrer les mots de passe. Il est disponible en téléchargement ici.

Source : Le blog sécurité de Microsoft

Sécurité : Découverte d'une faille dans l'outil de gestion Microsoft SQLServer 2000, 2005 et 2008 permettant d'obtenir les mots de passe des utilisateurs

La société de sécurité californienne Sentrigo a découvert qu'une faille de sécurité avait pris ses quartiers dans le logiciel SQL Server 2008 de Microsoft. Il apparaît ainsi qu'un utilisateur disposant des droits d'administration sur le serveur serait en mesure d'afficher les mots de passe de tous les autres utilisateurs. Ces derniers sont sauvegardés dans la base de donnée et devraient normalement l'être sous une forme crytpée. En cause, la chaîne dédiée aux mots de passe qui serait clairement visible. Un administrateur peut normalement modifier un mot de passe n'étant pas le sien, mais il ne devrait pas être en mesure de le lire. Les sites basés sur un serveur SQL 200, 2005 et 2008 seraient vulnérables à cette faille.

Source : Les conclusions de Sentrigo

[Emmanuel Lecoester]

Seuls les systèmes utilisant un authentification mixte ("SQL Server and Windows Authentication Mode") sont exposées à cette faille.

La faille existe sur SQL Server 2000, SQL Server 2005, and SQL Server 2008 quelque soit la version de Windows.

[sevyc64]

On parle très probablement ici des mots de passe des utilisateurs SQL, qui n'ont rien à voir avec les utilisateurs Windows.


Ces mots de passe là, c'est généralement l'administrateur SQL qui les fixe en créant les utilisateurs, alors qu'il puisse les voir ne doit pas être si dramatique que ça.

Reste à savoir si d'autres user avec des droits restreints peuvent aussi arriver à les voir, là, ça pourrait peut-etre poser plus de problèmes.

[B.AF]

Sentrigo, Inc., the innovator in database security software, today announced that it has discovered a significant vulnerability in Microsoft SQL Server

Ca sent pas le coup marketing du tout ça....

Quelle horreur, un DBA qui peut voir les mots de passe des users !

[sidev]

Bien que cette faille ne soit pas trop critique, du fait que c'est l'administrateur qui a accès au mot de passe, il est quand même dangereux, de voir qu'un admin peut se servir de votre mot de passe pour faire n'importe quoi.

[jeffray03]

a quoi cela servirait alors qu´il soit administrateur sans le pouvoir de modifier vos coordonnées de login. Il ya differentes manieres de sauvegarder les mots de passes, mais l´administrateur a toujours acces a ceux-la, donc moi je ne vois pas ou se trouve le probleme.

[lukeni2]

Ca sent pas le coup marketing du tout ça....

Quelle horreur, un DBA qui peut voir les mots de passe des users !

Il ne peut pas voir les mots de passe des utilisateurs Windows si l'authentification Windows est activé, en plus le fait pour un DBA de voir les mots de passe des utilisateurs n'est pas aussi drammatique que cela étant donné qu'il a le pouvoir de changer ce mot de passe s'il le veut.

[Emmanuel Lecoester]

Pour moi cela apparait bien comme une faille de sécurité, l'environnement de production c'est pour stocker des données de production ! si un utilisateur à plus de droits qu'un autre et que l'autre récupère son mdp ben il peut faire plein de chose.

A l'heure où le concept de déporter toute l'intelligence de l'application au niveau des données émerge, c'est une faille d'autant plus grande ! un développeur X d'une société de prestation se connecte en production avec un compte Y et récupère aussi bien les données que la gestion de celles-ci.

Si un MVP qui passait par ici pouvait nous expliquer plus en détail je suis preneur (en détaillant l'explication de nyal).

[Katleen Erna]

MAJ du 07.09.2009

Microsoft s'est enfin exprimé officiellement sur cette faille SQL et réfute en être à l'origine. L'entreprise se refuse donc a élaborer un correctif.

La firme américaine se dédouane totalement d'une quelconque responsabilité dans l'affaire, déclarant simplement que ce mode d'authentification est fortement déconseillé, en s'appuyant sur la 6ème loi immuable sur la sécurité informatique qu'elle avait publié en 2000 : "Un ordinateur n'est sécurisé que si son administrateur est digne de confiance".

Face à la passivité de Microsoft, Sentrigo a développé l'outil gratuit Passwordizer, permettant de chiffrer les mots de passe. Il est disponible en téléchargement ici.

Source : Le blog sécurité de Microsoft

[Leelith]

Il ne peut pas voir les mots de passe des utilisateurs Windows si l'authentification Windows est activé, en plus le fait pour un DBA de voir les mots de passe des utilisateurs n'est pas aussi drammatique que cela étant donné qu'il a le pouvoir de changer ce mot de passe s'il le veut.

bah si c'est dramatique. Un changement de mot de passe, ça se voit directement et tu sais que le DBA l'a fait (normalement). L'utilisation d'un compte X par le DBA grâce au mot de passe récupéré ne se voit pas.

D'ou la nécessité d'avoir le contrôle sur l'administration des comptes, mais non le contrôle sur les comptes eux-même.

[ILP]

Le problème de cette faille pourrai résider dans des injections SQL sur des bases de données non sécurisées. Par exemple, où l'utilisateur λ se connecterai avec des droits d'administrations.

Plein de bases de données sont configurées comme ça .
Les administrateurs pensent que quand dans leurs applis ne permet pas de modifier les droits d'utilisation, les utilisateurs ne peuvent pas y avoir accès .

[Lyche]

Le problème de cette faille pourrai résider dans des injections SQL sur des bases de données non sécurisées. Par exemple, où l'utilisateur λ se connecterai avec des droits d'administrations.

Mais ça, c'est pas une faille technique, c'est à celui qui à configuré les accès qui n'a pas été professionnel et qui n'a pas fait son travail.

[nyal]

Le problème de cette faille pourrai résider dans des injections SQL sur des bases de données non sécurisées. Par exemple, où l'utilisateur λ se connecterai avec des droits d'administrations.

D'après ce que j'ai compris du rapport, la mot de passe est visible en clair en RAM quand un compte SQL Server réalise une connexion. Du fait du mode mixte de connexion, Microsoft doit peut être garder le password en clair pour réaliser l'authentification selon deux types qui n'ont pas obligatoirement le même format de hachage (md5 ou sha-1 ou CRYPT ou maison ou ...) (Pour rappel, une fois la fonction de hachage appliquée, on ne peut revenir en arrière théoriquement)
Ce n'est pas donc réellement une faille. Il faut alors unifier les formats de hachage.
Je suis peut être à côté de la plaque.

Enfin, J'ai du mal à bien identifier le périmétre de la vulnérabilité. Le rapport n'est pas très clair. Dans une application lambda, il y'a souvent X utilisateurs de l'application mais utilisant le même compte SQL (compte purement technique avec un password aléatoirement généré). Cela ne doit impacter que le compte SQL qui est invisible pour un utilisateur.
Je suis peut être encore à côté de la plaque.

[sidev]

Enfin, J'ai du mal à bien identifier le périmétre de la vulnérabilité. Le rapport n'est pas très clair. Dans une application lambda, il y'a souvent X utilisateurs de l'application mais utilisant le même compte SQL (compte purement technique avec un password aléatoirement généré). Cela ne doit impacter que le compte SQL qui est invisible pour un utilisateur.

Prenons le cas d'un service informatique qui doit gérer une base de donnée.
Si tous les développeurs n'ont pas les même droits sur la BDD alors le piratage du mot de passe de l'admin par l'un des développeurs peut devenir un danger pour les autres.

[sevyc64]

Si tous les développeurs n'ont pas les même droits sur la BDD alors le piratage du mot de passe de l'admin par l'un des développeurs peut devenir un danger pour les autres.

D'un autre coté, il a les droits admin, donc il n'a peut-etre plus rien à faire des droits des autres développeurs, au pire il peut se les rajouter sur son propre compte

[B.AF]

mouai...En même temps, je connais pplein de soft où les user est géré dans une table genre "TBL_USER", ou "TBL_UTILISATEUR", ou "LOGIN" ou machin ou il a invariablement la colonne "PWD", "PassWord","UserPwd", qui pourra invariablement être déplombé en utilisant un des snippets de MDA/SHA dans la liste des 10 premier googlés....

Alors bon...Et puis le mec qui se fait une infrastructure Windows sans AD, il a peut être oublié deux / trois trucs au passage non ????