Was ist mieterübergreifende Impersonation?

Dieser Beitrag ist eine Antwort auf einen kürzlich veröffentlichten Artikel von OKTA Security, 'Cross-Tenant Impersonation: 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 vor jedem Anbieter, der versucht, die ständig wachsenden Bedrohungen für Unternehmen im Bereich der Cybersicherheit zu bekämpfen. Wir sind auch der Meinung, dass es genauso wichtig ist, diese Diskussionen zu führen, wenn etwas schief läuft. Wir müssen die Bedrohungslage kontinuierlich bewerten und sicherstellen, dass die richtigen Informationen für IT-Fachleute und Unternehmen zur Verfügung stehen, die auf fundierte und solide Ratschläge aus der Branche angewiesen sind.

Werfen wir also einen Blick darauf, was passiert ist, wie und wo die Risiken noch bestehen und vor allem, welche Lösungen es gibt. 

Was ist eine "mieterübergreifende Personifizierung"? 

Wie der Name schon vermuten lässt, handelt es sich um einen Angriffsvektor, bei dem sich ein hoch privilegierter Benutzer oder Administrator ausgibt. Sie ist "mandantenübergreifend", weil es sich um eine Sicherheitslücke handelt, die in mandantenübergreifenden Umgebungen wie Cloud-basierten Diensten, z. B. AWS (Amazon Web Services), MS Azure oder Google Cloud Platform (GCP), auftritt.

Die mandantenübergreifende Impersonation bezieht sich auf eine Situation, in der ein Benutzer oder eine Entität aus einem Mandanten unbefugten Zugriff auf Ressourcen oder Daten erhält, die einem anderen Mandanten gehören. Dies kann es einem Angreifer ermöglichen, gestohlene Daten auszunutzen, um sich als Benutzer oder Administrator auszugeben und weitere schändliche "Insider"-Aktivitäten durchzuführen. 

Was geschah im Fall von Okta Security?

"Bedrohungsakteure schienen entweder a) über Passwörter für privilegierte Benutzerkonten zu verfügen oder b) in der Lage zu sein, den delegierten Authentifizierungsfluss über Active Directory (AD) zu manipulieren, bevor sie den IT-Servicedesk einer Zielorganisation anriefen und eine Rücksetzung aller MFA-Faktoren (Multi-Faktor-Authentifizierung) im Zielkonto verlangten", so Defensive Cyber Operations von Okta. Die Hacker konnten sich Zugang zu den kompromittierten Konten verschaffen, sich als Benutzer ausgeben, ihnen höhere Privilegien zuweisen und die MFA-Faktoren zurücksetzen und/oder entfernen.

Der interessanteste Aspekt dieses Angriffs ist der Erstzugang. Dies ist etwas, das sehr oft nicht detailliert genug untersucht wird. Laut Okta handelte es sich um Social Engineering. Sie erklären: "Ein Bedrohungsakteur nutzte Social Engineering, um eine hoch privilegierte Rolle in einer Okta-Kundenorganisation (Tenant) zu erlangen."

Social Engineering ist eine Taktik, die von Cyberkriminellen eingesetzt wird, um unter Vorspiegelung falscher Tatsachen Informationen von Personen zu erhalten.

Wir gehen davon aus, dass die Hauptschwachstelle in der Abhängigkeit von Passwörtern und einem unsicheren Wiederherstellungsprozess bestand. Die Hacker waren in der Lage, die Super-Admin-Passwörter zu kompromittieren und dann das menschliche Element zu nutzen, um einen Wiederherstellungsprozess auszunutzen, der auf ihrer Fähigkeit beruht, 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-Identitätsanbieter (IdP) ermöglicht, wenn sich der Benutzer erfolgreich bei einem Quell-IdP authentifiziert hat. Vereinfacht ausgedrückt, ermöglichte die Inbound-Federation-Funktion den Hackern ein SSO bei verschiedenen Tenants. Daher auch der Begriff "mandantenübergreifende Impersonation". 

Könnte sich dieser Cyberangriff anderswo wiederholen? 

Da die Schwachstelle im Fall der Okta-Angriffe offenbar Anmeldedaten (Passwörter und MFA) kompromittiert wurde, könnte man automatisch annehmen, dass passwortlose MFA dazu beigetragen hätte, den Erstzugriff zu verhindern, aber das ist nicht ganz richtig. Die Antwort hat mehr mit der Gesamtarchitektur der Technologie zu tun. Dieses Problem ist nicht ausschließlich. Tatsächlich basieren viele MFA-Lösungen (passwortlos oder nicht) auf ähnlichen Architekturen und stützen sich auf die zentralisierte Anmeldedaten, die für andere Aspekte des Identitätslebenszyklus verwendet wird, wie 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 einer phishing-resistenten MFA wie WebAuthN und die Verwendung seiner stärksten Authentifizierungsmethode "derzeit Okta Verify oder Google Authenticator" für die Wiederherstellung von Konten im Self-Service. 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-Müdigkeit (Prompt Bombing) und Adversary-in-the-Middle-Angriffe. WebAuthN ist phishing-resistent, löst aber nicht das Problem der Kontowiederherstellung. Die Wiederherstellung von WebAuthN (Passkeys) stützt sich auf schwächere Authentifizierungsfaktoren, in der Regel Passwörter und OTP. Wenn sich Organisationen 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-Verantwortliche sollten nach Technologien Ausschau halten, die Funktionen wie Identitätsbindung und transitives Vertrauen umfassen. Sie sollten auch nach Technologien mit einer Architektur suchen, die zero trust, zero knowledge und Null PII (Personal Identifiable Information) umfasst.

Die Nutzung von Zero-Trust-Konzepten wie transitives Vertrauen und Identitätsnachweis ermöglicht Self-Service und stellt gleichzeitig sicher, dass der gesamte Lebenszyklus der Benutzeridentität immun gegen Phishing und nachweisbar ist und nicht von einem privilegierten Insider unterwandert werden kann.

Um der Authentifizierung zu vertrauen, müssen die Herkunft, Authentizität, Integrität und Identität des Authentifizierungsursprungs (Gerät) sichergestellt und mit der Benutzeridentität gekoppelt werden. Das Authentifizierungsgerät und die Benutzeridentität sollten untrennbar sein. Folglich muss ein explizites transitives Vertrauen zwischen dem Gerät und der Benutzeridentität durch 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 allein deshalb vertraut wird, weil sie von einem Benutzer und/oder dem Gerät eines Benutzers stammt. Es muss nachprüfbar gewährleistet sein, dass eine Transaktion über einen "vertrauenswürdigen Dienst" durchgeführt wurde, der mit einem "vertrauenswürdigen Gerät" verbunden ist, das an diesen "bestimmten Benutzer" gekoppelt ist und unter der "vollständigen Kontrolle des Benutzers" genehmigt wurde. Dies sollte die Grundlage einer jeden Zero-Trust-Sicherheitsreise sein.

Schlussfolgerung

Letztendlich glauben wir, dass die Lösungen in einer besseren Kenntnis und einem besseren Verständnis der Probleme (wie oben beschrieben) zu finden sind. Die Praktiker müssen in die Lage versetzt werden, gut informierte Entscheidungen zu treffen. Dazu gehört auch, dass die Branche über die bestehenden Technologien und ihre Schwächen aufgeklärt wird und weiß, wie diese Herausforderungen zu bewältigen sind.

Wenn Sie weitere Informationen zu diesem Thema, zur AuthN by IDEE MFA-Lösung oder zu anderen Themen im Zusammenhang mit Ihrem Anwendungsfall wünschen, nehmen Sie bitte Kontakt mit uns auf.

‍