Avis d’expert : les risques liés aux comptes à privilèges

0
137

Jocelyn De Larocque Latour est spécialiste de la réduction des risques liés aux infrastructures et logiciels informatiques.

Il a travaillé auprès de nombreux fournisseurs dont Microsoft et IBM où il a acquis un savoir-faire et une expérience dans le conseil et particulièrement les phases d’avant-vente et de support technique sur des solutions professionnelles. Aujourd’hui pour Quest, il accompagne les équipes de marketing et de vente dans le développement de leurs compétences, tant commerciales que techniques. Il intervient notamment sur les questions de conformités, particulièrement dans le cadre du RGPD européen.

TROIS FAÇONS POUR UN UTILISATEUR A PRIVILÈGES DE COULER VOTRE ACTIVE
DIRECTORY

Déçu par le montant de sa prime, l’administrateur IT UBS Paine Webber, Roger Duronio, a écrit 50 lignes de code qu’il a déployées sur des milliers de systèmes du réseau de l’entreprise, en se servant des mêmes outils admin Unix standard utilisés pour déployer des fichiers légitimes SUR CES mêmes systèmes. Puis il a démissionné.

Mais pas sa bombe logique. Celle-ci décomptait les semaines, donnant suffisamment de temps à Duronio pour passer l’équivalent de 20.000 dollars de commandes afin d’épuiser les stocks de UBS/PW. Puis, un matin, la bombe a explosé. Elle embarquait la commande « rm -rf / » … Ce que l’on peut traduire par « Supprimer tout ».

S’en suivit un désordre indescriptible. UBS/PW a dû revenir à l’utilisation de la combinaison papier-crayons pour poursuivre ses opérations. Ils ont dépensé 3 millions de dollars de frais de consulting auprès d’IBM pour restaurer les systèmes à partir de sauvegardes. Nul ne sait quel est le montant total de cette attaque.

Il ne s’agit que d’un exemple des dégâts que peuvent provoquer des utilisateurs à privilèges mécontents ou négligents. Dans un environnement Windows, c’est assez simple à reproduire puisque tout repose sur Active Directory (AD). Si l’Active Directory tombe en panne, c’est l’ensemble du réseau qui devient inaccessible, quand bien même rien n’entrave le fonctionnement des serveurs et applications.

C’est effectivement très facile ! Voici trois façons parmi de nombreuses autres qui permettent à un utilisateur à privilèges — ou un agresseur ayant volé les identifiants d’un compte à privilèges – de mettre à mal AD et, de ce fait, le reste du réseau informatique.

MÉTHODE 1 : REFUSER LES DROITS DE CONNEXION

Il existe cinq façons pour un compte utilisateur de se connecter à Windows : localement, à partir du réseau, par batch, en tant que service et via Remote Desktop Services. Pour chacune de ces méthodes de connexion, il existe deux types de droits de connexion, un qui autorise la connexion, l’autre qui la rejette.

En assignant correctement les cinq droits aboutissant à un déni refus de connexion, un utilisateur à privilèges peut interrompre les opérations :

  • Les utilisateurs ne pourront plus se connecter à leur poste de travail.
  • Les admins n’auront plus accès aux contrôleurs de domaines, même à partir de l’écran et du clavier local de la console.
  • Les comptes de service ne pourront plus se connecter.
  • Les applications ne pourront plus démarrer.

Ceci crée un double dilemme : comme il est impossible de se connecter avec un compte de domaine, il est impossible de régler le problème à distance. Il faut alors bénéficier d’un accès physique aux contrôleurs de domaine (DC) pour redémarrer DSRM et pouvoir commencer les opérations de restauration. En assignant correctement les cinq droits aboutissant à un déni de connexion, un utilisateur à privilèges peut interrompre les opérations.

MÉTHODE 2 : PLANTER FAIRE TOMBER LE DNS

Active Directory utilise le DNS comme mécanisme de localisation des contrôleurs de domaine (DC). Chaque Domain Active Directory Windows Server 2003 ou ultérieur a un nom de domaine DNS et chaque ordinateur Windows Server 2003 ou version ultérieure a un nom DNS.

Pour interrompre Active Directory, tout ce qu’un utilisateur à privilèges a à faire, est de supprimer toutes les entrées DNS d’un DC. Ces changements se répliquent ensuite rapidement aux autres DC via le DNS en cache. Puis le cache DNS arrive à expiration et soudainement plus rien ne peut être retrouvé. Les postes de travail notamment ne sont plus en mesure de trouver les contrôleurs de domaine en utilisant le DNS. Ils doivent alors procéder par la résolution de nom NetBIOS, ce qui ne fonctionne pas systématiquement. Quand le DNS est planté, plus rien ne fonctionne.

MÉTHODE 3 : EXPLOITER UNE VULNÉRABILITÉ DU SYSTÈME D’EXPLOITATION

Un jour, une entreprise utilisant Windows Server 2008 a découvert que tous ses DC suivaient un cycle de redémarrage en boucle. Il s’est avéré qu’un utilisateur à privilèges s’était introduit dans un sous-réseau et avait accidentellement changé un paramètre IPv6 en une adresse IP non valide.

Quand le processus de configuration de réplication du Knowledge Consistency Checker (KCC) a rencontré ce paramètre non valide, il s’est interrompu. Le DC a alors redémarré, mais pas avant que le paramètre non valide ait été répliqué aux autres DC de tout l’environnement, ce qui a provoqué leur redémarrage à répétition.

Des vulnérabilités inconnues ou non corrigées peuvent provoquer une panne d’AD. Microsoft a sorti un correctif à ce problème. Si vous êtes toujours sous Windows 2008 ou 2008 R2, veillez à vous mettre à jour des derniers correctifs. Mais rien ne garantit qu’il n’existe pas d’autres vulnérabilités qu’un utilisateur à privilèges pourrait exploiter délibérément ou pas, avec des conséquences tout aussi désastreuses. Les employés mécontents ne sont pas la seule menace.

Un trop grand nombre d’entreprises pensent atténuer le risque d’être victimes de ce type de scénarios en prétendant ne pas avoir d’utilisateurs à privilèges mécontents ou malveillants qui pourraient se transformer en menace intérieure. Même si vous pensez pouvoir apporter cette garantie (aujourd’hui et à l’avenir), vous vous exposez toujours à des risques pour deux raisons.

Premièrement, même les admins les plus honorables peuvent commettre des erreurs, à l’image du paramètre IPv6 non valide précité. Deuxièmement, il est possible que des identifiants à privilèges puissent être volés et utilisés abusivement lors d’une cyberattaque par différents profils d’acteurs malveillants :

  • Des hacktivistes
  • Un groupe hostile financé par un état
  • Des concurrents
  • Une tierce partie lésée ou offensée
  • Un nihiliste convaincu

Les entreprises craignent autant les corruptions de données dues à la négligence d’utilisateurs ou à des identifiants compromis (51%) que les corruptions du fait de salariés malveillants (47%).

N’oubliez pas que tous ces agresseurs n’investissent pas leur temps et leur énergie pour vous voler des données. Certains désirent simplement provoquer l’arrêt de vos services et mettre à mal votre entreprise, ce qui est bien plus facile.