Vigilance sécuritéAttaque de type Island Hopping : atténuation des dépendances indésirables
Jesper M. Johansson
Dans l'article du mois dernier de Vigilance sécurité, j'ai abordé les premières étapes d'utilisation d'un lecteur flash USB pour l'attaque d'un réseau. L'attaque commençait par un lecteur flash USB infecté connecté à un ordinateur. Le code malveillant s'exécutait alors, soit automatiquement soit avec une aide minimale de l'utilisateur (grâce à de
l'ingénierie sociale simple). Cette attaque demeurait locale au poste de travail, mais il est clair que le logiciel malveillant aurait pu se propager au reste du réseau. J'ai décrit ce type d'attaque de réseau en détail dans mon livre à paraître, Windows Server 2008 Security Resource Kit (Microsoft Press®, 2008), et adapte des éléments de ce chapitre pour cet article.
L'une des options de protection consiste évidemment à interdire les lecteurs amovibles. Bien que cela puisse sembler prudent, vos utilisateurs vous achèveraient vraisemblablement avant même que vous n'ayez atteint votre voiture si vous essayiez de le faire, et il pourrait être difficile de leur en vouloir. La meilleure solution, dans tous les environnements à l'exception des plus sensibles, consiste à tenter de gérer le risque impliqué et à limiter l'exposition.
Qui plus est, les lecteurs amovibles ne sont en aucun cas la seule méthode permettant de compromettre un ordinateur client. Vous rappelez-vous l'article « Les 10 lois immuables de sécurité » (disponible à l'adresse microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx) ? L'idée générale de la loi n°3 est toujours vraie : « Si la mauvaise personne possède un accès physique non restreint à votre ordinateur, ce n'est plus votre ordinateur ». Dans le contexte de cet article, si un attaquant dispose d'un accès à votre ordinateur, cet ordinateur doit être considéré comme compromis. Ceci peut même être effectué à distance si l'attaquant peut faire en sorte que vous exécutiez son code sur votre ordinateur. Vous reconnaîtrez peut-être la loi n°1 des lois immuables : « Si une personne malintentionnée peut vous persuader d'exécuter son programme sur votre ordinateur, il n'est plus votre ordinateur. »
Il est prudent de considérer que les lois immuables sont toujours applicables. Elles se sont avérées remarquablement résilientes et ne sont pas appelées à changer de manière significative avant que nous ne changions fondamentalement la manière dont fonctionnent les ordinateurs. Par conséquent, en considérant que ces lois s'appliquent au scénario présenté, il est essentiel de rendre les lecteurs amovibles inoffensifs. Vous pouvez y parvenir avec quelques ajustements du Registre.
Bien entendu, vous devez également utiliser des couches de protection supplémentaires. Vous pouvez raisonnablement supposer qu'un grand nombre de vos ordinateurs clients ont déjà été compromis ou sont manipulés par des utilisateurs qui n'ont pas toujours à l'esprit les meilleurs intérêts de votre organisation en matière de sécurité. Cela signifie que vous devez atténuer leurs effets sur le reste du réseau et augmente l'importance que revêtent la compréhension, l'analyse et l'atténuation des dépendances de sécurité.
Définition d'une dépendance de sécurité
Une dépendance de sécurité apparaît lorsque la sécurité d'un ordinateur dépend de la sécurité d'un autre. Vous pouvez avoir entendu dire que si votre contrôleur de domaine (DC) a été piraté, votre réseau entier a été piraté. C'est une façon simpliste de déclarer que tous les membres du domaine dépendent des DC pour leur sécurité. Si la sécurité du DC n'est pas assurée, les ordinateurs membres ne peuvent pas être sécurisés. Si un attaquant peut modifier la configuration de sécurité du domaine, il peut prendre possession de n'importe quel ordinateur du domaine, en ajoutant par exemple de nouveaux comptes au groupe Administrateurs d'un ordinateur membre. Toute vulnérabilité permettant la compromission d'éléments par un administrateur n'est pas seulement intéressante. Un administrateur est supposé disposer de l'accès complet à ce qu'il administre.
Les dépendances dans les systèmes informatiques sont inévitables. En fait, elles sont courantes et souvent souhaitées. Cependant, cela ne signifie pas que toutes les dépendances sont acceptables. Dans cet article, je discuterai des types de dépendances acceptables et de ceux qui ne le sont pas, et analyserai ensuite les types de dépendances et la manière de les atténuer. Dans Windows Server 2008 Security Resource Kit, j'aborde plus en détail les dépendances spécifiques et décrit comment les gérer.
Dépendances acceptables
En général, une dépendance est acceptable lorsqu'un système moins sensible dépend d'un système plus sensible pour sa sécurité. Les ordinateurs et les systèmes peuvent en général être divisés en classes, en fonction de leur degré de sensibilité. (Le jeu spécifique de classes d'un environnement particulier est sans intérêt pour une discussion générale. Ce qui est important, c'est qu'il existe des classifications inhérentes) Dans l'intérêt de cet article, supposons que j'ai deux classifications : postes de travail et DC. Dans ce scénario, il est acceptable pour les postes de travail de dépendre des DC en ce qui concerne leur sécurité. La classe DC est beaucoup plus sensible que les postes de travail donc, évidemment, elle doit être mieux protégée.
Le même argument peut s'appliquer aux comptes d'utilisateur. Il est acceptable qu'un administrateur puisse compromettre des données possédées par un utilisateur. En effet, les administrateurs prennent plus de responsabilité et possèdent un accès illimité (bien que pas toujours direct ou évident) à l'ordinateur et à tout ce qui est dessus. Si vous comprenez ce point et gérez les ordinateurs de façon appropriée, cette dépendance ne pose pas de problème.
Même les logiciels peuvent être analysés de la même façon. Il est certainement acceptable qu'un élément logiciel de moindre sensibilité, tel qu'un navigateur Web, puisse utiliser et dépendre d'un élément logiciel plus sensible, tel que le système d'exploitation, pour sa sécurité. Si le système d'exploitation comporte un bogue, le fait que le navigateur Web soit maintenant vulnérable à un nouveau problème n'est pas étonnant et occupe une place relativement basse dans la liste des inquiétudes immédiates. Le système d'exploitation et les autres applications et données critiques seront le centre d'attention principal. Ceci a trait à la façon dont les bogues sont résolus et les correctifs préparés : un bogue doit être résolu aussi près que possible du problème. Ainsi, l'impact de protection du correctif atteint son potentiel maximum. Par conséquent, au lieu de chercher à résoudre le problème dans le navigateur Web, il convient de réparer le système d'exploitation même.
Dans l'alternative, la dépendance peut être supprimée en modifiant la conception. Par exemple, le navigateur Web peut être récrit pour réduire ses dépendances au système d'exploitation. Cette dernière approche est appropriée dans les cas où les fonctionnalités des composants plus sécurisés (le système d'exploitation, dans ce cas précis) n'a jamais été prévue pour être utilisées de la façon dont le composant le moins sensible (le navigateur Web) l'utilise.
Dépendances inacceptables
Au vu de mon explication des dépendances acceptables, la définition d'une dépendance inacceptable devrait maintenant être évidente. Fondamentalement, un système plus sensible ne doit jamais dépendre d'un système moins sensible pour sa sécurité.
Si la compromission d'un poste de travail implique que la sécurité du DC a été enfreinte, vous avez un problème de sécurité sérieux entre les mains. Il est impossible de protéger un réseau si sa sécurité collective dépend de la sécurité de chaque ordinateur du réseau.
Examinez ceci en termes statistiques. Si chaque ordinateur du réseau est « sécurisé » 99,999 % du temps, vous pourriez penser que vous disposez d'un réseau extrêmement sécurisé. En fait, ce pourcentage est probablement très supérieur à la réalité dans la plupart des cas, à l'exception des plus petits réseaux actuels. Mais supposons maintenant que votre réseau compte 40 000 ordinateurs, chacun d'entre eux étant vulnérable 0,001 % du temps. Pour l'anecdote, un réseau général est non sécurisé jusqu'à un potentiel de 40 % du temps.
Bien entendu, avec des dépendances non gérées, il suffirait juste d'un ordinateur à 0,001 % du temps pour compromettre le réseau entier. Par conséquent, quel est le niveau de sécurité du réseau ? Clairement, il est absolument essentiel que les systèmes les plus sensibles soient protégés de ceux qui sont moins sensibles.
Cet argument peut facilement être étendu aux comptes d'utilisateur et aux logiciels. Par exemple, le nouveau client Terminal Server pour Windows® vous permet d'enregistrer les noms d'utilisateur et les mots de passe pour une ouverture de session Terminal Server pratiquement transparente. Ces informations d'identification sont stockées à l'aide de l'API Crediential Manager, protégé par les informations d'identification utilisées pour l'ouverture de session principale.
Ceci peut créer une dépendance de sécurité. Considérez le cas d'une administratrice réseau ouvrant une session sur son poste de travail personnel. Elle utilise ce poste de travail pour le courrier électronique, la navigation sur le Web et les autres tâches typiques des informaticiens. Naturellement, elle utilise dans ce but un compte de domaine à faibles privilèges.
À un certain moment pendant la journée, cette administratrice se connecte à l'un des DC pour exécuter certaines tâches d'administration. Elle utilise pour cela le client Terminal Server et choisit d'enregistrer son mot de passe pour rendre les connexions futures plus faciles. Ceci se traduit par au moins une, et peut-être deux dépendances de sécurité inacceptables. La première est que ses informations d'identification de compte d'administratrice de domaine sont maintenant protégées par ses informations d'identification d'informaticienne à faibles privilèges. Si ce compte d'utilisateur à faibles privilèges est compromis, le compte d'utilisateur administrateur de domaine est également compromis et, par conséquent, le domaine entier est compromis.
La deuxième dépendance résulte du fait qu'elle a tapé des informations d'identification d'administration de domaine sur un ordinateur non contrôleur de domaine. À moins que son poste de travail personnel soit protégé au moins aussi bien que les DC (et il ne l'est probablement pas), il existe une dépendance car la sécurité des DC dépend de la sécurité de ce poste de travail personnel de l'utilisateur. Si un employé mécontent du même bureau a par exemple installé un enregistreur de frappe sur le poste de travail de l'administratrice réseau, les informations d'identification administratives du domaine ont maintenant été capturées. Chaque fois que vous entrez des informations d'identification administratives sur un ordinateur non contrôleur de domaine, vous exposez le domaine entier à tous les défauts de sécurité de l'ordinateur non contrôleur de domaine.
Supposons maintenant qu'un attaquant insère un lecteur amovible dans un ordinateur sur lequel un administrateur de domaine possède une session ouverte, a ouvert une session à un moment quelconque ou ouvrira une session dans le futur. Cet administrateur de domaine devient compromis, et par extension, le domaine entier est compromis. Il est impératif que vous compreniez cette situation afin de pouvoir l'éviter. Cette même situation peut bien entendu survenir avec des logiciels lorsqu'une application sécurisée s'appuie sur les fonctionnalités d'une application moins sécurisée pour exécuter une certaine tâche.
Analyse d'une attaque
J'ai décrit plus tôt ce qui peut se produire si un lecteur amovible malveillant est inséré dans un ordinateur. Cependant, seul ce qui se produira sur l'ordinateur dans lequel est inséré le lecteur est évident. Supposons donc que l'ordinateur en question fasse partie de domaines joints, comme illustré à la figure 1.
Figure 1** Dépendances de domaines idéales **
Le scénario illustré ici représente une dépendance idéale. Les flèches sont directionnelles et pointent vers l'emplacement d'héritage de la dépendance. Par exemple, la sécurité du poste de travail dépend de la sécurité du DC et la sécurité de l'utilisateur dépend de la sécurité du poste de travail. L'attaquant peut être en mesure de compromettre le poste de travail, ce qui compromettrait toute information placée par l'utilisateur sur ce poste de travail, mais la compromission serait limitée à cet emplacement.
Supposons toutefois que l'utilisateur qui ouvre une session sur le poste de travail est membre du groupe administrateurs locaux sur le serveur. Imaginons en outre que l'administrateur de domaine ouvre fréquemment une session sur le serveur. Vous avez maintenant les dépendances illustrées à la figure 2.
Figure 2** Dépendances de domaine compromises **
En modifiant simplement l'hypothèse concernant la personne ayant ouvert une session sur les ordinateurs en question, la sécurité du réseau entier a été compromise. Puisqu'un administrateur de domaine ouvre une session sur le serveur, la sécurité du DC, et par conséquent du domaine entier, est dépendante de la sécurité de ce serveur.
Ceci serait acceptable si le serveur était géré de façon aussi sécurisée que le DC. Cependant, dans le cas qui nous occupe, un utilisateur qui ouvre une session sur le poste de travail est membre du groupe Administrateurs du serveur. Par conséquent, la sécurité du serveur dépend de la sécurité du poste de travail. Cela signifie que la sécurité du domaine entier dépend de la sécurité du poste de travail. Et devinez quoi ? L'utilisateur sur ce poste de travail vient juste d'exécuter involontairement l'outil de l'attaquant.
Il existe probablement peu de concepts plus importants à comprendre que les dépendances de sécurité dans le monde actuel de la sécurité des informations. Si vous commencez à analyser votre réseau et essayez de comprendre ce que sont les dépendances, vous rencontrerez presque certainement des dépendances inacceptables. Dans le scénario le plus défavorable, qui est beaucoup plus courant que vous pourriez le croire, la sécurité du réseau entier dépend du réseau entier. En d'autres termes, la sécurité de chaque ordinateur est, à certains égards, dépendante de la sécurité de chacun des autres ordinateurs. Il est donc impossible de créer un quelconque type de stratégie de gestion de risque raisonnable et réaliste dans ce type d'environnement, puisque les relations sont impossibles à contrôler et que la complexité est incompréhensible. La solution consiste à analyser et à gérer les dépendances.
J'ai seulement présenté dans cet article un court aperçu des dépendances et de la façon dont elles peuvent être analysées et atténuées. Vous pourrez trouver davantage d'informations dans mon livre, Windows Server 2008 Security Resource Kit. Il contient un chapitre entier consacré à la sécurisation du réseau par l'analyse des dépendances et leur gestion avec deux techniques sophistiquées, l'isolation de domaine et l'isolation de serveur, ainsi que des techniques plus courantes, telles que la gestion de compte administratif.
J'aimerais remercier David LeBlanc pour m'avoir aidé à mettre en forme les idées embryonnaires qui ont mené à cet article.
Jesper M. Johansson est architecte logiciel, chargé des problèmes de sécurité logicielle, et contribue à l’élaboration de TechNet Magazine. Il est titulaire d’un doctorat en systèmes d’information de gestion et possède plus de 20 ans d’expérience dans le domaine de la sécurité.
© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.