skip to Main Content

it.sec Security Team findet unbekannte Schwachstelle in Google Cloud Plattform (GCP)

Im Zuge eines Kundenprojekts konnte das Research Team der it.sec GmbH eine bisher unbekannte Schwachstelle in der Google Cloud Plattform (GCP) identifizieren und ausnutzen. Hierbei handelte es sich um die Manipulation von Requests, welche im Zuge der Autorisierungsprüfung beim Zugriff auf durch den Google Identity-Aware Proxy (IAP) geschützte Webanwendungen automatisch gesendet wurden. Bei der Schwachstelle handelte es sich um ein Cross Site Scripting (XSS).

Google IAP erlaubt es, den Zugriff auf Anwendungen oder virtuelle Maschinen in der GCP zu steuern. Dabei können Administratoren festlegen, welche Identitäten, unter welchen Bedingungen Zugriff auf bestimmte Ressourcen erhalten sollen. Die Identitäten sind dabei entweder Google-Benutzerkonten, oder es werden externe Identitäten über Protokolle wie OAuth oder SAML angebunden. Der Zugriff erfolgt dann über einen Login im Browser des Benutzers. Die Verwendung von Virtual Private Network (VPN) Technologien kann so vermieden werden.

Die Schwachstelle befand sich im Base64 Decodierer des Google IAP. Der Decodierer und somit die Schwachstelle konnte an zumindest 2 Stellen in der GCP identifiziert werden. Der IAP arbeitet mit JWTs (JSON Web Token), welche sowohl als Cookie als auch als Bearer Token zur Authentifizierung und Autorisierung gegen den IAP und folglich die geschützten Applikationen dienen.

Wie funktioniert IAP

Nach der Google-Authentifizierung wird ein GET-Request an die Applikation und somit an den IAP gesendet. Ist der Google-Account berechtigt, wird der Benutzer zur gewünschten Applikation weitergeleitet, andernfalls wird mit einer Fehlermeldung seitens des IAP geantwortet. Wird bei dem GET-Request ein ungültiges Cookie verwendet, erfolgt eine Weiterleitung zum Google-Login.

Der Fehler

Anders war dieses Verhalten jedoch, wenn eine POST-Request gesendet wurde. Hier wurde eine Fehlermeldung ausgegeben, bei welcher das Cookie oder der Bearer Token in der Antwort enthalten war.

Wird ein Wert, welcher vom Benutzer manipuliert werden kann, in der Antwort „reflected“, also gespiegelt, ist ein Cross Site Scripting (XSS) meist nicht weit. Auch in diesem Fall konnte das Cookie oder der Bearer Token nahezu beliebig manipuliert werden und der eingeschleuste JavaScript Code wurde vom Base64-Dekodierer des IAP gespiegelt. Folglich wurde der JavaScript Code im Browser ausgeführt.

Nun ist dies ein sogenanntes „Self-XSS“, also ein Cross Site Scripting, womit sich der Angreifer nur selbst angreifen kann, da in der Regel weder ein Cookie noch ein Bearer Token bei einem anderen Nutzer gesetzt werden kann. Die Schwachstelle ist also nur in Verbindung mit anderen Schwachstellen ausnutzbar.

Angriff über Sub-Domain

Unternehmen in der Google-Cloud oder Nutzer von Cloud-Diensten verwenden häufig eine sehr hohe Anzahl verschiedener Domains und darunterliegende Sub-Domains für ihre Dienste. Neben firmeneigenen Servern können solche Sub-Domains auch auf externe Infrastruktur verweisen.

Beispielsweise könnte eine Sub-Domain auf eine auf GitHub betriebene Webseite verweisen (sogenannte GitHub Pages). Wird diese Webseite dann später gelöscht, jedoch das Löschen der Sub-Domain vergessen, so kann ein Angreifer versuchen, die entsprechende Webseite neu zu erstellen. Gelingt dies, so ist der Angreifer in der Lage, unter dieser Sub-Domain eine beliebige Webseite zu betreiben. Für Besucher würde es wirken, als wäre dies eine Webseite des Unternehmens. Dieser Angriff wird „Sub-Domain Takeover“ genannt.

Würde also ein Angreifer eine Sub-Domain derjenigen Domain übernehmen, unter der ein Unternehmen eine durch Google IAP geschützte Webanwendung betreibt, so könnte der Angreifer von dieser Webseite aus Cookies in den Browsern der Benutzer setzen. Diese Cookies können so gesetzt werden, dass sie auch für die übergeordneten Domains gültig sind. Insbesondere könnte ein Cookie GCP_IAAP_AUTH_TOKEN_{cookie_id} mit beliebigem Wert gesetzt werden. Die cookie-id bleibt übrigens bei jedem Kunden gleich und kann mit einem kurzen Loginversuch identifiziert werden. Die cookie_id bleibt übrigens bei jedem Kunden gleich und kann mit einem kurzen Login Versuch identifiziert werden.

Proof of Concept (PoC)

Wir führen nun kurz vor, wie ein solcher Angriff vonstattengehen könnte. Dabei gehen wir von folgendem Szenario aus:

Die it.sec GmbH hat betreibt unter der URL https://iap.itsec.de eine durch Google IAP geschützte, geschäftskritische Webanwendung. Früher gab es eine Sub-Domain https://evil.iap.itsec.de, welche jedoch in Vergessenheit geraten ist. Ein Angreifer hat dies genutzt und unbemerkt Kontrolle über diese Domain erlangt.

Der Angreifer schreibt nun einen Webserver, mit dem er die Benutzer von https://iap.itsec.de angreifen möchte. Der Server wurde in Python geschrieben, siehe hier.

Die Funktionsweise ist wie folgt:

  1. Ein Besucher bekommt bei jeder Anfrage die in den Zeilen 7 bis 12 zu sehende HTML-Seite ausgeliefert. Sie enthält eine HTML-Form, welche einen POST-Request an die Zielseite https://iap.itsec.de auslöst. Außerdem lädt sie eine JavaScript-Datei https://evil.iap.itsec.de/attack.js nach.
  2. Der Webserver des Angreifers liefert bei Anfrage dieser JavaScript-Datei den in Zeile 15 bis 16 gezeigten Code aus. Dieser setzt ein Cookie „GCP_IAAP_AUTH_TOKEN_{cookie_id}“ für die Domain iap.itsec.de, wobei die Cookie ID ein für jede durch IAP geschützte Anwendung eindeutiger Wert ist. Diesen muss der Angreifer vorher durch Besuch von https://iap.itsec.de aus dem Cookie auslesen, den IAP dort setzt.
    Nach Setzen des Cookies sorgt der JavaScript-Code dafür, dass die Form abgesendet, also der POST-Request an https://iap.itsec.de ausgelöst wird.
  3. Der im Cookie enthaltene Wert wird dabei vom IAP dekodiert. Da kein gültiger JWT enthalten ist, gibt der IAP eine entsprechende Fehlermeldung aus, welche den Code
    <script>eval(atob(‚{payload}‘))</script> in die Seite einbettet. Der Payload ist dabei selbst der Base64-kodierter JavaScript-Code alert(„XSS on “ + document.domain). Dieser wird von der Funktion atob dekodiert, danach von eval ausgeführt. Auf diese Weise ist die Ausführung beliebigen JavaScript-Codes möglich. Base64-Kodierung wurde eingefügt, um eventuellen Problemen mit Sonderzeichen entgegenzuwirken.

Die Veröffentlichung der Schwachstelle erfolgte im Coordinated Vulnerability Disclosure Verfahren und somit erst nach der Behebung und offizieller Rückmeldung von Google.

Back To Top