Que S’Est-Il Passé ?

Le 13 juillet, Microsoft a publié CVE-2021-33757, qui a activé le cryptage AES par défaut pour la connexion au protocole distant pour MS-SAMR afin d’atténuer la rétrogradation en RC4, qui a exposé les données via un cryptage non sécurisé. Microsoft a ensuite publié un correctif pour la vulnérabilité, KB5004605, qui a apporté des modifications liées au protocole MS-SAMR. Microsoft a indiqué dans la documentation du correctif :

Après l’installation des mises à jour Windows du 13 juillet 2021 ou des mises à jour Windows ultérieures, le chiffrement AES (Advanced Encryption Standard) sera la méthode préférée des clients Windows lors de l’utilisation du protocole MS-SAMR hérité pour les opérations de mot de passe si le chiffrement AES est pris en charge par le serveur SAM.

Le 19 juillet, une vulnérabilité a été découverte dans Windows 10 qui permet aux non-administrateurs d’accéder à la base de données du Gestionnaire de comptes de sécurité (SAM), qui stocke les mots de passe des utilisateurs, selon Kevin Beaumont (utilisateur de Twitter @GossiTheDog). Kevin Beaumont a surnommé la vulnérabilité HiveNightmare alias SeriousSam.

Oh mon dieu. Je dois le valider moi-même, mais il semble que MS ait pu gaffer et rendre la base de données SAM (mots de passe des utilisateurs) accessible aux utilisateurs non administrateurs dans Win 10. https://t.co/cdxiH1AIuB

— Kevin Beaumont (@GossiTheDog) Juillet 19, 2021

Cela a été confirmé pour la dernière version de Windows 10, selon Benjamin Delpy, créateur de MimiKatz (utilisateur de Twitter @gentilkiwi).

Il semble également apparaître sur Windows 10 mis à jour vers une autre version de Windows 10…

Vérifiez si vous avez activé la copie fantôme pour la protection du système… (mais c’est activé par défaut…)

Conclusion: Mise à jour de Windows 10 (ou version 11) + Protection du système activée (par défaut) = vulnérable

— Benjamin Benjamin Delpy (@gentilkiwi) Juillet 19, 2021

La ruche SYSTÈME a également été exposée lors du changement d’ACL de Microsoft vers Windows, ce qui signifie que toutes les informations d’identification sont exposées sous leur forme hachée.

À quel point est-Ce Grave?

Les fichiers de base de données d’informations d’identification SYSTÈME et SAM ont été mis à jour pour inclure le jeu d’ACL en lecture pour tous les utilisateurs de certaines versions de Windows. Cela signifie que tout utilisateur authentifié a la capacité d’extraire ces informations d’identification mises en cache sur l’hôte et de les utiliser pour le craquage hors ligne ou pour passer le hachage en fonction de la configuration de l’environnement. Cela n’a été identifié que sur les points de terminaison Windows 10 mis à jour à ce stade, cependant, il est possible que les serveurs Windows aient été affectés.

Les constructions suivantes ont été identifiées comme touchées jusqu’à présent:

• 1809 ISO-Juin21-20H2
• 1909 ISO-Juin21-20H2
• 20H2 ISO-orig-21H1
• 21H1 ISO–Juin21-11 Insider (Windows 11)

Vous pouvez identifier votre build en regardant winver dans Run (Win + R)

Au 20/07/21, ce modèle d’attaque a été prouvé et constitue un chemin d’escalade de privilèges potentiel pour les attaquants. Si un administrateur d’ordinateur ou de domaine s’est récemment connecté à un hôte affecté par cette modification, ses informations d’identification hachées seront mises en cache sur l’hôte dans ces fichiers. Cela pourrait potentiellement donner à un attaquant un accès complet à votre environnement sans nécessiter d’escalade vers l’administrateur pour accéder à ces informations d’identification.

Que Dois-Je Faire?

Nous vous recommandons d’attendre que Microsoft publie les étapes de correction. En attendant, vous pouvez faire quelques choses:

• Surveillez l’accès SAM sur l’hôte lui-même pour déterminer si un attaquant tente de vider et d’escalader.
• Préparez-vous à corriger lorsque Microsoft a publié son correctif ou son atténuation pour ce problème. C’est le moyen le plus sûr de répondre à ce problème car Microsoft devra dérouler les modifications ACL qu’ils ont ajoutées.
• Si la machine est critique pour votre environnement du point de vue de la sécurité, réinitialisez les ACL par défaut dans le dossier concerné. Cette action comporte un certain risque, car vous modifierez les listes de contrôle d’accès définies par la mise à jour Windows. Cependant, jusqu’à présent dans nos tests, cela n’a pas eu d’impact négatif sur l’hôte, mais cela ne signifie pas qu’il n’aura pas d’impact sur les machines des autres en fonction de la configuration.
  • À partir d’une ligne de commande Powershell d’administrateur
    Get-ChildItem -File -Force $env:WINDIR\system32\config | ForEach-Object { icacls $_.FullName /reset

Comment détecter

Blumira recommande de surveiller les actions contre le système HKLM, la sécurité et les bases de données SAM sur tous les systèmes. En raison de ce changement incorrect d’ACL par Microsoft, il est désormais encore plus prioritaire de surveiller ces actions. Voici un exemple d’utilisation de Sysmon pour surveiller reg.actions exe contre les fichiers Système, de sécurité ou SAM.

Cela peut nécessiter des modifications en fonction de votre SIEM, par exemple, des barres obliques d’échappement et un formatage de correspondance regex. Les clients Blumira qui utilisent Sysmon auront déjà cette règle déployée dans leurs environnements.

windows_log_source="Microsoft-Windows-Sysmon" AND process_name LIKE "%reg.exe%" AND REGEXP_CONTAINS(command, "HKLM\\system|HKLM\\security|HKLM\\sam")

Blumira recommande également de surveiller WMIC, Shadow-Copy et toutes les actions qui impliqueraient l’instanciation de Mimikatz, qui peuvent toutes tirer parti de cette exposition.

Mise à jour du 21/07/21 (avec l’aimable autorisation de l’utilisateur Reddit u/eider96)

• Cela n’a rien à voir avec KB5004605
• L’accès RX pour les utilisateurs de BU \ ne permet pas un accès direct à ces fichiers car ils sont protégés, ils ne sont accessibles que si un instantané VSS a déjà été réalisé avec ces fichiers (ce qui est une action par défaut étant donné que l’historique des fichiers ou la restauration du système sont activés). Les utilisateurs non privilégiés peuvent tirer parti de ces instantanés et utiliser les autorisations inappropriées pour en extraire des fichiers. Les autorisations d’administrateur ne sont pas nécessaires pour lire l’instantané, elles sont directement accessibles via \?\GLOBALROOT\Device\HarddiskVolumeShadowCopy{$N} où {NN} est le numéro de l’instantané. Les administrateurs peuvent lister tous les instantanés en utilisant vssadmin list shadows.
• L’extrait de code PS fourni n’est pas destiné à sécuriser le système seul. Considérez également les instantanés existants et supprimez-les ou acceptez le risque et laissez-les être écrasés au fil du temps.
• Étant donné que les fichiers peuvent être copiés hors ligne à partir de l’instantané VSS, puis inspectés manuellement ou chargés sur un système séparé, la surveillance des actions contre ces ruches n’est pas garantie de fournir des résultats significatifs par rapport à cette vulnérabilité spécifique – il n’y a aucune raison de modifier ou de charger la ruche en ligne afin d’extraire les informations d’identification mises en cache à partir de fichiers récupérés.

Mise à jour 7/21/21 (avec l’aimable autorisation de l’utilisateur Reddit u/Oscar_Geare):

Microsoft a publié un CVE pour cette vulnérabilité. Dans le CVE, ils identifient que cela affecte toutes les versions 1809 et plus récentes. De plus, une solution de contournement est disponible:

• Restreindre l’accès au contenu de %windir%\system32\config

  • Ouvrez l’invite de commandes ou Windows PowerShell en tant qu’administrateur.

  • Exécutez cette commande: icacls %windir%\system32\config\*.* /inheritance:e

• Supprimer les copies fantômes du Service de copie fantôme de volume (VSS)

  • Supprimez tous les points de restauration du système et les volumes d’ombre qui existaient avant de restreindre l’accès à %windir%\system32\config.

  • Créez un nouveau point de restauration du système (si vous le souhaitez).

Nos commentaires (7/21/21):

Supprimez uniquement les shadow copies avec un certain niveau de connaissances dont vous n’avez pas besoin. La validation des sauvegardes est idéale et vous pouvez utiliser vssadmin list shadows pour voir la plupart de vos copies fantômes.

Étant donné que la crédibilité des correctifs de Microsoft a pris un grand coup au cours des dernières semaines, ce n’est pas une mauvaise idée de tester le correctif une fois implémenté.

Mise à jour – Détections et prospective (21/07/21 à 12h:45 PM HE)

Étant donné que les changements d’ACL survenus au sein de l’hôte ont empoisonné le VSS, vous pouvez prendre certaines mesures pour sécuriser un système. Cela inclut la suppression des instantanés VSS une fois que les ACL ont été résolues — ou du moins, la protection de ces instantanés VSS jusqu’à ce qu’ils soient corrigés et remplacés par de nouveaux instantanés.

Blumira teste et met actuellement en œuvre trois détections distinctes pour cela, dont l’une est plus tournée vers l’avenir pour assurer la visibilité des fichiers hive vivant à l’intérieur du VSS. Ces détections nécessitent Sysmon ou que vous ayez défini un audit avancé sur les hôtes à l’aide de GPO tels que Logmira de Blumira.

• Identification des exécutions HiveNightmare basées sur des modèles de chaînes codés en dur à l’aide de Sysmon. Cela sera facile à éviter pour de nombreux attaquants, mais permettra d’identifier la réutilisation des attaques existantes.
  type='windows' AND windows_log_source='Microsoft-Windows-Sysmon' AND windows_event_id in (1,5,11) AND ((process_name LIKE '%HiveNightmare%') or (regexp_contains(target, '(?i)S.*haxx$')))

• Identification de Powershell faisant référence à des fichiers Hive sensibles dans VSS à l’aide de la journalisation des blocs de script. Cela suppose que votre bloc de script se connecte à la colonne info et utilise l’insensible à la casse (?i) drapeau. * Nécessite l’activation de la journalisation des blocs de script pour Powershell.*
  type='windows' AND windows_event_id=4104 AND REGEXP_CONTAINS(info, r'(?i)\GLOBALROOT\Device\HarddiskVolumeShadowCopy\d{1,2}\Windows\System32\config\(system|security|sam)')

• Identification de la lecture des fichiers de ruche sensibles par tout le monde sur l’hôte à l’aide de SACL qui circulent dans VSS. Cela permet une augmentation significative de la visibilité de tout accès à la ruche lors de nos tests jusqu’à présent. Cela ne changera pas votre VSS existant jusqu’à ce qu’un autre point de restauration soit enregistré. * Nécessite l’activation du GPO d’accès aux objets (RE Logmira) et l’exécution du Powershell suivant pour activer cette détection.*
  type='windows' AND windows_event_id=4663 AND REGEXP_CONTAINS(object_name, r'(?i)Device\HarddiskVolumeShadowCopy\d\Windows\System32\config\(system|security|sam)')
  Vous devrez également exécuter le Powershell suivant pour activer le SACL d’audit sur les fichiers hive qui seront ensuite adoptés par VSS. Ce script ajoute la règle d’audit de réussite de ReadData pour tout le monde, permettant une large visibilité future sur tous les utilisateurs, autorisés ou non, accédant aux fichiers hive.
  $files = @("C:\Windows\System32\config\system","C:\Windows\System32\config\sam","C:\Windows\System32\config\security")

• Foreach ($file in $files){ $acl = Get-ACL $file; $auditRule = New-Object System.Security.AccessControl.FileSystemAuditRule("Everyone", "ReadData", "Success"); $ACL.SetAuditRule($auditRule); $acl | Set-Acl $file; Write-Host "Getting ACL for $file, Audit column should state Everyone Success ReadData"; Get-ACL $file -Audit | Format-List }

Ressources supplémentaires

• GitHub de Matthew Warner
• GitHub SigmaHQ

Essayez Blumira gratuitement

Blumira peut détecter les activités liées au système HKLM, à la Sécurité et aux bases de données SAM, ainsi que de nombreux autres incidents de sécurité.

L’essai gratuit de Blumira est facile à déployer ; les équipes informatiques et de sécurité peuvent commencer à voir une valeur de sécurité immédiate pour leurs organisations.

Inscrivez-vous à un essai gratuit pour commencer à détecter et à atténuer l’exposition aux vulnérabilités Windows: