Audits de contrôleurs Windows

Ary KOKOS (Solucom) et Alain SCHNEIDER (COGICEO) ont parlé de l'audit de contrôleurs de domaines Windows, et des conséquences de la récupération de mots de passe. Le support de la présentation est disponible sur le site de l'OSSIR.

En préambule, ils ont posé le coeur de leur réflexion quant à certains audits : comment combiner de la façon la plus efficace possible les vulnérabilités connues, les outils d'exploitation connus, et le classicisme de certaines architectures ?

Pour illustrer cette question, ils partent d'une situation relativement courante : l'auditeur est dans une salle de réunion, dans laquelle se trouve un ordinateur (de l'entreprise auditée) et une prise réseau.

Récupération du mot de passe administrateur

Dans 85% des cas, l'ordinateur dans la salle de réunion n'est pas protégé (accès physique). Les 15% qui restent sont plus délicats, et correspondent par exemple à la présence d'un disque dur chiffré. Un peu d'ingéniérie sociale est alors nécessaire, auprès du support utilisateurs, afin de récupérer les clés de déchiffrement.

La récupération des mots de passe Windows peut se faire

• directement sur la machine, avec des outils comme mimikatz, en examinant les tâches planifiées ou les logiciels spécifiques, etc.
• à partir des condensats, lorsqu'ils sont "cassables", c'est-à-dire qu'ils correspondent à des mots de passe triviaux ou déjà connus (par exemple le mot de passe "standard" pour l'entreprise/pour le compte).

Il est aussi possible de se passer des mots de passe, en n'utilisant que leur condensat (Attaque pass-the-hash).

Parfois, l'auditeur a de la chance. Ainsi, on peut trouver des tâches planifiées ou des scripts contenant les mots de passe codés en dur. Si les machines sont de surcroît produites à partir d'un environnement standardisé (master CD), le reste de l'audit en devient presque trivial.

Une remarque intéressante, concernant Windows8 et les politiques de groupes (gpp). Le mot de passe est présent, chiffré en dur avec une clé connue, donc facile à déchiffrer.

En conclusion sur la récupération des mots de passe : il ne faut surtout pas négliger les choses simples (de type password123, etc.). Cela marche encore très bien.

Balayage des stations

Le balayage des stations est un simple enchaînement, de type boule de neige :

1. accès à des systèmes,
2. obtention d'identifiants supplémentaires,
3. accès à d'autres systèmes.

Les outils, tout particulièrement ceux utilisés pour rebondir d'un système vers un autre, peuvent être détectés par certains antivirus. Dans une telle situation, il se révèle souvent plus facile de désactiver l'anti-virus plutôt que de tenter de le contourner. Une autre solution est de déposer les exécutables et outils dans la zone de quarantaine positive de l'antivirus (arborescence contenant des fichiers qui ne seront pas considérés comme hostiles).

Au titre des outils, les présentateurs considèrent que mimikatz est à privilégier.

Il convient malgré tout de faire attention aux éventuels effets de bord de ces accès en chaîne : il faut minimiser les perturbations apportées aux cibles. Il y a plusieurs grandes familles de risques :

• Des risques purement techniques : les outils laissent ou peuvent laisser des artefacts sur les systèmes concernés, voire en perturber le fonctionnement.
• Des risques sociaux : lorsque les auditeurs récupèrent des mots de passe ou obtiennent, d'une façon ou d'une autre, des accès à des systèmes, cela peut provoquer divers remous et ressentiments dans l'entreprise.

Pour éviter ces risques, il faut évidemment rester prudent dans ses opérations. Il peut donc se révéler intéressant de cibler quelques machines spécifiques, plutôt que de balayer tous les postes de travail et tous les serveurs de l'entreprise.

Ciblage des serveurs

Les présentateurs ont ensuite évoqué le ciblage direct des serveurs (par opposition au ciblage indirect, qui passe par des postes de travail sur lesquels on récupère les informations de l'administrateur du domaine). Le principal problème de ce ciblage est le temps limité pour mener l'opération.

Tout dépend ensuite des cibles et, notamment, de ce qui fonctionne dessus :

• cible de premier rang : utilise jboss, tomcat ou d'autres outils du même type, qui fonctionnent avec des droits administrateur. Il suffit de trouver une injection de code, et le jeu est terminé.
• cible de second rang : système pas à jour (exploitation de vieilles vulnérabilités, du genre Conficker), fonctionnalités spéciales de type "Scan to folder" pour lesquelles les mots de passe sont codés en dur quelque part (afin d'avoir les droits d'écriture dans les répertoires), outils de déploiement ou de gestion de paquetages "faits maison", etc.

Quelques statistiques

Pour une intrusion sur un domaine Windows, les présentateurs disent réussir à récupérer environ 85% des mots de passe. Selon leur expérience, 96% des domaines sont conquis en moins d'une semaine, dont 50% en moins de deux jours. Et la totalité des audits montre la présence d'au moins un mot de passe trivial.

En outre, de nombreux systèmes d'informations hébergent des outils très obsolètes (Windows 2000 voire antérieur).

Et ensuite ?

Il est souvent demandé aux auditeurs de prouver qu'ils ont réussi à atteindre des systèmes sensibles. Il faut donc trouver des données parlantes, qui peuvent être :

• des informations critiques de l'entreprise,
• des dossiers liés aux ressources humaines, à la direction générale, voire aux syndicats
• des messages sensibles,
• des données personnelles,
• etc.

Cela signifie que les auditeurs peuvent être amenés à aller examiner les répertoires des utilisateurs, les serveurs de fichiers, etc. Cela n'est pas sans risques sociaux ("la direction a demandé que les répertoires personnels soient examinés") voire légaux (accès à des données privées, nominatives, etc.).

De nouveau, les auditeurs doivent rester prudents dans ce qu'ils extraient du système d'informations pour prouver leur passage.

Quelles contre-mesures envisager ?

Les audits (et donc les attaques éventuelles) sont rapides car ils reposent le plus souvent sur des vulnérabilités connues. Les premières contre-mesures ne sont donc pas particuièrement exotiques non plus : il faut bloquer les vecteurs classiques

• une bonne gestion des mots de passe,
• interdiction du mot de passe administrateur local sur les machines,
• interdition des connexions administrateur sur tous les postes,
• segmentation du réseau,
• surveillance des activités (tout particulièrement des échecs répétés de connexion).

L'utilisation d'un pot de miel, en tant que détecteur simple, peut être envisagée. La rationalisation est alors de dire que s'il se passe quelque chose (quoi que ce soit) sur le pot de miel, c'est que le système d'informations est attaqué...