Was ist mandantenübergreifender Identitätswechsel?

Dieser Beitrag ist eine Antwort auf einen kürzlich Artikel veröffentlicht von OKTA Security, „Mandantenübergreifender Identitätswechsel: Prävention und Erkennung“ (vom 31. August).

Bevor wir uns mit diesem Thema befassen, ist es wichtig zu betonen, dass wir großen Respekt vor Okta haben, wie wir es mit jedem Anbieter tun, der versucht, die ständig zunehmenden Bedrohungen für Unternehmen in Bezug auf Cybersicherheit zu bekämpfen. Wir sind auch der Meinung, dass es genauso wichtig ist, diese Diskussionen zu führen, wenn etwas schief geht. Wir müssen die Bedrohungslage kontinuierlich evaluieren und sicherstellen, dass den IT-Experten und Organisationen, die auf fundierte und fundierte Ratschläge der Branche antworten, die richtigen Informationen zur Verfügung stehen.

Lassen Sie uns vor diesem Hintergrund einen Blick darauf werfen, was passiert ist, wie und wo die Risiken möglicherweise noch bestehen und vor allem die Lösungen.

Was ist „mandantenübergreifender Identitätswechsel“?

Wie der Name vermuten lässt, handelt es sich um einen Angriffsvektor, bei dem die Identität eines hoch privilegierten Benutzers oder Admins vortäuscht. Es handelt sich um eine „mandantenübergreifende“ Sicherheitslücke, da es sich um eine Sicherheitslücke handelt, die in Umgebungen mit mehreren Mandanten wie Cloud-basierten Diensten wie AWS (Amazon Web Services), MS Azure oder Google Cloud Platform (GCP) auftritt.

Mandantenübergreifender Identitätswechsel bezieht sich auf eine Situation, in der ein Benutzer oder eine Entität eines Mandanten unbefugten Zugriff auf Ressourcen oder Daten eines anderen Mandanten erhält. Dies kann es einem Angreifer ermöglichen, gestohlene Daten auszunutzen, um sich als Benutzer oder Administrator auszugeben und weitere schändliche Insideraktivitäten durchzuführen.

Was ist im Fall von Okta Security passiert?

„Bedrohungsakteure scheinen entweder a) Passwörter für privilegierte Benutzerkonten zu haben oder b) in der Lage zu sein, den delegierten Authentifizierungsfluss über Active Directory (AD) zu manipulieren, bevor sie den IT-Servicedesk einer Zielorganisation anrufen und ein Zurücksetzen aller MFA-Faktoren (Multi Factor Authentication) im Zielkonto anfordern“, so Defensive Cyber Operations von Okta. Die Hacker waren in der Lage, sich Zugriff auf kompromittierte Konten zu verschaffen und sich als Benutzer auszugeben, höhere Rechte zuzuweisen und MFA-Faktoren zurückzusetzen und/oder zu entfernen.

Der interessanteste Aspekt dieses Angriffs ist der erste Zugriff. Dies ist etwas, das sehr oft nicht detailliert genug untersucht wird. Laut Okta war es Social Engineering. Sie stellen fest: „Ein Bedrohungsakteur nutzte Social Engineering, um eine äußerst privilegierte Rolle in einer Okta-Kundenorganisation (Mieter) zu erlangen.“

Social Engineering ist eine Taktik, die von Cyberkriminellen verwendet wird, um unter falschen Vorwänden Informationen von Personen zu erhalten.

Unserer Meinung nach bestand die größte Sicherheitslücke in der Abhängigkeit von Passwörtern und einem unsicheren Wiederherstellungsprozess. Die Hacker waren in der Lage, Super-Admin-Passwörter zu kompromittieren und dann die menschliche Komponente auszunutzen, um einen Wiederherstellungsprozess auszunutzen, der von ihrer Fähigkeit abhängt, den Helpdesk davon zu überzeugen, die Super-Admin-Authentifizierungsfaktoren zurückzusetzen und/oder vollständig zu entfernen.

Sobald der Angreifer die Kontrolle über die Super-Admin-Konten hat, kann er die inhärente Schwäche der „Inbound-Federation“ ausnutzen. Inbound Federation ist eine Okta-Funktion, die den Zugriff auf Anwendungen in einem Ziel-Identity Provider (IdP) ermöglicht, wenn sich der Benutzer erfolgreich bei einem Quell-IdP authentifiziert hat. Einfach ausgedrückt: Die Funktion für den Inbound-Verbund ermöglichte es den Hackern, SSO an verschiedene Mandanten zu senden. Daher der Begriff „mandantenübergreifender Identitätswechsel“.

Könnte sich dieser Cyberangriff an anderer Stelle wiederholen?

Da es sich bei der Sicherheitslücke im Fall der Okta-Angriffe offenbar um kompromittierte Anmeldeinformationen (Passwörter und MFA) gehandelt hat, könnte man automatisch annehmen, dass passwortloses MFA dazu beigetragen hätte, den ersten Zugriff zu verhindern, aber das ist nicht ganz richtig. Die Antwort hat mehr mit der Gesamtarchitektur der Technologie zu tun. Dieses Problem ist nicht exklusiv. Tatsächlich basieren viele MFA-Lösungen (passwortlos oder nicht) auf ähnlichen Architekturen und basieren auf zentralisierten Anmeldeinformationen, die für andere Aspekte des Identitätslebenszyklus verwendet werden, z. B. die Registrierung eines Geräts, die Kontowiederherstellung oder das Onboarding oder Offboarding neuer Benutzer und/oder Geräte.

Okta empfiehlt beispielsweise die Verwendung von Phishing-resistentem MFA wie WebAuthn und die Verwendung der stärksten Authentifizierungsmethode „derzeit Okta Verify oder Google Authenticator“ für die Self-Service-Wiederherstellung. Sowohl Okta Verify als auch Google Authenticator verwenden PUSH oder OTP (One Time Password) für MFA. Push-basierte MFA und OTP sind nachweislich anfällig für MFA-Fatigue (Prompt Bombing) und gegnerische Angriffe. WebAuthn ist zwar phishing-resistent, löst aber das Problem bei der Kontowiederherstellung nicht. Die Wiederherstellung von WebAuthn (Passkeys) basiert auf schwächeren Authentifizierungsfaktoren, in der Regel Passwörtern und OTP. Wenn Unternehmen sich weiterhin auf das menschliche Element (Helpdesk-Personal), Passwörter und OTPs (One Time Password) verlassen, werden ähnliche Angriffe nur fortbestehen.

Lösungen und bewährte Verfahren

IT-Führungskräfte sollten nach Technologien suchen, die Funktionen wie Identitätsbindung und transitives Vertrauen beinhalten. Sie sollten auch nach Technologien suchen, deren Architektur auf Null Vertrauen, Nullwissen und keinerlei personenbezogene Daten (PII) setzt.

Die Nutzung von Zero-Trust-Konzepten wie transitiver Vertrauens- und Identitätsprüfung ermöglicht Self-Service und stellt gleichzeitig sicher, dass der gesamte Lebenszyklus der Benutzeridentität vor Phishing gefeit und nachweisbar ist und nicht von einem privilegierten Insider unterlaufen werden kann.

Um der Authentifizierung vertrauen zu können, müssen Herkunft, Authentizität, Integrität und Identität des Authentifizierungsursprungs (Geräts) sichergestellt und mit der Benutzeridentität verknüpft werden. Das Authentifizierungsgerät und die Benutzeridentität sollten untrennbar miteinander verbunden sein. Daher muss eine explizite transitive Vertrauensstellung zwischen dem Gerät und der Benutzeridentität über eine Identitätsbindung hergestellt werden. Dadurch wird sichergestellt, dass nur der echte Benutzer auf einen Dienst zugreifen kann, indem er sich mit dem vertrauenswürdigen Gerät authentifiziert, und dass ein Angreifer die Identität eines Benutzers nicht fälschen und/oder kopieren kann.

Transitive Trust stellt sicher, dass einer Authentifizierung nicht nur deshalb vertraut wird, weil sie von einem Benutzer und/oder einem Gerät eines Benutzers stammt. Es muss nachweislich gewährleistet sein, dass eine Transaktion auf einem „vertrauenswürdigen Dienst“ ausgeführt wurde, der an ein „vertrauenswürdiges Gerät“ gebunden ist, das mit diesem „bestimmten Benutzer“ verbunden und unter der „vollständigen Kontrolle des Benutzers“ autorisiert wurde. Dies sollte die Grundlage jeder Zero-Trust-Sicherheitsstrategie bilden.

Fazit

Letztlich glauben wir, dass die Lösungen in einer besseren Kenntnis und einem besseren Verständnis der Probleme (wie oben beschrieben) zu finden sind. Praktiker müssen in die Lage versetzt werden, fundierte Entscheidungen zu treffen. Dazu gehört auch, die Branche über bestehende Technologien sowie über die Schwächen und die Bewältigung dieser Herausforderungen aufzuklären.

Wenn Sie weitere Informationen zu diesem Thema wünschen, wenden Sie sich bitte an AuthN von IDEE MFA-Lösung, oder etwas anderes, das mit Ihrem Anwendungsfall zu tun hat, nehmen Sie bitte Kontakt mit uns auf.

‍