Wie Azure AD neue Authentifizierungsrisiken eröffnet

Es ist seit Jahren bekannt, dass lokale Windows Active Directories für NTLM-Relay- und Pass-the-Hash-Angriffe anfällig sind. Auf diese Weise können sich Angreifer seitlich durch ein Netz bewegen und auf zusätzliche Rechner und Ressourcen zugreifen. Einige dieser Angriffe nutzen grundsätzliche Design-Schwächen in den Authentifizierungsprotokollen aus, die in Windows-Netzen verwendet werden. Deshalb kann Microsoft diese Schwachstellen nicht einfach durch Softwareänderungen/Patches beheben. Deshalb müssen Unternehmen tiefgehendere Maßnahmen ergreifen, die strengere Konfigurationen und zusätzliche Kontrollen beinhalten, um sich besser zu schützen.

Mit der Einführung von hybriden Netzen – also der Kombination von lokalen Netzen und Cloud –, setzen Unternehmen mittlerweile auf Dienste wie Azure Active Directory (Azure AD), um die Authentifizierung der verschiedenen Rechner untereinander zu ermöglichen. Allerdings unterscheidet sich Azure AD deutlich von einem lokalen AD. So verwendet Azure AD andere Protokolle und offeriert neue Funktionen, die die Netzwerkmöglichkeiten von Unternehmen erweitern. Gleichzeitig eröffnen die Features aber auch neue Angriffsmöglichkeiten, wie auf der US-Security-Messe Black Hat kürzlich gezeigt wurde.

Von "Pass-the-Hash" zu "Pass-the-Certificate"

Bei Pass-the-Hash handelt es sich um einen Angriff, bei dem Hacker gehashte Versionen lokal gespeicherter Anmeldedaten von einem kompromittierten Rechner extrahieren und zur Authentifizierung bei anderen Rechnern verwenden. NTLM-Relay ist eine Methode, bei der Authentifizierungsanfragen zwischen einem Client und einem Server abgefangen werden. Anstelle des Clients wird nun der Angreifer authentifiziert. Diese Angriffsmethoden werden häufig von raffinierten Hackergruppen für gezielte Angriffe verwendet.

Diese traditionellen Pass-the-Hash- und Relay-Angriffe funktionieren jedoch mit Azure AD nicht, da Azure AD weder NTLM noch Kerberos verwendet, die Standard-Authentifizierungsprotokolle in Windows-Netzen. Stattdessen verwendet es OAuth, SAML, OpenID und ein neues Protokoll namens NegoEx. Dabei handelt es sich um eine Erweiterung des standardisierten Generic Security Services Application Program Interface (GSSAPI), auf dem Kerberos basiert.

Laut dem Microsoft-Forscher Mor Rubin wird NegoEx auf jedem Gerät aktiviert, das mit Azure AD verbunden ist. Darüber lassen sich verschiedene mit Azure AD verbundene Geräte gegenseitig authentifizieren. Der NegoEx-Authentifizierungs-Handshake stützt sich auf ein Client-Zertifikat, das für jeden Benutzer einzigartig ist und von Azure AD mit einer Gültigkeitsdauer von einer Stunde ausgestellt wird.

Auf der Black Hat 2022 demonstrierte Rubin, wie ein Relay-Angriff auf den NegoEx-Handshake erfolgreich durchgeführt werden kann, und zwar in ähnlicher Weise, wie dies bei NTLM der Fall ist. Anschließend zeigte er, wie ein Angreifer das Peer-to-Peer-Client-Zertifikat mit einer ähnlichen Methode erlangen und dann zur Authentifizierung bei anderen Rechnern verwenden kann. Mit anderen Worten, dies sind Äquivalente von NTLM-Relay und Pass-the-Hash, aber im Kontext von Azure AD-verbundenen Geräten, trotz der Unterschiede in den verwendeten Protokollen.

Der Microsoft-Experte empfahl Unternehmen außerdem, ihre Protokolle auf Azure AD-Maschinen mit folgenden Authentifizierungsanfragen zu überwachen: die von Client-Namen mit IP-Adressen kommen, die nicht übereinstimmen, oder Authentifizierungsanfragen über Zertifikate, die für Benutzer ausgestellt wurden, die nicht mit den Maschinen verbunden sind. Rubins Präsentation war der Höhepunkt seiner im vergangenen Jahr begonnenen Forschung und beinhaltete auch die Veröffentlichung eines Open-Source-NegoEx-Relay-Tools namens Negoexrelayx.

Missbrauch von externen Identitäten in Azure Active Directory

In einer weiteren Black-Hat-Präsentation, in der es um reine Azure AD-Bedrohungen ging, die es in lokalen Active Directory-Implementierungen nicht gibt, zeigte der niederländische Forscher Dirk-jan Mollema von Outsider Security, wie er die Funktion für externe Identitäten missbrauchen konnte, um Azure AD-Konten zu hintergehen.

Externe Identitäten sind eine Funktion von Azure AD, mit der Unternehmen externen Benutzern Zugriff auf bestimmte Ressourcen geben können. Diese Benutzer können Teil eines anderen Azure AD-Mandanten sein oder über einen externen Identitätsanbieter authentifiziert und nur durch eine E-Mail-Adresse identifiziert werden. Diese Funktion wird gerne von Unternehmen genutzt, die mit externen Vertragspartnern zusammenarbeiten, oder um Anbietern von Managed Services, die Abonnements verwalten, Zugriff zu gewähren.

Externe Benutzer können von einer Person mit Administratorrechten über die Azure AD-Schnittstelle eingeladen werden. Daraufhin wird ein Einladungslink generiert und per E-Mail an den externen Benutzer gesendet. Das Problem, so Mollema, sei, dass Einladungen auch programmatisch über die API von Azure AD, den AAD Graph, erstellt und angenommen werden können.

Außerdem zeigte das Beispiel von Mollema, dass bei der Interaktion mit dieser Funktion über die API nicht viele Prüfungen durchgeführt wurden. Dabei konnte jeder Benutzer innerhalb des Azure AD-Tenants die API abfragen und die Einladungen sehen, die noch nicht in Anspruch genommen worden waren. Zudem konnte jede Einladung über die API ohne Validierung eingelöst werden und mit einem anderen externen Konto verknüpft werden als dem, für das sie gedacht war. Darüber hinaus konnten die Administratoren nicht erkennen, dass eine Einladung über die Schnittstelle gekapert wurde.

Der Angriff würde auch die Liste der Domänennamen umgehen, die für die externe Zusammenarbeit im Azure AD-Tenant zugelassen sind, da die Einladung gekapert und mit einem Konto in einer anderen Domäne verknüpft werden könnte. Darüber hinaus können automatisierte Regeln vorhanden sein. Diese können einem Konto, das eine bestimmte Einladung einlöst, automatische Berechtigungen verleihen, was zu einer Ausweitung der Rechte führt.

Der Forscher von Outsider Security ging bei dem Angriff sogar noch weiter. Mollema analysierte, wie die externen Identitäten in Microsoft Graph, einer Microsoft-API für Entwickler, anstelle des AAD-Graphen aussahen. Dabei erkannte er, dass einige der Eigenschaften, die mit einer Identität verbunden sind, mit den richtigen Berechtigungen über den MS Graph geändert werden können. Eines dieser Attribute ist die Issuer-Eigenschaft, die den Identitätsanbieter definiert, und eine der verfügbaren Optionen ist einfach "Mail". Dies wird für externe Benutzer verwendet, die nur durch E-Mail identifiziert werden und noch kein Microsoft- oder Azure AD-Konto haben.

Anschließend untersuchte der Security-Forscher, wer diese Attribute ändern kann, und stellte fest, dass neben Administratoren auch Anwendungen, bei denen sich Benutzer anmelden und über die entsprechenden Berechtigungen verfügen, Identitäten ändern können. Zudem könnten Benutzer ihre eigene Identität über den MS-Graph ändern. Dies öffnete die Tür für Backdoor-Angriffe von bestehender Konten. Zum Beispiel, wenn ein Angreifer durch Diebstahl eines Zugangstokens vorübergehend Zugriff auf sie erhält oder vorübergehend die Kontrolle über einen Computer erlangt, auf dem sie eine aktive Sitzung haben.

Wenn es sich bei dem Konto zufällig um einen Benutzeradministrator handelt, könnten die Angreifer außerdem alle Konten durch die Hintertür öffnen, indem sie ihnen externe Identitäten hinzufügen und sie mit gekarperten E-Mail-Adressen verknüpfen. Dies gitl auch für globale Administratoren, da diese die Berechtigung haben, ihre Identitäten über den MS Graph zu ändern.

Auf diese Weise kann aber nur die primäre Authentifizierungsmethode geändert werden, das heißt von einem Benutzernamen und einem Kennwort zu einer Authentifizierung über eine externe E-Mail. Ist für das Konto eine Multi-Faktor-Authentifizierung (MFA) konfiguriert, kann sich der Angreifer trotzdem nicht anmelden.

Mollema fand jedoch auch hierfür eine Umgehung. Zunächst verwendete er das vorübergehend kompromittierte Opferkonto, um eine Einladung für das externe Konto des Angreifers zu generieren. Der Angreifer nahm die Einladung an, woraufhin ein Gastkonto im Namen des Opfers erstellt wurde. Der Angreifer meldete sich dann bei dem Gastkonto an und richtete MFA für dieses ein.

Anschließend löschte er mit dem Konto des Opfers das Gastkonto. Dadurch wird zwar das Gastkonto gelöscht, das mit dem externen Konto des Angreifers verknüpft ist, nicht aber das MFA-Token, das im Cache gespeichert ist. Das externe Konto des Angreifers verfügt also weiterhin über ein aktives MFA-Token im Azure AD-Tenant des Opfers, auch wenn das zugehörige Gastkonto jetzt nicht mehr vorhanden ist. Der Angreifer kann dann das Konto des Opfers durch eine Hintertür öffnen und sein externes Konto als Identität hinzufügen, so dass er nicht mehr zur MFA-Authentifizierung aufgefordert wird. Dadurch wird der MFA-Schutz des Opfers umgangen.

Entschärfung von Azure AD und anderen Schwachstellen bei der Cloud-Authentifizierung

Microsoft hat die meisten der von Mollema entdeckten Probleme bereits behoben, sodass die von ihm beschriebenen Angriffe nicht mehr funktionieren. Seine Ergebnisse zeigen jedoch, wie komplex die Authentifizierung in den neuen Cloud-Umgebungen sein kann. Die Einführung neuer Funktionen wie das Zulassen von E-Mail-OTP als Identitätsanbieter oder externer Identitäten kann immer zu Logikfehlern führen, die Umgehungen ermöglichen.

Mollema rät Unternehmen, alle Gastkonten mit nicht eingelösten Einladungen regelmäßig zu entfernen, die Rechte für Gasteinladungen und die Einstellungen für den Gastzugang zu sperren, die für die externe Zusammenarbeit zugelassenen Mandanten einzuschränken, MFA für alle Anwendungen durchzusetzen und die Zugriffsprotokolle auf Anzeichen für einen möglichen Missbrauch von Gastkonten zu überprüfen. (jm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CSO Online.