Quelle identité fait tourner le service et qui peut le prouver

Un service Windows tourne sous une identité et cette identité est toute l’histoire sécurité: c’est le rayon d’impact quand le service est exploité et c’est le nom dans les logs quand il faut savoir qui a fait quoi. L’essentiel de ce que j’audite vient d’un raccourci unique, un compte local avec un mot de passe statique figé dans la configuration du service, qui est à la fois un secret en clair et une identité que personne ne renouvelle. La correction n’est pas un meilleur mot de passe, c’est de choisir une identité dont aucun humain ne détient jamais le mot de passe.

L’échelle des identités

Prenez le barreau le plus haut sur lequel le service peut vivre, pas le plus bas qui se trouve fonctionner.

Les trois identités de service intégrées sont le plancher et couvrent la plupart des services isolés: LocalService (très limité, pas d’identité réseau), NetworkService (limité localement, s’authentifie au réseau comme le compte machine) et LocalSystem (pleine puissance locale, à éviter pour tout service maison). Aucune n’a de mot de passe. Pour un service qui ne touche que ses propres fichiers, LocalService est la bonne réponse et la fin de la discussion.

sc.exe create MyService binPath="C:\app\svc.exe" obj="NT AUTHORITY\LocalService"

Un compte de service virtuel, NT SERVICE\<NomService>, est le barreau suivant et celui qu’on néglige. Le gestionnaire de services crée un SID propre au service, sans mot de passe et ce SID peut recevoir ses propres droits fichiers et registre, de sorte que deux services sous NetworkService cessent de partager une identité et deviennent isolables l’un de l’autre. Pour un service mono-machine qui a besoin de ses propres ACL, c’est en général le point d’équilibre.

Un group Managed Service Account (gMSA) est la réponse dès que le service a besoin d’une identité de domaine, pour atteindre un partage ou une base en tant que lui-même. Active Directory détient le mot de passe, le renouvelle selon son propre calendrier et aucun opérateur ne le tape ni ne le stocke jamais. Cette propriété, une identité de domaine sans mot de passe qu’un humain connaisse, est exactement ce que l’anti-pattern du compte local à mot de passe ne fournit pas.

# une fois par forêt
Add-KdsRootKey -EffectiveImmediately
New-ADServiceAccount -Name gmsa_app -DNSHostName app.company.internal `
    -PrincipalsAllowedToRetrieveManagedPassword "AppServers"
# sur l'hôte, après Install-ADServiceAccount
sc.exe config MyService obj="COMPANY\gmsa_app$" password=""

Un compte local à mot de passe statique est le barreau du bas, un palliatif le temps qu’un gMSA soit provisionné, jamais une destination. S’il le faut, traitez le mot de passe comme le passif qu’il est: unique par hôte, jamais réutilisé, tout chemin interactif refusé et une entrée d’agenda pour supprimer le compte quand le vrai arrive.

Moindre privilège, concrètement

Quelle que soit l’identité qui fait tourner le service, elle a besoin du droit “ouvrir une session en tant que service” et de rien qu’elle n’utilise. Les droits de refus comptent autant que les octrois, parce qu’ils empêchent une identité de service d’être un jour utilisable comme voie d’entrée:

# accorder le seul logon de service; refuser tout chemin interactif et distant
$acc = "NT SERVICE\MyService"
# SeServiceLogonRight accordé; SeDenyInteractiveLogonRight,
# SeDenyNetworkLogonRight, SeDenyRemoteInteractiveLogonRight refusés

Les droits viennent des groupes intégrés correspondants plutôt que de privilèges distribués un à un: Event Log Readers pour un collecteur de logs, Performance Monitor Users pour un agent de métriques, IIS_IUSRS pour un worker web. L’accès fichier est accordé au SID du service sur les répertoires exacts qu’il utilise, lecture et exécution sur les binaires, écriture seulement là où il écrit vraiment:

icacls "C:\app"      /grant "NT SERVICE\MyService:(OI)(CI)RX" /T
icacls "C:\app\data" /grant "NT SERVICE\MyService:(OI)(CI)M"  /T

Le principe est ennuyeux et c’est tout le jeu: un service qui n’a jamais le droit que de lire ses binaires et d’écrire son répertoire de données est un service dont la compromission achète à l’attaquant une lecture de ses binaires et une écriture dans son répertoire de données et rien d’autre.

Traçabilité: prouver ce qui tourne sous quelle identité

Le second rôle d’une identité de service est la traçabilité et elle ne fonctionne que si l’identité est distincte par service. Une douzaine de services tournant tous sous NetworkService sont une douzaine de choses qu’on ne distingue pas dans un log; la même douzaine sous leurs propres comptes virtuels ou gMSA sont douze noms qu’on peut suivre.

La vue faisant autorité sur ce qui tourne réellement sous quoi vient du gestionnaire de services, pas de l’intention de l’installeur:

Get-CimInstance Win32_Service |
    Select-Object Name, StartName, State, StartMode |
    Sort-Object StartName

Pour la piste d’audit, les ID d’événements qui comptent sont 7045 (un service a été installé, la première chose à vérifier quand un inattendu apparaît), 7034/7036 (plantages et changements d’état) et dans le journal Sécurité le 4624 avec un type d’ouverture 5 (une ouverture de session de service) rattaché au compte, plus le 4672 quand cette ouverture s’est vu accorder des privilèges sensibles. Activez l’audit lié aux services et cela devient une chronologie:

auditpol /set /subcategory:"Security System Extension" /success:enable /failure:enable
Get-WinEvent -FilterHashtable @{LogName='System'; ID=7045}

Où atterrir

Préférez l’identité dont aucun humain ne détient le mot de passe: un SID de service intégré pour le travail isolé, un compte virtuel quand il lui faut ses propres ACL, un gMSA dès qu’il lui faut une identité de domaine. Accordez le droit de logon de service, refusez tout chemin d’ouverture interactif et réseau, cantonnez les droits fichiers et registre au SID propre du service et donnez à chaque service une identité distincte pour que les logs puissent les distinguer. Le compte local à mot de passe statique est celui dont il faut migrer, pas celui qu’il faut perfectionner et sa seule durée de vie correcte est “jusqu’à ce que le gMSA existe”.