Nouveaux chemins d'attaque ? Billets de service demandés par AS

Jul 18, 2023

Accueil » Cybersécurité » Actualités SBN » Nouveaux chemins d'attaque ? Billets de service demandés par AS

En aidant Andrew Schwartz avec son article Kerberos FAST (qui contient plus d'informations sur ce qu'est FAST et son fonctionnement, alors lisez-le), j'ai remarqué quelque chose d'intéressant. Les AS-REQ pour les comptes de machine ne sont pas blindés. Ceci est décrit par Microsoft ici :

Le blindage Kerberos utilise un ticket d'octroi de tickets (TGT) pour l'appareil afin de protéger les échanges du service d'authentification avec le KDC, de sorte que l'échange du service d'authentification de l'ordinateur n'est pas blindé. Le TGT de l'utilisateur est utilisé pour protéger ses échanges TGS avec le KDC.

Cela m'a amené à me demander s'il était possible de demander des tickets de service (ST) au service d'authentification (AS). La possibilité de demander des ST à l'AS a plusieurs conséquences, notamment de nouveaux chemins d'attaque, des contournements de détection et un affaiblissement potentiel des contrôles de sécurité. Tous les problèmes abordés dans cet article ont été signalés à Microsoft et ont été "considérés comme étant de par leur conception" (Figure 1).

Tout d'abord, voici un aperçu de haut niveau du flux Kerberos typique (Figure 2, provenant d'ADSecurity) :

Le fait qu'une clé de session soit émise pour chaque ticket est une caractéristique importante pour la recherche suivante. Cette clé de session est renvoyée au compte demandeur dans une section chiffrée de la réponse ; la clé de chiffrement est déjà connue du demandeur.

Par exemple, la clé de session TGT est stockée dans une section chiffrée avec la clé utilisée pour prouver l'identité du demandeur lors de la demande d'un TGT. Cette clé est normalement la clé à long terme (hachage du mot de passe) du compte. Mais dans le cas de la cryptographie à clé publique pour l'authentification initiale (PKINIT) dans le protocole Kerberos, la clé est dérivée du certificat. La clé de session ST est stockée dans une section chiffrée avec la clé de session TGT.

La clé de session de ticket est requise pour utiliser le ticket à l'étape suivante du flux Kerberos.

Une requête Kerberos comporte deux sections principales :

Le req-body est envoyé principalement en clair et contient plusieurs informations :

Une réponse Kerberos comporte plusieurs sections et contient une partie chiffrée :

La partie du flux Kerberos sur laquelle cet article se concentre est AS-REQ/AS-REP, qui est généralement utilisé pour demander un TGT. Dans des opérations normales, un AS-REQ a une des deux valeurs dans sondécollechamp à l'intérieur du corps req :

J'ai remarqué qu'avec l'application de Kerberos Flexible Authentication Secure Tunneling (FAST), les comptes de machines envoyaient toujours leurs AS-REQ non blindés. Je me demandais si un AS-REQ pouvait être utilisé pour demander directement un ST, plutôt qu'un TGT. Cela m'a amené à modifier Rubeus pour déterminer si la spécification d'un autre SPN dans ledécolle d'un AS-REQ amènerait le DC à répondre avec un ST pour ce SPN. Il s'avère que la réponse était "oui" (Figure 3).

En utilisant un compte machine, je peux demander un ST sans utiliser de blindage lorsque FAST est appliqué. Quoi d'autre est possible?

Kerberoasting, découvert par Tim Medin, est une méthode pour récupérer le mot de passe en clair ou le hachage NT pour un compte de service, généralement un compte d'utilisateur avec un SPN. Le Kerberoasting est possible car une partie d'un ST est chiffrée avec la clé à long terme du compte de service (hachage du mot de passe). En extrayant la partie chiffrée du ticket, il est possible de former un hachage à partir de différents mots de passe en clair et de tenter de déchiffrer la partie chiffrée. Si le déchiffrement réussit, le hachage utilisé est la clé à long terme utilisée pour chiffrer le ticket. Cette clé peut ensuite être utilisée pour s'authentifier en tant que compte de service.

De plus, n'importe quel compte peut demander un ST pour n'importe quel service. Par conséquent, la possibilité de s'authentifier auprès d'Active Directory (AD) est nécessaire pour effectuer l'attaque. Au moins, c'était vrai.

Tout d'abord, j'ai essayé d'utiliser un compte qui ne nécessitait pas de pré-authentification (DONT_REQ_PREAUTH) pour demander un ST. Lorsqu'un compte ne nécessite pas de pré-authentification pour s'authentifier, un TGT peut être demandé sans nécessiter de données de pré-authentification, qui sont chiffrées avec une certaine forme d'informations d'identification (par exemple, hachage de mot de passe, certificat). Si un attaquant n'a pas obtenu d'informations d'identification valides pour un compte, une pré-authentification valide ne peut pas être générée. Si la pré-authentification n'est pas requise, ce n'est pas un problème.

Lorsqu'un ticket est demandé sans pré-authentification, le résultat comporte toujours une partie chiffrée. Cette partie cryptée est cryptée avec la clé d'identification utilisée pour l'authentification et contient la clé de session pour le ticket inclus dans la réponse. Il s'agit des données cryptées utilisées dans l'attaque ASREPRoast de Will Schroeder. Le TGT résultant n'est utilisable qu'avec l'accès à la clé de compte demandeur, puisque la clé de session TGT est requise.

Cependant, pour Kerberoasting, l'accès à la clé de session n'est pas requis. Seule la ST résultante, ou plus précisément la partie chiffrée de la ST, qui n'est pas sécurisée avec la clé du compte demandeur, est requise. Par conséquent, si un compte est configuré pour ne pas nécessiter de pré-authentification, il est possible de Kerberoast sansn'importe quel crédits. Cette méthode de Kerberoasting a été implémentée dans Rubeus au sein de ce PR.

Étant donné que l'accès à un compte valide n'a pas encore été obtenu, LDAP ne peut pas être interrogé. Au lieu de cela, une liste de comptes de service potentiels est requise. Des recherches antérieures d'Arseniy Sharoglazov montrent que les ST peuvent être demandés en utilisant uniquement le nom d'utilisateur du compte de service plutôt que d'exiger le SPN réel, ce qui est très utile pour cette recherche.

Une liste de noms d'utilisateur peut être générée de plusieurs manières, y compris l'énumération des utilisateurs à l'aide de sessions nulles sur un contrôleur de domaine, la génération d'une liste de noms d'utilisateur à l'aide de l'intelligence open source (OSINT) ou la supposition de noms d'utilisateur potentiels. Toute liste de noms d'utilisateurs potentiels peut être facilement vérifiée en envoyant un AS-REQ sans pré-authentification. Un nom d'utilisateur valide qui nécessite une pré-authentification reçoit unKDC_ERR_PREAUTH_REQUIREDerreur (Figure 4).

Un nom d'utilisateur valide qui ne nécessite pas de pré-authentification reçoit un TGT (Figure 5).

Un nom d'utilisateur invalide reçoit unKDC_ERR_C_PRINCIPAL_UNKNOWNerreur (Figure 6).

À des fins de démonstration, une liste est générée à l'aide d'une session nulle sur le DC, à l'aide de la méthode de cycle RID (-R) d'enum4linux-ng, comme le montre la figure 7.

À l'aide de cette liste de noms d'utilisateur, il est facile de déterminer les comptes qui ne nécessitent pas de pré-authentification dans AD (Figure 8).

Notez que les AS-REQ sans pré-authentification ne sont pas consignés en tant qu'événement Windows à moins que le compte ne nécessite pas de pré-authentification.

Avec la liste des noms d'utilisateur et le nom d'utilisateur d'un compte qui ne nécessite pas de pré-authentification, l'attaque peut être lancée (Figure 9).

La sortie résultante peut ensuite être utilisée pour tenter de casser un mot de passe hors ligne.

Une autre conséquence intéressante est la capacité de Kerberoast à partir d'une position Man-in-the-Middle (MitM). Ce type d'attaque n'est généralement pas possible avec les TGS-REQ car lecksum dans l'authentificateur à l'intérieur de l'AP-REQ protège le corps de requête de la demande et est fréquemment inclus par les clients Windows Kerberos authentiques. Par conséquent, la modification de ladécolled'un TGS-REQ sans mettre à jour la somme de contrôle dans l'authentificateur invalide la somme de contrôle de l'authentificateur et renvoie uneKRB_AP_ERR_MODIFIED erreur. Mais ce n'est pas un problème pour les AS-REQ car lereq-corps, et par conséquent ladécolledomaine, ne sont pas protégés.

En testant cette approche, j'ai découvert que les AS-REQ peuvent être rejoués plusieurs fois. Un attaquant n'a besoin de capturer qu'un seul AS-REQ pour envoyer un grand nombre d'AS-REQ avec différentsdécollevaleurs.

Pour démontrer cette approche, j'ai écrit une preuve de concept (POC). Ce POC, RoastInTheMiddle, implémente une usurpation ARP entre les contrôleurs de domaine et les systèmes victimes pour effectuer une attaque MitM. Le POC transmet ensuite le trafic tout en écoutant les AS-REQ. Lorsqu'une AS-REQ est trouvée, le POC exécute un Kerberoast. Le POC n'est pas prêt pour l'attaque mais démontre qu'une attaque est possible.

Tout d'abord, le POC démarre quatre threads, un renifleur, un spoofer ARP, un réassembleur (pour les requêtes réparties sur plusieurs paquets) et le torréfacteur (Figure 10).

Lorsqu'il voit une AS-REQ, le POC commence à essayer d'ajouter Kerberoast à la liste fournie, qui peut contenir des noms d'utilisateur ou des SPN (Figure 11).

Comme le montre la figure 11, cette tentative entraîne la sortie de tous les ST reçus au format hashcat, prêts pour le craquage de mot de passe hors ligne.

La possibilité de MitM AS-REQ, puis de les modifier et de les rejouer, pourrait également être utile pour développer d'autres attaques. J'ai essayé de modifier les options kdc pour inclure leà proximitédrapeau, qui se traduit par un ticket avec leà proximité ensemble de drapeaux. Cependant, je n'ai pas pu trouver de chemin d'attaque en utilisant ce ticket et ce drapeau. Ce comportement peut également permettre l'utilisation d'autres comptes pour effectuer un Kerberoast, permettant aux attaquants d'éviter de graver un compte compromis.

Certaines améliorations pourraient être possibles pour ce processus. Tout d'abord, il est possible de contraindre un AS-REQ à partir d'un TGS-REQ en l'interceptant et en répondant avec unKRB_AP_ERR_BAD_INTEGRITY erreur. Cela force le client à se réauthentifier en envoyant un AS-REQ.

Il devrait également être possible d'effectuer cette attaque en utilisant l'injection de serveur de noms DHCPv6 (comme mitm6 de Dirk-jan Mollema ou Inveigh de Kevin Robertson), en répondant aux requêtes DNS SRV pour le service LDAP, puis en traitant la connexion LDAP suivante.

Prise en charge de la modification de laetypesdans la demande permet des attaques de type de cryptage inférieur lorsque l'environnement le permet, comme décrit par Will Schroeder ici.

Enfin, le POC nécessite l'installation de Npcap sur le système exécutant le POC (qui utilise sharppcap), principalement pour l'usurpation d'ARP. Si vous prenez la route IPv6 ou implémentez les réponses ARP à l'aide de sockets bruts, vous pouvez supprimer cette dépendance.

De nombreuses détections Kerberos reposent sur 4769 événements (un ticket de service Kerberos a été demandé). Cependant, la demande d'un ticket de service à l'aide d'un AS-REQ ne produit pas 4769 événements mais plutôt 4768 événements (un ticket d'authentification Kerberos (TGT) a été demandé).

La figure 12 montre un événement 4768 lorsqu'une ST est demandée à l'aide d'une AS-REQ.

Par conséquent, les attaquants utilisant cette méthode peuvent facilement contourner de nombreuses détections qui reposent sur 4769 événements.

Bien que je n'aie pas été en mesure de demander des tickets S4U2self à l'AS, les ST récupérés de l'AS n'ont pas la somme de contrôle des tickets (apportée pour protéger les tickets S4U2self contre l'attaque du bit de bronze par Jake Karnes).

Enfin, une ST demandée au TGS est généralement renvoyée avec un PAC (Figure 13).

Il est possible de demander une ST sans PAC au TGS, mais cela nécessite de changer les comptes de serviceNO_AUTH_DATA_REQUIREDbit dans l'attribut useraccountcontrol (Figure 14).

Lorsque cette configuration est en place, le ST retourné n'a pas de PAC, comme le montre la différence de taille du ticket retourné (Figure 15).

Une ST sans PAC peut être demandée à l'AS simplement en définissant la section de données PA-PAC-OPTIONS PA sur faux en ajoutant le/nopacpasser à Rubeus (Figure 16).

Cette approche peut être utilisée comme alternative à la création de tickets argent, en demandant un ST sans PAC, puis en injectant un autre PAC en l'incluant dans leenc-autorisation-données partie de la demande. Cela pourrait également fournir d'autres chemins d'attaque potentiels.

Étant donné que Microsoft ne trouve apparemment pas que ces problèmes méritent d'être résolus, la détection au sein de votre organisation est la seule option. Comme indiqué précédemment, lorsqu'un ST est demandé à partir de l'AS, l'événement 4768 est enregistré (Figure 17).

Dans cet événement, vous pouvez voir que le nom du service et l'ID du service ne sont paskrbtgt.Tous les tickets authentiques demandés à l'AS, y compriskadmin/changepwtickets, avoir un nom de service et un identifiant de service dekrbtgt(Figure 18).

Vérification du trafic réseau pour les AS-REQ qui ne sont pas pour lekrbtgt/domaineoukadmin/changepwdevrait également détecter ces demandes (Figure 19).

Cette recherche, ainsi que la réponse de Microsoft, démontrent la nécessité d'une surveillance continue et de mesures de renforcement appropriées. La possibilité de contourner les détections actuelles et d'effectuer des attaques efficaces, comme Kerberoasting, à partir d'une position non authentifiée est un problème sérieux qui ne doit pas être ignoré. La recherche décrite ici pourrait conduire à de nouvelles attaques inédites, exposant potentiellement les organisations à un risque plus élevé.

Assurez-vous que les détections sont en place lorsque ces types de demandes de tickets sont effectués.

J'aimerais remercier les personnes suivantes pour leurs contributions à cette recherche :

Le post Nouveaux chemins d'attaque ? AS Requested Service Tickets est apparu en premier sur Semperis.

*** Il s'agit d'un blog syndiqué du Security Bloggers Network de Semperis rédigé par Charlie Clark. Lisez le message original sur : https://www.semperis.com/blog/new-attack-paths-as-requested-sts/