Und wie habe ich das gemacht? Alles begann mit einer Anwendung, die ich entwickelt habe. Aus offensichtlichen Gründen werde ich den Namen nicht veröffentlichen. Die Anwendung ist recht einfach, sie wurde für Fitnessbegeisterte entwickelt und bietet Optionen wie die Eingabe von Geschwindigkeitsdaten während eines Laufs oder vorgefertigte Krafttrainingskomplexe. Wie bei vielen anderen Produkten muss der Benutzer zuerst ein Konto erstellen. Laut Analysten werden etwa 60% der Menschen, anstatt den gesamten Registrierungsprozess zu durchlaufen, von der verlockenden Schaltfläche "Mit Google anmelden" in Versuchung geführt.
Sie wissen wahrscheinlich allgemein, was in solchen Fällen passiert: Wenn der Benutzer auf eine Schaltfläche klickt, wird in der Anwendung ein Browserfenster zum Anmelden bei einem Google-Konto geöffnet.
Für diesen Benutzer ist die Zwei-Faktor-Identifizierung aktiviert. Nachdem er die E-Mail-Adresse und das Kennwort eingegeben hat, wird ein Dialogfeld angezeigt, in dem er gefragt wird, ob er es ist. Der Standort und der Gerätetyp sind identisch, daher klickt er auf "Ja".
Das ist in der Tat alles. Jetzt kann eine Person die Anwendung sicher verwenden, während ich von einem Remote-Server aus uneingeschränkten Zugriff auf ihr Konto erhalte. Er wird niemals irgendwelche Nachrichten darüber erhalten. Und wenn er sich als akribisch herausstellt und anfängt, den Netzwerkverkehr zu untersuchen, wird er feststellen, dass das Gerät Netzwerkanforderungen nur und ausschließlich an verschiedene Subdomains von google.com gesendet hat.
Aber wie ist das überhaupt möglich? Kehren wir zu unserer Schaltfläche "Mit Google anmelden" zurück. Lassen Sie uns gleich eines klarstellen: Für diejenigen, die sich nicht auskennen, kann die Anwendung nach dem Klicken auf diese Schaltfläche alles tun. Starten Sie den Autorisierungsprozess in Google, geben Sie eine Trompetenstimme und zeigen Sie ein GIF mit einer Katze. Nicht alle Optionen aus dieser Liste sind gleich wahrscheinlich, aber Sie können träumen.
In meinem Fall öffnet die Anwendung durch Klicken auf die Schaltfläche ein Dialogfeld mit WebView und legt die Webadresse fest: accounts.google.com/EmbeddedSetup . Es entspricht der Anmeldeseite des Google-Kontos, nur einer speziellen, die für neue Android-Geräte entwickelt wurde. Dieser Umstand wird später eine Rolle spielen, wenn wir freundlicherweise alle notwendigen Informationen in Form eines Cookies erhalten.
Leider sieht diese Seite anders aus und verhält sich anders als die Standard-Anmeldeseite (zumindest so, wie es standardmäßig sein sollte):
Beachten Sie den seltsamen blauen Streifen, die Worte Erfahren Sie mehr und so weiter im rechten Bild.
Und jetzt beginnt der Spaß. Ich verwende die in iOS und Android integrierten Standard-APIs, um einen gut geschriebenen Javascript-Code einzufügen , der die erforderlichen Änderungen vornimmt, damit sich die Seite in Aussehen und Verhalten nicht von der Standard-API unterscheidet.
Die Schlauen werden jetzt denken: "Stop. Wenn Sie also JavaScript-Code einfügen können, was hindert Sie daran, Ihr Login und Passwort einfach direkt aus Textfeldern zu stehlen?" Absolut nichts - im Allgemeinen gibt es zu diesem Zweck bereits einen vorgefertigten Codeexistieren. Heutzutage reicht der Zugriff auf Login und Passwort nicht mehr aus. Sofern Sie kein großes Glück haben, befindet sich der Server nur wenige hundert Kilometer vom Standort des Benutzers entfernt. Andernfalls erhält der Benutzer einen Brief und eine Benachrichtigung mit einer Nachricht über "verdächtige Aktivitäten", und der Hacking-Versuch wird gestoppt. Und die Zwei-Faktor-Authentifizierung macht unser Leben noch schwieriger.
Sprechen wir also über etwas anderes, wie das Master-Token. Auf den ersten Blick sieht es irgendwie unfreundlich aus, aber auf den zweiten - es stellt sich heraus, dass es noch schlimmer ist, als es schien.
Wenn sich das Android-Gerät zum ersten Mal anmeldet, sendet es das von der oben genannten integrierten Anmeldeseite empfangene Token an einen speziellen Endpunkt. Hier ist ein Beispiel für eine typische Anfrage:
POST /auth HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 349
Host: android.clients.google.com
Connection: Keep-Alive
User-Agent: GoogleLoginService/1.3 (a10 JZO54K);gzip
app: com.google.android.gmsapp=com.google.android.gms&client_sig=38918a453d07199354f8b19af05ec6562ced5788&callerPkg=com.google.android.gms&callerSig=38918a453d07199354f8b19af05ec6562ced5788&service=ac2dm&Token=oauth2_4%2F4AY0e-l5vPImYAf8XsnlrdshQQeNir3rSBx5uJ2oO9Tfl17LpsaBpGf1E2euc18UyOc8MnM&ACCESS_TOKEN=1&add_account=1&get_accountid=1&google_play_services_version=204713000
Das Token in dieser Anfrage stammt aus den Cookies der Konto-Anmeldeseite, und alles andere sind Informationen, die öffentlich verfügbar sind (danke, microG !). Dieselbe Konto-Anmeldeseite behandelt Dinge mit Zwei-Faktor-Authentifizierung - wir müssen überhaupt nichts tun.
Danach sendet der oben genannte Endpunkt das gleiche Master-Token. Aber wie würde ich ohne verdächtige Netzwerkanfragen darauf zugreifen können? Ganz einfach: über ein Log in Google Firebase.
Und der Master-Token ist mächtig. Die Gültigkeitsdauer ist unbegrenzt, sofern der Benutzer das Kennwort oder die Zwei-Faktor-Authentifizierungseinstellungen nicht ändert. Soweit ich weiß, unterliegt es keinen Sicherheitsüberprüfungen, unabhängig von Standort, IP und Aktionen. Es provoziert niemals das System, eine Benachrichtigung oder einen Brief an den Benutzer zu senden.
Und vor allem: Es eröffnet mir ausnahmslos den Weg für alle Dienste, die jemals von einem mobilen Gerät im Auftrag des Inhabers des entsprechenden Kontos verfügbar waren. Eine POST-Anfrage reicht aus, um mich als offizielles Google-Konto auszugeben und ein OAuth-Token für den Zugriff auf alles zu erhalten, einschließlich privater (und höchstwahrscheinlich nirgendwo veröffentlichter) APIs. Ich kann E-Mails lesen, Google Drive durchsuchen, Backups von meinem Telefon und Fotos in Google Fotos anzeigen und gleichzeitig den Webverlauf des Benutzers lesen und mit seinen Freunden in Google Messenger chatten. Ich habe sogar eine modifizierte Version von microG erstellt, mit der ich alle diese Benutzerkonten direkt über normale Google Apps verwalten kann.
Und ich Sie daran erinnern, sieht der gesamte Prozess wie folgt aus... Ich lade alle ein, die Frage zu stellen: Würdest du erwischt werden?
Exposition
Wie viele von Ihnen vermutet haben, ist nicht alles in diesem Artikel wahr. Ich habe keine Fitness-Apps im Play Store veröffentlicht und nicht Millionen von Master-Tokens gesammelt. Vielen Dank an diesen Beitrag für die Inspiration. Aber die Methode selbst funktioniert. Ich und jeder andere Entwickler könnten definitiv eine Anwendung mit einer solchen Überraschung erstellen (vielleicht hat es bereits jemand getan).
FAQ
Die Seite unterscheidet sich jedoch vom normalen Login. Ich hätte es bemerkt!
Die Unterschiede sind nicht so auffällig, so dass sie es höchstwahrscheinlich nicht bemerkt hätten. Die Anmeldeseite für das Google-Konto unter Android verfügt normalerweise über eine Benutzeroberfläche zum Auswählen eines Kontos. Es gibt jedoch Ausnahmen - beispielsweise viele Webanwendungen, z. B. solche, die auf Ionic und Cordova erstellt wurden. Die meisten iOS-Anwendungen bevorzugen häufig auch die Webversion, die der obigen Option sehr ähnlich ist. Selbst wenn es Ihnen so scheint, als ob das Fehlen eines Bildschirms mit "so und so eine Anwendung nach Zugriff fragt ..." Sie auf jeden Fall benachrichtigt werden, kann dies auf Kosten einiger zusätzlicher implementiert werden Stunden Arbeit.
Funktioniert das auch unter iOS?
Ich habe es nicht ausprobiert, aber es gibt keinen Grund zu der Annahme, dass es nicht funktioniert.
Und was soll man damit machen?
Im Allgemeinen ist die Frage komplex. Streng genommen fällt keine meiner Handlungen unter die Definition eines Exploits, aber das Ergebnis ist dennoch sehr gefährlich. Für den Anfang möchte Google die Benachrichtigungen "Mit einem neuen Gerät anmelden" sortieren, damit sie einwandfrei funktionieren. Persönlich bekomme ich sie, wenn ich versuche, mich von einem Computer aus in mein Konto einzuloggen, aber während ich diese Anwendung getestet habe, hat das System nie funktioniert. Eine weitere gute Idee ist es, die Richtlinien für die Schaltflächen "Mit Google anmelden" zu aktualisieren . Jetzt sagt es überhaupt nichts über die Implementierungsanforderungen aus. Vielleicht sollten sie durch Dunkelheit tiefer in den Sicherheitsdschungel eintauchen - ein Prinzip, das Apple trotz all seiner Mängel bisher gut für die Sicherheit von iMessage dient.
Ich muss zugeben: Ich bin nicht sicher, ob hier eine technische Lösung gefunden werden kann, die das Problem vollständig beseitigen würde. Wenn die offizielle Google-Anwendung in der Lage ist, Aktionen auszuführen, können Programme von Drittanbietern diese mit der gebotenen Sorgfalt wiederholen. Das Unternehmen beschäftigt jedoch kluge Mitarbeiter. Warten Sie also ab.
Ist dieses Problem für alle Autorisierungssysteme in Anwendungen von Drittanbietern relevant?
Möglicherweise. Ich habe nicht genau verstanden, in welchen Fällen Benachrichtigungen gesendet wurden und in welchen nicht, aber selbst wenn Benachrichtigungen eintreffen, ist ihnen nicht immer klar, was passiert. Die Funktion "Mit Apple anmelden" unterliegt jedoch sehr strengen Richtlinien, und die App Store-Verwaltung (bei der die Funktion meines Erachtens hauptsächlich verwendet wird) überwacht streng die Einhaltung der Anforderungen. Andererseits haben sie ihre eigenen Probleme mit der Autorisierung, gegen die dies verblasst.
Wahre Begebenheit
Selbst wenn es nicht Millionen waren, habe ich wirklich eine kleine Menge Master-Token von ahnungslosen Benutzern gesammelt, und das ganz ungewollt.
Die wahre Geschichte meiner Offenbarung begann, als ich die Carbon Player-Anwendung entwickelte. jetzt ist es bereits in Vergessenheit geraten und hat keine breite Verbreitung erhalten. Die App wurde als Ersatz für Google Play Music konzipiert (erinnern Sie sich an die Tage, als es sie gab?), Nur mit einem viel cooleren Design. Um auf den benutzerdefinierten Musikordner zuzugreifen, habe ich gmusicapi übersetzt Simon Weber in Java, aber beim Umschreiben des Codes habe ich zunächst nicht wirklich verstanden, wie der Autorisierungsprozess dort funktioniert. Ich habe nur festgestellt, dass ich einen Benutzernamen und ein Passwort benötige, die ich über ein einfaches Dialogfeld angefordert habe. Dann kommen einige Anfragen und einige Token, die für mich zum Extrahieren von Musik geeignet sind, fallen heraus.
Bevor ich die erste Version der Anwendung auf eine kleine Gruppe von Testern übertrug, durchsuchte ich den Code, fügte überall Protokollierung hinzu und implementierte auch einen Interceptor, der automatisch alle Protokolle auf Firebase hochladen sollte. Natürlich war ich klug genug, keine Passwörter zu protokollieren, aber ich habe die drei Token zugesagt, die ich versehentlich von meiner gmusicapi-Implementierung erhalten habe. Zwei von ihnen waren ziemlich harmlos - sie gaben nur Zugang zu verschiedenen Musikgeschäften. Aber der dritte erwies sich als Master-Token.
Im Allgemeinen hat die Anwendung während ihres gesamten Bestehens höchstens fünfundzwanzig Downloads gesammelt, und ich winkte schnell mit der Hand, um nicht von meinem Studium abgelenkt zu werden. Zuvor gelang es ihm jedoch, einige Updates zu veröffentlichen, von denen eines eine Neugestaltung der neuen fantastischen (für diese Zeit) Google Play Music-Homepage war - eines der wenigen Elemente des Originalprodukts, die gut aussahen.
Der Prozess erwies sich als viel verwirrender als ich dachte und musste unerwartet viel Reverse Engineering von Protokollpuffern durchführen. Noch wichtiger ist, dass aus irgendeinem Grund jetzt ein völlig anderes Token erforderlich war, das in gmusicapi nicht mehr implementiert war. Um es zu implementieren, habe ich mich daher mehrere Stunden lang in das Autorisierungssystem eingegraben, um herauszufinden, wie es funktioniert. Dies führte zu einem schrecklichen Moment der Offenbarung, als mir klar wurde, dass ich die sensibelsten Informationen aufzeichnete, die ich konnte. Ich werde eins sagen: Die Protokollierung wurde gestoppt. 25 Personen, die die Anwendung heruntergeladen haben, verzeihen Sie mir bitte (ich habe Ihre Token aus Firebase gelöscht!).
Es gab eine andere, die nichts mit dem ersten Mal zu tun hatte, als ich bei einem Startup arbeitete und einen Passwort-Manager erstellte. Einer der Hauptvorteile der Anwendung bestand darin, dass Passwörter ausschließlich auf dem Telefon gespeichert wurden, gleichzeitig aber dank eines JavaScript-Lesezeichens, das Geräte über einen QR-Code „verband“, eine Autorisierung vom Computer aus möglich war. Damit alles reibungslos funktioniert, hat die Anwendung beim Öffnen einer Site auf einem Computer vom Telefon aus auf dieselbe Site zugegriffen und einen sorgfältig geschriebenen JavaScript-Code eingefügt, der Anmeldungen, Kennwörter und alles andere erfasst. Klingt bekannt?
Am Ende kamen diese beiden Ideen in meinem Kopf zusammen. Ich hatte einen Prototyp für Carbon Player, hatte aber nicht genug Zeit, um ihn zum Laufen zu bringen. Ein paar Jahre später begann ich endlich, so etwas wie eine Demoversion auf dieser Basis zu erstellen. Dabei musste viel geändert werden - die in diesem Artikel beschriebene Methode unterscheidet sich erheblich von der im Prototyp implementierten, da Google Änderungen am Autorisierungssystem vorgenommen hat. Aber das Endergebnis bleibt das gleiche und ist nicht weniger beängstigend als damals.
Wenn Sie möchten, können Sie die Demoversion herunterladenund das System in Aktion sehen; Ich gebe mein Wort, dass nichts in der Cloud protokolliert wird. Beachten Sie, dass die Anwendung sehr einfach ist und kaum getestet wurde. Daher besteht eine gute Chance, dass die Methode nicht funktioniert, wenn Ihr Konto eine andere Konfiguration hat. Vielen Dank, dass Sie den Artikel gelesen haben. Ich hoffe, Sie haben sich ein wenig daran erinnert, wie wichtig es ist, alles in Frage zu stellen. Selbst die harmlosesten Dinge verbergen manchmal etwas, das nicht sehr angenehm ist (obwohl es bei Eiscremekuchen umgekehrt ist).