Was wäre, wenn IAM-Benutzer AWS-API-Schlüssel ohne Einschränkung frei generieren könnten? Was wäre, wenn Sicherheitsadministratoren keinen Einblick in die Erstellung von API-Schlüsseln hätten und nicht überprüfen könnten, wer API-Schlüssel verwendet?
Obwohl dieses Szenario nicht auf AWS zutrifft, ist es für Google Cloud HMAC Keys eine harte Realität. In diesem Blog werden drei Schwachstellen beschrieben, die sich aus der Art und Weise ergeben, wie Google Cloud mit nutzerbezogenen HMAC-Schlüsseln umgeht.
1. Schwachstelle Nr. 1 - Unzureichende Protokollierung
2. Schwachstelle Nr. 2 - Nicht verwaltbare langfristige Berechtigungsnachweise
3. Schwachstelle Nr. 3 - Nicht prüfbare langfristige Anmeldedaten
TLDR;
- HMAC-Schlüssel haben einen praktischen Zweck. Sie können verwendet werden, um Sigv4-signierte Header zu erstellen, die zur Authentifizierung gegenüber der Cloud Storage XML API verwendet werden . für bis zu 7 Tage nach der ersten Erstellung.
- Google Cloud Audit-Protokolle zeichnen keine Ereignisse zur Erstellung oder Löschung von HMAC-Schlüsseln auf, wenn diese mit Nutzerkonten verbunden sind.
- Administratoren steht keine Google Cloud API zur Verfügung, so dass sie das Vorhandensein von HMAC-Schlüsseln, die mit Nutzerkonten verbunden sind, nicht überprüfen können.
- Es sind keine Cloud IAM-Berechtigungen verfügbar, um die Erstellung, Löschung oder Verwendung von HMAC-Schlüsseln einzuschränken.
- Dieses Problem wurde über das Schwachstellen-Belohnungsprogramm von Google gemeldet. Das Unternehmen hat das Problem geschlossen, ohne eine Lösung anzubieten, da das gemeldete Verhalten wie vorgesehen funktioniert.
Verwendung von HMAC-Schlüsseln
Die APIs für die Erstellung und Löschung von HMAC-Schlüsseln, die mit Benutzerkonten verbunden sind, sind nicht von außen zugänglich. Diese Aktionen können nur über den privaten API-Dienst der Konsole cloud (cloudconsole-pa) durchgeführt werden, auf den über die Registerkarte "Interoperabilität" der Speicherkonsole zugegriffen wird. Die nachstehend aufgeführten URLs stellen die Endpunkte innerhalb der Konsole cloud dar, die zum Erstellen und Löschen von benutzerbezogenen HMAC-Schlüsseln verwendet werden, wenn sie von einem gültigen Anmelde-Cookie begleitet werden.
- Eine POST-Anfrage an `/v3/entityServices/StorageEntityService/entities/STORAGE_USER_HMAC/CREATE` erzeugt einen HMAC-Schlüssel, der im Sigv4-Signierungsprozess verwendet wird
- Eine POST-Anfrage an `/v3/entityServices/StorageEntityService/entities/STORAGE_USER_HMAC/DELETE` löscht einen mit einem Benutzer verbundenen HMAC.
Nutzer von Google Cloud können eine scheinbar unendliche Menge des Ressourcentyps erstellen: "type.googleapis.com/google.internal.cloud.console.clientapi.storage.UserHmac"
Bei den Tests wurde keine Obergrenze für HMAC-Schlüssel ermittelt, und es wurde keine Einschränkung der Bewertung festgestellt.
Schwachstelle Nr. 1 - Unzureichende Protokollierung
Cloud Audit-Protokolle erfassen keine Aktionen, die über den privaten API-Dienst der Konsole cloud (cloudconsole-pa) vermittelt werden. Folglich gibt es keine Protokollierung der Erstellung oder Löschung von HMAC-Schlüsseln im Zusammenhang mit Benutzerkonten. Das Fehlen von Protokollen behindert die Fähigkeit der Verteidiger, die Erstellung von HMAC-Schlüsseln für Benutzerkonten zu melden oder zu überwachen, was ein Persistenzrisiko darstellt, oder ihre Löschung, was ein Denial-of-Service-Risiko bedeutet.
Schwachstelle Nr. 2 - Nicht verwaltbare langfristige Berechtigungsnachweise
Nutzer mit Google Cloud -Zugang können HMAC-Schlüssel erstellen, wofür mindestens die Berechtigung resource manager.projects.get erforderlich ist. Es gibt jedoch keine Cloud IAM-Berechtigungen, um HMAC-Schlüssel für sich selbst oder andere Nutzer zu verwalten, was Administratoren daran hindert, deren Erstellung zu kontrollieren. Aus diesem Grund enthält dieser Ratschlag keine Empfehlungen, um das Risiko der HMAC-Schlüssel-Exposition durch Einschränkung der Berechtigungsvergabe zu mindern.
Schwachstelle Nr. 3 - Nicht überprüfbare langfristige Anmeldeinformationen
Cloud Administratoren stehen bei der Verwaltung von HMAC-Schlüsseln in ihren Unternehmen vor Herausforderungen, da sie nicht wissen, welche Benutzerkonten diese Schlüssel generiert haben und ob sie aktiv für den Zugriff auf Speicherobjekte verwendet werden. Darüber hinaus fehlt eine Funktion zum Entzug von Schlüsseln, die mit anderen Benutzern verknüpft sind, was die Möglichkeiten zur effektiven Durchsetzung von Sicherheitsrichtlinien einschränkt.
Teams, die auf Vorfälle reagieren, verlassen sich auf Cloud Logging, um den Zugriff auf Cloud Storage-Objekte zu überwachen, aber es fehlen ihnen spezifische Indikatoren, um festzustellen, ob HMAC-Schlüssel bei diesen Zugriffsversuchen verwendet werden. Während verschiedene Eindämmungsmaßnahmen, wie das Sperren oder Löschen kompromittierter Benutzerkonten, zunächst wirksam erscheinen, da zuvor erstellte Sigv4-signierte Header zurückgewiesen werden, ermöglicht die Reaktivierung oder Neuerstellung desselben Benutzers die Wiederverwendung von Anmeldedaten, sofern diese nicht abgelaufen sind.
Darüber hinaus kann durch das Entfernen von Cloud IAM-Rollen der Zugriff auf die betroffenen Speicherressourcen widerrufen werden. Es ist jedoch wichtig zu beachten, dass die Neuzuweisung von Rollen die zuvor erstellten Sigv4-signierten Header nicht ungültig macht, so dass sie auch nach dem Rollenwechsel weiterhin funktionieren.
HMAC-Schlüssel-Missbrauchsfall
Ein Angreifer, der im Besitz eines Google-Benutzerkontos mit Zugriff auf ein Google Cloud -Projekt und mindestens der Berechtigung `resource manager.projects.get` ist, kann HMAC-Schlüssel auf der Registerkarte "Interoperabilität" in der Speicherkonsole generieren.
Ein Angriffsweg, der HMAC-Schlüssel ausnutzt, könnte folgendermaßen aussehen:
1. Ein Angreifer kompromittiert ein Google-Nutzerkonto
2. Erzeugt einen HMAC-Schlüssel für den Benutzer
3. Verwendet den HMAC-Schlüssel, um eine Reihe von Sigv4-signierten Headern mit einer 7-tägigen Gültigkeitsdauer zu erzeugen.
4. Exfiltriert Daten von Google Cloud Storage, bis die Header-Signatur abläuft.
5. Die Identifizierung des böswilligen Speicherzugriffs und/oder die Reaktion darauf wird durch die oben beschriebenen Schwachstellen Nr. 1, 2 und 3 behindert.
6. Versuche der Eindämmung können entweder unwirksam sein, wie z. B. das Ändern des Passworts des kompromittierten Benutzers, oder vorübergehend sein, wenn ein betroffener Benutzer gesperrt und später wieder aktiviert wird.
Proof of Concept
Das Google Cloud SDK bietet keine Funktionalität, um einen nutzerassoziierten HMAC-Schlüssel durch den Sigv4-Signierungsprozess in verwendbare Anmeldeinformationen zu konvertieren. Daher haben wir ein einfaches Python-Hilfsskript zur Verfügung gestellt, das genau das tut. Es nimmt eine Zugriffsschlüssel-ID, ein Geheimnis, ein Objekt und einen Bucket-Namen auf und gibt eine Curl-Anfrage mit einem signierten Autorisierungs-Header zurück, der verwendet wird, um das gewünschte GCS-Objekt über die XML-API abzurufen.
Der Proof of Concept ist stark von einem Artikel von Rosy Parmar über die Verwendung von HMAC zur Authentifizierung bei Google Cloud beeinflusst.
Empfehlungen
Angesichts der zahlreichen Missbräuche im Zusammenhang mit benutzerspezifischen HMAC-Schlüsseln werden hier eine Reihe von Empfehlungen zur Verbesserung der Verwaltung, Protokollierung und des Lebenszyklus von GCP-HMAC-Schlüsseln vorgestellt.
1. Berechtigungen & APIs
- Einführung von APIs und zugehörigen Berechtigungen, die Administratoren die Befugnis geben, bei Bedarf benutzerspezifische HMAC-Schlüssel zu erstellen und zu löschen.
- Erstellen Sie APIs und zugehörige Berechtigungen, die es Google Workspace-Administratoren ermöglichen, HMAC-Schlüssel für alle Nutzer in ihrer Organisation und deren Verwendung zu prüfen und Schlüssel für andere zu löschen.
2. Organisationspolitische Zwänge
- Erstellen Sie eine Organisationsrichtlinienbeschränkung, die es den Richtlinienadministratoren ermöglicht, die Erstellung von benutzerbezogenen HMAC-Schlüsseln zu verhindern.
3. Protokollierung
- Write to Admin Activity admin protokolliert die Erstellung und Löschung aller HMAC-Schlüssel, einschließlich derer, die mit Benutzern verbunden sind.
- Geben Sie in Cloud Logs an, wenn auf die Cloud Storage XML API mit einem Sigv4 Header Credential zugegriffen wird.
4. Ausweisverwaltung
- Begrenzen Sie die Anzahl der HMAC-Schlüssel, die ein Benutzer erstellen kann, auf maximal zwei.
- Einführung eines benutzerkonfigurierten Verfallsdatums für HMAC-Schlüssel.
- Zeigen Sie HMAC-Schlüssel den Benutzern nur einmal an, wenn sie erstellt werden, und geben Sie sie bei nachfolgenden Anfragen nicht an die Benutzeroberfläche weiter.
Zeitplan für die Offenlegung
2/07/24 [Kat Traxler]: Gemeldet in Googles Vulnerability Reward Program unter der Überschrift "HMAC-Schlüssel, die für Nutzer generiert werden, stellen ein Sicherheitsrisiko dar, vor allem weil bei ihrer Erstellung oder Löschung keine Protokollierung erfolgt."
2/07/24 [Google]: Bestätigt den Erhalt des Berichts
2/08/24 [Google]: Es wurde mitgeteilt, dass sie die Angelegenheit aufgrund fehlender Details schließen. Forderte Angriffsszenario und Konzeptnachweis an.
09.02.24 [Kat Traxler]: Antwortete mit einem detaillierteren Durchgang der Angreifer-Aktionen angesichts der Eigenschaften von HMAC-Schlüsseln und dem Versprechen, einen PoC zu schreiben
2/12/24 [Google]: Status geändert auf 'Zugewiesen, wiedereröffnet, behandelt'.
2/16/24 [Google]: Das Google Bug Hunter Team hat die Details der gemeldeten Schwachstelle zusammengefasst, ein Beispiel für einen Sigv4-signierten Header angefordert und gefragt, ob die Anmeldeinformationen für den Zugriff auf etwas anderes als die Google Cloud Storage XML API verwendet werden können.
2/18/24 [Kat Traxler]: Beantwortet die Reihe von Fragen und bestätigt, dass aus HMAC-Schlüsseln generierte Anmeldeinformationen nur für den Zugriff auf die Google Cloud Storage XML API verwendet werden können.
19.2.24 [Kat Traxler]: Ich habe dem Google Bug Hunter Team einen Link zu einem auf Github gehosteten PoC zur Verfügung gestellt, der es ihnen ermöglicht, ihre eigenen signierten Header mit HMAC-Schlüsseln zu erzeugen.
28.2.24 [Google]: Das Problem wurde "als Missbrauchsrisiko identifiziert und an unser Team für Vertrauen und Sicherheit weitergeleitet".
28.2.24 [Google]: Antwortete mit einem Dankeschön für den Bericht und wies darauf hin, dass das Team die Meldung analysiert.
04/01/24 [Kat Traxler]: "Ich möchte diesen Bericht weiterverfolgen. Es ist etwa 4 Wochen her, seit wir das letzte Mal gesprochen haben. Zur Erinnerung: Ich habe vor, dieses Problem in der ersten Juniwoche zu veröffentlichen. Ich möchte die Zeit nutzen, um mich mit dem Serviceteam abzustimmen und die fehlenden Protokollierungs- und IAM-Kontrollen zu implementieren. Ohne neue Ereignisse, die protokolliert werden, und neue IAM-Kontrollen wird die Veröffentlichung nur Details über den Persistenzmechanismus enthalten, ohne Hinweise für die Kunden, wie sie ihn verhindern oder erkennen können. Niemand mag diese Art von Enthüllungsblog. *Bitte lassen Sie mich wissen, wie ich dazu beitragen kann, dieses Problem zu beheben oder mit den verantwortlichen Parteien zu koordinieren."
4/02/24 [Google]: "🎉 Nice catch! Ich habe auf der Grundlage Ihres Berichts einen Fehler beim zuständigen Produktteam gemeldet. Wir werden mit dem Produktteam zusammenarbeiten, um sicherzustellen, dass dieses Problem behoben wird. Wir werden Sie informieren, wenn das Problem behoben wurde."
4/11/24 [Google]: "Das Gremium des Google Vulnerability Reward Program hat entschieden, dass die Sicherheitsauswirkungen dieses Problems nicht die Voraussetzungen für eine finanzielle Belohnung erfüllen."
6/04/24 [Google]: "Unsere Systeme zeigen, dass der Fehler, den wir aufgrund Ihrer Meldung erstellt haben, geschlossen wurde, ohne dass eine Behebung erfolgt ist. Dies kann aus verschiedenen Gründen geschehen sein: Die Risikoauswirkung könnte zu gering sein, um eine Behebung zu rechtfertigen, es könnte andere mildernde Faktoren geben, oder das Produkt wird einfach nicht mehr gewartet. Der genaue Status ist INTENDED_BEHAVIOR. Diese Entscheidung wurde von den zuständigen Produktteams getroffen und hat keinen Einfluss auf Ihre VRP-Prämienhöhe oder Ihre Position in der Rangliste. Wir können in dieser automatischen Benachrichtigung keine weiteren Details angeben, aber wir beantworten gerne Ihre Fragen zu dieser Entscheidung."