Einführung
Bei unserer Tätigkeit ist es oft so, dass unsere Boltonshield-Experten immer wieder dasselbe System testen, auch wenn die zeitlichen Abstände zwischen den einzelnen Analysen manchmal größer werden. Häufig gibt es zwischen zwei Tests auch signifikante Veränderungen an dem getesteten System. In dieser Fallstudie beschreiben wir kurz unsere Schwachstellenüberprüfung einer Anwendung, bei der sich leider eine gravierende Schwachstelle in der neuen Anwendungsversion zeigte.
Unser Kunde hat mehrere beliebte Webdienste entwickelt. Er wollte die Berechtigungen der Anwendungen über eine gemeinsame Plattform laufen lassen und entschied sich daher für die Verwendung des offenen Standards OAuth 2.0. Die Anwendungen des Kunden erwiesen sich bisher als äußerst sicher, sodass er davon ausging, eine Schwachstellenüberprüfung der neuen Anwendungen nach der Live-Schaltung würde ausreichen.
Unsere ersten Eindrücke
OAuth 2.0 ist ein offener Standard, also eigentlich eine Ansammlung an Empfehlungen. Deshalb enthält er keine strengen Vorschriften bezüglich der Umsetzung einzelner Punkte. Im Hinblick auf die Sicherheit enthält der OAuth-Standard bekannte kritische Punkte, die von Entwicklern oft falsch umgesetzt werden. Solche Mängel können leicht dazu führen, dass die Konten der Benutzer geknackt werden.
Es gibt einige beliebte und frei zugängliche OAuth-2.0-Implementierungen, deren Nutzung den Entwicklern das Leben deutlich leichter machen kann. Sie können verwendet werden, um die Entstehung mehrerer typischer Schwachstellen zu vermeiden. Jedoch wurde uns bereits zu Beginn des Tests klar, dass es sich hier um eine individuelle Implementierung handelte. Dementsprechend war die Überprüfung auf solche bekannten Schwachstellen besonders wichtig.
Wie sah die Implementierung des Kunden aus?
Das durch OAuth 2.0 festgelegte Modell umfasst zwei Akteure:
- Autorisierungsserver
- Clients (Client-Anwendungen)
Der Autorisierungsserver verwaltet die Berechtigungsanfragen seitens der Clients. Dazu stellt er dem Benutzer eine Anmeldeseite zur Verfügung, die zu ihm führt, und erzeugt Codes und Tokens, die für die Berechtigung verwendet werden. Diese werden anschließend überprüft. Einige bekannte Beispiele, die den OAuth-2.0-Authentifizierungsdienst nutzen, sind Google, Facebook, Microsoft und Linkedin. Werden diese genutzt, kann auch die Anmeldung an unserer Anwendung per Google- oder Facebook-Konto erfolgen.
Clients sind die Anwendungen, die einen bestimmten Autorisierungsserver nutzen. Wenn sich der Benutzer anmelden möchte, leitet ihn die Client-Anwendung auf die Anmeldeseite, die vom Autorisierungsserver zur Verfügung gestellt wird. Nach der erfolgreichen Anmeldung kann der Benutzer auf der vom Autorisierungsserver zur Verfügung gestellten Seite, dem Zugriff auf die Client-Anwendung zustimmen. Dann leitet der Autorisierungsserver den Benutzer an die Seite weiter, die vom Client vorab zur Verfügung gestellt wurde.
Unser Kunde verwendete eine Hybridlösung in seinem System. In den unterschiedlichen Client-Anwendungen hatten die Benutzer getrennte gültige Konten, aber sie konnten diese mit einem zentralen Konto verknüpfen. Diese praktische Funktion ermöglicht die einmalige Anmeldung: Man muss sich nur ein einziges Mal am zentralen Autorisierungsserver anmelden.
In der Client-Anwendung stößt der Benutzer die Verknüpfung des Kontos mit dem zentralen Konto an. Danach wird er zum Autorisierungsserver weitergeleitet, wo er der Verknüpfung der Konten auf der vom Autorisierungsserver zur Verfügung gestellten Seite zustimmen kann. Im nächsten Schritt wird der Benutzer mit einem Autorisierungscode wieder zu der Client-Anwendung weitergeleitet. Im Hintergrund schickt die Client-Anwendung diesen Autorisierungscode an den Autorisierungsserver, der ihn überprüft. Ist der Autorisierungscode gültig, ist der Prozess abgeschlossen und die beiden Konten sind verknüpft.
Was die Entwickler nicht berücksichtigt hatten
Im Laufe der Schwachstellenüberprüfung der Anwendung stellten wir fest, dass der Autorisierungsserver den Benutzer mit einem Autorisierungscode an die Anwendung weiterleitet, der mittels GET-Anforderung zur Verfügung gestellt wird. Der Autorisierungsserver prüft jedoch nicht, ob der Benutzer den Prozess tatsächlich selbst gestartet hat.
Diese Art der Schwachstelle ist allgemein als Cross-site Request Forgery (CSRF) bekannt. Ein Angreifer muss lediglich ein Konto in der Anwendung und auf dem Autorisierungsserver erstellen, die Verknüpfung dieser beiden Konten anstoßen und am Ende des Prozesses die Anforderung abfangen, mit der der Autorisierungsserver den Benutzer zu der Client-Anwendung weiterleitet. Dann wäre es ihm ein Leichtes, mit der abgefangenen Anforderung einen Link zu erstellen. Wenn ein angemeldeter Benutzer diesen Link aufruft, stimmt er unwissentlich der Verknüpfung seines Kontos mit dem Konto des Angreifers zu.
Beispiel für einen gefährdeten Link: https://xxxxxxxx.app.com/oauth/callback/code=457adXy84Ydasdf
Indem sich der Angreifer diesen Fehler zunutze macht, kann er sich sogar ohne Autorisierungsdaten an dem Konto des Benutzers anmelden. Das bedeutet, das Benutzerkonto ist gefährdet.
Obwohl ein solcher Angriff zunächst kompliziert wirkt, wird bei genauerer Überlegung klar, wie einfach die Ausführung tatsächlich ist. Der Angreifer muss das Opfer nicht dazu bringen, den Link direkt aufzurufen. Er kann den Link in eine andere Seite einbetten, um nicht das Misstrauen des Benutzers zu wecken, denn das Starten einer GET-Anforderung reicht aus. Bei vorhandenen Cross-site-Scripting-Schwachstellen kann der Angriff sogar ausgeführt werden, ohne dass der Benutzer das Geringste bemerkt.
Nach den Tests
Unseren Erfahrungen zufolge wird die echte Gefahr aufgrund von Cross-site-Scripting-Schwachstellen oft unterschätzt. In vielen Fällen sind sich nicht einmal die Entwickler bewusst, wie leicht eine solche Schwachstelle ausgenutzt werden kann und wie schwerwiegend die Folgen sein können. Deshalb beschlossen wir nach der Schwachstellenüberprüfung der Anwendungen zusätzlich zum sofortigen Fehlerbericht eine kurze Demonstration zu zeigen. Mit der Demonstration konnten wir unseren Kunden von der bestehenden Gefahr in diesem Fall überzeugen und der Kunde beschloss, die von uns vorgeschlagenen Sofortmaßnahmen zu ergreifen.
Durch Ausnutzung der aufgedeckten Schwachstelle waren die Konten von Tausenden Benutzern gefährdet. Die Sofortmaßnahmen waren also gerechtfertigt. Zum Glück ermöglichte das eingesetzte Versionsmanagementmodell unserem Kunden, relativ schnell zu einer früheren Version zurückzukehren. Bis zur Behebung des Fehlers mussten die Benutzer lediglich auf den Komfort des zentralen Kontos verzichten.
Unsere Experten arbeiteten bei der Korrektur dieses Sicherheitsmangels eng mit den Entwicklern zusammen. Sie leisteten Unterstützung für eine schnelle und gründliche Behebung der erkannten Schwachstellen.
Unser Kunde wollte ähnlichen Problemen in der Zukunft vorbeugen. Deshalb bat er uns, eine Schulung für Entwickler zum Thema Schwachstellen von OAuth 2.0 und einzuhaltende Sicherheitsvorschriften in seinem Haus abzuhalten. Wir sind stolz darauf, dass auch mehrere andere Schulungen durch unser Team nachgefragt wurden. Die Schwachstellenüberprüfung der Anwendung führte dazu, dass sich das System unseres Kunden und das Bewusstsein seiner Entwickler für Sicherheitsthemen deutlich verbessert haben.
Treten Sie mit uns in Kontakt, um herauszufinden, wie Boltonshield auch Ihrem Unternehmen helfen kann.