Silverfort Protection contre l'exploit Bronze Bit CVE-2020-17049 - Mise à jour

***** Par Yiftach Keshet, directeur du marketing produit et Dor Segal, chercheur en sécurité Silverfort   *****

Le 8 décembre, le nouveau Mors en bronze exploit de CVE-2020-17049 Vulnérabilité Kerberos a été rendue publique, ajoutant une autre arme de pointe à l'arsenal post-compromis des attaquants. Bien que le correctif complet de cette vulnérabilité ne soit pas appliqué avant le 8 février 2021, Silverfortest unifié Protection d'identité La plate-forme offre une protection complète contre l'attaque Bronze Bit. Grâce à sa capacité unique à appliquer la MFA et les contrôles d'accès adaptatifs sur Active Directory protocoles d'authentification, Silverfort introduit un nouveau paradigme sur défense contre les attaques de mouvement latéral in Active Directory environnements. Une analyse détaillée des types de délégation, CVE-2020-17049 et le correctif Microsoft a été réalisée par SilverfortChercheur en sécurité – Dor Segal et c'est disponible ici.

Le cheminement vers une délégation sécurisée

CVE-2020-17049 permet à un attaquant de contourner le Délégation limitée par les ressources contrôle de sécurité de l'authentification.

En général, Délégation fait référence à la capacité de Active Directory compte pour usurper l'identité ou agir au nom d'un autre compte, afin d'accéder aux ressources avec les privilèges d'accès de l'autre compte. Un exemple courant est lorsqu'un utilisateur accède à une application Web : bien qu'il semble que l'utilisateur accède directement à l'application Web, ce qui se passe dans le backend est que le compte d'utilisateur délègue ses privilèges d'accès à un compte de service qui usurpe l'identité de l'utilisateur et accède à la base de données de l'application au nom de l'utilisateur.

Du point de vue de la sécurité, la préoccupation est de savoir ce qui se passe si ce mécanisme est abusé par un attaquant. Le premier mécanisme de délégation proposé dans AD, également connu sous le nom de délégation sans contrainte, introduisait un risque important car il permettait au service d'emprunt d'identité d'accéder à toutes les ressources auxquelles le compte délégant pouvait accéder.

Cette préoccupation a conduit à une évolution progressive de la délégation au fil des années comme le montre ce tableau :

Comme on peut le voir clairement dans le tableau, chaque génération réduit le risque en diminuant sensiblement le nombre de comptes délégués, de services d'emprunt d'identité et de ressources accessibles. Bien que le scénario d'un attaquant effectuant une délégation malveillante soit toujours possible, ses implications en termes d'accès aux ressources sont considérablement réduites.

Délégation limitée en ressources sont le type de délégation le plus sécurisé, ils sont donc actuellement la norme utilisée dans la plupart des Active Directory environnements.

Maintenant que nous avons un aperçu de la délégation, nous pouvons comprendre l'impact de l'exploit Bronze Bit.

L'attaque du bit de bronze - Altération des contrôles de sécurité de la délégation

L'attaque Bronze Bit utilise la vulnérabilité CVE-2020-17049 pour permettre à un attaquant d'effectuer ce qui suit (extrait et modifié à partir du blogue):

'Un attaquant peut usurper l'identité d'utilisateurs qui ne sont pas autorisés à être délégués. Cela inclut les membres du groupe Utilisateurs protégés et tous les autres utilisateurs explicitement configurés comme "sensibles et ne peuvent pas être délégués"

Cette attaque nous ramène donc en termes d’exposition au risque, augmentant la surface d'attaque à pratiquement tous les comptes d'utilisateurs de l'environnement.

Activités d'atténuation de Microsoft CVE-2020-17049

Microsoft a publié un pièce pour cette vulnérabilité dans le cadre du Patch Tuesday du 8 novembre. Cependant, en raison de divers Problèmes d'authentification Kerberos a nouveau patch a été rendu disponible le 8 décembre. Ce correctif offre aux entreprises une protection contre l'exploitation de la vulnérabilité jusqu'à l'application complète de la Kerberos correctif de protocole, qui aura lieu le 8 février 2021. Compte tenu des difficultés typiques liées aux correctifs de sécurité des serveurs en général et aux contrôleurs de domaine en particulier, il est probable que malgré la disponibilité des correctifs, tout le monde ne les déploie pas immédiatement. Il existe donc actuellement une exposition au risque importante pour ces organisations.

Silverfort Protection contre les attaques basées sur la délégation

Silverfort Unified Identity Protection Platform est la seule solution qui consolide la surveillance, analyse de risque et l'application des politiques d'accès pour toutes les authentifications d'utilisateurs et de comptes de service sur tous les réseaux d'entreprise et environnements cloud.

Grâce à sa technologie innovante sans agent et sans proxy, Silverfort peut s'étendre MFA à un large éventail de ressources qui ne pouvaient pas être protégées auparavant. Cela inclut bien sûr toute authentification qui utilise le protocole Kerberos.

Et il est important de noter que lors de la mise en place a Silverfort stratégie pour un utilisateur, les contrôles de sécurité de la stratégie s'appliquent à la fois aux authentifications directes et déléguées effectuées par l'utilisateur. Voyons comment cela s'applique à la protection des déléguants et des non-déléguants. des comptes d'utilisateurs ou administrateurs.

Protection contre l'attaque Bronze Bit – délégation de comptes

En pratique, les comptes délégants (c'est-à-dire les comptes configurés pour autoriser la délégation) sont déjà protégés par défaut en raison de Silverfortla surveillance continue de Active Directory des protocoles d'authentification, qui identifient automatiquement ces comptes et intègrent la délégation dans leur score de risque.

Ainsi, la stratégie basée sur les risques suivante déclencherait une exigence MFA chaque fois qu'une tentative d'authentification anormale aura lieu :

Chaque fois que la tentative d'authentification d'un tel compte dépasse moyenne score de risque, une exigence MFA apparaîtra pour l'utilisateur. Si l'authentification a été faite par un attaquant effectuant une délégation malveillante pour le compte de ce compte, le propriétaire du compte peut bloquer l'accès en confirmant qu'il ne s'agit pas de sa demande.

Protection contre l'attaque Bronze Bit – comptes non délégués

Mais comment protéger les comptes utilisateurs qui ne sont pas configurés pour la délégation ? La politique basée sur le risque ne suffira pas ici, puisque ces comptes n'incluent pas le facteur de délégation, une approche différente est donc nécessaire.

Récapitulons - le scénario que nous voulons atténuer est le suivant : un attaquant a compromis un compte de service - appelons-le 1 compte. L'attaquant veut accéder à une ressource sensible - appelons-la ressource 1 – mais ne peut pas le faire avec les privilèges d'accès de 1 compte. Avec l'exploit Bronze Bit, l'attaquant peut utiliser 1 compte usurper l'identité d'un compte hautement privilégié que nous appellerons 2 compte qui est configuré pour ne pas autoriser la délégation (par exemple, tout membre du Groupe d'utilisateurs protégés), afin d'accéder ressource 1.

Compte 1 se fait passer pour 2 compte pour accéder ressource 1. Dans les coulisses, avant d'accéder ressource 1, 2 compte s'authentifie auprès de 1 compte afin de fournir utilisateur 1 la capacité d'agir en son nom. Maintenant, 1 compte doit être un service configuré pour autoriser l'emprunt d'identité. Étant donné que tous les services configurés pour le faire sont déjà connus (après tout, ils ont été configurés par l'équipe d'administration du domaine), tout ce dont nous avons besoin est la politique suivante :

Les « comptes sans délégation » représentent tous les comptes d'utilisateurs configurés pour ne pas déléguer, tandis que les « comptes de service d'emprunt d'identité » représentent tous les les comptes de service qui sont configurés pour autoriser l'emprunt d'identité. Alternativement, si nous voulons refuser la délégation uniquement et toujours accéder à la ressource, ils peuvent utiliser le champ "Source" pour limiter uniquement l'accès à la délégation.

Dans ce cas, nous vous recommandons d'attribuer 'Refuser' comme action de protection : étant donné que ces comptes ne doivent jamais interagir avec la délégation les comptes de service, aucune perturbation opérationnelle ne devrait se produire.

Cette protection altère totalement l’attaque Bronze Bit. Même si l'attaquant parvenait à forcer un tir haut compte privilégié tenter une délégation, Silverfort empêchera son engagement réel avec un compte de service usurpant l'identité.

Silverfort protection contre l'exploit Bronze Kit démontre une fois de plus comment l'application d'un contrôle d'accès adaptatif à Active Directory protocoles d'authentification, et plus particulièrement aux outils de ligne de commande d'accès à distance que les attaquants utiliseraient pour lancer l'attaque Bronze Kit, est impératif pour fournir une protection suffisante contre mouvement latéral attaques.

En savoir plus sur Silverfort ici