Lernen Sie Silver SAML kennen: Goldenes SAML in der Cloud

Wichtigste Ergebnisse

• Golden SAML, eine Angriffstechnik, die das SAML-Single-Sign-On-Protokoll ausnutzt, wurde als Post-Breach-Exploit verwendet und verschlimmerte den verheerenden SolarWinds-Angriff von 2020 - eine der größten Sicherheitsverletzungen des 21.
• Der Angriff auf die Lieferkette von SolarWinds betraf Tausende von Organisationen auf der ganzen Welt, darunter auch die US-Regierung, indem bösartiger Code in die IT-Management- und Überwachungssoftware Orion des Unternehmens eingeschleust wurde.
• Nach diesem Angriff haben CISA- und Cybersecurity-Experten Unternehmen mit hybriden Identitätsumgebungen empfohlen, die SAML-Authentifizierung auf ein Cloud-Identitätssystem wie Entra ID zu verlagern.
• Die Semperis-Forscher Tomer Nahum und Eric Woodruff haben eine neue Anwendung von Golden SAML entdeckt - eine, die sogar in Unternehmen ausgenutzt werden kann, die frühere Sicherheitsempfehlungen zum Schutz vor Golden SAML befolgt haben.
• Die neue Angriffstechnik mit dem Namen Silver SAML ermöglicht die Ausnutzung von SAML, um von einem Identitätsanbieter wie Entra ID aus Angriffe auf Anwendungen zu starten, die so konfiguriert sind, dass sie SAML zur Authentifizierung verwenden, wie z.B. Salesforce.
• Nach Kenntnis von Semperis wurden keine Angriffe auf Silver SAML gemeldet.
• Die Forscher von Semperis stufen diese Sicherheitslücke als MÄSSIGES Risiko für Unternehmen ein. Sollte Silver SAML dazu verwendet werden, sich unbefugten Zugang zu geschäftskritischen Anwendungen und Systemen zu verschaffen, ist das Risiko - je nach kompromittiertem System - SCHWER.

Golden SAML ist eine bekannte Angriffstechnik, die von CyberArk entdeckt und von Shaked Reiner veröffentlicht wurde. Golden SAML ist seit Jahren für die Extraktion von Signierzertifikaten aus Active Directory Federation Services (AD FS) und die Verwendung dieser Zertifikate zum Fälschen von SAML-Authentifizierungsantworten bekannt. Heute stellen wir eine neue Anwendung von Golden SAML vor - mit Microsoft Entra ID und ohne AD FS. Lernen Sie Silver SAML kennen.

Was ist Silver SAML?

Heute verwenden viele Unternehmen Entra ID als Identitätsanbieter (IdP) für Software-as-a-Service (SaaS) und Line-of-Business (LOB) Anwendungen. SAML ist das wichtigste Mittel zur Authentifizierung für diese Anwendungen.

Innerhalb von Entra ID bietet Microsoft ein selbstsigniertes Zertifikat für die Signierung von SAML-Antworten. Alternativ können Unternehmen auch ein extern generiertes Zertifikat verwenden. Diese Option birgt jedoch ein Sicherheitsrisiko.

Jeder Angreifer, der in den Besitz des privaten Schlüssels eines extern generierten Zertifikats gelangt, kann eine beliebige SAML-Antwort fälschen und diese Antwort mit demselben privaten Schlüssel signieren, den Entra ID besitzt. Mit dieser Art von gefälschter SAML-Antwort kann der Angreifer dann auf die Anwendung zugreifen - als beliebiger Benutzer.

Der in diesem Beitrag besprochene Konzeptnachweis konzentriert sich auf Entra ID. Dieser Angriff kann jedoch von jedem IdP genutzt werden, der den Import von extern generierten SAML-Signaturzertifikaten erlaubt.

Für diesen Konzeptnachweis hat Semperis ein neues Tool namens SilverSAMLForger entwickelt und veröffentlicht, mit dem Sie signierte SAML-Antworten fälschen können. Sie können SilverSAMLForger auf GitHub finden.

Hintergrund: SAML, Golden SAML und der SolarWinds-Angriff

SAML ist ein Grundpfeiler der modernen Authentifizierung. Zum Beispiel verlassen sich 63 Prozent der Entra ID Gallery Anwendungen auf SAML für die Integration. Multi-Cloud-Integrationen mit Amazon Web Services (AWS), Google Cloud Platform (GCP) und anderen verlassen sich auf SAML. Und viele Unternehmen investieren weiterhin in SAML für SaaS- und LOB-Anwendungen, weil es so einfach zu implementieren ist.

Golden SAML und Solorigate

Als Teil des globalen Angriffs auf die Lieferkette von SolarWinds (auch bekannt als Solorigate) war Golden SAML einer der innovativeren Angriffsvektoren der Angreifer.

Die Angreifer verschafften sich zunächst Zugang zu SolarWinds, indem sie bösartigen Code in die Orion-Plattform des Unternehmens einschleusten, die für die Überwachung der Infrastruktur und das IT-Management verwendet wird. Später nutzten die Angreifer diese Ausgangsposition, um seitlich in die AD FS-Umgebung einzudringen. Von dort stahlen sie das private Schlüsselmaterial, das zum Signieren von SAML-Antworten verwendet wird.

Infolge dieses Angriffs auf Golden SAML haben viele Unternehmen der Umstellung von Anwendungen auf Entra ID für die SAML-Authentifizierung Priorität eingeräumt. Durch diese Änderung entfiel die Notwendigkeit, eine komplexe Tier 0-Infrastruktur zu verwalten, und SAML-Signierschlüssel können nicht aus Entra ID exportiert werden. Selbst die CISA empfiehlt Unternehmen mit hybriden Identitätsumgebungen, die SAML-Authentifizierung auf Cloud-Identitätssysteme wie Entra ID zu verlagern.

Das Problem mit SAML und dem Signieren von Zertifikaten

Leider gehen viele Unternehmen mit Signierzertifikaten falsch um und schwächen die SAML-Sicherheit, indem sie extern generierte Zertifikate verwenden. Nach unseren Beobachtungen neigen Unternehmensorganisationen dazu:

• Erzeugen Sie selbstsignierte Signierzertifikate auf einem Client-System
• Generieren Sie Signierzertifikate über eine unternehmensweite Public Key Infrastruktur (PKI), wie z.B. Active Directory Certificate Services (AD CS)
• Beziehen Sie Signierzertifikate von einer externen Zertifizierungsstelle (CA) und verwenden Sie diese.

Erschwerend kommt hinzu, dass die Unternehmen diese extern erstellten Zertifikate nehmen und:

• Senden Sie Zertifikats-PFX-Dateien und Passwörter über unsichere Kanäle wie Teams oder Slack
• Erzeugen Sie Zertifikate auf den Client-Rechnern und lassen Sie die Zertifikate für den Export im lokalen Zertifikatspeicher der Rechner verfügbar.
• Generieren Sie Zertifikate auf Webservern, auf denen in der Regel Microsoft Internet Information Services (IIS) läuft, und lassen Sie die Zertifikate für den Export im lokalen Zertifikatspeicher des Rechners verfügbar.

Selbst für Unternehmen, die Dienste wie Azure Key Vault - eine sicherere Methode für die Verwaltung von Geheimnissen und Zertifikaten - nutzen, können Angriffsvektoren existieren. (Wir werden diese Vektoren im nächsten Abschnitt behandeln.)

Die Verwendung eines extern generierten Zertifikats für die Signierung von SAML-Antworten vergrößert die Angriffsfläche für jeden IdP, auch für Entra ID. Wir haben in Unternehmen, die SAML-Signaturzertifikate extern statt direkt in Entra ID generieren und verwalten, mehrere gemeinsame Erfahrungen gemacht.

• Fehlende Vertrauenskette bei selbstsignierten Zertifikaten von Entra ID
• Unmöglichkeit, den Widerruf von Zertifikaten mit selbstsignierten Zertifikaten zu nutzen
• Notwendigkeit der blinden Anwendung einer definierten Unternehmensrichtlinie für die Verwaltung von Zertifikaten (in der Regel aus einem oder beiden der oben genannten Gründe)
• Ein subjektives Gefühl, dass selbstsignierte Zertifikate "weniger sicher" sind

Darüber hinaus möchten einige Organisationen eine längere Lebensdauer für SAML-Signaturzertifikate beibehalten als die Standardeinstellung von Entra ID. Diese Organisationen stellen externe Zertifikate aus und wissen nicht, dass sie einfach neue Zertifikate von Entra ID ausstellen und diese Zertifikate mit einer längeren Lebensdauer konfigurieren können.

Viele Unternehmen verstehen die Feinheiten des Einsatzes von Zertifikaten für die SAML-Signierung nicht. Die Signierung von Zertifikaten wird einfach in die allgemeinen Richtlinien für die Zertifikatsverwaltung integriert. Obwohl die üblichen Praktiken für den Lebenszyklus und die Verwaltung von Zertifikaten für viele Arten von Systemen wichtig sind, gelten sie nicht für Zertifikate, die für die SAML-Signierung verwendet werden, und sollten dies auch nicht tun.

Eine Vertrauenskette ist bei SAML nicht relevant. Die meisten IdPs und Service Provider (SP) Anwendungen ignorieren jede Vertrauenskette. Im Gegensatz zu dem Server/Client-Szenario, das Sie bei Webbrowsern sehen, ist ein Administrator in SAML-Konfigurationen ein wesentlicher Bestandteil der Vertrauenskette. Der Administrator muss konfigurieren und angeben, welchem Signierzertifikat er vertraut, und zwar speziell in der Anwendung.

Auch der Widerruf von Zertifikaten ist bei SAML keine relevante Praxis. Wenn ein Signierzertifikat kompromittiert ist, muss ein Administrator dieses Zertifikat im SP und IdP rotieren (d.h. ersetzen). OASIS SAML 2.0 Metadata Interoperability Profile Version 1.0 weist ausdrücklich darauf hin, dass keine Sperrlisten, Online Certificate Status Protocol (OCSP) oder andere Mechanismen zur Schlüsselvalidierung verwendet werden sollen. Stattdessen sollten Sie den IdP veranlassen, kompromittierte Schlüssel aus den SAML-Metadaten zu entfernen.

Importieren externer Zertifikate

Wie Abbildung 1 zeigt, können Sie selbstsignierte Zertifikate für eine Unternehmensanwendung (in diesem Beispiel Okta) im Entra Admin Center über die Einstellungen der Anwendung Verwalten > Einzelanmeldung > SAML > SAML-Zertifikate konfigurieren.

Im Bereich SAML-Signaturzertifikat können Sie Ihr eigenes Zertifikat importieren, um die SAML-Antwort oder Assertions zu signieren(Abbildung 2).

Was ist mit Azure Key Vault?

Wir müssen uns einen Moment Zeit nehmen, um über Azure Key Vault zu sprechen: einer der Orte, an dem selbstsignierte Zertifikate gespeichert sein können. Wir wollten herausfinden, ob ein Angreifer Schlüssel aus Key Vault extrahieren kann. Spoiler: Das können sie. (Wenn Ihr Unternehmen Key Vault nicht verwendet, können Sie gerne zum nächsten Abschnitt springen).

Azure Key Vault ist eine beliebte Schlüsselverwaltungslösung von Microsoft. Mit Key Vault können Sie Geheimnisse, Verschlüsselungsschlüssel und Zertifikate sicher speichern und verwalten.

Wie bei den meisten Cloud-Diensten gibt es auch bei Key Vault zwei Ebenen, die den Zugriff und die Verwaltung regeln: die Steuerungsebene und die Datenebene.

• Kontrollebene. Rollen und Berechtigungen, die der Kontrollebene zugewiesen sind, sind mit Verwaltungsaufgaben und Key Vault-Konfigurationseinstellungen verbunden. Benutzer, Gruppen oder Serviceprinzipale, denen Rechte für die Kontrollebene zugewiesen sind, können Zugriffsrichtlinien konfigurieren, Key Vault erstellen und andere Verwaltungsaufgaben durchführen. Rechte können granular für einen einzelnen Tresor vergeben werden, werden aber häufig auf der Ebene der Ressourcengruppe, des Abonnements oder der Verwaltungsgruppe vergeben.
• Datenebene. Die Datenebene bezieht sich auf die tatsächlichen Daten, die in einem Schlüsseltresor gespeichert sind: Geheimnisse, Schlüssel und Zertifikate. Mit den auf der Datenebene zugewiesenen Rechten wird gesteuert, welche Benutzer oder Serviceprinzipale kryptografisches Material aus dem Schlüsseltresor lesen und schreiben können. Zu diesen Rechten gehört auch die Möglichkeit, private Schlüssel von Zertifikaten zu lesen, was ein Problem darstellt, wenn diese Schlüssel für die Signatur von SAML-Antworten verwendet werden.

Key Vault-Berechtigungen können über rollenbasierte Zugriffskontrolle (RBAC) oder Key Vault-Zugriffsrichtlinien erteilt werden.

Das RBAC-Berechtigungsmodell

Mit dem RBAC-Modell(Abbildung 3) kann jeder Benutzer, der eine der folgenden RBAC-Rollen innehat, das Zertifikat eines Schlüsseltresors abrufen.

• Key Vault Administrator
• Beauftragter für Schlüsseltresor-Zertifikate
• Key Vault Data Access Administrator. Mit dieser Rolle können Sie den Zugriff verwalten, indem Sie Rollenzuweisungen hinzufügen oder entfernen. Sie können daher jeder Entität die Rolle Key Vault Administrator oder Key Vault Certificates Officer zuweisen.
• Key Vault Contributor. Diese Rolle gewährt keine Berechtigungen für die Datenebene, ermöglicht es Ihnen aber, die Zugriffsrichtlinien des Key Vault zu aktualisieren, wenn das Berechtigungsmodell für Zugriffsrichtlinien ebenfalls verwendet wird.

Abbildung 4 zeigt ein Beispiel für die Berechtigungen, die der Rolle Key Vault Administrator gewährt werden.

Eine Person mit der Rolle Key Vault Contributor, die keine Berechtigungen auf der Datenebene für den Zugriff auf die Geheimnisse und Zertifikate des Schlüsseltresors hat, kann diese dennoch extrahieren, wenn Zugriffsrichtlinien verwendet werden. Diese Rolle verfügt jedoch über die Berechtigung Microsoft.KeyVault/* für die Kontrollebene. Diese Berechtigung kann in Microsoft.KeyVault/vaults/accessPolicies/write übersetzt werden, so dass der Inhaber in der Lage ist, Zugriffsrichtlinien für den Key Vault zu schreiben und Geheimnisse des Key Vault zu extrahieren.

Wenn Sie RBAC-Berechtigungen auf der Ebene der Ressourcengruppe oder des Abonnements hinzufügen können, indem Sie die Kontrolle über ein Konto des Besitzers der Ressourcengruppe oder ein Benutzerkonto mit der RBAC-Berechtigung Administrator für rollenbasierte Zugriffskontrolle oder einen Benutzer mit der Berechtigung Microsoft.Authorization/roleAssignments/write erlangen, können Sie Berechtigungen für den Schlüsseltresor hinzufügen. Der Schlüsseltresor erbt dann diese Berechtigungen. Wie bereits erwähnt, können einige RBAC-Rollen auch direkt die Zugriffsrichtlinien für den Key Vault ändern.

Auf Schlüsseltresore kann auch über Automatisierungskonten und verwaltete Identitäten zugegriffen werden, die über die erforderlichen Berechtigungen verfügen.

Das Zugriffsrichtlinien-Berechtigungsmodell von Key Vault

In diesem Modell können Sie einem Benutzer, einem Dienst oder einer Gruppe auch Zugriffsrechte für Key Vault erteilen. Sie können zwischen Schlüsselberechtigungen, geheimen Berechtigungen und Zertifikatsberechtigungen wählen(Abbildung 5).

Sie können Zugriffsrichtlinien im Fenster Key Vault Zugriffsrichtlinien hinzufügen(Abbildung 6).

Jeder Angreifer, der die Kontrolle über einen Benutzer, einen Dienstprinzipal oder eine Gruppe erlangt, der/die die Berechtigung hat, die PFX-Datei abzurufen, die zum Signieren der SAML-Assertions oder -Antworten für den angegriffenen SP verwendet wird - entweder über RBAC- oder Key Vault-Zugriffsrichtlinien - kann einen Silver SAML-Angriff auf diesen SP durchführen.

SAML und Entra ID

SAML in seiner aktuellen Version 2.0 ist fast 20 Jahre alt. Die OASIS veröffentlichte das Protokoll im März 2005. Seitdem haben viele Unternehmen SAML für die föderierte Authentifizierung und webbasierte SSO-Lösungen übernommen. Die wichtigste Implementierung des Protokolls - und der Anwendungsfall in Entra ID - ist die Nutzung des SSO-Profils des Webbrowsers.

Ein typischer SAML-Profilfluss hat drei Hauptkomponenten:

• Der Dienstanbieter (SP) oder die Anwendung, die im Microsoft-Ökosystem auch als vertrauende Partei (RP) bezeichnet wird.
• Der Identitätsanbieter (IdP), der in unserem Konzeptnachweis Entra ID ist
• Der Benutzer-Agent, in der Regel der Webbrowser eines Kunden (Endbenutzers)

Benutzer interagieren mit Anwendungen zur Authentifizierung auf verschiedene Weise, je nachdem, ob die Anwendung für SP-initiierte oder IdP-initiierte Abläufe konfiguriert ist oder diese unterstützt.
In einem SP-initiierten Ablauf(Abbildung 7) findet die folgende Sequenz statt:

1. Der Benutzer ruft eine URL für die Anwendung (SP) auf.
2. Der SP erzeugt eine SAML-Anfrage(Abbildung 8) und leitet den Benutzer an Entra ID (IdP) weiter.
3. Entra ID konsumiert die SAML-Anfrage.
4. Wenn sich der Benutzer noch nicht bei Entra ID authentifiziert hat, wird der Benutzer zur Authentifizierung aufgefordert.
5. Der Benutzer authentifiziert sich erfolgreich bei Entra ID.
6. Entra ID erzeugt eine SAML-Antwort(Abbildung 9) und leitet den Benutzer an den SP weiter.
7. Der SP verifiziert die SAML-Antwort.
8. Der Benutzer erhält Zugriff auf die Anwendung.

Bei einem vom IdP initiierten Datenfluss(Abbildung 10) läuft die folgende Sequenz ab:

1. Der Benutzer ruft myapps.microsoft.com auf.
2. Wenn sich der Benutzer noch nicht bei Entra ID authentifiziert hat, wird der Benutzer zur Authentifizierung aufgefordert.
3. Der Benutzer authentifiziert sich erfolgreich bei Entra ID.
4. Entra ID bietet eine Liste der Anwendungen, die dem Benutzer unter myapps.microsoft.com zur Verfügung stehen.
5. Der Benutzer wählt die Zielanwendung aus.
6. Entra ID generiert eine SAML-Antwort und leitet den Benutzer an den SP weiter.
7. Der SP verifiziert die SAML-Antwort.
8. Der Benutzer erhält Zugriff auf die Anwendung.

Der Inhalt einer SAML-Assertion enthält mehrere Informationen über den Endbenutzer bzw. das Subjekt in einer Reihe von Schlüssel-Wert-Paaren. Diese Informationen werden oft als SAML-Ansprüche bezeichnet und enthalten Informationen wie:

• Der Betreff. Die Anwendung verwendet diese erforderliche Komponente als eindeutige Kennung des Benutzers. In vielen Implementierungen ist der Betreff der User Principal Name (UPN) oder die E-Mail-Adresse des Benutzers.
• Attribut-Informationen. Diese Informationen können den Vornamen, den Nachnamen, die E-Mail-Adresse und den Anzeigenamen des Benutzers umfassen. Die Gruppenzugehörigkeit oder Rollen werden oft angegeben, damit die Anwendung entscheiden kann, welche Rechte der Benutzer haben soll.
• Andere Kontextinformationen zur Authentifizierung. Diese Informationen können die Art der verwendeten Authentifizierung, den Aussteller und das Publikum sowie Zeitstempelinformationen umfassen, die das Gültigkeitsfenster für die SAML-Antwort angeben.

Wie können Sie sicherstellen, dass die SAML-Antwort, die vom Benutzer bearbeitet wird, nicht manipuliert wurde? An dieser Stelle kommt die Signierung ins Spiel.

Entra ID unterstützt sowohl das Signieren von SAML-Antworten als auch von SAML-Assertions. Der Zweck des Signierens von Antworten und Assertions besteht darin, zu überprüfen, dass der Inhalt der Antwort nicht verfälscht wurde und dass die Anwendung den Informationen in der Antwort vertrauen kann. Die Anwendung verwendet die Signatur, um zu überprüfen, ob die Antwort vom IdP erzeugt wurde, der über den privaten Schlüssel verfügt, mit dem die Antwort signiert wurde.

Aus diesem Grund ist der Diebstahl des privaten Signierschlüssels ein kritisches Problem. Mit dem Signierschlüssel in der Hand kann ein Bedrohungsakteur eine Kopie einer SAML-Antwort fälschen und einen Silver SAML-Angriff durchführen.

Durchführen eines Silver SAML-Angriffs

Um die Theorie zu testen, dass die Golden SAML-Angriffstechnik gegen Entra ID gerichtet werden kann - was wir als Silver SAML-Angriff bezeichnet haben - haben wir das Tool SilverSAMLForger entwickelt. Dieses Tool erzeugt eine SAML-Antwort, die eine Entra ID-Antwort dupliziert und diese Antwort mit einem bereitgestellten Zertifikat signiert.

Unser Silver SAML-Konzept basiert auf der Prämisse, dass eine Organisation ein extern generiertes Signierzertifikat verwendet, das ein Angreifer mit einer der zuvor beschriebenen Methoden erlangt hat. Wir betrachten die Anwendung von Silver SAML sowohl bei SP-initiierten Flüssen als auch bei IDP-initiierten Flüssen, da beide anfällig für Angriffe sind.

Silver SAML in einem vom SP initiierten Fluss

Silberner SAML-Angriff mit Entra ID als IdP und Okta als SP. Um den Angriff in einem vom SP initiierten Ablauf zu starten, mussten wir die SAML-Anfrage abfangen und den Inhalt der SAML-Antwort durch die von uns erstellte gefälschte SAML-Antwort ersetzen(Abbildung 11). Mit der Burp Suite konnten wir diese Aufgaben problemlos bewältigen.

In diesem Beispiel haben wir versucht, eine SAML-Antwort für den Benutzer oktaAdministrator@xd6z7.onmicrosoft.com zu fälschen . Dieser Benutzer ist ein Superadministrator in Okta. Wir haben weder das Passwort des Benutzers noch das mit MFA verbundene Gerät des Benutzers (falls konfiguriert).

Zunächst benötigten wir einige Attribute in den SAML-Claims-Informationen in Übereinstimmung mit den Angaben, die bei der Registrierung der Anwendung beim IdP eingerichtet wurden. Wir benötigen zum Beispiel die UPN, den Nachnamen, den Vornamen, den Anzeigenamen und die objectID. Ein Angreifer kann diese Attribute leicht im Entra Admin Center oder über die Microsoft Graph API finden.

Wir mussten auch den Empfänger und die Zielgruppe kennen. Diese Informationen waren im Entra-Verwaltungszentrum im Bereich " Einmalige Anmeldung" der Anwendung verfügbar(Abbildung 12).

Wenn Sie SilverSAMLForger.exe mit den erforderlichen Parametern ausführen, wird eine base64- und URL-kodierte Zeichenkette ausgegeben(Abbildung 13). Wir können nun diese gefälschte SAML-Antwort kopieren.

Wir haben die generierte SAML-Antwort auf die abgefangene HTTPS-Anfrage kopiert(Abbildung 14) und die Antwort auf die gefälschte Antwort geändert(Abbildung 15).

Nachdem wir die gefälschte Antwort gesendet haben, können wir das Abfangen beenden, da wir nun als der Zielbenutzer angemeldet sind(Abbildung 16).

Silberner SAML-Angriff in einem IdP-initiierten Fluss

Von einem IdP initiierte Datenflüsse sind mit einem viel größeren Risiko für das Unternehmen verbunden, da keine Interaktion mit Entra ID erforderlich ist. Wenn die Anwendung IdP-initiierte Abläufe unterstützt, können Sie direkt eine SAML-Antwort an die Anwendung senden(Abbildung 17).

Für diesen Teil des Proof of Concept haben wir versucht, einen von einem IdP initiierten Angriff auf Salesforce durchzuführen.

Wir zielten auf den Benutzer Patti Fernandez ab und fälschten eine Antwort mit ihrem UPN als Betreff. Die Antwort(Abbildung 18) wurde mit demselben SAML-Signaturzertifikat signiert, das für Salesforce in Entra ID konfiguriert war.

Wenn Sie diese Antwort entschlüsseln, können Sie sehen, dass es sich um eine gefälschte Antwort für Patti handelt(Abbildung 19).

In Burp Suite haben wir Repeater verwendet, um die gefälschte SAML-Antwort direkt an unsere Instanz von Salesforce zu senden(Abbildung 20).

Wenn wir die Antwort in einem Browser öffnen, stellen wir fest, dass wir in Salesforce als Patti angemeldet sind, ohne dass eine Interaktion mit Entra ID stattfindet(Abbildung 21).

Verteidigung gegen Silver SAML-Angriffe

Um sich wirksam gegen Silver SAML-Angriffe in Entra ID zu schützen, sollte Ihr Unternehmen nur selbstsignierte Entra ID-Zertifikate für die SAML-Signierung verwenden.

SAML-Signierzertifikate werden im Dienstprinzipal für eine SAML-Anwendung in Entra ID gespeichert. Sie können die Graph API verwenden, um die Informationen über den Signierschlüssel einzusehen. Rufen Sie einfach eine GET-Anfrage an die folgende URI auf:

https://graph.microsoft.com/beta/servicePrincipals/{serviceprincipalobjectid}

Abbildung 22 zeigt ein Beispiel für die offengelegten Informationen. Beachten Sie, dass das Material des privaten Schlüssels nicht exportiert werden kann, was Angreifer daran hindert, die Informationen zu sammeln, die sie für einen Silver SAML-Angriff benötigen.

Globale Administratoren, Anwendungsadministratoren, Cloud-Anwendungsadministratoren und alle Benutzer, denen der Besitz von Anwendungen übertragen wurde, können die verfügbaren Signierschlüssel ändern und einen externen Signierschlüssel importieren. Auch wenn die zugehörige Anwendung aktualisiert werden muss, sollten Unternehmen einschränken, wer Eigentümer von Anwendungen in Entra ID ist. Überwachen Sie zumindest die Änderungen an SAML-Signierschlüsseln, vor allem, wenn der Schlüssel nicht bald abläuft.

Unternehmen können vorhandene Dienstprinzipale, die für SAML konfiguriert sind, überprüfen und den Anzeigenamen kontrollieren. Wenn das verwendete Zertifikat von Microsoft generiert wurde, enthält das Zertifikat den Wert CN=Microsoft Azure Federated SSO Certificate. Allerdings hindert nichts einen Angreifer daran, ein externes Zertifikat mit demselben Betreffnamen zu importieren.

Unternehmen können auch die Audit-Protokolle von Entra ID auf Änderungen an PreferredTokenSigningKeyThumbprint unter ApplicationManagement überwachen. Sie müssen diese Ereignisse mit Add service principal credential events korrelieren, die sich auf den Service Principal beziehen. Die Rotation von abgelaufenen Zertifikaten ist ein üblicher Prozess, so dass Sie feststellen müssen, ob die Audit-Ereignisse legitim sind. Die Implementierung von Änderungskontrollprozessen, um die Rotation zu dokumentieren, kann dazu beitragen, die Verwirrung während der Rotationsereignisse zu minimieren.
Wenn eine Anwendung sowohl SAML als auch OpenID Connect (OIDC) für die Authentifizierung unterstützt, könnten Sie in Erwägung ziehen, die Integration mit Entra ID zu ändern, um OIDC zu verwenden und so diesen Angriff zu entschärfen. Die Komplexität des Wechsels von SAML zu OIDC hängt weitgehend davon ab, wie der Anwendungsentwickler die Standards implementiert hat.

Auf der Anwendungsseite können sich Anwendungsentwickler auf verschiedene Weise vor Angriffen schützen. (Ihre Möglichkeiten hängen von den Methoden und Bibliotheken ab, die Sie in Ihrer SAML-Implementierung verwenden).

• Verlangt SP-initiierte Flows, die vor IdP-initiierten Flows - den gefährlichsten Arten von Angriffen - schützen.
• Für vom SP initiierte Datenflüsse folgen Sie der SAML-Spezifikation und stellen sicher, dass Antworten einen InResponseTo-Wert enthalten, der mit einer zugehörigen SAML-Anfrage korreliert.
• Beobachten Sie die Zeit, in der die Anwendung eine SAML-Antwort erhält. Der IdP gibt in der Antwort ein Zeitfenster für die Gültigkeit an, aber Anwendungsentwickler können weitere logische Beschränkungen für das akzeptable Zeitfenster für den Empfang einer Antwort in SP-initiierten Flows einführen.
• Bieten Sie die Möglichkeit, OIDC anstelle von SAML für die Integration zu verwenden.

Lassen Sie sich von Silver SAML nicht überrumpeln

Wie der Goldene SAML-Angriff haben auch die Silbernen SAML-Angriffe das Potenzial, harmlos zu sein - oder verheerend. Da die Einführung von Cloud- und hybriden Identitätsumgebungen weiter zunimmt, erwarten wir, dass mehr Bedrohungen auf IdPs wie Entra ID abzielen werden. Dieser Beitrag zeigt, wie Silver SAML mit Entra ID möglich ist, aber jeder IdP, der Ihnen die Verwendung selbstsignierter Zertifikate ermöglicht, ist anfällig. Wir empfehlen Unternehmen, jetzt entscheidende Schritte zu unternehmen, um Lücken und Schwachstellen in diesen Umgebungen zu schließen.

Offenlegung

Dieses Problem wurde am 2. Januar 2024 über das Microsoft Security Response Center (MSRC) gemeldet. Microsoft antwortete am 26. Februar 2024: "Nach sorgfältiger Untersuchung wurde dieser Fall als "by-design" eingestuft und erfüllt nicht die Anforderungen des MSRC für eine sofortige Behandlung. Wir haben den Bericht jedoch an das Team weitergeleitet, das für die Wartung des Produkts oder Dienstes verantwortlich ist. Sie werden bei Bedarf geeignete Maßnahmen ergreifen, um die Kunden zu schützen."

Zeitleiste

• Januar 2, 2024: MSRC Fall erstellt
• 3. Januar 2024: Der Status des Falls wurde auf Überprüfung/Reprod geändert.
• 17. Februar 2024: MSRC Überprüfung des Forschungsartikels
• 26. Februar 2024: MSRC Antwort erhalten
• 29. Februar 2024: Öffentliche Bekanntgabe