Wichtigste Ergebnisse
- Beim Testen von 104 Anwendungen fand Semperis 9 (oder etwa 9 %), die für nOAuth-Missbrauch anfällig waren.
- Da der Missbrauch bereits aufgedeckt wurde, ist die Fähigkeit, nOAuth durchzuführen, wenig komplex.
- Der Missbrauch von nOAuth nutzt mandantenübergreifende Schwachstellen aus und kann zur Exfiltration von Daten aus SaaS-Anwendungen, zur Persistenz und zu lateralen Bewegungen führen.
- Der Missbrauch ist für die Kunden anfälliger Anwendungen schwer zu erkennen und für die Kunden anfälliger Anwendungen unmöglich zu bekämpfen.
- Die Semperis-Forscher stufen diese Schwachstelle als potenziell SCHWER ein, da der Angriff wenig komplex und die Erkennung und Abwehr schwierig ist.
Die nOAuth-Schwachstelle offenbart eine kritische Authentifizierungslücke in anfälligen Software-as-a-Service (SaaS)-Anwendungen. Ein Angreifer braucht nur Zugriff auf einen Entra-Mieter - eine niedrige Hürde - und die E-Mail-Adresse des Zielbenutzers, um das Konto dieses Benutzers in der anfälligen Anwendung zu übernehmen. Von dort aus kann der Angreifer auf alle Daten zugreifen, auf die die Zielperson innerhalb dieser Anwendung Zugriff hat.
Im Dezember 2024 meldeten wir unsere Erkenntnisse umgehend den Anwendungsanbietern und dem Microsoft Security Response Center (MSRC). Das MSRC bestätigte den Erhalt des Berichts und eröffnete den Fall 93209. Im März 2025 informierten wir das MSRC über unsere Absicht, den Fall zu veröffentlichen. MSRC schloss den Fall im April 2025. Im Mai und Juni 2025 setzten wir uns weiterhin mit Anwendungsanbietern in Verbindung, die anfällig waren, und teilten MSRC die Einzelheiten mit. Im Juni 2025 erhielten wir eine Rückmeldung von MSRC, in der wir bekräftigten, dass Anbieter den Empfehlungen folgen sollten und dass Anbieter, die dies nicht tun, aus der Entra App Gallery entfernt werden.
Die Erkennung eines Angriffs, der nOAuth missbraucht, ist schwierig bis unmöglich. Den Kunden stehen keine anderen Abhilfemaßnahmen zur Verfügung, als die Hersteller von Anwendungen um Updates zu bitten, die die Anwendungen für den nOAuth-Missbrauch unverwundbar machen. Aufgrund der Einfachheit dieses Missbrauchs, der Komplexität der Erkennung und der Existenz aktiv angreifbarer Anwendungen betrachtet Semperis diese Schwachstelle als ernstes Risiko für Entra ID-Kunden.
Dieser Artikel beschreibt die Untersuchung von nOAuth durch das Semperis Security Research Team, die sich auf Anwendungen in der Microsoft Entra App Gallery konzentriert. Wir haben neun anfällige Anwendungen entdeckt, darunter auch solche, die möglicherweise personenbezogene Daten (PII) enthalten.
Was ist nOAuth?
Am 20. Juni 2023 veröffentlichte Omer Cohen von Descope die Enthüllung "nOAuth: How Microsoft OAuth Misconfiguration Can Lead to Full Account Takeover". Das grundlegende Problem, das zu nOAuth führt, ist die Verwendung von Anti-Patterns durch App-Entwickler in Bezug auf die Implementierung von OpenID Connect (OIDC). Zu diesen Anti-Patterns gehört die Verwendung veränderlicher Attribute, wie z.B. einer E-Mail-Adresse, als Benutzerkennzeichen. Da Entra ID Benutzern eine nicht verifizierte E-Mail-Adresse erlaubt, ermöglicht die Verwendung dieses Attributs eine Benutzer-Identifizierung über die Grenzen von Mandanten hinweg. In der Offenlegung von Descope wird beschrieben, dass der Angriff in einer "Grauzone" in Entra ID stattfindet, da die Entwickler Anti-Patterns befolgen müssen. Dem stimmen wir zwar zu, aber das macht die gemeinsamen Kunden von Microsoft und dem SaaS-Anbieter (ISV) anfällig für diesen Missbrauch.
Als Reaktion auf Cohens Entdeckung veröffentlichte MSRC einen Artikel über nOAuth-Risiken: "Potenzielles Risiko der Privilegieneskalation in Azure AD-Anwendungen". Dieser Artikel war Teil der Erklärung von Microsoft zu den Auswirkungen auf die Kunden:
Microsoft hat mehrere mandantenfähige Anwendungen mit Benutzern identifiziert, die eine E-Mail-Adresse mit einem nicht verifizierten Domänenbesitzer verwenden. Obwohl ungeprüfte E-Mail-Adressen kein Risiko für Anwendungen darstellen, die keine E-Mail-Ansprüche für Autorisierungszwecke verwenden, wurden die Eigentümer dieser Anwendungen benachrichtigt und erhielten eine Anleitung, wie sie ihre Anwendungen gegebenenfalls ändern können. Wenn Sie keine Benachrichtigung erhalten haben, hat Ihre Anwendung keine E-Mail-Ansprüche mit ungeprüften Domaininhabern verwendet. Um Kunden und Anwendungen zu schützen, die für eine Eskalation der Rechte anfällig sein könnten, hat Microsoft Abhilfemaßnahmen ergriffen, um Token-Ansprüche von nicht verifizierten Domänenbesitzern für die meisten Anwendungen auszuschließen.
Microsoft Erklärung zu den Auswirkungen auf Kunden
Microsoft hat auch eine spezielle Anleitung für die Abkehr von der Verwendung von E-Mail-Ansprüchen veröffentlicht. Zum Zeitpunkt der Erstellung dieses Artikels ist dieser Leitfaden nicht mehr auf der Microsoft-Website verfügbar, aber Sie können eine archivierte Version an anderer Stelle finden.
Wie funktioniert der Missbrauch von nOAuth?
nOAuth Missbrauch erfordert drei Komponenten:
- Die Möglichkeit, eine nicht verifizierte E-Mail-Adresse in Entra ID einzustellen
- Eine App-Registrierung, die den Anspruch auf eine ungeprüfte E-Mail zulässt
- Anfälligkeit einer Anwendung für diese Kombination
Lassen Sie uns ein Beispiel dafür durchgehen, wie diese Art von Missbrauch aussehen könnte.
Einstellen einer nicht verifizierten E-Mail-Adresse in Entra ID
Die Dienste von Entra ID und Microsoft 365 enthalten einen Standard-Tenant mit einem onmicrosoft.com-Domänennamen, z. B. contoso.onmicrosoft.com. Wenn Unternehmen ihre Bereitstellungen konfigurieren und ihre eigenen Domänennamen für die Dienste einbinden, verwendet der Verifizierungsprozess einen TXT- oder MX-Eintrag, um die Eigentümerschaft der Domäne zu überprüfen. Nach der Überprüfung wird der Domänenname in Entra ID als solcher markiert(Abbildung 1).
Um die Gastbenutzerfunktionalität in Entra ID zu unterstützen, muss das Domänensuffix des E-Mail-Attributs jedoch keine verifizierte Domäne sein. Daher kann jeder Benutzer in jedem Entra-Tenant eine beliebige E-Mail-Adresse im Mail-Attribut haben.
Abbildung 2 zeigt zum Beispiel den Benutzer Adele Vance, dessen Attribut mail denselben Wert hat wie das Attribut userPrincipalName.
Wir können einen einfachen PATCH ausführen, um dieses Mail-Attribut zu ändern(Abbildung 3).
Ein weiterer GET zeigt, dass Adele jetzt eine E-Mail-Adresse für eine Domäne hat, die innerhalb dieses Mandanten nicht verifiziert ist(Abbildung 4).
Überprüfen einer geänderten E-Mail Adresse
Wenn wir die ungeprüfte E-Mail-Adresse als Anspruch in einem ID-Token validieren möchten, können wir eine App-Registrierung in Entra ID mit einer Redirect URI von https://jwt.ms konfigurieren und das ID-Token an diese weitergeben.
Bei App-Registrierungen, die nach Juni 2023 erstellt wurden, wird der unverifizierte E-Mail-Antrag standardmäßig nicht von Entra ID ausgegeben. Um die Konfiguration so zu ändern, dass dies möglich ist, können wir einen einfachen PATCH für das authenticationBehavior für die App-Registrierung verwenden und removeUnverifiedEmailClaim auf false setzen(Abbildung 5). Dieser Vorgang wird von Microsoft in dem Artikel "Manage application authenticationBehaviors" dokumentiert.
Sobald unsere App-Registrierung konfiguriert ist, können wir sie verwenden, um das Verhalten einer anfälligen Anwendung zu replizieren und das ID-Token anzuzeigen(Abbildung 6).
Wenn dieses ID-Token von einer Anwendung verwendet wird, die den E-Mail-Anspruch als eindeutige Kennung verwendet, weiß die Anwendung nicht, dass der Benutzer in Wirklichkeit nicht der rechtmäßige Benutzer ist.
nOAuth-Missbrauch eindämmen
Wie bereits erwähnt, erfordert die Eindämmung des nOAuth-Missbrauchs letztlich, dass der Entwickler die Authentifizierung ordnungsgemäß implementiert, um eine eindeutige, unveränderliche Kennung zu gewährleisten.
Pam Dingle, Director of Identity Standards bei Microsoft, veröffentlichte kurz nach der Veröffentlichung von nOAuth einen Artikel über Anti-Patterns bei Entwicklern. Es lohnt sich, ihn zu lesen: "Das Anti-Muster der falschen Identifizierung".
Wie Pam in seinem Artikel hervorhebt, ist gemäß der OpenID Connect-Spezifikation in Abschnitt 5.7 eine Kombination ausIssuer- undSubject-Angaben die einzige Möglichkeit für eine Anwendung(SP), eine eindeutige und stabile Benutzerkennung zu gewährleisten.
In Entra ID wird der Emittent(iss) als Issuer-URI ausgegeben, der die weltweit eindeutige Tenant-ID enthält(Abbildung 7).
Der Betreff(sub) ist ein paarweiser Identifikator, der für jeden Benutzer für jede Anwendungs-ID eindeutig ist(Abbildung 8). Genauso wichtig ist, dass sub ein unveränderlicher Wert in Entra ID ist. Entra ID erlaubt keine Art von Anspruchsumwandlung oder Modifizierung des Subjektanspruchs, wodurch seine Einzigartigkeit gewährleistet wird.
Einzelheiten zu den Ansprüchen innerhalb eines von Entra ID ausgegebenen ID-Tokens finden Sie hier: "ID-Token Ansprüche Referenz".
Microsoft Änderungen zur Eindämmung des nOAuth-Missbrauchs
Innerhalb von Entra ID hat Microsoft Änderungen vorgenommen, so dass jede App-Registrierung, die nach Juni 2023 erstellt wird, standardmäßig keinen E-Mail-Anspruch ausgibt, wenn die E-Mail-Adresse nicht verifiziert ist. Natürlich gibt es Tausende und Abertausende von SaaS-Anwendungen, die bereits vor Juni 2023 erstellt wurden, und viele Entwickler wollen und müssen die E-Mail-Adresse immer noch verwenden. Viele SaaS-Anwendungen möchten E-Mails an Endbenutzer senden, und die Verwendung eines Claims ist der einfachste Weg, diese Informationen zu erhalten.
Um Entwicklern zu helfen, hat Microsoft auch den optionalen Anspruch xms_edov eingeführt, mit dem ein Entwickler feststellen kann, ob eine E-Mail-Adresse verifiziert ist. Als ich diesen Artikel schrieb, schien der xms_edov-Anspruch jedoch nicht mehr verfügbar zu sein, so dass man sich fragt, ob er veraltet ist. Obwohl in den Microsoft-Dokumenten angegeben ist, dass der Anspruch optional ist, ist er in der Benutzeroberfläche für die Einstellung optionaler Ansprüche nicht mehr verfügbar. Das Einstellen von xms_edov als optionalen Anspruch über die Graph API funktioniert zwar, aber Sie erhalten anschließend die Meldung, dass es sich nicht um einen gültigen optionalen Anspruch handelt(Abbildung 9).
In der Praxis könnte ein Entwickler diese Informationen verwenden, um zu entscheiden, ob die E-Mail-Adresse eines Benutzers im Mandanten verifiziert ist(Abbildung 10).
Die neue nOAuth-Missbrauchsforschung von Semperis
Der Descope Fokus
In der von Descope veröffentlichten Studie liegt der Schwerpunkt auf SaaS-Anwendungen, die Unterstützung für mehrere Identitätsanbieter bieten, wie Google und Microsoft, Facebook usw.(Abbildung 11).
Aus Gründen der Benutzerfreundlichkeit verfügen SaaS-Anwendungen in der Regel über eine Logik zum Zusammenführen von Konten. Wenn ich mich beispielsweise mit einem Facebook-Konto bei Medium anmelde und mich später mit meinem Google-Konto einlogge, führen mich die beiden Authentifizierungsquellen letztlich zum gleichen Medium-Konto.
Das Problem, das Descope untersuchte, bestand darin, dass jedes Benutzerkonto in Entra ID den E-Mail-Anspruch tragen konnte. Entwickler, die auf der Grundlage von E-Mails zusammenführten, konnten einem Angreifer unwissentlich Zugang zum Konto eines Zielbenutzers verschaffen.
Über einige der von Microsoft implementierten Funktionen hinaus empfahl Descope, dass SaaS-Anwendungen, die Funktionen zur Zusammenführung von Konten unterstützen, den Datenfluss unterbrechen, wenn zum ersten Mal versucht wird, sich mit einer anderen Kontoquelle anzumelden, indem eine Funktion zur Überprüfung des E-Mail-Eigentums verwendet wird. Wir stimmen diesem Ratschlag zu. Diese Funktion kann die Form eines magischen E-Mail-Links annehmen, bei dem der Benutzer eine E-Mail erhält, in der er aufgefordert wird, die Eigentümerschaft zu bestätigen, bevor die Zusammenführung stattfindet.
Bei unseren eigenen Untersuchungen haben wir festgestellt, dass dies eine gängige Sicherheitspraxis bei Anwendungen ist, die sich als unverwundbar gegenüber nOAuth-Missbrauch erwiesen haben.
Semperis Forschung
Im Spätherbst 2024 haben wir im Rahmen einiger Sondierungsarbeiten die von Descope durchgeführten Untersuchungen überprüft und beschlossen, sie mit einigen SaaS-Anwendungen zu testen. Dabei kam uns die Idee, die Microsoft Entra App Gallery zu untersuchen. Die Entra App Gallery ist ein Portal innerhalb von Entra ID, das von Microsoft verwaltet wird und es SaaS-Drittanbietern ermöglicht, Anwendungen zu präsentieren, die sich in Entra ID integrieren lassen(Abbildung 12).
Bei unserer Recherche haben wir alle 1.017 zu diesem Zeitpunkt verfügbaren OIDC-Integrationen untersucht und 104 Anwendungen gefunden, die eine Selbstregistrierung für die Anwendung ermöglichen. Da der SaaS-Markt stark umkämpft ist, neigen die Anbieter dazu, entweder kostenlose Stufen oder Testversionen ihrer Anwendungen ohne große Reibungsverluste anzubieten, so dass Sie die Anwendung nutzen und testen können, ohne den Umweg über die Vertriebskanäle gehen zu müssen. Wir haben uns auf diese Anwendungen konzentriert, nicht nur, weil sie eine niedrige Hürde für die Sicherheitsforschung darstellen, sondern auch, um die Grenzen des ethischen Testens einzuhalten.
In jeder von uns getesteten Anwendung verwendeten wir einen "Opfer"-Tenant, den wir verwalteten, um ein Konto zu konfigurieren, das uns innerhalb der Plattform gehörte. Mit einem anderen Tenant, dem "Angreifer"-Tenant, haben wir dann versucht, nOAuth gegen unser eigenes Opfer zu missbrauchen. Auf diese Weise konnten wir sicherstellen, dass unsere Tests nur Konten unter unserer Kontrolle betrafen und nur auf von uns erstellte Testdatenmuster zugriffen.
Unsere Untersuchung unterscheidet sich von der von Descope insofern, als wir uns für Anwendungen interessierten, die einen mandantenübergreifenden nOAuth-Missbrauch von Entra ID erlauben. Im Wesentlichen ist der Zielkunde (das Opfer) ein Microsoft-Kunde mit einem Entra ID-Tenant, und der Angreifer verwendet einen anderen Entra ID-Tenant, um den Missbrauch durchzuführen. Das folgende Diagramm von Descope ist für den Angriffsfluss in unserer Untersuchung gültig(Abbildung 13).
Bei unserem Schwerpunkt muss die SaaS-Anwendung jedoch nur Entra ID für die Authentifizierung unterstützen. Obwohl fast alle von uns getesteten SaaS-Anwendungen ein lokales Benutzerkonto unterstützten, stellten wir fest, dass einige Anwendungen auch mehrere Identitätsanbieter unterstützten, z. B. Google und Entra ID, während andere nur Entra ID unterstützten.
Wenn eine Anwendung nur Entra ID für die Authentifizierung unterstützt, ist es unwahrscheinlich, dass der Entwickler die von Descope erwähnte Logik für die Zusammenführung von Konten und die Verifizierung von E-Mails implementiert hat, da der Entwickler wahrscheinlich nicht mit einem Szenario der Kontokollision gerechnet hat.
Anfällige Anwendungen
Beim Testen von 104 Anwendungen fanden wir 9, die für nOAuth-Missbrauch anfällig waren. Das bedeutet, dass etwa 9 % der getesteten Anwendungen anfällig waren. Da 104 Anwendungen nur ein Tropfen auf den heißen Stein unter den SaaS-Anwendungen sind, die mit Entra ID integriert sind, können Sie diese Zahlen auf die Zehntausenden von verfügbaren SaaS-Anwendungen hochrechnen.
Bei den Anwendungen, die wir für gefährdet hielten, haben wir einige interessante Beobachtungen in Bezug auf Größe, Umfang und Art der Anwendung gemacht. Wir fanden eine HRMS-Plattform (Human Resources Management System), die in der Praxis wahrscheinlich mit PII gefüllt ist. Ebenso fanden wir Anwendungen, die für Aufgaben wie Mail- und Kalenderzugriff wieder in Microsoft 365 integriert waren. Da diese Integrationen unterschiedliche Kombinationen von Zugriffs- und Aktualisierungs-Token verwenden, wäre ein Angreifer, der nOAuth erfolgreich missbraucht, nicht nur in der Lage, auf die Daten der SaaS-Anwendung zuzugreifen, sondern möglicherweise auch auf die Ressourcen von Microsoft 365.
Leider ist das Testen in großem Maßstab zeitaufwändig. Wir mussten nicht nur den Entra-Tenant so konfigurieren, dass er den Missbrauch durchführt, sondern wir brauchten auch menschliche Augen auf der Benutzeroberfläche der SaaS-Anwendung, um festzustellen, ob der Angreifer Zugriff auf das Konto des Opfers erlangen konnte. Obwohl die meisten Anwendungen, die für diesen Missbrauch nicht anfällig waren, in der Regel einen neuen Onboarding-Flow in die Anwendung boten, wurden wir bei einigen Anwendungen einfach auf den Hauptbildschirm der Anwendung weitergeleitet, so dass wir Kontoinformationen prüfen oder versuchen mussten, Daten innerhalb der Anwendung zu manipulieren, um festzustellen, ob der Angreifer im selben Konto wie das Opfer war.
Kontaktaufnahme mit Interessengruppen
Als Ergebnis dieser Nachforschungen eröffneten wir einen Fall bei MSRC. Wir versuchten auch, die Beteiligten bei jedem ISV zu ermitteln, der eine verwundbare Anwendung hatte. Nachdem wir uns mit diesen Beteiligten in Verbindung gesetzt hatten, boten wir ihnen gemäß dem Semperis-Prinzip, eine Kraft für das Gute zu sein, an, ihnen bei der Behebung der Sicherheitslücke in ihrer Anwendung zu helfen. In diesen Fällen halfen wir den Anbietern, das Problem zu verstehen und führten zusätzliche Tests des nOAuth-Missbrauchs in ihrer Anwendung durch, bis das Problem behoben war.
Kundenverteidigung: ein Mangel an Optionen
Letztendlich besteht der einzige Schutz, den ein Kunde gegen nOAuth-Missbrauch hat, darin, 1) den Anbieter zu drängen, das Problem zu beheben oder 2) die SaaS-Anwendung aufzugeben.
Da der Angriff außerhalb des Blickfelds des Opfers stattfindet, können herkömmliche Verteidigungsmechanismen keinen Schutz bieten. Dazu gehören:
- Multifaktor-Authentifizierung (MFA) und Durchsetzung der Authentifizierungsstärke in Entra ID
- Bedingter Zugang
- Zero Trust Network Access (ZTNA) und Cybersecurity for Any Business (CASB) Lösungen
- Endpunkt-Erkennung und -Reaktion (EDR)
- Erweiterte Erkennung und Reaktion (XDR)
nOAuth Missbrauchserkennung
Obwohl (SaaS Security Posture Management (SSPM)-Lösungen) einen gewissen Einblick in SaaS-Anwendungen geben können, konzentrieren sie sich im Allgemeinen auf die Konfiguration und die Sicherheitslage, die den Kunden der Plattform offengelegt wird, und sind nicht geeignet, einen nOAuth-Missbrauch anzuzeigen. Ähnliche Probleme gibt es bei Sicherheits-Browser-Plattformen und Browser-Plug-ins für Unternehmen, die andere Hintertüren in SaaS-Anwendungen aufzeigen können, aber diese Art von Angriffen wahrscheinlich nicht aufdecken werden.
Leider lässt dies den Kunden nur wenige Möglichkeiten:
- Korrelation von SaaS-Authentifizierungsprotokollen mit Entra ID innerhalb einer SIEM-Plattform
- Fragen Sie ihre Anbieter nach nOAuth
- nOAuth Missbrauchstests selbst durchführen
Aus der Sicht von Entra ID haben wir die Service-Principals von mandantenfähigen Anwendungen untersucht und keine Attribute gefunden, die einem Kunden anzeigen, dass die Anwendung ungeprüfte E-Mail-Claims verwendet. Selbst wenn solche Attribute vorhanden wären, gäbe es keine Möglichkeit anzugeben , wofür die Anwendung diese Forderung verwendet.
Korrelation der Authentifizierungsprotokolle
Um mithilfe der Protokollkorrelation nOAuth-Missbrauch zu erkennen, müssen Sie die Authentifizierungsprotokolle von Entra ID in eine SIEM-Lösung (Security Information and Event Management) wie Microsoft Sentinel übertragen. Außerdem müssen Sie die Authentifizierungsprotokolle Ihrer SaaS-Anwendung abrufen und dann die beiden Protokolle innerhalb des SIEM korrelieren. Sie müssten nach Authentifizierungsereignissen in der SaaS-Plattform suchen, die ein fehlendes Authentifizierungsereignis in Entra ID aufweisen(Abbildung 14).
Natürlich werden die Ergebnisse der Umsetzung dieser Theorie in die Praxis sehr unterschiedlich ausfallen. Obwohl das Subjekt(sub) der wichtigste Identifikator in der SaaS-Anwendung ist, wird dieser Wert bei der Authentifizierung nicht in den Anmeldeprotokollen von Entra ID erfasst. Daher müsste die SaaS-Anwendung auch Attribute wie UPN oder E-Mail-Adresse in ihren Protokollen für die Korrelation enthalten. Ebenso müssen die Authentifizierungsprotokolle des SaaS-Anbieters so verfügbar sein, dass sie von einem SIEM genutzt werden können. Andere Faktoren, wie z.B. Zeitdrift und Genauigkeit, können die Erkennung von nOAuth-Missbrauch durch Protokollkorrelation erschweren.
Testen auf nOAuth und Anbieterverantwortung
Die einzige andere Möglichkeit für einen Kunden wäre, die von ihm genutzten SaaS-Anwendungen auf nOAuth-Missbrauch zu testen. Bevor er dies tut, kann er sich an den Anbieter der Anwendung wenden und fragen, ob der Anbieter nOAuth kennt und gegen nOAuth-Missbrauch getestet hat.
Ein paar Punkte, die Sie beachten sollten:
- Zertifizierungen wie SOC II haben diesen Missbrauch nicht untersucht. Wir haben anfällige Anwendungen gefunden, deren Anbieter SOC II- und andere Zertifizierungen auf ihren Websites aufgeführt haben.
- Fragen Sie den Anbieter ausdrücklich, ob er gegen diese Sicherheitslücke getestet hat. Wir haben Anbieter gefunden, die glaubten, die Schwachstelle behoben zu haben, aber wir konnten immer noch nOAuth-Missbrauch mit ihren Anwendungen durchführen.
Wenn der Anbieter diese Frage nicht abschließend beantworten kann, kann der Kunde diesen Test mit jeder beliebigen Anwendung durchführen, die für ihn von Interesse ist. Genau wie die Sicherheitsforscher sollten auch die Kunden sicherstellen, dass sie ihre Tests innerhalb der ethischen Grenzen durchführen: Sie testen mit ihren eigenen Benutzerkonten und kennen alle vertraglichen Anforderungen, die sie möglicherweise mit dem Anbieter haben.
Verteidigung von Softwareentwicklern gegen nOAuth
Entwickler, die den E-Mail-Anspruch verwenden, sollten sich vergewissern, dass sie ihn nicht zur Benutzeridentifizierung nutzen. Wenn dies der Fall ist, sollten sie die von Microsoft dokumentierten Schritte zur Einhaltung der OIC-Spezifikationen unter Verwendung von Issuer und Subject durchführen.
Entwickler können auch ihre App-Registrierungen überprüfen, um festzustellen, ob sie die unverifizierte E-Mail-Anforderung erhalten. Es ist jedoch Sache des Entwicklers, seinen Code zu untersuchen, um festzustellen, wie der E-Mail-Anspruch verwendet wird.
Es gibt auch alternative Lösungen für den Empfang der E-Mail-Attributdaten, die nicht aus einem Anspruch im ID-Token stammen. OIDC spezifiziert einen UserInfo-Endpunkt, der in Entra ID implementiert ist. Dieser Endpunkt kann verwendet werden, um Informationen über den authentifizierten Benutzer zu erhalten. Durch den Aufruf des UserInfo-Endpunkts kann die Anwendung nach der Authentifizierung die E-Mail-Adresse des Benutzers erhalten, auch wenn diese Adresse nicht verifiziert ist. Dieser Schritt stellt sicher, dass der E-Mail-Anspruch nicht als eindeutiger Identifikator des Benutzers verwendet wird.
In diesem Beispiel können wir den Endpunkt UserInfo für Adele Vance aufrufen, die eine nicht verifizierte E-Mail-Adresse hat(Abbildung 15). Der Betreff, also der eindeutige Bezeichner, stimmt mit dem im ID-Token überein.
Entwickler, die ihren Code zur Behebung der nOAuth-Schwachstelle aktualisiert haben, sollten ihre Anwendung nach der Behebung testen, um sicherzustellen, dass sie nicht für nOAuth-Missbrauch anfällig ist. Bei unserer Arbeit mit Anbietern zur Behebung der Schwachstelle hat sich gezeigt, dass die erste Korrektur die Schwachstelle nicht immer behebt.
Als wir mit dem MSRC über unsere Ergebnisse sprachen, bekräftigte es, dass Entwickler die Empfehlungen befolgen müssen, und verwies uns auf den Artikel, den es nach der Offenlegung im Jahr 2023 veröffentlichte. Da es für Anwendungen einen legitimen Bedarf gibt, die E-Mail-Adresse eines Benutzers zu erhalten, gibt es keine Möglichkeit festzustellen, ob eine Anwendung das Attribut richtig verwendet, ohne jede Anwendung zu testen. Wie wir bei unseren eigenen Tests festgestellt haben, ist dies ein sehr zeitaufwändiger Prozess.
MSRC sagte auch, dass es mit den Anbietern von Anwendungen kommuniziert hat und dass diejenigen, die ihre Anwendungen nicht korrigiert haben, aus der Entra App Gallery entfernt werden.
Offenlegung und Zeitplan
Wir waren überrascht, dass der Missbrauch von nOAuth funktionierte, insbesondere in Anwendungen, die in der Entra Gallery veröffentlicht wurden. Wir haben einen Fall bei MSRC eröffnet (Fallnummer 93209).
Wir forderten die Microsoft Identity Product Group außerdem auf, angesichts der Schwierigkeit, nOAuth-Missbrauch zu erkennen, aggressiver beim Schutz der Kunden vorzugehen. Wir schlugen vor, die Kunden von Dienstherren zu warnen, dass die Anwendung ungeprüfte E-Mail-Ansprüche zulässt, obwohl dies, wie wir festgestellt haben, kein absolutes Erkennungsmerkmal für die Anfälligkeit für nOAuth wäre.
Wir haben auch die neun verwundbaren Anwendungen angegeben, die wir gefunden haben, für den Fall, dass MSRC mit diesen Anbietern in Kontakt steht.
- 3. Dezember 2024: Fall erstellt mit MSRC
- 3. Dezember 2024: Fall von MSRC anerkannt
- 4. Dezember 2024: Wir haben der MSRC zusätzliche Details zu dem Fall mitgeteilt
- 17. Dezember 2024: Wir haben den Fall mit MSRC aktualisiert und festgestellt, dass wir mit einem Anbieter zusammengearbeitet haben, um eine der anfälligen Anwendungen zu beheben
- 17. März 2025: Wir haben MSRC nach dem Status des Falls gefragt; keine Antwort erhalten
- 18. März 2025: Wir haben MSRC im Portal über die Absicht informiert, in der Sitzung bei Troopers 2025 (falls ausgewählt) offenzulegen.
- 19. März 2025: Wir haben das MSRC per E-Mail über unsere Absicht informiert, die Schwachstelle in der Sitzung bei Troopers offenzulegen (falls sie ausgewählt wird) und um eine Anleitung zur Offenlegung gebeten, da die ursprüngliche Schwachstelle bereits offengelegt worden war; keine Antwort erhalten
- 18. April 2025: Der Fall wurde von MSRC geschlossen, mit dem Hinweis, dass "ein Fix für das von Ihnen geschilderte Problem gemeldet wurde", ohne weitere Informationen
- April - Mai 2025: Wir haben Anwendungsanbieter getestet und gefunden, die für nOAuth anfällig sind. Wir haben die Anbieter erneut benachrichtigt und uns mit unseren Ergebnissen an MSRC gewandt.
- Juni 2025: MSRC hat Details zu Anwendungen, die für nOAuth anfällig sind, in der Entra Application Gallery veröffentlicht
- Juni 26, 2025: Öffentliche Bekanntgabe
