Bi(n)gBang: Microsoft Azure-Schwachstelle ermöglicht Bing Search Hijacking und Office 365-Datenklau

[English]Unschöne Geschichte, auf die alle gewartet haben, und die die Gefahren der Cloud aufzeigt. Microsoftsd Azure-Cloud-Dienste ermöglichten eine Fehlkonfigurierung, die dann eine Sicherheitslücke schuf. In der Folge konnten Angreifer potentiell Schadcode in die Suchergebnisseiten  von Bing einschleusen, um diese zu manipulieren. Zudem wäre es möglich gewesen, mit erbeuteten Bing-Anmelde-Tokens Daten aus Microsoft Office 365-Anwendungen abzugreifen. Wie heißt es so schön: Alles hängt mit allem zusammen. Hier ein Abriss, was gerade bekannt wurde.

Das Bi(n)gBang-Ereignis in Azure

Es wird "als der Bug des Jahres" bezeichnet, eine zulässige Fehlkonfiguration von Microsoft Azure führte zu einer Sicherheitslücke mit gravierenden Folgen. Hillai Ben-Sasson hat das Thema auf Twitter angeschnitten und Jeremy Kirk weist in nachfolgendem Tweet auf den Wiz-Blog-Beitrag BingBang: How a simple developer mistake could have led to Bing.com takeover hin.

Sicherheitsforscher von Wiz beschreiben im betreffenden Dokument einen neuen Angriffsvektor, den sie in Azure Active Directory (AAD) identifiziert haben. Der Angriffsvektor basiert auf einer verbreiteten AAD-Fehlkonfiguration, die falsch konfigurierte Anwendungen für unbefugten Zugriff anfällig macht. Das betraf auch das Content Management System (CMS), das Bing.com betreibt. Als Folge konnten die Sicherheitsforscher die Funktionen von Bing.com übernehmen. Anschließend ließen sich Bing.com-Suchergebnisse ändern. Weiterhin vermuten die Sicherheitsforscher, dass der Diebstahl von Office 365-Anmeldedaten von Millionen von Bing-Nutzern möglich sei. Diese Zugangsdaten gewährten wiederum Zugriff auf die privaten E-Mails und Dokumente der Nutzer. Die Sicherheitsforscher haben der Schwachstelle den treffenden Namen BigBang (ok präzise heißt es "BingBang" – aber BigBang gefällt mir besser) verpasst.

Azure Single Sign On (SSO)

Microsoft bietet seinen eigenen SSO-Dienst (Single Sign On) in Azure an. Azure Active Directory (AAD) ist der gängigste Authentifizierungsmechanismus für in Azure App Services oder Azure Functions erstellte Anwendungen. Die nachfolgende Anmeldeseite haben eigentlich alle Nutzer, die irgend einen Online-Dienst von Microsoft benutzt haben, schon mal gesehen. Man meldet sich über E-Mail und Passwort (oder 2FA) am Microsoft-Konto an und erhält Zugriff auf die Dienste.

AAD bietet dabei verschiedene Arten des Kontozugriffs: mandantenabhängig, mandantenübergreifend, persönliche Konten oder eine Kombination der beiden letzteren. Bei mandantenfähigen Anwendungen können nur Benutzer aus demselben Mandanten ein OAuth-Token für die App ausstellen. Bei mandantenfähigen Anwendungen hingegen kann jeder Azure-Tenant ein OAuth-Token für sie ausstellen. Daher müssen App-Entwickler die Token in ihrem Code überprüfen und entscheiden, welcher Benutzer sich anmelden darf.

Verwirrende Zuständigkeiten

Mit den verwalteten Diensten Azure App Services und Azure Functions können Entwickler/Administratoren eine Authentifizierungsfunktion mit einem Mausklick zum Dienst hinzufügen (siehe folgende Abbildung). Diese komplizierte Architektur ist den Entwicklern der Apps nicht immer klar, und die Verantwortung für die Validierung der Token der Endnutzer ist ebenfalls unklar.

Identy Provider (Quelle: Wiz)

Infolgedessen sind Konfigurations- und Validierungsfehler weit verbreitet. Denn der Dienst stellt nur die Gültigkeit des Authentifizierungs-Tokens sicher. Es ist den Entwicklern und Administratoren der Anwendungen und Dienste meist nicht klar, dass sie die Verantwortung tragen, die Identität des Benutzers über OAuth zu validieren und erst dann den entsprechend Zugriff zu ermöglichen.

Bei der Single-Tenant-Authentifizierung sind die Auswirkungen auf den Tenant der Anwendung beschränkt – schreiben die Sicherheitsforscher. Alle Benutzer desselben Tenants können eine Verbindung zur Anwendung herstellen. Kritisch wird es jedoch bei mandantenfähigen Anwendungen. Denn jeder Azure-Benutzer kann sich mit dem Authentifizierungs-Token bei der Anwendung ohne angemessene Validierung anmelden.

Bing Trivia und der Bi(n)gBang

Als die Sicherheitsforscher diese Probleme und ihre potenziellen Auswirkungen erkannten, begannen sie, das Internet nach offenen Anwendungen zu durchsuchen. Die Ergebnisse haben überrascht: 25 % aller von den Sicherheitsforschern gescannten mandantenfähigen Anwendungen waren anfällig für einen sogenannten Authentifizierungs-Bypass, sprich die Authentifizierung der Benutzer wurde nicht ausreichend geprüft.

Überraschenderweise befand sich auch die von Microsoft selbst entwickelte Anwendung namens "Bing Trivia" in der Liste der anfälligen Produkte. Da diese App falsch konfiguriert war, konnten sich die Forscher mit ihrem eigenen Azure-Benutzer bei ihr anmelden. Dann fanden sie ein Content Management System (CMS), das mit Bing.com verknüpft war.

Um zu überprüfen, ob dieses CMS tatsächlich die Live-Ergebnisse von Bing steuert, wählten sie ein Schlüsselwort im CMS aus und änderten vorübergehend dessen Inhalt. Sie änderte ein Schlüsselwort im CMS in einen eigenen Begriff und stellten fest, dass diese Änderung in den Live-Ergebnissen der Bing.com-Suche ausgegeben wurde. Die manipulierten Ergebnisse mit Titel, Miniaturansicht und beliebigem Link erschien sofort auf Bing.com (siehe folgendes Bild mit dem originalen bing.com-Suchergebnis und dem manipulierten Ergebnis).

Bing.com Ergebnisse: Original links, manipuliert rechts, Quelle: Wiz

Das war bereits der "JackPot", denn ein böswilliger Akteur, der auf der Seite der Bing Trivia-App landete, hätte jeden beliebigen Suchbegriff manipulieren und Fehlinformationskampagnen starten, Malwareseiten verlinken sowie andere Websites fälschen und sich als solche ausgeben können.

Office 365-Anmeldeinformationen von Bing-Benutzern stehlen

Aber es geht noch weiter. Die Wiz-Sicherheitsforscher testeten, ob aus bing.com auch Cross-Site Scripting (XSS)-Angriffe auf Office 365-Anwendungen möglich seien. Bei einem Cross-Site Scripting (XSS)-Angriff werden bösartige Scripte in eine vertrauenswürdige Websites eingeschleust.

Bei ihren Experimenten stellten die Wiz-Leute fest, dass sie mit ihren per XSS injizierten Scripten das Office 365-Token eines jeden Bing-Benutzers kompromittieren konnten. Damit hatten die Forscher den nächsten Jackpot, denn bing.com und Office 365 sind ineinander integriert. Bing verfügt über einen sogenannten Arbeitsbereich ("Work"-Bereich). Dieser ermöglicht es Nutzern ihre Office 365-Daten zu durchsuchen. Um diese Funktion zu implementieren, kommuniziert Bing mit Office 365 im Namen des angemeldeten Benutzers. Die Forscher haben einen XSS-Payload für bing.com erstellt, der die Office 365-Zugangstoken der Benutzer stiehlt.

Ein solches gestohlenes Token könnte ein potenzieller Angreifer den Zugriff auf die Office 365-Daten von Bing-Benutzern ermöglichen. Dazu gehören auch Zugriff auf Outlook-E-Mails, Kalender, Teams-Nachrichten, SharePoint-Dokumente und OneDrive-Dateien. Die Sicherheitsforscher von Wiz haben sich bei Tests auf den eigenen Nutzer beschränkt; es wurden keine Tests mit anderen Bing.com-Nutzern durchgeführt.

Ein böswilliger Akteur mit demselben Zugang hätte die beliebtesten Bing-Suchergebnisse mit derselben Nutzlast kapern und die sensiblen Daten von Millionen von Office 365-Nutzern abgreifen können. Das ist der Super-GAU – und wäre mit der neckischen ChatGPT-Integration, die im Anflug ist, auch nicht zu verhindern gewesen. Die Sicherheitsforscher meldeten ihre Erkenntnisse dem Microsoft Security Response Center (MSRC) und erhielten eine Bug-Bounty-Prämie von 40.000 US-Dollar. Microsoft hat noch am gleichen Tag einen Fix eingespielt und am 29. März 2023 den Support-Beitrag Guidance on Potential Misconfiguration of Authorization of Multi-Tenant Applications that use Azure AD.

Es stellen sich Fragen

An dieser Stelle stellt sich die Frage, ob diese Schwachstelle nicht bereits längst ausgenutzt wurde. Die Zahl der Hacks in letzter Zeit machen da schon nachdenklich. Und was mich ebenfalls umtreibt: Wie ist dieser Vorgang im Sinne der DSGVO für europäische Nutzer einzustufen? Wenn der Zugriff auf E-Mails oder Termine von Office 365-Konten möglich waren, ist dies in meinen Augen ein DSGVO-Vorfall, der von Firmen, die dieses Produkt nutzen, potentiell gemeldet werden müsste.

Und die andere Frage, die mich beschäftigt, lautet: "Haben die Leute die Cloud noch im Griff"? Die Entwicklung wird immer schneller, die IT-Strukturen werden dagegen komplexer. Der obige Sachverhalt zeigt, dass ein einfacher Fehler eines Entwicklers kritische Auswirkungen haben kann. Wie schreiben die Wiz-Sicherheitsforscher: "Die Agilität, mit der wir als Cloud-Entwickler arbeiten, macht uns anfällig für Fehler, weshalb wir den nächsten unvermeidlichen Vorfall vorhersehen sollten. Unsere Widerstandsfähigkeit als Sicherheitsteams hängt davon ab, wie wir diese Fehler auffangen und entschärfen. Die Verhinderung einer versehentlichen Gefährdung sollte eine der wichtigsten Säulen eines jeden Cloud-Sicherheitsprogramms sein." Hier schließe ich den letzten Satz mit "Jungs, diesen Anspruch könnt ihr getrost knicken", denn an dieser Stelle war leider das Geld alle, der Zuständige musste bei der Prüfung gerade wegen Magenverstimmung auf's Klos und überhaupt, der Geschäftsführer meinte "funktioniert doch alles, wozu weiteres Geld ausgeben". Oder wie seht ihr das so?