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:
- 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.
-
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. -
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.
Die Aufsichtsbehörden in Hamburg und Bayern haben ausdrücklich darauf hingewiesen, dass Google Analytics-Cookies nur mit Einwilligung gesetzt werden dürfen.
Eine weitere wichtige Aussage in diesem Zusammenhang ist außerdem, dass die Aufsichtsbehörden Google LLC nicht mehr als Auftragsverarbeiter der Website-Betreiber ansehen: „Das Produkt Google Analytics wurde in den vergangenen Jahren so fortentwickelt, dass es in der aktuellen Gestaltung keine Auftragsverarbeitung mehr darstellt. Vielmehr räumt sich Google als Anbieter das Recht ein, die Daten auch zu eigenen Zwecken zu verwenden.“
Die Konsequenz hieraus ist, dass nach Ansicht der Aufsichtsbehörden Google LLC damit aktuell gegen seine eigenen Auftragsverarbeitungsbedingungen (Ziffer 5.2, Weisungsgebundenheit) verstoßen würde. Leider sind bislang aus dieser Auffassung keine sichtbaren Schritte seitens der Aufsichtsbehörden gegen Google LLC an die Öffentlichkeit gedrungen.
Website-Betreibern ist zu empfehlen, sich den Einsatz von Google Analytics gut zu überlegen. Zwar haben die Aufsichtsbehörden immer wieder beteuert, man werde sich zunächst an die Hersteller/Anbieter wenden, wenn diese für die Vertragsgestaltung verantwortlich sind (so zum Beispiel auch im Zusammenhang mit Microsoft), allerdings ist das datenschutzrechtliche Verhältnis zwischen Website-Betreiber und Google LLC zumindest ungeklärt und damit auch angreifbar.
S. Kieselmann
Senior Consultant Datenschutz
Dipl.sc.pol.Univ.
Selbst für Amnesty sind Facebook, Google & Co. mittlerweile ein großes Thema.
In einem entsprechenden Bericht kritisiert Amnesty, dass sich diese Unternehmen mit ihren Plattformen und Diensten in fast jeden Winkel des digitalen Lebens von Menschen eingeschlichen haben.
Mehr als 4 Milliarden Menschen kommunizieren fast tagtäglich über das Internet, beruflich oder privat, sie verabreden und „versammeln“ sich dort. Die dabei notwendigen Dienste und Werkzeuge (Web-Browser, Suchmaschinen, Messenger-Dienste, Social-Media- und Video-Plattformen, Cloud-Speicher, Smart Speaker etc.), erhalten sie von den sog. Internet-Giganten. Im Gegenzug erlauben die Nutzer, dass ihre Daten und damit ihre Kommunikation stetig überwacht wird.
Sogar Personen, die ihre Dienste gar nicht nutzen, sind vor der Erfassung ihrer Daten nicht sicher, bspw. weil sie in den Kontaktverzeichnissen der Nutzer auftauchen oder auf Websites surfen, wo Tracking-Software implementiert ist.
Dabei werden nicht nur Daten über den einzelnen Menschen gesammelt, sondern auch von allen Seiten zusammengeführt, angereichert und algorithmisch ausgewertet. Dadurch sichern sich die Unternehmen gegenüber dem einzelnen Menschen eine informationsasymmetrische Machtposition, an der auch andere gerne teilhaben möchten und auch tatsächlich teilhaben - Stichwort Cambridge Analytica.
Der Bericht fordert daher die Unternehmen auf, die von ihnen verursachten Menschrechtsverletzungen endlich zu beheben. Die Regierungen werden aufgefordert, strengere Gesetze zu schaffen und deren Geltung auch durchzusetzen - denn die Selbstregulierung der Unternehmen hat bisher nur mäßig funktioniert.
Fazit: Die Datenschutzgrundverordnung ist da ein erster Schritt. Denn sie gilt auch für Facebook, Google und Co., wenn sie auf dem Markt der EU tätig werden. Allerdings mangelt es oftmals an der Durchsetzung. Entweder geht dies zu Lasten der Unternehmen in der EU, denen es an wirtschaftlichen Alternativen zu den Produkten der Anbieter mangelt, oder zu Lasten der für sie zuständigen Aufsichtsbehörden, die sich teils wohl in Sisyphusarbeit um Lösungsabsprachen im Interesse aller mit den Anbietern bemühen. Dies kann nur verbessert werden, wenn weltweit Regelungen wie in der Datenschutzgrundverordnung gelten würden.
S. Kieselmann
Beraterin für Datenschutz
Dipl.sc.pol.Univ.
Verwendet ein Internetnutzer die Google-Suchmaschine, wird seine Suche zu der jeweiligen Domain des Staates weitergeleitet, welche anhand seiner IP-Adresse identifiziert wird. Nutzt er also eine IP-Adresse, die ihn bspw. in Frankreich ansässig erscheinen lässt, werden ihm ggf. Einträge zu einem anderen Menschen gar nicht erst angezeigt, wenn er diesen anhand von dessen Namen sucht.
So musste Google gemäß der Entscheidung des EuGH vom 13.05.2014 Einträge zu einem Betroffenen, die ihn namentlich erwähnten samt Angaben zu seinen Schulden, „auslisten“. Die Links zu von Dritten veröffentlichten Internetseiten mit Informationen zu ihm tauchten dann in der Ergebnisliste auf die entsprechende Suchanfrage hin nicht mehr auf.
Mit seinem Urteil vom 24.09.2019 hat der EuGH nun klargestellt, wie weit diese „Löschpflicht“ von Google reicht: Hat eine betroffene Person ein Recht auf eine solche Auslistung, ergibt sich damit noch nicht, dass dieses Recht über das Hoheitsgebiet der Mitgliedstaaten hinausgeht. Das bedeutet, dass die Einträge zu dieser Person erst einmal weiterhin über Domains anderer Staaten, die keine EU-Mitglieder sind, abrufbar bleiben. Google muss die entsprechenden Einträge dort nicht auslisten, sondern nur wirksam verhindern, dass Internetnutzer in EU-Mitgliedstaaten diese Einträge in ihrer Ergebnisliste auffinden.
Der EuGH weist aber darauf hin, dass eine Aufsichtsbehörde dennoch in Einzelfällen befugt sein kann, Suchmaschinenbetreiber wie Google anzuweisen, die Einträge in allen Versionen ihrer Suchmaschine auszulisten, wenn eine Grundrechtsabwägung ergibt, dass das Recht der betroffenen Person auf Achtung ihres Privatlebens und auf Schutz der sie betreffenden personenbezogenen Daten höher zu werten ist als das Recht auf freie Information.
S. Kieselmann
Beraterin für Datenschutz
Die SPD befürwortet ein Daten-Für-Alle-Gesetz.
Hintergrund ist wohl, trotz strenger datenschutzrechtlicher Bestimmungen am digitalen Fortschritt ebenso teilnehmen zu können wie Diktaturen und Staaten mit nicht angemessenem Datenschutzniveau.
Daten bedeuten Macht und entsprechend soll das Datenmonopol der digitalen Konzerne wie Google, Facebook und Co. mit einem solchen Gesetz aufgelöst werden, indem sie gezwungen werden, „ihre“ Daten der Allgemeinheit zur Verfügung zu stellen.
Als „kollektive“ Daten und damit Allgemeingut sollen sie dann „zum Wohl des Einzelnen und für unsere Gemeinschaft“ genutzt werden, um Innovationen bspw. auf dem Gebiet der Künstlichen Intelligenz zu fördern und europäische Unternehmen wettbewerbsfähig zu halten („Prinzip von Open Data“).
Statt „exklusive[r] Eigentumsrechte“ soll es „darum gehen, den Zugang zu Daten zu verbreitern.“
Das Recht auf informationelle Selbstbestimmung „macht den Einzelnen grundsätzlich zum Herrn der ihn betreffenden Daten“ (Gola/Schomerus, BDSG, 11. Auflage § 1 Rn 10). Die „Eigentumsverhältnisse“ sind eigentlich somit klar.
Auch wenn das „grundlegende Recht auf Datenschutz der Einzelnen“ durchgehend betont wird:
Konzerne wie Facebook verdienen nicht deshalb so viel Geld, weil sie vollständig anonymisierte und damit eben keine personenbezogenen Daten verarbeiten; Skandale wie Cambridge Analytics haben dies immer wieder gezeigt. Im besten Fall handelt es sich um zunächst einmal pseudonymisierte Daten, die sich aufgrund ihrer Menge und der Hinzuspeicherung von Daten aus einer Vielzahl von Quellen leicht zu personenbezogenen Daten verdichten können.
Mit dem Konstrukt der „kollektiven Daten“ aus dem Bestand der digitalen Großkonzerne wirkt die Idee eines Daten-Für-Alle-Gesetzes auf den ersten Blick daher eher wie ein latenter Vorwurf an den Datenschutz (zwar nett, aber im Zeitalter von Post Privacy veraltet) und ein Hofieren der Innovationskraft von Google, Facebook und Co., an der man teilhaben möchte.
S. Kieselmann
Beraterin für Datenschutz
Dipl.sc.pol.Univ.
Die Datenschutzgrundverordnung (DSGVO) ist gut ein halbes Jahr alt. Die anfängliche Aufregung war spürbar, doch seit ein paar Monaten ist es ruhiger geworden um die DSGVO. Nun wurde aber das erste ernstzunehmende europäische Bußgeld für Google erlassen.
Google soll in Frankreich insgesamt 50 Millionen Strafe zahlen. Die französische Datenschutzbehörde CNIL stellte eine Vielzahl von Verstößen gegen die DSGVO fest.
Informationen zur Verarbeitung der erhobenen Daten und der Speicherdauer sind für die Nutzer nur schwer zugänglich, erklärte die französische Datenschutzbehörde am Montag. Die Informationen sind in mehreren Dokumenten verteilt. Auch ist Vieles unklar formuliert.
Zudem ist nach Ansicht der Aufsichtsbehörde die von Google eingeholte Einwilligung zur Anzeige von personalisierter Werbung nicht rechtskonform. Die Einwilligenden werden nicht ausreichend informiert.
Google wolle nun nach einer ausführlichen Prüfung des Bescheides die Transparenz bzgl. der Daten erhöhen.
Dr. Bettina Kraft
Teamleitung und Senior Consultant für Datenschutz
Volljuristin
Die größten Browserhersteller Mozilla, Google, Apple und Microsoft haben angekündigt, dass ihre Browser ab 2020 die älteren Versionen von TLS, nämlich TLS 1.0 und TLS 1.1, nicht mehr unterstützen. Das bedeutet, dass Seiten, die nicht mindestens TLS 1.2 unterstützen, dann nicht mehr aufrufbar sein könnten, mindestens aber als unsicher markiert werden.
Dies wurde von den Browserherstellern zeitgleich bekannt gegeben. Nachdem nun von Chrome auch Seiten ohne HTTPS als "nicht sicher" klassifiziert werden, ist dies ein weiterer Schritt, um Benutzer sicherer surfen zu lassen.
Grund für die Abschaffung sind hauptsächlich schwache Hash-Verfahren wie beispielsweise MD5 und SHA1, welche momentan beide gebrochen werden können. Sollte ein Angreifer also lesend Zugriff auf Netzwerkverkehr erhalten, so kann er versuchen, die Verschlüsselung zu brechen. Hierdurch erhält er unter Umständen Zugriff auf sensible Informationen seines Opfers, beispielsweise die Zugangsdaten.
Außerdem bieten die alten TLS Versionen weitere Angriffsmöglichkeiten, wie z. B. BEAST oder POODLE.
Momentan stellen Verbindungen, welche mit TLS 1.0 und TLS 1.1 gesichert werden, allerdings nur einen verschwindend geringen Anteil dar: laut Google's Security Blog werden nur 0.5% aller HTTPS-Verbindungen mit TLS 1.0 oder TLS 1.1 aufgebaut. Da TLS 1.2 schon 2008 als Empfehlung galt, war genug Zeit, um auf die neueren Versionen umzustellen.
Tatsächlich spielt nicht nur die verwendete Version des TLS-Protokolls eine Rolle, sondern auch die angebotenen Cipher. Unter einem Cipher versteht man die bei SSL/TLS eingesetzte Kombination von Verschlüsselungs-, Signatur- und Hashverfahren. Werden diese zu schwach gewählt, kann die Verschlüsselung potenziell gebrochen werden. Zwar wird standardmäßig der stärkste verfügbare Cipher zwischen Client und Server ausgehandelt, jedoch kann ein Angreifer hier eingreifen und eine sehr schwache Verbindung zwischen seinem Opfer und dem Server erzwingen. Diese Attacken werden "TLS Protocol Downgrade Attacks" genannt.
Christian Stehle
IT Security Consultant
Bei Google Analytics handelt es sich um ein Instrument zum Webtracking bzw. zur Reichweitenanalyse im Internet, mit dem das Surfverhalten der Webseitennutzer anhand der über diese erhobenen Daten (Online-Kennzeichnungen (einschließlich Cookie-Kennungen), Internet-Protokoll-Adressen und Gerätekennungen, vom Webseitenbetreiber vergebene Kennzeichnungen) zu Zwecken der bedarfsgerechten Gestaltung der Webseiten analysiert werden kann. Um einen datenschutzkonformen Einsatz des Analysetools Google Analytics gewährleisten zu können, sind eine Reihe von Maßnahmen durch den Webseitenbetreiber (= Verantwortlicher i.S.v. Art. 4 Nr. 7 DSGVO) zu ergreifen.
Insbesondere muss ein Vertrag zur Auftragsverarbeitung zwischen dem Webseitenbetreiber und dem Anbieter von Google Analytics abgeschlossen werden. Der bisher von Google Inc. zur Verfügung gestellte Vertrag entspricht noch nicht den Vorgaben von Art. 28 DSGVO. Daher stellt Google LLC (vormalige Bezeichnung Google Inc.) nun unter https://privacy.google.com/businesses/processorterms/ sog. „Auftragsdatenverarbeitungsbedingungen“, die alle Regelungsinhalte aus Art. 28 DSGVO enthalten, zur Verfügung, denen die Webseitenbetreiber, die Google Analytics einsetzen, in ihren Kontoeinstellungen zustimmen müssen.
Der Webseitenbetreiber muss des Weiteren zustimmen, dass Daten der Webseitennutzer auch außerhalb der EU/EWR übermittelt werden. Diese Datenübermittlungen in Drittstaaten sollen gemäß den Auftragsdatenverarbeitungsbedingungen jedoch abgesichert sein durch die seit dem 26.09.2016 bestehende Privacy Shield-Zertifizierung der Google LLC sowie ihrer hundertprozentigen Tochtergesellschaften (https://www.privacyshield.gov/participant?id=a2zt000000001L5AAI&status=Active).
Es bleibt abzuwarten, wie sich der Hamburgische Beauftragte für Datenschutz und Informationsfreiheit, mit dem der bisher von Google zur Verfügung gestellte Vertrag zur Auftragsverarbeitung abgestimmt wurde, zu den neuen Auftragsdatenverarbeitungsbedingungen äußern wird.
S. Kieselmann
Beraterin für Datenschutz
Dipl.sc.pol.Univ.