Sécurité

Comprendre la gestion des mots de passe des comptes partagés

Chris Stoneff

 

En un coup d'œil :

  • Risques liés aux mots de passe des comptes partagés et à privilèges
  • Stockage des mots de passe
  • Gestion et sécurisation des mots de passe
  • Conformité

Sommaire

Présentation du problème
Plus c'est long, mieux c'est
Violence sur les domaines
Des excuses, des excuses, toujours des excuses
Ce que veulent les organismes de régulation
Approche automatisée
Pensez-y

Parmi les choses auxquelles les administrateurs sont de plus en plus souvent confrontés figure la modification régulière du mot de passe pour les comptes partagés et à privilèges, tels que le compte

administrateur ou racine prédéfini, les comptes d'urgence, voire les comptes de processus. S'il faut donner une définition, le compte administrateur ou racine prédéfini est le compte qui est fourni avec chaque version de Windows®, Linux et UNIX, et il possède toujours le même Identificateur de sécurité (SID) ou Identificateur d'utilisateur (UID). Les comptes d'urgence sont les autres comptes que vous créez afin de faciliter l'accès d'urgence à un système sécurisé. Ces comptes administrateur ou d'urgence sont parfois utilisés par des utilisateurs sans privilèges pour accéder aux systèmes principaux lorsque des problèmes surviennent. Enfin, les comptes de processus sont les comptes que vous utilisez pour exécuter les services, les tâches, les applications COM + et les éléments prédéfinis tels que les scripts et autres fichiers binaires qui doivent se connecter.

Maintenant, vous avez probablement déployé vos systèmes à l'aide de scripts ou d'images d'installation. Par ailleurs, tous vos postes de travail ou serveurs ont probablement le même nom de compte administrateur et le même mot de passe à 8 caractères, qui n'a sans doute pas été modifié depuis le déploiement initial des systèmes. Pour cette raison, j'utilise le terme singulier « mot de passe », par opposition aux « mots de passe ».

Un administrateur peut être obligé de modifier ces mots de passe pour se conformer aux meilleures pratiques ou respecter les exigences de conformité, telles que celles imposées par la loi Sarbanes-Oxley (SOX), le secteur des cartes de paiement (PCI) ou la loi HIPAA (Health Insurance Portability and Accountability Act). Il peut arriver qu'administrateur modifie les mots de passe lorsqu'un ancien administrateur ou un technicien qui a connaissance de ces mots de passe quitte l'entreprise, par crainte de la divulgation d'une violation de la sécurité ou de perte de la capacité de traiter les cartes de crédit. Malgré ces facteurs, tout cela se résume au fait que l'administrateur doit modifier ces mots de passe pour assurer la sécurité de l'entreprise et des données que l'entreprise est tenue de protéger.

Présentation du problème

Lorsqu'il s'agit de traiter ces comptes et leurs mots de passe, plusieurs facteurs doivent être bien compris :

  1. Plus un mot de passe vieillit, moins ce mot de passe est sûr.
  2. Les mots de passe plus longs sont, en règle générale, plus difficiles à craquer.
  3. Le mode d'authentification des ordinateurs ne change pas juste parce qu'ils appartiennent à un domaine. Au sein de chaque domaine se trouve le cœur d'un groupe de travail.

« Plus un mot de passe vieillit, moins ce mot de passe est sûr » est une affirmation trompeuse. Ce qu'elle signifie véritablement, c'est que si vous avez la volonté d'entrer par effraction dans un ordinateur, tout ce dont vous avez vraiment besoin, c'est de temps. Si quelqu'un me demande « Combien de temps cela prend-il pour craquer un mot de passe ? », je réponds généralement qu'il n'y a pas de réponse absolue et donne plutôt certains indices pouvant aider à déterminer la réponse pour un système donné :

  • Combien de personnes connaissent-elles le mot de passe ?
  • Toutes ces personnes travaillent-elles toujours pour l'entreprise ?
  • Si certaines des personnes qui connaissent le mot de passe du compte ne travaillent plus pour l'entreprise, étaient-elles en bon termes avec l'entreprise lorsqu'elles l'ont quittée ?
  • Refusez-vous l'accès pour un démarrage depuis le lecteur de disquette, de CD ou de DVD ou le réseau ?
  • Les utilisateurs des ordinateurs sont-ils également des administrateurs locaux ?
  • Tous vos systèmes utilisent-ils exactement le même mot de passe pour leurs comptes à privilèges ?

Pour commencer par le début de cette liste, il est juste de dire que plus le nombre de personnes connaissant un secret est élevé, plus ce secret risque d'être connu de tous. Je me rappelle avoir travaillé pour des entreprises où les administrateurs trouvaient qu'il était plus pratique de définir le mot de passe partagé sur la même valeur et de le communiquer aux membres de l'équipe informatique ainsi qu'aux stagiaires, plutôt que de taper les mots de passe pour eux lorsqu'ils en avaient besoin. Bien sûr, au fil du temps, l'entreprise a commencé à trouver des machines avec divers paramètres non approuvés et des utilisateurs réseau ordinaires capables de se connecter à ces comptes.

Si toutes ces personnes qui connaissent les mots de passe travaillent toujours pour l'entreprise et en sont des employés satisfaits et consciencieux, ce risque lié à l'accès est légèrement atténué. Mais vous ne savez jamais quand vous pourriez devoir combattre un utilisateur malveillant. Si l'un de ces utilisateurs a quitté l'entreprise en mauvais termes, vous avez un électron libre et hostile qui sait comment pénétrer dans votre réseau en utilisant un compte autrement intraçable.

Si vous ne refusez pas l'accès pour un démarrage depuis n'importe quoi d'autre que le disque dur, vous permettez également aux utilisateurs de démarrer en utilisant des images non autorisées, telles que Windows PE ou les divers systèmes Linux qui peuvent lire directement à partir du système de fichiers d'un ordinateur et accéder au stockage sécurisé de l'ordinateur. (Je dois faire remarquer qu'un grand nombre de violations émanent d'éléments internes. Même si tous les membres de personnel et les stagiaires sont toujours employés par l'entreprise, cela ne garantit en aucun cas que les mots de passe et les systèmes sont sécurisés).

Je connais beaucoup de personnes qui ont continué de se connecter à un réseau d'un employeur précédent juste parce qu'ils le pouvaient. Il est certes légèrement amusant qu'ils pointent du doigt la pratique peu recommandable de ne pas modifier les mots de passe des systèmes, mais il est également effrayant de considérer les dommages qu'ils pourraient faire s'ils avaient des intentions malveillantes.

Si vous autorisez la possibilité de démarrer depuis un DVD ou le réseau, vous risquez de ne pas pouvoir vérifier ce que les personnes font. En effet, un disque de démarrage Linux ou une image de réseau peut souvent accéder directement à votre système de fichiers. Si vos systèmes utilisent le même nom d'utilisateur et le même mot de passe pour leurs comptes à privilèges, vous préparez vos systèmes pour une lourde chute. Mais nous y reviendrons ultérieurement.

L'âge et la longueur des mots de passe sont pertinents suivant la méthode utilisée pour craquer un mot de passe. Si une méthode de force brute est utilisée pour déterminer des mots de passe, il ne s'agit alors vraiment que d'une question de temps. Moins un mot de passe est modifié, plus un pirate disposera de temps pour obtenir le mot de passe.

De même, les variations de caractères des mots de passe plus longs augmentent de façon exponentielle si bien que ces derniers nécessitent donc plus de temps pour les craquer. Il est donc important de considérer si vos mots de passe ont une longueur de 7 caractères, de 8 à 14 caractères ou 15 caractères ou plus. Et si les mots de passe font moins de 15 caractères et que vous utilisez Windows, désactivez-vous les hachages LAN Manager (LM) dans le cadre de la configuration du système ou de la Stratégie de groupe ?

Quelle est l'incidence de la durée du mot de passe ? Dans le cas de Windows, la réponse est simple. Passons sur l'historique des processus de hachage de Microsoft, mais disons que Microsoft implémente deux types de hachages pour les mots de passe : les hachages LM et les hachages Message Digest 4 (MD4). Par défaut, Microsoft utilise les hachages LM, et les valeurs sont stockées pour tous les mots de passe jusqu'à 14 caractères, à moins que vous désactiviez explicitement le stockage de ces hachages. Ces mots de passe sont décomposés en deux valeurs de 7 caractères, la première valeur pour les 7 premiers caractères et la deuxième valeur pour les 7 caractères suivants, comme illustré à la figure 1.

Figure 1 Exemple de table de hachage

Nom du compte RID Hachage LM Hachage NT Mot de passe Remarques
Administrateur 500 aad3b435b51404ee: aad3b435b51404ee 31d6cfe0d16ae931: b73c59d7e0c089c0 M. de p. vide Le hachage LM est identique au hachage LM de mot de passe de 20 caractères.

Administrateur 500 0182bd0bd4444bf8: aad3b435b51404ee 328727b81ca05805: a68ef26acb252039 M. de p. de 7 car. = 1234567 La première partie représentant les 7 premiers caractères est identique au mot de passe de 8 caractères.

Administrateur 500 0182bd0bd4444bf8: 36077a718ccdf409 0182bd0bd4444bf8: 36077a718ccdf409 M. de p. de 8 car. = 12345678 La première partie représentant les 7 premiers caractères est identique au mot de passe de 8 caractères, mais la deuxième partie est différente.

Administrateur 500 aad3b435b51404ee: aad3b435b51404ee b79d07c2ecb3d565: 033ece663f5a0b2e M. de p. de 20 car. = 9876543210 9876543210 Le hachage LM est identique au mot de passe vide parce qu'un hachage LM ne peut pas être créé avec des mots de passe de plus de 14 caractères.

Fred 1221 e52cac67419a9a: 224a3b108f3fa6cb6d 8846f7eaee8fb117: ad06bdd830b7586c Identique Dans ces trois exemples, voyez-vous comme les hachages LM et NT sont identiques ? Cela signifie que tous les mots de passe sont identiques pour tous ces comptes. Microsoft ne varie jamais l'algorithme de hachage.

Lundi 1385 e52cac67419a9a: 224a3b108f3fa6cb6d 8846f7eaee8fb117: ad06bdd830b7586c Identique
SvcAcctX 1314 e52cac67419a9a: 224a3b108f3fa6cb6d 8846f7eaee8fb117: ad06bdd830b7586c Identique

Ainsi, si votre mot de passe fait seulement 7 caractères, il sera contenu dans un hachage LM unique. Pendant des années, Microsoft a recommandé d'utiliser au moins 8 caractères dans vos mots de passe. Cela était dû au fait que le huitième caractère obligeait alors à diviser le mot de passe en deux valeurs de hachage LM.

Toutefois, il est important de noter que les hachages LM sont très largement compris et très faciles à contourner. Leur seul but dans les solutions actuelles est d'aider à maintenir la compatibilité descendante avec les systèmes de plus bas niveau, tels que Windows NT® 4.0.

À l'heure actuelle, il est recommandé d'utiliser des mots de passe (ou plutôt des phrases de passe) d'au moins 15 caractères ou, de préférence, plus, parce que par définition, ils ne généreront pas de hachage LM. S'il n'est pas viable d'imposer l'utilisation de mots de passe de 15 caractères dans votre environnement, vous devez désactiver le stockage des hachages LM dans le processus de création d'image (en utilisant la stratégie locale) et dans votre Stratégie de groupe Active Directory®.

Cette stratégie se trouve sous à la Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies locales\Options de sécurité. Définissez simplement la stratégie « Sécurité réseau : ne pas stocker de valeurs de hachage de niveau Lan Manager sur la prochaine modification de mot de passe » sur ACTIVÉ.

Il est important de se rappeler que bien que les bonnes pratiques dictent l'utilisation de lettres majuscules et minuscules ainsi que de caractères numériques ou spéciaux, les meilleures pratiques dictent également une longueur de 15 caractères ou plus.

Plus c'est long, mieux c'est

L'une des méthodes actuellement utilisées pour pénétrer dans les ordinateurs est appelé « tables arc-en-ciel », et utilise les hachages LM comme code malveillant. Mais des mots de passe plus longs peuvent annuler l'efficacité des tables arc-en-ciel.

Je suis stupéfait du nombre d'administrateurs chargés de la sécurité qui semblent en savoir très peu (voire rien) sur les tables arc-en-ciel. Il existe diverses façons de créer des tables arc-en-ciel pour traiter différents algorithmes. Mais il s'agit simplement d'une liste pré-calculée de tous les hachages LM de 0 à 14 caractères.

L'inconvénient des tables arc-en-ciel réside dans le fait que l'attaquant doit d'abord obtenir les hachages LM. Ceci mène aux questions précédentes concernant la façon dont le système peut être démarré (sur CD ou DVD) ou si vos utilisateurs sont des administrateurs locaux. En fin de compte, ces hachages LM peuvent être extraits en quelques secondes à l'aide d'outils gratuits, comme pwdump. Avec l'utilisation des tables arc-en-ciel, les hachages sont analysés pour déterminer le mot de passe.

Pour satisfaire ma propre curiosité, j'ai défini un mot de passe sur le compte administrateur prédéfini d'un système. Il se composait de 14 caractères et contenait diverses lettres majuscules et minuscules ainsi que des caractères et des numéros spéciaux. J'ai ensuite utilisé des tables arc-en-ciel que j'ai téléchargées gratuitement sur Internet, et j'ai pu extraire les hachages de mot de passe pour tous les comptes sur mon système et déterminer le mot de passe de l'administrateur en moins de deux minutes.

Je dois admettre qu'il est assez intéressant de regarder le premier hachage LM être vaincu, ensuite le deuxième hachage, puis de les réunir pour obtenir le mot de passe. Pour réitérer mon argument, si j'avais désactivé mes hachages LM en utilisant la stratégie que j'ai évoquée précédemment, ce vecteur d'attaque particulier serait sévèrement limité, si pas entièrement bloqué.

Violence sur les domaines

Être dans un domaine ne résout pas le problème. Les ordinateurs qui se trouvent dans un domaine authentifient toujours de la même façon. Et, comme j'ai dit auparavant, au sein de chaque domaine se trouve le cœur d'un groupe de travail. Cette affirmation simple n'est pas toujours évidente. J'ai eu de nombreuses conversations à ce sujet, et je me trouve souvent à rappeler aux administrateurs ce qui est nécessaire pour accéder à une machine : un nom d'utilisateur et un mot de passe. Je dois ensuite plonger dans une discussion sur le fonctionnement de Windows dans un groupe de travail.

Si vous tentez d'accéder à un système, vous aurez besoin de fournir un nom d'utilisateur et un mot de passe au système distant. Grâce à l'utilisation de l'authentification intégrée, Windows tentera de le faire pour vous. Cela signifie que si vous accédez à un autre système Windows, Windows utilisera vos nom d'utilisateur et mot de passe actuellement connectés. Par conséquent, si vous tentez d'accéder à un autre système Windows, ces nom d'utilisateur et mot de passe ne vous seront jamais demandés si le système distant a les mêmes nom d'utilisateur et mot de passe.

Ce mode d'authentification est également appelé authentification directe. Ce processus fonctionne dans les groupes de travail et entre les domaines. Dans le pire des cas, le système vous demandera un nom d'utilisateur et un mot de passe, ce qui signifie que vous devez simplement retaper vos informations de connexion.

Maintenant, même si vous connectez un poste de travail ou un serveur à un domaine et qu'Active Directory devient votre référentiel de comptes central, tous les Gestionnaires de comptes de sécurité locaux (SAM) ou magasins de comptes locaux sur ces systèmes ne disparaissent pas comme par magie. La seule chose qui semble arriver à ces SAM locaux, c'est qu'ils ne sont plus gérés ni sécurisés, et c'est là que se trouve la racine du problème. Quand avez-vous modifié le compte administratif ou racine prédéfini pour la dernière fois sur vos systèmes ? Mieux encore, téléchargez n'importe quel utilitaire de rapports capable d'afficher l'âge du mot de passe pour tous vos comptes et voyez si les résultats seraient acceptables en cas d'audit.

Si vous ne voyez toujours pas très bien ce que je veux dire, prenez n'importe lequel de vos postes de travail de domaine et ouvrez une session en tant que compte de domaine avec les privilèges d'administrateur. Ouvrez la gestion des ordinateurs sur votre système et créez un utilisateur local nommé JVousLAvaisBienDit. Donnez un mot de passe au compte et ajoute-le au groupe d'administrateurs locaux de votre système. Répétez ce processus sur un deuxième système de domaine.

Maintenant, de l'un ou l'autre de ces systèmes, ouvrez une session en tant que compte JVousLAvaisBienDit local et tentez d'accéder à la deuxième machine en allant dans \\Nom_système\c$. Vous pourrez accéder au partage administratif et vous ne devrez même pas fournir un mot de passe ! J'espère que cet exemple ne vous surprend pas. Si c'est le cas, s'il vous plaît, tirez-en la leçon et permettez-moi de me répéter : le simple fait que votre système appartienne à un domaine ne modifie pas le fait que tous ces systèmes fonctionnent toujours comme s'ils appartenaient à un groupe de travail.

Si vous utilisez pour vos comptes partagés et à privilèges des mots de passe qui ne changent que rarement, voire jamais, vos comptes partagés et à privilèges courent un risque. Et tout ce qu'il faudra pour compromettre l'ensemble de votre réseau, c'est un peu de temps.

Des excuses, des excuses, toujours des excuses

Lorsque je parle avec des administrateurs et même avec des directeurs informatiques, j'entends fréquemment les mêmes principales raisons pour ne pas modifier les mots de passe de ces comptes :

  • Nous avons des milliers de systèmes et pas suffisamment de temps ou de main-d'œuvre pour modifier ces comptes.
  • Nous n'avons pas le budget nécessaire.
  • Nous avons complètement désactivé nos comptes administrateur.
  • Nous n'avons pas encore été compromis, donc nous ne pensons pas que ce soit vraiment un problème.
  • Les auditeurs n'ont pas remarqué.

Bien que je puisse comprendre les deux premières raisons, ces excuses ne sont pas valables. Je frémis à l'idée que certaines de mes informations personnelles puissent être stockées par des entreprises qui ne résolvent pas ce problème pour une raison quelconque.

S'il est vrai que tous les systèmes de votre réseau ne stockent pas des informations sensibles, les utilisateurs de ces ordinateurs ont potentiellement accès à des informations sensibles, telles que votre numéro de sécurité sociale, vos dossiers médicaux ou vos données financières. En tant qu'administrateur d'un système, un utilisateur peut installer des enregistreurs de touches et des utilitaires de capture d'écran, empêcher la Stratégie de groupe de s'appliquer, introduire des shims dans divers sous-systèmes pour capturer et transmettre des données, et ainsi de suite. Et lorsque l'utilisateur fait cela au niveau d'un ordinateur individuel, votre capacité à attraper cet utilisateur malveillant est beaucoup plus limitée puisqu'il s'agit d'un administrateur nommé.

Saviez-vous que le fait de désactiver le compte administrateur prédéfini dans Windows ne vous empêche pas d'ouvrir une session en tant que ce compte ? Essayez ce qui suit : redémarrez votre système dans le mode Sans échec et ouvrez une session en utilisant le compte administrateur prédéfini. Vous pouvez probablement utiliser le mot de passe attribué au compte à partir de l'image originale et y parvenir. Pour plus d'informations sur ce comportement, consultez l'article de la base de connaissances Microsoft® « Comment accéder à l'ordinateur après avoir désactivé le compte d'administrateur » (support.microsoft.com/kb/814777).

Ce que veulent les organismes de régulation

Les réglementations SOX, PCI, HIPAA et autres peuvent vous faire tourner la tête. Il peut être difficile de comprendre leurs exigences, dans la mesure où elles sont extrêmement vastes et ne sont pas clairement définies. De façon générale, ce que recherchent ces réglementations peut être résumé comme suit.

Premièrement, vous devez garantir qui a accès à tous les comptes et informations privilégiés à tout moment, et fournir une méthode permettant de le prouver. Ceci est le bon comportement dans tous les scénarios ; un compte à privilèges est un compte assortis de droits à faire n'importe quoi sur un système. Ceci est l'administrateur prédéfini. Ceci est le compte d'urgence. Il s'agit des comptes que l'ensemble de votre personnel de support technique et chaque administrateur travaillant pour vous connaissent probablement.

Lorsque vous choisissez d'implémenter une solution pour gérer ces mots de passe de compte partagés, vous créez une piste d'audit pour le compte administrateur prédéfini où il n'en existe pas actuellement. Vous obtenez un mot de passe qui est fluide. Et comme la solution est automatisée, vous ne perdrez pas des semaines de productivité passées à modifier ces mots de passe. Au bout du compte, puisque la solution fournit des fonctionnalités d'audit, votre entreprise se rapprochera d'autant de la réussite à son audit.

Approche automatisée

La façon la plus efficace de traiter les comptes de ce type consiste à modifier régulièrement les comptes de sorte que deux comptes ne partagent jamais le même mot de passe. Avec les mots de passe partagés, la compromission d'un système entraînerait la compromission de l'autre. En d'autres termes, il ne devrait pas exister de comptes locaux ou de domaine communs.

Lorsque vous utilisez des solutions automatisées capables d'attribuer ces mots de passe de façon aléatoire et d'en assurer la gestion, évitez de faire seulement le strict minimum de ce qui est requis par vos auditeurs. Par exemple, pourquoi n'utiliser que 8 caractères pour vos mots de passe quand vous pourriez en utiliser 15, 20 ou 127, sans effort supplémentaire (voir la figure 2) ?

fig02.gif

Figure 2 Utilisez l'automatisation pour créer de très longs mots de passe (Cliquez sur l'image pour l'agrandir)

Envisagez également de randomiser vos comptes à privilèges tous les jours, comme illustré à la figure 3. Il n'y a pas de raison de ne faire cela que tous les 90 jours si vous pouvez le faire tous les mois, toutes les semaines ou même tous les jours. Après tout, si la procédure est automatisée, cela ne devrait pas créer de travail supplémentaire. Par ailleurs, si vous faites cela régulièrement, vous obligerez les utilisateurs à récupérer les mots de passe depuis l'interface de récupération vérifiée de l'outil, générant ainsi une autre piste d'audit là où il n'en existait pas auparavant. (Si vous stockez actuellement les mots de passe écrits dans une enveloppe dans un coffre dans le coin arrière du bureau de quelqu'un, vous ne disposez pas de piste d'audit pour ces mots de passe comme vous en disposeriez si vous utilisiez une solution de gestion des mots de passe).

fig03.gif

Figure 3 Randomisez vos comptes à privilèges tous les jours (Cliquez sur l'image pour l'agrandir)

Enfin, assurez-vous que lorsque les mots de passe sont récupérés, ils peuvent être et seront à nouveau randomisés après une période fixe suivant la récupération. Je ne parle pas des tâches de randomisation planifiées que vous avez créées, je parle de créer des mots de passe à usage unique qui soient uniquement valides pendant quelques heures au lieu de quelques mois. Une fois encore, cette méthode obligera les utilisateurs à récupérer les mots de passe depuis l'interface de récupération vérifiée de l'outil, ce qui génère une piste d'audit.

Pensez-y

Le problème de la gestion des mots de passe des comptes partagés doit être résolu. Cela signifie que vous devez mettre en place une méthode vous permettant de modifier vos mots de passe de façon régulière et fiable. La solution doit être évolutive et flexible. Elle doit également fournir un accès sécurisé aux mots de passe, et doit vérifier chacune des actions effectuées par l'outil et chacune des actions effectuées par chacun des utilisateurs de l'outil. En outre, les mots de passe générés doivent être uniques à chaque système afin d'éviter une intrusion due au partage des informations de compte.

Beaucoup de fournisseurs se sont attaqués à ce problème il y a déjà de nombreuses d'années, et encore plus de nouveaux fournisseurs se sont récemment introduits dans ce domaine. Veillez à faire des recherches et à essayer tous les nouveaux outils avant d'acheter pour garantir que la solution que vous choisissez est adaptée à votre environnement.

Christophe Stoneff est responsable de produit chez Lieberman Software (liebsoft.com), une société de développement de logiciels de gestion de la sécurité et de systèmes. Ce qui le motive n'est pas tant de savoir comment les choses fonctionnent, mais pourquoi.