Gerade erst hat Google Neue Tools zum Schutz der Nutzer-Daten angekündigt und ist auch sonst dafür bekannt, dass die eigenen Server eine uneinnehmbare Festung sind. Doch einem Hobby-Hacker ist es nun gelungen, auf gleich drei verschiedenen Wegen in Googles Systeme einzudringen und hatte dabei sogar Zugriff auf intern verwendete Datenbanken. Als Tor hat er ausgerechnet den Bug-Tracker von Google verwenden können, der sich als sehr gesprächig erwiesen hat.
So wie jedes andere größere Unternehmen auch, besitzt Google eine Reihe von internen Systemen, mit denen die Mitarbeiter und Entwickler ihre Arbeit erledigen. Google ist allerdings auch für Dogfood bekannt und setzt auch intern sehr stark auf die eigenen Produkte – und manchmal sogar auf die gleichen Plattformen. Im Fall des Google Issue Tracker verwenden sogar die internen und die externen Systeme die gleiche Datenbank und stellen so ein Einfallstor da.
Dem Entwickler bzw. Hobby-Hacker Alex Birsan ist es mit vergleichsweise leichten Mitteln gelungen, über den Issue Tracker Zugriff auf interne Datenbanken und Inhalte zu bekommen – und zwar nicht auf irgendwelche. Google verwendet den Issue Tracker intern für alle Probleme und Sicherheitslücken und ist damit, wie Birsan schon richtig sagt, ein Heiliger Gral für das Unternehmen, dessen Zugriff von außen natürlich geschützt werden muss. Laut dem Entdecker werden dort etwa 2.000 bis 3.000 Probleme und Lücken pro Stunde (!) gemeldet und diskutiert.
Mit nur wenigen Stunden Bastelarbeit ist es Birsan gelungen, praktischen vollen Zugriff auf diese Datenbank zu bekommen, und hätte alle bekannten und noch nicht gestopften Lücken so ausnutzen können. Aber damit noch nicht genug, denn er konnte sich sogar eine google.com-Adresse registrieren, hatte Zugriff auf das interne System Moma, über das wir schon vor 10 Jahren erstmals berichtet haben, und das sich offenbar seitdem kaum geändert hat.
Um dem ganzen noch die Krone aufzusetzen konnte er sogar über die internen System vollkommen kostenlos ein Taxi bestellen, was er aber vermutlich schlussendlich dann doch nicht getan hat 😉 Insgesamt haben ihm diese Lücken 15.600 Dollar an Prämien für die entdeckten und gemeldeten Bugs eingebracht.
Schritt 1: Einrichtung eines Google-Accounts und Zugriff auf interne Systeme
Barsin hat entdeckt, dass man auch per E-Mail Einträge an den Bugtracker senden kann, wobei eine google.com-Adresse inklusive einer ID des Eintrags zum Einsatz kommt – in dem Format buganizer-system+componentID+issueID@google.com. Das hat er sich zunutze gemacht, und hat sich durch einen weiteren Umweg einen Google-Account mit einer google.com-Adresse angelegt. Als E-Mail-Adresse hat er eine Adresse aus dem Issue Tracker verwendet, so dass die Bestätigungsmail mit dem Aktivierungs-Link direkt an den Tracker ging, von wo aus er diese dann bestätigen konnte. Schon hatte er einen offiziellen Google-Account.
Direkt nach der Bestätigung wurde er zum internen MOMA-System weitergeleitet, konnte sich dort aber – glücklicherweise im Sinne der Sicherheit – nicht einloggen. Mit einer google.com-Adresse hatte bzw. hätte er aber Zugriff auf viele Dinge, die nicht nach außen dringen dürfen, und es wären sicherlich noch unzählige weitere Zugriffe auch aus anderen Diensten möglich gewesen. Da nur Mitarbeiter eine solche Adresse bekommen, hätte er mit etwas mehr Zeit vermutlich noch mehr anrichten können.
Schritt 2: Informationen aus internen Sicherheitslücken
Beim zweiten Versuch es ihm gelungen, Issues mit einer beliebigen ID als Favorit zu markieren. Dazu musste er einfach nur die ID im Javascript austauschen, und schon hatte er das Problem abonniert. Das tat er dann per Script mit einigen Tausend zufälligen IDs und bekam anschließend im Minutentakt E-Mails mit weiteren Informationen von Google-Mitarbeitern, die das Unternehmen eigentlich niemals hätten verlassen sollen.
Natürlich benötigt man vorher die Kenntnis der IDs, aber da man einfach so ins Blaue tausende von IDs abonnieren kann, ist für echte Hacker sicherlich immer wieder mal interessantes dabei.
Schritt 3: Zugriff auf alle intern gemeldeten Lücken
Auch beim letzten Versuch kam wieder ein Script zum Einsatz, bei dem er einfach nur beliebige IDs austauschen musste. Eigentlich war das Skript nur dafür gedacht, die eigene E-Mail-Adresse aus dem System zu entfernen, aber es konnte deutlich mehr. Als Antwort wurde vom Server jeweils der gesamte Fehler inklusive Titel und Beschreibung ausgespuckt, so dass er praktisch Zugriff auf alle Issues bekommen konnte – selbst wenn sie längst nicht mehr aktiv sind und eben nicht mit Methode #2 abgegriffen werden können.
Welcher der drei Fehler nun am schwersten wiegt lässt sich kaum sagen, rein finanziell hat er aber für letztes die größte Belohnung bekommen. Natürlich sind alle Lücken gestopft und funktionieren nicht mehr.
—
Es ist doch schon sehr erstaunlich, dass ausgerechnet eine Datenbank mit solch sensiblen Informationen so leicht zugänglich gewesen ist, und es keine große Sicherheitsmaßnahmen zum Schutz der Daten gibt. Beim Schutz der Daten der Nutzer macht Google einen deutlich besseren Job, allerdings sind auch diese mit einer Auflistung aller offenen Sicherheitslücken auf dem silbernen Tablett nur mehr bedingt sicher. Vielleicht sollte man die Verknüpfung von internen und externen Systemen noch einmal überdenken 😉
» Der vollständige Bericht des Entdeckers