Missbrauch von Entra OAuth zur Anwendungsberechtigung interner Microsoft-Umgebungen

• Forschende haben nachgewiesen, dass sich mithilfe des Zustimmungs- und Berechtigungsdelegationsprozesses von Entra OAuth ein Zugriff auf interne Microsoft-Anwendungen erzielen lässt.
• Diese Schwachstelle ist eine neue Bedrohung für den Schutz interner Systeme und zeigt auf, dass externe Nutzer einen Zugriffspfad auf interne Dienste schaffen können.
• Das grundlegende Zustimmungsmodell und unzureichende Berechtigungseinstellungen sind die Hauptursachen.
• Die Studie ergab, dass bestehende Sicherheitskontrollen weiterhin anfällig sind, wenn es um OAuth-Zustimmungsanfragen und Zugriffssteuerung geht.
• Unternehmen und Organisationen erkennen die Notwendigkeit, OAuth-Zustimmung und Berechtigungsverwaltung zu stärken.

---

Forschungsübersicht und Hintergrund

• Microsoft Entra OAuth ist ein Authentifizierungs-/Autorisierungssystem, bei dem verschiedene Anwendungen mit Zustimmung der Nutzer Zugriff auf unterschiedliche Dienste erhalten.
• Die Forschenden fanden heraus, dass in Zielumgebungen intern zugängliche Microsoft-Anwendungen auch von außen erreichbar werden können, wenn ein bestimmtes Szenario zur Zustimmung und Berechtigungsdelegation ausgenutzt wird.

Ursachenanalyse

• Die Schwachstelle entsteht durch Missbrauch des Prozesses der OAuth-Zustimmungsanfrage.
• Wenn eine Anwendung nicht korrekt eingeschränkt ist, kann ein Angreifer durch das Erzwingen der Benutzereinwilligung ein internes Ressourcentoken erlangen.
• Der standardmäßig bereitgestellte Zustimmungs- und Berechtigungsmechanismus ist nicht ausreichend fein granular, sodass einige interne Dienste ein Risiko der externen Offenlegung tragen.

Auswirkungen und Risiken

• Ein bösartiger Nutzer kann diese Schwachstelle nutzen, um auf interne Microsoft-Systeme und Anwendungen zuzugreifen.
• Bei Erfolg besteht das Risiko der Ablieferung sensibler Daten oder eines Missbrauchs interner Funktionen.

Maßnahmen und Empfehlungen

• Organisationen sollten ihr OAuth-Verwaltungssystem neu bewerten und alle Prozesse für Zustimmung und Rechtezuweisung streng kontrollieren.
• Basierend auf dem Prinzip der geringsten Berechtigungen ist es erforderlich, den beantragten Ressourcen- und Berechtigungsumfang klar zu begrenzen.
• Es ist erforderlich, regelmäßig ein OAuth-Anwendungs-Audit und Prozesse zur Zustimmungskontrolle einzurichten, um die Verwaltung zu verstärken.

[GN⁺]

Hacker-News-Kommentare

• Die Microsoft-Dokumentation ist wirklich ein Albtraum, daher überrascht mich eine Schwachstelle überhaupt nicht.
  Ich habe vor Kurzem SSO-Login mit Entra ID implementiert und musste, obwohl es immerhin Single-Tenant war, praktisch per Zufall herumprobieren, bis im Access-Token die richtigen Scopes gesetzt waren und die Rückgabe zusätzlicher Felder korrekt konfiguriert war.
  Wenn man nach einem Einstiegsguide sucht, landet man bei unzähligen Unterseiten, die wiederum nur mit Microsoft-typischen kryptischen Begriffen und wenig hilfreichen Dokumentationslinks gefüllt sind.

• Dieses Ergebnis überrascht mich überhaupt nicht.
  Die OAuth2-Konfiguration und Dokumentation von Entra sind völlig chaotisch.
  Es ist so verwirrend, dass offenbar nicht einmal Microsoft selbst es zuverlässig zum Laufen bekommt.
  Deren Lösung für dieses Problem besteht darin, „noch mehr Dokumentation“ hinzuzufügen, aber schon die vorhandene Spaghetti-Dokumentation ist kaum zu lesen.

  • Ich hatte dieses Problem vor ein paar Wochen.
    Laut offizieller Dokumentation kann man den Authorization Code Flow nicht mit Scopes für mehrere Resource Server ausführen.
    Wenn man aber openid $clientid/.default anfordert, funktioniert es trotzdem.
    Am Ende des Flows bekommt man dann ein ID-Token und ein Access-Token, und das ID-Token zeigt, dass der OIDC-Scope angewendet wurde.
    Schaut man sich aber das Access-Token an, fehlt dort openid im Scope.
    Microsoft Graph, das als UserInfo-Endpoint dienen würde, lässt sich tatsächlich nicht aufrufen.
    Ich konnte nirgends eine vernünftige Erklärung für dieses Verhalten finden.

• Die Autorisierung von Multi-Tenant-Apps verursacht immer wieder unerwartete Probleme.
  Ich bin ein ehemaliger PM bei Microsoft, der an dem Patch gearbeitet hat, der auf Basis der Wiz-Research-Ergebnisse eingeführt wurde.
  Eine Korrektur zum Artikel: Dort steht, man habe bei der Autorisierung von Multi-Tenant-Apps empfohlen, nur den Claim iss oder tid zu prüfen.
  Die tatsächliche Empfehlung ist etwas komplexer.
  Wenn man nur den Tenant validiert, kann das dazu führen, dass jeder Service Principal autorisierten Zugriff erhält.
  Man sollte bei Tokens neben dem Tenant immer auch das Subject prüfen.
  Zum Beispiel sollte man Tokens über die Kombination aus tid + oid validieren oder vor der Autorisierung sowohl Tenant als auch Subject als Bedingung prüfen.
  Details stehen in der offiziellen Claims-Validation-Dokumentation.

  • Ich möchte den Ansatz hervorheben, grundsätzlich davon auszugehen, dass alle Tokens gefälscht sind.
    Sicheres Verhalten muss der Default sein.
    Selbst wenn es CPU kostet, sollte jedes einzelne Feld validiert werden.
    Signaturen haben nur dann einen Wert, wenn man sie auch tatsächlich überprüft.
    Wenn möglich, sollte man zusätzlich gegen die Identity-Datenbank gegenprüfen.
    Ich habe Entwicklern immer beigebracht, dass Tenant, Benutzer, Gruppen, Ressourcen – alles vor einer Freigabe sorgfältig geprüft werden muss.

  • Das ist zu 100 % richtig.
    Eigentlich sollten Engineers unbedingt den offiziellen Guide lesen.
    Den entsprechenden Guide gibt es hier.

  • Ich frage mich, ob es eine klar formulierte „Checkliste der zu prüfenden Dinge“ gibt.
    So etwas sollte doch eigentlich einfach in Ja/Nein-Form aufbereitet sein.
    Ich habe noch nie von einem System gehört, in dem es Checkboxen gibt wie „Sollen Benutzer dieser Gruppe die persönlichen Notizen aller lesen dürfen?“

• Selbst wenn man die Komplexität von Entra ausblendet, ist es leicht, Fehler nicht zu bemerken, weil gerade innerhalb von Microsoft die vielen unterstützten Tenants und die Tenants externer 3P-Kunden ohne klare Trennung vermischt sind.
  Noch beängstigender ist der Glaube, dass man Sicherheit allein mit einem „Authentifizierungs-Token“ lösen könne.
  Solche Seiten hätten niemals dem Internet ausgesetzt sein dürfen, auch wenn sie inzwischen nicht mehr öffentlich erreichbar sind.
  Netzwerksicherheit wird oft nachrangig behandelt, ist aber eines der wirksamsten Verteidigungsmittel.

  • Netzwerksicherheit ist letztlich auch nur eine Verteidigungsschicht.
    Entscheidend ist ein mehrstufiges Sicherheitskonzept (defense-in-depth).

• Man sagte uns, wir sollten in die Cloud gehen, es sei sicherer als ein internes Netz, und nur Idioten würden noch ein eigenes Ops-Team unterhalten.
  Ich bin wohl zu alt und zu festgefahren, um zu begreifen, warum Apps nur für internes Microsoft überhaupt von außen erreichbar sein sollten.

  • In den letzten zehn Jahren geht der Trend – angestoßen durch das, was Google „Zero Trust“ nennt – stark dahin, VPNs komplett abzuschaffen.
    Denn sobald jemand im VPN ist, wird es sehr schwer, den Zugriff auf wichtige Daten wirklich zu begrenzen.
    Deshalb werden heute auch „interne“ Services nach außen exponiert, und eine saubere Verwaltung abgestufter Permissions ist zwingend nötig.
    Das macht Angriffe, die sich in einem Zug durch mehrere Services ausbreiten, deutlich schwieriger.
    Einführung in das Zero-Trust-Konzept

  • Meiner Meinung nach ist die Tatsache, dass die App in einem öffentlichen Netzwerk erreichbar war, also nicht im Intranet lief, nicht das eigentliche Problem.
    Das eigentliche Problem ist, dass eine solche Anwendung wie Entra ID Multi-Tenant ist.
    Wichtige Identitätsinformationen werden in derselben Datenbank für mehrere Tenants – einschließlich böswilliger Angreifer – gespeichert und geteilt.
    Deshalb kommt es immer wieder zu Verstößen gegen Tenant-Grenzen.
    Selbst wenn Entra ID sehr robuste Tenant-Prüfungen hat, bleiben Schwachstellen bestehen.
    Zum Beispiel sind Requests über zwei oder mehr Tenants hinweg, wie im Blog beschrieben, grundsätzlich schwer korrekt zu autorisieren, und ein kleiner Fehler kann das gesamte Risiko auslösen.
    Im Vergleich zu einer Single-Tenant-App ist ein Angriff vor der Authentifizierung deutlich schwerer, weil der Angreifer zunächst Benutzer innerhalb dieses Tenants werden müsste.

  • Es gibt viele Behauptungen wie „Geht in die Cloud, sie ist sicherer als das interne Netz, und ihr braucht kein eigenes Ops-Team“,
    aber der Kernpunkt ist – wie der Blog zeigt –, dass Entwickler, die an der Autorisierung von Resource Servern arbeiten, nicht einmal grundlegende Claims wie Issuer, Audience oder Subject im Token prüfen.
    Wenn sich solche Fehler wiederholen, bringt es auch nichts, wenn das Ganze im Intranet steht.
    Das eigentliche Problem ist also nicht Cloud versus Self-Hosting, sondern dass Sicherheit grundsätzlich schwierig ist und Verbesserungszyklen oft erst einsetzen, wenn echte Probleme auftreten.
    Solche Sicherheitsmängel verschwinden nicht einfach dadurch, dass man etwas ins Intranet oder hinter ein VPN stellt.

  • Ist der Begriff „Defence in depth“ inzwischen wohl aus der Mode gekommen?

  • Für die meisten Unternehmen ist es immer noch ein guter Rat, Server nicht selbst zu betreiben.
    Selbst wenn man der beste Dachdeckerbetrieb in drei Bundesstaaten ist, möchte man wahrscheinlich nicht die eigene Website, E-Mail und Terminbuchung vollständig selbst betreiben.
    Die Leute in diesem Forum können vermutlich ihre eigenen Server aufsetzen und betreiben, aber das ist nicht der „normale Benutzer“.

• Dass es nach dem Fund einer RCE-Schwachstelle auf einem Windows-Build-Server 0 $ Belohnung gab, ist absurd.
  Selbst wenn man dort keine echte Zero-Day-Lücke, sondern nur ein Konfigurationsproblem gefunden hat: Wenn sich die Build-Umgebung mit einer Backdoor-DLL kompromittieren ließe, könnte das weltweit eine Katastrophe auslösen.

  • Ich war Windows-Build-Engineer bei Microsoft.
    Mit dieser Verwaltungs-UI für Build-Tools bin ich nicht vertraut, vielleicht wurde sie nach meinem Weggang eingeführt, aber ich glaube nicht, dass diese UI wirklich so gedacht war, dass man damit Remote Code Execution ermöglichen kann.
    Man musste immer Pakete aus NuGet beziehen, und auch wenn es oberflächlich so aussah, als könne man beliebige Pakete und Quellen angeben, gab es tatsächlich eine Whitelist, die auf interne Microsoft-NuGet-Feeds beschränkt war.
    Die Kontrolle über NuGet-Pakete war für uns im Windows-Engineering-Team ein sehr wichtiges Thema.
    Externe öffentliche NuGet-Pakete waren vollständig verboten, und wenn man unbedingt eines verwenden musste, musste es erst neu verpackt und dann in eine interne Quelle hochgeladen werden.

• Es ist Microsoft, also gibt es dort viele großartige Leute, aber wenn man sich den jüngsten Leak des Master Key ansieht, dazu Engineers, die GPT in PRs um Code gebeten haben, und dann noch einen CEO, der sagt, Backend-Engineers würden verschwinden,
  dann finde ich, dass man diesem Unternehmen nicht vertrauen kann.
  Natürlich sehen die meisten Leute ein, dass sie keine echte Alternative haben.
  Aber wenn man trotzdem bleibt, ist das schon ein bisschen verantwortungslos.

  • Was genau ist denn mit „Engineers haben GPT in PRs um Features gebeten“ gemeint?
    Geht es vielleicht um dotnet/runtime?

• Für mich ist die Sache ganz einfach.
  Entra* – oder Azure AD, oder wie auch immer es gerade heißen mag – sollte man nicht für AuthZ verwenden.
  Für AuthN ist es in Ordnung, aber die Autorisierung sollte man selbst implementieren.
  Wenn man nur AuthZ selbst übernimmt, kann man solche Probleme leicht vermeiden.
  *- Warum der Name geändert wurde, weiß ich auch nicht. Es wirkt, als gäbe es bei Microsoft einen Manager mit dem Motto: „Ich benenne um, also bin ich.“

  • Der Name „Azure AD“ erweckt einfach den falschen Eindruck, dass es nur AD ist, das in Azure gehostet wird.
    Inzwischen ist es deutlich mehr als das.

  • Es ist grundsätzlich in Ordnung, AuthZ mit Entra umzusetzen.
    Man muss einfach das Kästchen „Benutzerzuweisung für diese App erforderlich“ aktivieren und dann die Zuweisungen selbst vornehmen[1].
    Allerdings ist das auch die einzige AuthZ-Funktion, die Entra bietet.
    Wenn man AuthZ nicht explizit aktiviert, ist es falsch zu erwarten, dass Entra die Autorisierung automatisch für einen übernimmt.
    Eine einfache „Erlauben/Ablehnen“-Autorisierung ist ohnehin nur für sehr simple Apps sinnvoll, bei denen alle Benutzer dieselben Rechte haben.
    In komplexeren Anwendungen haben Benutzer in der Regel unterschiedliche Zugriffsstufen, daher muss die eigentliche Autorisierung in der Anwendung selbst implementiert werden.
    [1] Zuweisen von App-Berechtigungen im Admin-Portal

• Wenn wir schon dabei sind: Ein weiteres Problem bei Entra-ID-Multi-Tenant-Apps ist, dass sich bestimmte Tenants nicht gezielt auf eine Blacklist oder Whitelist setzen lassen.
  Dazu kommt, dass MSAL in Dingen wie Browser-Erweiterungen gar nicht funktioniert, sodass Nutzer zusätzliche Sicherheitsmechanismen für die Kommunikation mit Entra ID selbst implementieren müssen.
  Kein Wunder also, dass ständig neue Probleme auftauchen.

  • Dass man in Entra ID bei Multi-Tenant-Apps bestimmte Tenants nicht gezielt erlauben oder blockieren kann, ist wirklich lästig.
    Es wäre schön, wenn es eine Funktion gäbe wie „Diese App darf nur von folgenden Tenants genutzt werden“, aber derzeit gibt es nur „mein Tenant“ oder „alle Tenants in Azure“.
    Mein Workaround besteht darin, die App als „nur für diesen Tenant“ zu konfigurieren und Benutzer anderer Tenants in meinen Tenant einzuladen.
    Oder man setzt sie auf „alle Tenants erlaubt“ und steuert die tatsächlichen Benutzer dann über Gruppenfreigaben.
    Ich habe keine Ahnung, ob diese Einschränkung technische Gründe hat oder einfach daher kommt, dass kein wichtiger Kunde sie eingefordert hat.

• Azure ist wirklich pures Chaos.
  Okta hat zwar auch seine Probleme, aber die Dokumentation ist deutlich besser, und trotz des hohen Preises kann man Sicherheit dort vollständig getrennt von Azure-Services verwalten.
  Meiner Meinung nach ist das den Preis wert.