Das Sicherheitsforschungsteam von Obsidian Security hat einen bedeutenden OAuth 2.0-Implementierungsfehler in mehreren Unified-API-Integrationsplattformen, wie z.B. Merge.dev, aufgedeckt. Diese Schwachstelle ermöglicht es Bedrohungsakteuren, sich als verifizierte OAuth-Anwendungen (Open Authorization) dieser Plattformen auszugeben, wodurch sie OAuth-Phishing-Angriffe auf verschiedene SaaS-Anwendungen durchführen können. Diese Entdeckung weist auf eine kritische Schwachstelle im Ökosystem der API-Integration hin, die weitreichende Folgen für die SaaS-Sicherheit haben kann.

Warum das wichtig ist:

Diese Sicherheitslücke birgt mehrere Risiken:

  • Unbefugter Datenzugriff: Angreifer können OAuth-Tokens ausnutzen, um über mehrere SaaS-Anwendungen hinweg ohne ordnungsgemäße Autorisierung auf sensible Daten zuzugreifen.
  • Erhöhter Phishing-Erfolg: Mit verifizierten OAuth-Anwendungen können Angreifer das Vertrauen von Endbenutzern gewinnen und so die Erfolgsquote von Phishing-Versuchen erhöhen.
  • Multiplattform-Schwachstelle: Die Schwachstelle ist nicht auf eine bestimmte Plattform beschränkt, sondern ähnelt einem systemischen Problem.

Was sind API-Integrationsplattformen und warum sind sie wertvoll?

Einheitliche API-Integrationsplattformen (Unified API Integration Platforms, UAIPs) sind Tools zur Rationalisierung des Integrationsprozesses mehrerer SaaS-Anwendungen. Sie fungieren als zentralisierte Hubs, die es Entwicklern ermöglichen, verschiedene Anwendungen wie HRIS, ATS, Buchhaltungssysteme, CRMs und mehr über eine einzige Schnittstelle zu verbinden. Indem sie vorregistrierte OAuth-Anwendungen mit zugewiesenen Berechtigungen anbieten, vereinfachen UAIPs die oft komplexe Aufgabe der Verwaltung mehrerer APIs. API-Integrationsplattformen sind aus mehreren Gründen wertvoll:

  • Vereinfachung der API-Verwaltung: Diese Plattformen ermöglichen Entwicklern die Verwaltung von API-Schlüsseln, Dienstkonto-Anmeldeinformationen und OAuth-Integrationen von einem einzigen Ort aus. Dies reduziert den Zeit- und Arbeitsaufwand für das Einrichten und Pflegen von Verbindungen zwischen verschiedenen Anwendungen.
  • Vereinheitlichte API-Vorgänge: Durch die Abstrahierung gängiger API-Vorgänge in ein standardisiertes Format machen UAIPs es für Entwickler überflüssig, sich mit mehreren APIs und Protokollen vertraut zu machen. Diese Einheitlichkeit vereinfacht die Entwicklung und beschleunigt die Integrationsprozesse.

Worin besteht also das Problem?

Das Risiko eines Missbrauchs ergibt sich aus dem unzureichenden CSRF-Schutz (Cross-Site Request Forgery) in vielen UAIPs. Um dieses Problem zu verstehen, wollen wir uns einen typischen Integrationsprozess ansehen und herausfinden, wo Schwachstellen auftreten.

Typischer Integrationsprozess:

  1. Autorisierungsanfrage: Die UAIP erstellt einen Autorisierungslink für den OAuth-Server der Zielanwendung und fordert den Zugriff auf die Daten des Benutzers über seine zuvor registrierte OAuth-Anwendung an.
  2. Benutzer-Aktion: Der Endbenutzer klickt auf den Autorisierungslink, authentifiziert sich und gewährt den Zugriff auf den OAuth-Server der Zielanwendung.
  3. Autorisierungscode: Der OAuth-Server gibt einen Autorisierungscode aus und leitet ihn über den Browser des Benutzers an das UAIP zurück.
  4. Token-Austausch: Das UAIP tauscht diesen Autorisierungscode gegen ein Zugriffstoken aus und verknüpft es mit dem Konto des Benutzers.
  5. Datenzugriff: Der Benutzer verwendet die einheitliche API der UAIP, um Daten aus integrierten Anwendungen abzurufen, wobei die UAIP die Daten unter Verwendung des Zugangstokens des Benutzers abruft.

Die Schwachstelle:

Das Problem tritt auf, wenn Benutzer 1 den Autorisierungslink an Benutzer 2 sendet, der dann die Autorisierung abschließt. In diesem Fall funktioniert die Integration zwar noch, aber das Zugriffstoken von Benutzer 2 kann unzulässigerweise an das UAIP-Konto von Benutzer 1 gebunden sein. Folglich kann Benutzer 1 über die vereinheitlichte API von UAIP auf die Daten von Benutzer 2 zugreifen.

Technische Panne:

Das Kernproblem besteht darin, dass die UAIP nicht überprüft, ob der Benutzer, der die Autorisierung einleitet, derselbe ist wie der, der sie abschließt. Anfällige UAIPs interpretieren den „Status“-Parameter im Autorisierungslink falsch.

OAuth 2.0-Spezifikation: Der „state“-Parameter sollte mit den Sitzungsdaten des Benutzers im Backend verknüpft und an den Sitzungs-Cookie gebunden sein, nicht nur ein eigenständiger Wert sein. Gemäß der OAuth 2.0 Spezifikation:

„Der Client MUSS einen CSRF-Schutz für seine Umleitungs-URI implementieren. Dies geschieht in der Regel durch die Aufnahme eines Wertes, der die Anfrage an den authentifizierten Zustand des User-Agents bindet (z. B. ein Hash des Session-Cookies). Der Client SOLLTE den Parameter „state“ verwenden, um diesen Wert an den Autorisierungsserver zu senden. Sobald die Autorisierung erteilt wurde, leitet der Autorisierungsserver den User-Agent mit dem Bindungswert im „state“-Parameter an den Client zurück. Dadurch kann der Client die Gültigkeit der Anfrage überprüfen, indem er den „state“-Parameter mit dem authentifizierten Status abgleicht. Der für den CSRF-Schutz verwendete Bindungswert MUSS nicht ermittelbar sein und sicher gespeichert werden.

Kurz gesagt, das Fehlen eines angemessenen CSRF-Schutzes in UAIPs kann zu unbefugtem Datenzugriff führen, was unterstreicht, wie wichtig es ist, den „state“-Parameter korrekt zu implementieren und zu verifizieren, um vor solchen Schwachstellen zu schützen.

Proof of Concept

In der Demo haben wir Merge.dev als Beispiel verwendet, um einen Google Drive-Phishing-Angriff durchzuführen. Normalerweise ist dies schwierig zu bewerkstelligen, da Google eine strenge Überprüfung für OAuth-Anwendungen durchsetzt, die sensible Berechtigungen anfordern, bevor sie von der Allgemeinheit genutzt werden können. Mit der verifizierten OAuth-Anwendung von Merge.dev ist es uns jedoch gelungen, diese Einschränkungen zu umgehen:

Video unter https://www.obsidiansecurity.com/blog/oauth-phishing-threat-exploiting-saas-integration-platforms/

Das Gesamtbild:

Verifizierte OAuth-Anwendungen mit hohen Berechtigungen sind Hauptziele für OAuth-Phishing-Angriffe. UAIPs bieten vorregistrierte OAuth-Anwendungen, von denen viele bereits von OAuth-Autorisierungsservern wie Azure AD und Google verifiziert sind. Diese verifizierten Anwendungen gewinnen leicht das Vertrauen der Nutzer, was die Erfolgsquote von Phishing-Angriffen deutlich erhöht.

UAIPs stellen außerdem eine einheitliche API zur Verfügung, die es böswilligen OAuth-Anwendungen ermöglicht, eine Vielzahl von Operationen durchzuführen. Einmal integriert, können diese Plattformen Angreifern automatisch dabei helfen, Zugangstoken zu pflegen und zu aktualisieren. Einige UAIP-OAuth-Anwendungen können bereits von den Entwicklern genehmigt worden sein, was eine heimliche Kompromittierung mit einem Klick ohne Benutzerinteraktion ermöglicht.

Seit dem 9. November 2020 blockiert Azure AD die Zustimmung der Endbenutzer für neu registrierte und nicht verifizierte mandantenfähige OAuth-Anwendungen. UAIPs, die keine verifizierten OAuth-Anwendungen anbieten, können jedoch immer noch für Phishing-Angriffe mit Azure-Anwendungen, die vor dieser Regelung registriert wurden, ausgenutzt werden.

Mit ihrer breiten Unterstützung für Anwendungen und vertrauenswürdige Attribute können anfällige UAIPs als Waffe eingesetzt werden, um effektivere Phishing-as-a-Service-Plattformen im Vergleich zu bestehenden Tools wie dem o365-Attack-Toolkit zu schaffen.

Wie kann ich diese Art von Angriff verhindern?

Um diese Art von Angriff zu verhindern, sollte der Statuswert bei der Initiierung der Autorisierungsanfrage-API in der Sitzung des aktuellen Benutzers gespeichert werden. Hier ist eine gängige Praxis mit Pseudocode:

Beim Empfang der Autorisierungsantwort wird der Benutzer überprüft, indem der Statuswert im Anfrage-URI mit dem in der Benutzersitzung gespeicherten Statuswert abgeglichen wird:

Abschließende Überlegungen

Wir haben festgestellt, dass neben der Demoplattform auch drei andere Unified-API-Integrationsplattformen für das gleiche Problem anfällig sind, das wir behandelt haben. Dies verdeutlicht, wie verbreitet und oft übersehen CSRF-Integrationsschwachstellen sind. Wir hoffen, dass dieser Blog diese Risiken ans Licht bringt und die technische Gemeinschaft dazu anregt, diese Bedrohungen proaktiver anzugehen.

Anhang

Zeitplan für den Schwachstellenbericht:

  • 8. Juli 2024: Meldung der Sicherheitslücke an vier gefährdete Anbieter.
  • 8. Juli 2024: Merge.dev reagierte umgehend und bestätigte das Problem.
  • 13. August 2024: Merge.dev bestätigt, dass der Fehler behoben wurde.
  • 3. September 2024: Da die anderen drei Anbieter nicht reagiert haben, haben wir das Problem öffentlich gemacht.
Sie eine Demo