Voies de compromis

  • Article

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Loi numéro sept : Le réseau le plus sécurisé est un réseau bien administré. - 10 lois immuables de l’administration de la sécurité

Dans les organisations qui ont subi des événements de compromission catastrophiques, les évaluations révèlent généralement que les organisations ont une visibilité limitée sur l’état réel de leurs infrastructures informatiques, ce qui peut différer considérablement de leurs états « tels que documentés ». Ces écarts introduisent des vulnérabilités qui exposent l’environnement à des compromissions, souvent avec peu de risque de découverte tant que la compromission n’a pas progressé jusqu’à ce que les attaquants « possèdent » de fait l’environnement.

Des évaluations détaillées de la configuration AD DS de ces organisations, infrastructures à clé publique (PK), serveurs, stations de travail, applications, listes de contrôle d’accès (ACL) et autres technologies révèlent des configurations incorrectes et des vulnérabilités qui, si elles avaient été corrigées, auraient pu empêcher la compromission initiale.

L’analyse de la documentation, des processus et des procédures informatiques identifie les vulnérabilités introduites par les lacunes dans les pratiques administratives qui ont été exploitées par les attaquants pour obtenir des privilèges qui ont été utilisés pour compromettre entièrement la forêt Active Directory. Une forêt entièrement compromise est une forêt dans laquelle les attaquants compromettent non seulement des systèmes individuels, des applications ou des comptes d’utilisateur, mais escaladent aussi leur accès pour obtenir un niveau de privilège dans lequel ils peuvent modifier ou détruire tous les aspects de la forêt. Lorsqu’une installation Active Directory a été compromise à ce niveau, les attaquants peuvent apporter des modifications qui leur permettent de maintenir une présence dans l’environnement, ou pire, de détruire l’annuaire et les systèmes et les comptes qu’il gère.

Bien qu’un certain nombre de vulnérabilités couramment exploitées dans les descriptions qui suivent ne soient pas des attaques contre Active Directory, elles permettent aux attaquants d’établir une position dans un environnement et de l’utiliser pour exécuter des attaques d’escalade des privilèges (également appelées attaques d’élévation de privilèges), puis pour cibler et compromettre AD DS.

Cette section de ce document se concentre sur la description des mécanismes que les attaquants utilisent généralement pour accéder à l’infrastructure et éventuellement lancer des attaques par élévation de privilèges. Consultez également les sections suivantes :

Notes

Bien que ce document se concentre sur les systèmes Active Directory et Windows qui font partie d’un domaine AD DS, les attaquants se concentrent rarement uniquement sur Active Directory et Windows. Dans les environnements avec un mélange de systèmes d’exploitation, de répertoires, d’applications et de référentiels de données, il est courant de constater que les systèmes non Windows sont également compromis. Cela est particulièrement vrai si les systèmes fournissent un « pont » entre les environnements Windows et non Windows, comme les serveurs de fichiers accessibles par les clients Windows et UNIX ou Linux, les annuaires qui fournissent des services d’authentification à plusieurs systèmes d’exploitation ou les méta-annuaires qui synchronisent les données entre des annuaires disparates.

AD DS est ciblé en raison des fonctionnalités centralisées de gestion de l’accès et de la configuration qu’il fournit non seulement aux systèmes Windows, mais à d’autres clients. Tout autre annuaire ou application qui fournit des services d’authentification et de gestion de la configuration peut être et sera ciblé par des attaquants déterminés. Bien que ce document soit axé sur les protections qui peuvent réduire la probabilité d’une compromission des installations Active Directory, chaque organisation qui inclut des ordinateurs, des annuaires, des applications ou des référentiels de données non Windows doit également se préparer aux attaques contre ces systèmes.

Cibles de violation initiales

Personne ne crée intentionnellement une infrastructure informatique qui expose l’organisation à des compromis. Lorsqu’une forêt Active Directory est construite pour la première fois, elle est généralement intacte et à jour. À mesure que les années passent et que de nouveaux systèmes d’exploitation et applications sont acquis, ces derniers sont ajoutés à la forêt. À mesure que les avantages de gestion qu’Active Directory offre deviennent reconnus, de plus en plus de contenu est ajouté à l’annuaire, de plus en plus de personnes intègrent leurs ordinateurs ou applications à AD DS, et les domaines sont mis à niveau pour prendre en charge les nouvelles fonctionnalités offertes par les versions les plus récentes du système d’exploitation Windows. Cependant, au fil du temps, même quand une nouvelle infrastructure est ajoutée, d’autres parties de l’infrastructure peuvent ne pas être gérées comme elles l’étaient initialement. Les systèmes et les applications fonctionnent correctement et sont essentiellement ignorés, et les organisations commencent à oublier qu’elles n’ont pas éliminé leur infrastructure héritée. D’après ce que nous voyons dans l’évaluation des infrastructures compromises, plus l’environnement est ancien, grand et complexe, plus il est probable qu’il existe de nombreuses instances de vulnérabilités couramment exploitées.

Quelle que soit la motivation de l’attaquant, la plupart des violations de la sécurité des informations commencent par la compromission d’un ou de deux systèmes à la fois. Ces événements initiaux, ou points d’entrée dans le réseau, tirent souvent parti de vulnérabilités qui auraient pu être corrigées, mais qui ne l’ont pas été. Le rapport Enquêtes sur les violations de données (DBIR) de 2012, qui est une étude annuelle produite par l’équipe Verizon RISK en coopération avec un certain nombre d’agences de sécurité nationales et d’autres entreprises, indique que 96 pour cent des attaques n’étaient « pas très difficiles » et que « 97 pour cent des violations ont été évitées par des contrôles simples ou intermédiaires ». Ces résultats peuvent être une conséquence directe des vulnérabilités couramment exploitées qui suivent.

Lacunes dans les déploiements des programmes antivirus et anti-programme malveillant

Loi numéro huit : un scanneur de logiciels malveillants obsolète n’est que légèrement meilleur qu’aucun scanneur du tout. - Dix lois immuables de la sécurité (version 2.0)

L’analyse des déploiements de programmes antivirus et anti-programme malveillant des organisations révèle souvent un environnement dans lequel la plupart des stations de travail sont configurées avec des logiciels antivirus et anti-programme malveillant activés et à jour. Les exceptions sont généralement les stations de travail qui se connectent rarement à l’environnement d’entreprise et les appareils des employés pour lesquels les logiciels antivirus et anti-programme malveillant peuvent être difficiles à déployer, configurer et mettre à jour.

Toutefois, les populations de serveurs ont tendance à être moins systématiquement protégées dans de nombreux environnements compromis. Comme indiqué dans les Enquêtes sur les violations de données de 2012, 94 pour cent de toutes les compromissions de données ont impliqué des serveurs, ce qui représente une augmentation de 18 pour cent par rapport à l’année précédente, et 69 pour cent des attaques ont incorporé des programmes malveillants. Dans les populations de serveurs, il n’est pas rare de constater que les installations antivirus et anti-programme malveillant sont configurées de manière incohérente, obsolètes, mal configurées, voire désactivées. Dans certains cas, les programmes antivirus et anti-programme malveillant sont désactivés par le personnel administratif, mais dans d’autres cas, les attaquants désactivent les logiciels après avoir compromis un serveur via d’autres vulnérabilités. Lorsque les programmes antivirus et anti-programme malveillant sont désactivés, les attaquants placent ensuite des programmes malveillants sur le serveur et se concentrent sur la propagation de la compromission dans l’ensemble de la population du serveur.

Il est important non seulement de s’assurer que vos systèmes sont protégés par une protection complète et actuelle contre les programmes malveillants, mais également de surveiller les systèmes qui désactivent ou suppriment les logiciels antivirus et anti-programme malveillant, et de redémarrer automatiquement la protection lorsqu’elle est désactivée manuellement. Bien qu’aucun programme antivirus ou anti-programme malveillant ne puisse garantir la prévention et la détection de toutes les infections, une implémentation antivirus et anti-programme malveillant correctement configurée et déployée peut réduire le risque d’infection.

Mise à jour corrective incomplète

Loi numéro 3 : si vous ne suivez pas les correctifs de sécurité, votre réseau ne sera vous appartiendra pas pendant longtemps. - 10 lois immuables de l’administration de la sécurité

Microsoft publie des bulletins de sécurité le deuxième mardi de chaque mois, même si, dans de rares occasions, les mises à jour de sécurité sont publiées entre les mises à jour de sécurité mensuelles (également appelées mises à jour « hors bande ») lorsque la vulnérabilité est présente un risque urgent pour les systèmes clients. Qu’une petite entreprise configure ses ordinateurs Windows pour qu’ils utilisent Windows Update pour gérer la mise à jour corrective du système et des applications ou qu’une grande organisation utilise des logiciels de gestion comme Microsoft Endpoint Configuration Manager pour déployer des correctifs conformément à des plans hiérarchiques détaillés, de nombreux clients appliquent les correctifs en temps relativement opportun pour leurs infrastructures Windows.

Toutefois, peu d’infrastructures incluent uniquement des ordinateurs Windows et des applications Microsoft, et dans les environnements compromis, il est courant de constater que la stratégie de gestion des correctifs de l’organisation contient des lacunes. Les systèmes Windows dans ces environnements sont mis à jour de manière incohérente. Les systèmes d’exploitation non Windows sont mis à jour de manière sporadique, voire jamais. Les applications commerciales prêtes à l’emploi (COTS) contiennent des vulnérabilités pour lesquelles des correctifs existent, sans avoir été appliqués. Les appareils réseau sont souvent configurés avec des informations d’identification par défaut, sans aucune mise à jour de microprogramme des années après leur installation. Les applications et systèmes d’exploitation qui ne sont plus pris en charge par leurs fournisseurs sont souvent maintenus en cours d’exécution, bien qu’ils ne puissent plus être corrigés contre les vulnérabilités. Chacun de ces systèmes non mis à jour représente un autre point d’entrée potentiel pour les attaquants.

La consumérisation de l’informatique a introduit des défis supplémentaires dans le fait que les appareils appartenant aux employés sont utilisés pour accéder aux données appartenant à l’entreprise, et que l’organisation peut avoir peu ou pas de contrôle sur les mises à jour correctives et la configuration des appareils personnels des employés. Le matériel de classe entreprise est généralement fourni avec des options de configuration et des fonctionnalités de gestion prêtes pour l’entreprise, au prix de moins de choix en matière de personnalisation individuelle et de sélection d’appareils. Le matériel axé sur les employés offre un large éventail de fabricants, de fournisseurs, de fonctionnalités de sécurité matérielle, de fonctionnalités de sécurité logicielle, de fonctionnalités de gestion et d’options de configuration, et de nombreuses fonctionnalités d’entreprise peuvent être absentes.

Logiciel de gestion des vulnérabilités et des correctifs

Si un système de gestion des correctifs efficace est en place pour les systèmes Windows et les applications Microsoft, une partie de la surface d’attaque créée par les vulnérabilités non corrigées a été traitée. Toutefois, à moins que les systèmes non Windows, les applications non Microsoft, l’infrastructure réseau et les appareils des employés soient également tenus à jour sur les correctifs, l’infrastructure reste vulnérable. Dans certains cas, le fournisseur d’une application peut offrir des fonctionnalités de mise à jour automatique ; dans d’autres, il peut être nécessaire de concevoir une approche pour récupérer et appliquer régulièrement les correctifs.

Applications et systèmes d’exploitation obsolètes

« Vous ne pouvez pas vous attendre à ce qu’un système d’exploitation vieux de six ans vous protège contre une attaque datant seulement de six mois. » - Un professionnel de la sécurité de l’information avec 10 ans d’expérience dans la sécurisation des installations d’entreprise

Bien que « soyez à jour, restez à jour » peut ressembler à une expression marketing, les systèmes d’exploitation et les applications obsolètes créent des risques dans les infrastructures informatiques de nombreuses organisations. Un système d’exploitation publié en 2003 peut toujours être pris en charge par le fournisseur et fourni avec des mises à jour pour résoudre les vulnérabilités, mais ce système d’exploitation peut ne pas contenir les fonctionnalités de sécurité ajoutées dans les versions plus récentes du système d’exploitation. Les systèmes obsolètes peuvent même nécessiter un affaiblissement de certaines configurations de sécurité AD DS pour prendre en charge les moindres fonctionnalités de ces ordinateurs.

Les applications qui ont été écrites pour utiliser des protocoles d’authentification hérités par des fournisseurs qui ne prennent plus en charge l’application ne peuvent généralement pas être réorganisées pour prendre en charge des mécanismes d’authentification plus forts. Toutefois, le domaine Active Directory d’une organisation peut toujours être configuré pour stocker des hachages LAN Manager ou des mots de passe chiffrés réversibles pour prendre en charge ces applications. Les applications écrites avant l’introduction des systèmes d’exploitation plus récents peuvent ne pas fonctionner correctement ou du tout sur les systèmes d’exploitation actuels, ce qui oblige les organisations à maintenir des systèmes de plus en plus anciens, et dans certains cas, du matériel et des logiciels complètement non pris en charge.

Même dans les cas où les organisations ont mis à jour leurs contrôleurs de domaine pour Windows Server 2012, Windows Server 2008 R2 ou Windows Server 2008, il est courant de trouver des parties significatives de la population de serveurs membres qui exécutent Windows Server 2003, Windows 2000 Server ou Windows NT Server 4.0 (qui sont entièrement non pris en charge). Plus une organisation maintient des systèmes vieillissants, plus la disparité entre les ensembles de fonctionnalités augmente et plus il est probable que les systèmes de production ne soient pas pris en charge. En outre, plus longtemps une forêt Active Directory est maintenue, plus nous constatons que les systèmes et applications hérités sont oubliés dans les plans de mise à niveau. Cela peut signifier qu’un seul ordinateur exécutant une seule application peut introduire des vulnérabilités à l’échelle du domaine ou de la forêt, car Active Directory est configuré pour prendre en charge ses protocoles et ses mécanismes d’authentification hérités.

Pour éliminer les systèmes et applications hérités, vous devez d’abord vous concentrer sur leur identification et leur catalogage, puis sur la mise à niveau ou le remplacement de l’application ou de l’hôte. Bien qu’il puisse être difficile de trouver des solutions de remplacement pour les applications hautement spécialisées pour lesquelles il n’existe ni prise en charge ni chemin de mise à niveau, vous pouvez tirer parti d’un concept appelé « destruction créative » pour remplacer l’application héritée par une nouvelle application qui fournit les fonctionnalités nécessaires. La Planification des compromis est décrite plus en détail dans « Planification des compris » plus loin dans ce document.

Configuration incorrecte

Loi numéro quatre : Il n’est pas très utile d’installer des correctifs de sécurité sur un ordinateur qui n’a jamais été sécurisé en premier lieu. - 10 lois immuables de l’administration de la sécurité

Même dans les environnements où les systèmes sont généralement tenus à jour et corrigés, nous identifions généralement des lacunes ou configurations incorrectes dans le système d’exploitation, les applications s’exécutant sur des ordinateurs et Active Directory. Certaines configurations incorrectes exposent uniquement l’ordinateur local à la compromission, mais une fois qu’un ordinateur est « possédé », les attaquants se concentrent généralement sur la propagation de la compromission vers d’autres systèmes et au final Active Directory. Voici quelques-uns des domaines courants dans lesquels nous identifions les configurations qui introduisent des risques.

Dans Active Directory

Les comptes Active Directory les plus couramment ciblés par les attaquants sont ceux qui sont membres des groupes les plus privilégiés, comme les membres des groupes Administrateurs de domaine (DA), Administrateurs d’entreprise (EA) ou Administrateurs intégrés (BA) dans Active Directory. L’appartenance de ces groupes doit être réduite au plus petit nombre de comptes possible afin que la surface d’attaque de ces groupes soit limitée. Il est même possible d’éliminer l’appartenance « permanente » à ces groupes privilégiés. Autrement dit, vous pouvez implémenter des paramètres qui vous permettent de remplir temporairement ces groupes uniquement lorsque leurs privilèges à l’échelle du domaine et de la forêt sont nécessaires. Lorsque des comptes hautement privilégiés sont utilisés, ils doivent être utilisés uniquement sur des systèmes sécurisés désignés, comme des contrôleurs de domaine ou des hôtes administratifs sécurisés. Des informations détaillées pour faciliter l’implémentation de toutes ces configurations sont fournies dans Réduction de la surface d’attaque Active Directory.

Lorsque nous évaluons l’appartenance des groupes privilégiés les plus élevés dans Active Directory, nous trouvons généralement une appartenance excessive dans les trois groupes les plus privilégiés. Dans certains cas, les organisations ont des dizaines, voire des centaines de comptes dans des groupes DA. Dans d’autres cas, les organisations placent des comptes directement dans des groupes Administrateurs intégrés, pensant que le groupe est « moins privilégié » que le groupe DA. Ce n’est pas le cas. Nous trouvons souvent une poignée de membres permanents du groupe EA dans le domaine racine de la forêt, bien que les privilèges EA soient rarement requis, et seulement temporairement. Il est également courant de trouver le compte d’administration quotidien d’un utilisateur informatique dans les trois groupes, même s’il s’agit d’une configuration redondante dans les faits. Comme décrit dans Réduction de la surface d’attaque Active Directory, qu’un compte soit membre permanent de l’un de ces groupes ou de leur ensemble, le compte peut être utilisé pour compromettre, voire détruire l’environnement AD DS et les systèmes et comptes gérés par celui-ci. Des recommandations pour la configuration sécurisée et l’utilisation de comptes privilégiés dans Active Directory sont fournies dans Réduction de la surface d’attaque Active Directory.

À propos des contrôleurs de domaine

Lorsque nous évaluons les contrôleurs de domaine, nous constatons souvent qu’ils sont configurés et gérés différemment des serveurs membres. Les contrôleurs de domaine exécutent parfois les mêmes applications et utilitaires installés sur les serveurs membres, non pas parce qu’ils sont nécessaires sur les contrôleurs de domaine, mais parce que les applications font partie d’une build standard. Ces applications peuvent fournir des fonctionnalités minimales sur les contrôleurs de domaine, mais ajouter considérablement à leur surface d’attaque en exigeant un paramètre de configuration qui ouvre des ports, crée des comptes de service à privilèges élevés ou accorde l’accès au système aux utilisateurs qui ne doivent pas se connecter à un contrôleur de domaine à d’autres fins que l’authentification et l’application de la stratégie de groupe. Dans certaines violations, les attaquants utilisent des outils qui étaient déjà installés sur les contrôleurs de domaine, non seulement pour accéder aux contrôleurs de domaine, mais aussi pour modifier ou endommager la base de données AD DS.

Lorsque nous extrayons les paramètres de configuration d’Internet Explorer sur les contrôleurs de domaine, nous constatons que les utilisateurs se sont connectés avec des comptes disposant de niveaux de privilèges élevés dans Active Directory et ont utilisé les comptes pour accéder à Internet et à l’intranet à partir des contrôleurs de domaine. Dans certains cas, les comptes configurent les paramètres Internet Explorer sur les contrôleurs de domaine pour autoriser le téléchargement de contenu Internet, et des utilitaires gratuits sont téléchargés à partir de sites Internet et installés sur les contrôleurs de domaine. La configuration de la sécurité renforcée d’Internet Explorer est activée par défaut pour les utilisateurs et les administrateurs, mais nous constatons souvent qu’elle est désactivée pour les administrateurs. Lorsqu’un compte à privilèges élevés accède à Internet et télécharge du contenu sur n’importe quel ordinateur, cet ordinateur est exposé à un risque grave. Lorsque l’ordinateur est un contrôleur de domaine, toute l’installation AD DS est mise en danger.

Protection des contrôleurs de domaine

Les contrôleurs de domaine doivent être traités comme des composants d’infrastructure critiques, sécurisés plus rigoureusement et configurés de manière plus rigide que les serveurs de fichiers, d’impression et d’applications. Les contrôleurs de domaine ne doivent pas exécuter de logiciel qui n’est pas nécessaire au fonctionnement du contrôleur de domaine ou qui ne protège pas le contrôleur de domaine contre les attaques. Les contrôleurs de domaine ne doivent pas être autorisés à accéder à Internet, et les paramètres de sécurité doivent être configurés et appliqués par des objets de stratégie de groupe (GPO). Des recommandations détaillées pour l’installation, la configuration et la gestion sécurisées des contrôleurs de domaine sont fournies dans Sécurisation des contrôleurs de domaine contre les attaques.

Dans le système d’exploitation

Loi numéro deux : Si une personne malveillante peut modifier le système d’exploitation sur votre ordinateur, ce n’est plus votre ordinateur. - Dix lois immuables de la sécurité (version 2.0)

Bien que certaines organisations créent des configurations de base pour des serveurs de types différents et autorisent une personnalisation limitée du système d’exploitation après son installation, l’analyse des environnements compromis révèle souvent un grand nombre de serveurs déployés de manière ad hoc et configurés manuellement et indépendamment. Les configurations entre deux serveurs exécutant la même fonction peuvent être complètement différentes, aucun des serveurs n’étant configuré de manière sécurisée. À l’inverse, les bases de référence de configuration de serveur peuvent être appliquées de manière cohérente, mais également mal configurées de manière cohérente ; autrement dit, les serveurs sont configurés de manière à créer la même vulnérabilité sur tous les serveurs d’un type donné. Une mauvaise configuration inclut des pratiques comme la désactivation de fonctionnalités de sécurité, l’octroi de droits et d’autorisations excessifs aux comptes (en particulier les comptes de service), l’utilisation d’informations d’identification locales identiques sur les systèmes et l’autorisation de l’installation d’applications et d’utilitaires non autorisés qui créent leurs propres vulnérabilités.

Désactivation des fonctionnalités de sécurité

Les organisations désactivent parfois le Pare-feu Windows avec la sécurité avancée (WFAS) par conviction que WFAS est difficile à configurer ou nécessite une configuration intensive. Toutefois, à compter de Windows Server 2008, lorsqu’un rôle ou une fonctionnalité sont installés sur un serveur, ils sont configurés par défaut avec les privilèges minimum requis pour le rôle ou la fonctionnalité, et le Pare-feu Windows est automatiquement configuré pour prendre en charge le rôle ou la fonctionnalité. En désactivant WFAS (et en n’utilisant pas un autre pare-feu basé sur l’hôte à sa place), les organisations augmentent la surface d’attaque de l’ensemble de l’environnement Windows. Les pare-feu de périmètre offrent une certaine protection contre les attaques qui ciblent directement un environnement à partir d’Internet, mais n’offrent aucune protection contre les attaques qui exploitent d’autres vecteurs d’attaque, comme les attaques par téléchargement drive-by ou les attaques provenant d’autres systèmes compromis sur l’intranet.

Les paramètres de contrôle de compte d’utilisateur (UAC) sont parfois désactivés sur les serveurs, car le personnel administratif trouve les invites intrusives. Bien que l’article du Support Microsoft 2526083 décrit les scénarios dans lesquels le contrôle de compte d’utilisateur peut être désactivé sur Windows Server, à moins que vous n’exécutiez une installation minimale (où le contrôle de compte d’utilisateur est intentionnellement désactivé), vous ne devez pas désactiver le contrôle de compte d’utilisateur sur les serveurs sans attention ni recherche.

Dans d’autres cas, les paramètres de serveur sont configurés pour des valeurs moins sécurisées, car les organisations appliquent des paramètres de configuration de serveur obsolètes aux nouveaux systèmes d’exploitation, comme l’application de bases de référence Windows Server 2003 aux ordinateurs exécutant Windows Server 2012, Windows Server 2008 R2 ou Windows Server 2008, sans modifier les bases de référence pour refléter les modifications apportées au système d’exploitation. Au lieu de transporter d’anciennes bases de référence de serveur vers de nouveaux systèmes d’exploitation, lors du déploiement d’un nouveau système d’exploitation, passez en revue les modifications de sécurité et les paramètres de configuration pour vous assurer que les paramètres implémentés sont applicables et appropriés pour le nouveau système d’exploitation.

Octroi de privilèges excessifs

Dans presque tous les environnements que nous avons évalués, des privilèges excessifs sont accordés aux comptes locaux et basés sur un domaine sur les systèmes Windows. Les utilisateurs disposent de droits d’administrateur local sur leurs stations de travail, les serveurs membres exécutent des services configurés avec des droits au-delà de ce dont ils ont besoin pour fonctionner, et les groupes Administrateurs locaux dans l’ensemble de la population de serveurs contiennent des dizaines, voire des centaines de comptes locaux et de domaine. La compromission d’un seul compte privilégié sur un ordinateur permet aux attaquants de compromettre les comptes de chaque utilisateur et service qui se connecte à l’ordinateur, et de collecter et d’exploiter les informations d’identification pour propager la compromission à d’autres systèmes.

Si les attaques d’usurpation d’identité, ou pass-the-hash (PTH) et d’autres attaques de vol d’informations d’identification sont aujourd’hui omniprésentes, c’est parce qu’il existe des outils disponibles gratuitement qui facilitent l’extraction des informations d’identification d’autres comptes privilégiés par un attaquant ayant obtenu un accès administrateur ou système à un ordinateur. Même sans outils permettant de collecter des informations d’identification à partir de sessions ouvertes, un attaquant disposant d’un accès privilégié à un ordinateur peut tout aussi facilement installer des enregistreurs de frappes qui capturent les séquences de touches, des captures d’écran et le contenu du Presse-papiers. Un attaquant disposant d’un accès privilégié à un ordinateur peut désactiver les logiciels anti-programme malveillant, installer des rootkits, modifier des fichiers protégés ou installer des programmes malveillants sur l’ordinateur pour automatiser les attaques ou transformer un serveur en hôte de téléchargement drive-by .

Les tactiques utilisées pour étendre une violation au-delà d’un seul ordinateur varient, mais la clé pour propager la compromission est l’acquisition d’un accès hautement privilégié à d’autres systèmes. En réduisant le nombre de comptes disposant d’un accès privilégié à n’importe quel système, vous réduisez la surface d’attaque non seulement de cet ordinateur, mais aussi la probabilité qu’un attaquant récolte des informations d’identification précieuses à partir de l’ordinateur.

Normalisation des informations d’identification de l’administrateur local

Les spécialistes de la sécurité ont longtemps débattu de l’intérêt de renommer les comptes Administrateur locaux sur les ordinateurs Windows. L’important avec les comptes Administrateur locaux est de savoir s’ils sont configurés avec le même nom d’utilisateur et le même mot de passe sur plusieurs ordinateurs.

Si le compte Administrateur local est nommé avec la même valeur entre les serveurs et que le mot de passe attribué au compte est également configuré sur la même valeur, les attaquants peuvent extraire les informations d’identification du compte sur n’importe quel ordinateur sur lequel un accès administrateur ou système a été obtenu. L’attaquant n’a pas à compromettre initialement le compte Administrateur. Il lui suffit de compromettre le compte d’un utilisateur membre du groupe Administrateurs local ou d’un compte de service configuré pour s’exécuter en tant que LocalSystem ou avec des privilèges d’administrateur. L’attaquant peut ensuite extraire les informations d’identification du compte Administrateur et relire ces informations d’identification dans les connexions réseau sur d’autres ordinateurs du réseau.

Tant qu’un autre ordinateur dispose d’un compte local avec le même nom d’utilisateur et le même mot de passe (ou hachage de mot de passe) que les informations d’identification présentées du compte, la tentative d’ouverture de session réussit et l’attaquant obtient un accès privilégié à l’ordinateur ciblé. Dans les versions actuelles de Windows, le compte Administrateur intégré est désactivé par défaut, mais dans les systèmes d’exploitation hérités, le compte est activé par défaut.

Remarque

Certaines organisations configurent intentionnellement les comptes d’administrateur locaux pour qu’ils soient activés, en estimant que cela offre une « sécurité » au cas où tous les autres comptes privilégiés seraient verrouillés hors d’un système. Toutefois, même si le compte Administrateur local est désactivé et qu’aucun autre compte n’est disponible pour activer le compte ou se connecter au système avec des privilèges d’administrateur, le système peut être démarré en mode sans échec et le compte Administrateur local intégré peut être réactivé, comme décrit dans l’article du support Microsoft 814777. En outre, si le système applique toujours correctement les objets de stratégie de groupe, un objet de stratégie de groupe peut être modifié pour réactiver (temporairement) le compte Administrateur, ou des groupes restreints peuvent être configurés pour ajouter un compte basé sur un domaine au groupe Administrateurs local. Des réparations peuvent être effectuées et le compte Administrateur peut à nouveau être désactivé. Pour empêcher efficacement une compromission latérale qui utilise des informations d’identification de compte Administrateur local intégrées, des noms d’utilisateur et des mots de passe uniques doivent être configurés pour les comptes d’administrateur locaux. Pour déployer des mots de passe uniques pour les comptes d’administrateur locaux via un objet de stratégie de groupe, consultez Solution pour la gestion du mot de passe du compte Administrateur intégré via un objet de stratégie de groupe sur technet.  

Autorisation de l’installation d’applications non autorisées

Loi numéro un : Si un méchant peut vous persuader d’exécuter son programme sur votre ordinateur, ce n’est plus seulement votre ordinateur. - Dix lois immuables de la sécurité (version 2.0)

Si une organisation déploie des paramètres de base cohérents sur ses serveurs, l’installation d’applications qui ne font pas partie du rôle défini d’un serveur ne doit pas être autorisée. Si l’installation de logiciels qui ne font pas partie des fonctionnalités désignées d’un serveur est autorisée, les serveurs sont exposés à une installation accidentelle ou malveillante de logiciels augmentant la surface d’attaque du serveur, introduisant des vulnérabilités d’application ou provoquant une instabilité du système.

Applications

Comme décrit précédemment, des applications sont souvent installées et configurées pour utiliser des comptes pour lesquels l’application a reçu plus de privilèges que ce dont elle a réellement besoin. Dans certains cas, la documentation de l’application spécifie que les comptes de service doivent être membres du groupe Administrateurs local d’un serveur ou être configurés pour s’exécuter dans le contexte de LocalSystem. Cela n’est souvent pas dû au fait que l’application exige ces droits, mais parce que la détermination des droits et autorisations dont les comptes de service d’une application ont besoin nécessite un investissement en temps et en efforts supplémentaires. Si une application ne s’installe pas avec les privilèges minimaux requis pour que l’application et ses fonctionnalités configurées fonctionnent, le système est exposé à des attaques qui tirent parti des privilèges d’application sans aucune attaque contre le système d’exploitation lui-même.

Absence de pratiques de développement d’applications sécurisées

Une infrastructure existe pour prendre en charge les charges de travail métier. Lorsque ces charges de travail sont implémentées dans des applications personnalisées, il est essentiel de s’assurer que les applications sont développées à l’aide des meilleures pratiques de sécurité. L’analyse de la cause racine des incidents à l’échelle de l’entreprise révèle souvent qu’une compromission initiale est causée par des applications personnalisées, en particulier celles qui sont accessibles sur Internet. La plupart de ces compromissions s’effectuent via la compromission par des attaques connues comme l’injection SQL (SQLi) et les attaques par script inter-site (XSS).

L’injection de code SQL est une vulnérabilité d’application qui permet à une entrée définie par l’utilisateur de modifier une instruction SQL passée à la base de données pour exécution. Cette entrée peut être fournie via un champ dans l’application, un paramètre (comme la chaîne de requête ou un cookie) ou d’autres méthodes. Le résultat de cette injection est que l’instruction SQL fournie à la base de données est fondamentalement différente de celle prévue par le développeur. Prenons, par exemple, une requête courante utilisée dans l’évaluation d’une combinaison nom d’utilisateur/mot de passe :

SELECT userID FROM users WHERE username = 'sUserName' AND password = 'sPassword'

Lorsque ce message est reçu par le serveur de base de données, il indique au serveur d’examiner la table des utilisateurs et de retourner tout enregistrement userID où le nom d’utilisateur et le mot de passe correspondent à ceux fournis par l’utilisateur (probablement par le biais d’un formulaire de connexion quelconque). Naturellement, l’intention du développeur dans ce cas est de retourner un enregistrement valide uniquement si un nom d’utilisateur et un mot de passe corrects peuvent être fournis par l’utilisateur. Si l’une ou l’autre valeur est incorrecte, le serveur de base de données ne peut pas trouver d’enregistrement correspondant, et retourne un résultat vide.

Le problème se produit lorsqu’un attaquant fait quelque chose d’inattendu, comme fournir son propre code SQL à la place de données valides. Étant donné que SQL est interprété à la volée par le serveur de base de données, le code injecté serait traité comme si le développeur l’avait placé lui-même. Par exemple, si l’attaquant a entré administrator pour l’ID utilisateur et xyz OR 1=1 comme mot de passe, l’instruction résultante traitée par la base de données serait :

SELECT userID FROM users WHERE username = 'administrator' AND password = 'xyz' OR 1=1

Lorsque cette requête est traitée par le serveur de base de données, toutes les lignes de la table sont retournées dans la requête, car 1=1 prend toujours la valeur True. Il n’est donc pas important que le nom d’utilisateur et le mot de passe corrects soient connus ou fournis. Le résultat net dans la plupart des cas est que l’utilisateur est connecté en tant que premier utilisateur dans la base de données d’utilisateurs ; dans la plupart des cas, il s’agit de l’utilisateur administratif.

En plus de la simple connexion, des instructions SQL incorrectes comme celles-ci peuvent être utilisées pour ajouter, supprimer ou modifier des données, ou même supprimer des tables entières d’une base de données. Dans les cas les plus extrêmes où l’injection SQL est associée à des privilèges excessifs, des commandes du système d’exploitation peuvent être exécutées pour permettre la création de nouveaux utilisateurs, télécharger des outils d’attaque ou effectuer toute autre action du choix des attaquants.

Avec le scripting inter-site, la vulnérabilité est introduite dans la sortie de l’application. Une attaque commence par un attaquant fournissant des données incorrectes à l’application, mais dans ce cas, les données incorrectes sont sous la forme d’un code de script (comme JavaScript) qui sera exécuté par le navigateur de la victime. L’exploitation d’une vulnérabilité XSS peut permettre à un attaquant d’exécuter n’importe quelle fonction de l’application cible dans le contexte de l’utilisateur qui a lancé le navigateur. Les attaques XSS sont généralement lancées par un e-mail d’hameçonnage qui encourage l’utilisateur à cliquer sur un lien qui se connecte à l’application et exécute le code d’attaque.

XSS est souvent exploité dans les scénarios de banque en ligne et d’e-commerce où un attaquant peut effectuer des achats ou transférer de l’argent dans le contexte de l’utilisateur exploité. Dans le cas d’une attaque ciblée sur une application de gestion des identités web personnalisée, cela peut permettre à un attaquant de créer ses propres identités, de modifier les autorisations et les droits et de conduire à une compromission systémique.

Bien qu’une description complète des scripts intersites et de l’injection SQL ne soit pas comprise dans ce document, Open Web Application Security Project (OWASP) publie une liste des 10 principales vulnérabilités avec une discussion approfondie sur les vulnérabilités et les contre-mesures.

Indépendamment de l’investissement dans la sécurité de l’infrastructure, si des applications mal conçues et écrites sont déployées au sein de cette infrastructure, l’environnement est rendu vulnérable aux attaques. Même les infrastructures bien sécurisées ne peuvent souvent pas fournir de contre-mesures efficaces à ces attaques d’applications. Pour aggraver le problème, les applications mal conçues peuvent nécessiter l’octroi d’autorisations excessives aux comptes de service pour fonctionner.

Microsoft Security Development Lifecycle (SDL) est un ensemble de contrôles de processus structurels qui permettent d’améliorer la sécurité dès la collecte des exigences et tout au long du cycle de vie de l’application jusqu’à ce qu’elle soit mise hors service. Cette intégration de contrôles de sécurité efficaces n’est pas seulement critique du point de vue de la sécurité, elle est essentielle pour garantir que la sécurité des applications est rentable et planifiée. L’évaluation des problèmes de sécurité d’une application lorsque son code est effectivement terminé nécessite que les organisations prennent des décisions concernant la sécurité de l’application uniquement avant ou même après le déploiement de cette dernière. Une organisation peut choisir de résoudre les défauts de l’application avant de déployer l’application en production, ce qui entraîne des coûts et des retards, ou l’application peut être déployée en production avec des failles de sécurité connues, ce qui expose l’organisation à des compromissions.

Certaines organisations placent le coût total de la résolution d’un problème de sécurité dans le code de production à plus de 10 000 $ par problème, et les applications développées sans SDL efficace peuvent atteindre en moyenne plus de dix problèmes de gravité élevée toutes les 100 000 lignes de code. Dans les applications volumineuses, les coûts augmentent rapidement. En revanche, de nombreuses entreprises définissent un point de référence de moins d’un problème pour 100 000 lignes de code à l’étape finale de révision du code du SDL et visent à éviter les problèmes dans les applications à haut risque en production.

L’implémentation du SDL améliore la sécurité en incluant les exigences de sécurité dès le début de la collecte et de la conception des exigences d’une application, ce qui permet de modéliser les menaces pour les applications à haut risque, nécessite une formation et une surveillance efficaces des développeurs, et nécessite des normes et des pratiques de code claires et cohérentes. L’effet net d’un SDL est une amélioration significative de la sécurité des applications tout en réduisant les coûts de développement, de déploiement, de maintenance et de mise hors service d’une application. Bien qu’une discussion détaillée de la conception et de l’implémentation de SDL dépasse le cadre de ce document, reportez-vous au Cycle de vie de développement de la sécurité Microsoft pour obtenir des conseils et des informations détaillées.