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/
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/
