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.

[GrandFather]

C'est un principe de base de la sécurité informatique : un administrateur d'un système doit avoir la main sur la gestion des mots de passe des utilisateurs (les invalider, etc.), mais il n'a pas à les connaître. Etant donné que la grosse majorité des utilisateurs emploient par commodité le même mot de passe pour accéder à différents systèmes, la moindre violation de confidentialité le rendrait immédiatement suspect.

Il est évident que ce principe est loin d'être respecté en toutes circonstances, mais dans le cas d'un SGBDR il le devrait...

[Antacid]

C'est un principe de base de la sécurité informatique : un administrateur d'un système doit avoir la main sur la gestion des mots de passe des utilisateurs (les invalider, etc.), mais il n'a pas à les connaître. Etant donné que la grosse majorité des utilisateurs emploient par commodité le même mot de passe pour accéder à différents systèmes, la moindre violation de confidentialité le rendrait immédiatement suspect.

Il est évident que ce principe est loin d'être respecté en toutes circonstances, mais dans le cas d'un SGBDR il le devrait...

Effectivement. C'est là que le bas blesse, comme on dit. Je serais curieux de voir quel pourcentage des utilisateurs utilisent un seul mot de passe pour toutes leurs applications!

[cf1020]

Se ne sont que les mots de passe des utilisateurs du serveur SQL Server, parce que les mots de passe Windows sont gardés dans l'Active Directory

[Invité]

Ouais, c'est pas bien, on est d'accord.
Ce n'est tout de même pas dramatique, la portée reste limitée.

Mais j'ai déjà travaillé sur une application livrée avec les mots de passe en clair dans la table Users... Ça fait pas très sérieux...

[cherkaoui.j.e]

c'est pas une faille mais une fonctionnalité.

[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.

[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

[Skyounet]

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.

Oui mais là on parle d'un utilisateur avec des droits administrateurs sur SQL Server, un DBA quoi. Autrement dit il n'a pas besoin du mot de passe de l'utilisateur Y pour aller lire des données vu qu'il a tous les droits.

[Emmanuel Lecoester]

hello skyounet, merci pour ce complément. C'est la ligne de défense de Microsoft

En fait ce n'est pas tant le fait que le DBA voit tout qui me gêne, c'est que le dba puisse se faire passer pour moi au niveau de la base vu qu'il a mon mdp

[Krison]

ca ajoute en effet une légère difficulté si le DBA ne peut pas voir en clair le mot de passe.
Mais je crois que si on a un DBA "malveillant", il trouvera toujours le moyen de faire ce qu il veut puisse qu il a presque tous les droits.
C est bien de le savoir, et c est vrai qu au niveau principe: ce n est pas top.
Mais il faut savoir relativiser... et je pense qu il y a tout de meme du marketing/pub la derriere / Sentrigo...