‍

OAuth Achilles: Die Geheimnisse hinter der Kontoübernahme mit nur einem Klick

‍

Willkommen zurück zu unserer Blogserie: Schwachstelle des Monats! Mit dieser Reihe möchten wir Ihnen Einblicke in unsere tägliche Arbeit und die unserer Hacker geben und über Sicherheitslücken sprechen. Wir hoffen, damit wichtiges Sicherheitswissen über spezifische Schwachstellen zu verbreiten, aufzuzeigen, wie man sie findet und welche Techniken dabei zum Einsatz kommen. So möchten wir das Bewusstsein für die vielen Sicherheitslücken schärfen, die möglicherweise noch unentdeckt sind.

‍

Autor: Der Blogbeitrag dieses Monats wurde verfasst von Cindy Yang

Credits: Die Schwachstelle dieses Monats wurde von dem Hacker supr4s gemeldet

‍

Kontext des Bug-Bounty-Programms

• Ein zeitlich und budgetär begrenztes privates Programm
• Im Scope befinden sich mehrere cloudbasierte Systeme des Kunden
• Zeitraum zwischen Programmstart und Einreichung des Berichts: ca. 1,5 Monate

‍

Warum diese Schwachstelle

‍

Es kann jeden von uns treffen! Durch den unbefugten Zugriff mit nur einem Klick des Opfers kann ein Angreifer persönliche Daten ausnutzen, die Onlinepräsenz manipulieren und erhebliche Störungen verursachen.

‍

Das betroffene System

‍

Eine Website mit einem Kundenbereich und einem Shop – sowie der Möglichkeit, Konten aus einem Drittsystem zu verknüpfen.

‍

Die vom Hacker beschriebene Schwachstelle

‍

‍

Um alles zu verstehen, müssen Sie zunächst wissen, was OAuth ist.

‍

OAuth (Open Authorization) ist eine Methode, mit der Sie einer App oder einem Dienst sicher Zugriff auf Ihre Informationen gewähren können, ohne Ihren Benutzernamen und Ihr Passwort preiszugeben. Es ist, als würden Sie einem Freund einen begrenzten Schlüssel für Ihr Haus geben, ohne ihm den Hauptschlüssel auszuhändigen.

‍

Stellen Sie sich vor, Sie möchten Ihr Konto auf einer Kunden-Website (nennen wir sie Website A) mit einer anderen Website (Website B) verknüpfen. Sie starten den Vorgang auf Website A. Diese leitet Sie zur Anmeldeseite von Website B weiter, wo Sie sicher Ihre Zugangsdaten eingeben. Nach der Anmeldung bittet Website B um Ihre Erlaubnis, Website A Zugriff zu gewähren. Sobald Sie zustimmen, generiert Website B ein eindeutiges Zugriffstoken für Website A. Dieses Token dient als Nachweis Ihrer Autorisierung, ohne Ihre Anmeldedaten offenzulegen.

‍

Um während dieses Prozesses sicherzustellen, dass die Antwort an die Person zurückgeht, die die Anfrage gestellt hat, wird üblicherweise ein State-Parameter verwendet. Dieser Parameter ist in der Regel ein zufälliger Wert, der von der Client-Anwendung erstellt wird und für jede Autorisierungsanfrage einzigartig sein sollte. Sein Zweck ist es, die ursprüngliche Anfrage nachzuverfolgen und sie der entsprechenden Antwort zuzuordnen.

‍

Wenn der State-Parameter fehlt, kann es zu Problemen kommen. Sehen wir uns den Prozess im Folgenden genauer an.

‍

Erstellen Sie zwei Konten auf Website A, eines für den Angreifer (attacker@example.com) und eines für das Opfer (victim@example.com), sowie ein Konto für den Angreifer auf Website B.

Die Vorgehensweise ist wie folgt:

• Der Angreifer meldet sich mit seinem Konto attacker@example.com auf Website A an.
• Der Angreifer verknüpft sein Konto mit seinem Konto auf Website B. Beachten Sie, dass dabei eine GET-Anfrage gestellt wird. Bei der Überprüfung der Anfrage stellen wir fest, dass kein state -Parameter vorhanden ist, was einen CSRF-Angriff ermöglicht.

‍

‍

• Der Angreifer kann nun einen CSRF-PoC erstellen, bei dem es sich um einen Link zu einem Formular handelt, das automatisch eine Anfrage an den OAuth-Autorisierungs-Endpunkt von Website B sendet. Sobald er das Opfer dazu verleitet, auf den Link zu klicken, wird das Konto des Opfers ohne dessen Wissen mit dem Konto des Angreifers auf Website B verknüpft. Nachfolgend finden Sie ein Beispiel für einen CSRF-PoC.

‍

‍

• Wenn sich der Angreifer nun mit seinem Konto von Website B auf Website A anmeldet, wird er zum Konto des Opfers weitergeleitet. Um das Konto des Opfers zu übernehmen, muss er die E-Mail-Adresse des Kontos ändern.

‍

‍

Auswirkungsanalyse

‍

Die Kritikalität ist begrenzt, da das Opfer zunächst dazu verleitet werden muss, auf den manipulierten Link zu klicken. Sobald das Opfer jedoch auf den Link klickt, wird sein Konto auf Website A mit dem Konto des Angreifers auf Website B verknüpft. Im Anschluss kann der Angreifer das Konto des Opfers übernehmen, indem er die E-Mail-Adresse ändert, ohne das aktuelle Passwort zu kennen.

‍

Lassen Sie uns zusammenarbeiten!

Interessieren Sie sich für dieses Thema und möchten Sie gemeinsam mit unseren Kunden und Hackern an solchen Schwachstellen arbeiten? Wir stellen ein – melden Sie sich gerne bei uns.

‍

Interessiert daran, Schwachstellen zu finden? Wir sind immer auf der Suche nach neuen Hacking-Talenten – registrieren Sie sich bitte hier: www.signalfisher.com!