Comptes à hauts privilèges : comment ne pas se les faire compromettre bêtement

Introduction au Single Sign On (SSO) Windows 

Chaque matin, arrivés sur notre lieu de travail, nous nous empressons d’allumer notre ordinateur et de saisir nos identifiants et mots de passe. Notre bureau Windows apparait et nous pouvons enfin consulter les fichiers que nous avions enregistrés la veille quelque part sur les serveurs de notre entreprise. Nous envoyons quelques emails à notre patron, nous consultons les nouvelles sur l’intranet de l’entreprise.

Nous faisons cela sans jamais ressaisir notre mot de passe. C’est ce qu’on appelle le « Single Sign On» ou « SSO » : Notre ordinateur conserve quelque part dans sa mémoire nos identifiants et mots de passe et les communique à qui souhaite contrôler leur validité : serveurs de fichiers, serveurs de courriel, serveurs web de l’intranet, etc.

Risque du SSO pour les administrateurs

Le SSO est très pratique pour les utilisateurs. Malheureusement il peut poser d’énormes risques de sécurité lorsqu’utilisé avec des comptes à hauts privilèges : domain admins, administrateurs des serveurs et postes de travail, etc.

Ces comptes à hauts privilèges sont régulièrement utilisés par des administrateurs, membres du helpdesk et autres outils de gestion informatique  pour se connecter et administrer un grand nombre de systèmes hétérogènes pour par exemple dépanner un utilisateur en détresse ou bien configurer un serveur, faire l’inventaire des systèmes, etc.

Pour réaliser leurs taches a distance ils disposent de plusieurs méthodes de connexion et d’identification: RDP, RDP Restricted admin mode, Consoles de gestion Windows, script powershell, PsExec, Run as, etc. La liste est longue…

Dépendamment des manières de réaliser leurs tâches, les administrateurs peuvent, sans en avoir conscience, déposer leurs identifiants dans la mémoire des systèmes Windows qu’ils souhaitent administrer.  Cela représente un risque : La sécurité de leurs identifiants et alors proportionnelle à la sécurité de ces systèmes.

Si un des systèmes administrés est compromis par un hacker ou un malware, ces identifiants peuvent être volés puis réutilisés ailleurs dans l’environnement informatique de l’entreprise. 

Les hackers peuvent alors réaliser des transactions financières non autorisées, consulter des informations sensibles, menacer la direction de « détruire » l’environnement informatique si ces derniers de paient pas une forte rançon. Vous l’avez compris, les scénarios possibles sont infinis.

Exemple d’identifiants présents dans la mémoire d’un ordinateur capturé avec à un outil de hacking:

Se défendre

Microsoft a sorti un très bon Livre blanc permettant de discerner les méthodes d’administration sécurisées (ne laissant pas les identifiants et mots de passe dans la mémoire des ordinateurs) de celles utilisant le SSO de Windows. En voici un résumé :

Exemples de méthodes d’administration « Sécurisées » :

Méthodes d’administration

Net use * \\SERVER

Net use * \\SERVER /u:user

MMC snap-ins to remote computer

PowerShell WinRM

PsExec without explicit creds

Remote Registry

Remote Desktop Gateway

IIS "Integrated Windows Authentication"

RDP restricted admin mode

Exemples de méthodes d’administration laissant des identifiants dans la mémoire des systèmes administrés (potentiellement dangereuses) :

Méthodes d’administration

Log on at console

RUNAS

Remote Desktop (RDP)

PowerShell WinRM with CredSSP

PsExec \\server -u user -p pwd cmd

Scheduled task

Run tools as a service

IIS "Basic Authentication"

Si vous ne voyez pas votre méthode d’administration dans ces listes, n’ayez crainte. Réalisez vos tâches d’administration et lancez ce script PowerShell sur le système avec un autre compte administrateur :

[dateTime]$1dayAgo = (get-date).addDays(-1); Get-EventLog Security -AsBaseObject -After $1dayAgo -InstanceId 4624|Where-Object {($_.Message -match "de session :\s+2") -or  ($_.Message -match "de session :\s+4") -or ($_.Message -match "de session :\s+5") -or ($_.Message -match "de session :\s+8") -or ($_.Message -match "de session :\s+9") -or ($_.Message -match "de session :\s+10") -or ($_.Message -match "de session :\s+11")}| Format-List | findstr /c:"Nom du compte?:"

Si le nom du compte que vous avez utilisé pour réaliser vos tâches d’administration apparait, cela signifie que l’ordinateur administré a stocké les identifiant et mot de passe de ce compte dans sa mémoire. Essayez plusieurs manières de réaliser vos tâches d’administration jusqu’à ce que le système administré ne stocke plus les mots de passe en mémoire.

Si vous n’avez pas le choix de stocker vos identifiants et mots de passe dans la mémoire des systèmes administrés alors préférez utiliser un compte local ayant un mot de passe unique sur chaque système. Si ce compte est compromis, cela n’aura pas d’impact aggravant sur les autres systèmes présents dans le domaine.

L’idéal étant de lancer ce script régulièrement sur tous vos systèmes afin d’identifier les comptes a hauts privilèges se connectant a des systèmes de manière « non sécurisée ».

Des questions concernant cet article? 

N’hésitez pas à laisser un commentaire pour en faire profiter tout le monde. 

Vous pouvez aussi nous joindre à ce courriel : info@oppidumsecurity.com

Ou nous parler via notre site internet : https://oppidumsecurity.com/