Phishing-Resistenz zuerst
Phishing-resistente Authentifizierung ist die aktuelle Grundlage für sichere Authentifizierung, was FIDO/WebAuthn, FastPass, PIV/CAC usw. bedeutet. Dieser Beitrag konzentriert sich darauf, wie diejenigen, die diese Grundlage bereits erfüllen, die Sicherheit auf die nächste Stufe heben können.
Passwörter, SMS, Push-Benachrichtigungen und Einmalcodes sind anfälliger für viel weniger ausgeklügelte Angriffe als die in diesem Artikel beschriebenen, daher empfehlen wir sie nicht.
Wo Phishing-Resistenz zu kurz greift
Wie bereits erwähnt, sind FastPass, Passkeys und andere FIDO-Authentifikatoren eine hervorragende Möglichkeit, Ihre Organisation vor Phishing-Angriffen zu schützen, da der Angreifer dafür im Wesentlichen eine Art Präsenz auf Ihrem Gerät erlangen (oder sogar physisch einen Schlüssel stehlen) muss.
Phishing-resistente Authentifikatoren basieren auf zwei vom NIST definierten Anforderungen, Verifier Name Binding und Channel Binding [dies ist ein Entwurf, Kommentare sind 'geschlossen'], die zusammen die meisten Phishing-Angriffe erfolgreich verhindern. Sowohl FIDO als auch FastPass basieren beispielsweise auf Verifier Name Binding.
Zusätzlich zu diesen Anforderungen müssen Phishing-resistente Authentifikatoren einen geschützten Kanal zwischen dem Browser und dem Authentifikator erstellen, um das Abhören oder Weiterleiten von Angriffen auf ein Remote-Gerät zu verhindern. Aber die Anforderungen berücksichtigen keine böswillige Präsenz auf dem Gerät des Benutzers. Infolgedessen kann eine Klasse ausgefeilterer Angriffe auftreten – und wenn sie erfolgreich sind, ermöglichen sie es Angreifern, die Anforderungen an die Phishing-Resistenz zu erfüllen.
Beispiel für einen Angriff: Geräteübergreifende Authentifizierung über SOCKS
Stellen Sie sich ein Opfer vor, das auf einen Link geklickt hat, der Malware auf seinem System installiert hat. Als Grundlage für diesen Angriff muss der Angreifer bereits in der Lage sein, Code als Benutzer auf seinem Rechner auszuführen.
|
1 |
Der Angreifer erstellt einen SOCKS Reverse Proxy zwischen dem kompromittierten Gerät und seinem eigenen Gerät (Schritt 1 im Diagramm). Mit der richtigen Einrichtung kann der Angreifer dann entweder FastPass- oder FIDO2-Challenges von seinem eigenen Gerät über den SOCKS-Proxy an das kompromittierte Gerät weiterleiten. |
|
2–3 |
Der Angreifer versucht, von seinem eigenen Gerät aus auf die Ressourcen des Benutzers zuzugreifen, und leitet die Authentifizierungsabfrage über den Proxy an das Gerät des Benutzers weiter. |
|
4 |
Der Browser fragt direkt vom Angreifergerät beim Okta-Server ab und wartet darauf, dass die Authentifizierungsabfrage erfüllt wird. |
|
5 |
Der Angreifer muss das kompromittierte Gerät dazu bringen, die Challenge-Antwort mit seinem TPM zu signieren.
Eine gut konfigurierte Richtlinie erfordert die Anwesenheit des Benutzers und löst eine benutzerseitige Aufforderung zur Eingabe von Biometriedaten oder eines Gerätepasscodes aus, was den Verdacht des Benutzers erwecken kann. In einem Szenario, in dem sich Malware auf dem Gerät befindet, kann der Angreifer jedoch möglicherweise einen Passcode angeben oder den Angriff geschickt so timen, dass der Benutzer von der Aufforderung nicht überrascht wird (z. B. wenn der Benutzer nicht an seinem Rechner sitzt oder ohnehin eine Authentifizierungsabfrage erwartet). |
|
6-8 |
Schließlich wird die Challenge-Response vom kompromittierten Gerät an den Okta-Server gesendet, wobei die TPM-Schlüsselprüfungen, die Phishing-Resistenz und die Gerätevertrauensgarantien bestanden werden.
Infolgedessen hat das Gerät des Angreifers nun eine gültige Sitzung, da er in der Lage war, die Authentifizierung zwischen seinem Webbrowser und dem Authentifikator auf dem kompromittierten Gerät transparent zu vermitteln. |
Geben Sie Filter für vertrauenswürdige Apps ein
Im August 2024 veröffentlichte Okta eine Funktion zur Abschwächung dieser Art von Angriffen für FastPass: Filter für vertrauenswürdige Apps. Diese hochsichere Einrichtung ermöglicht es Administratoren, alle Authentifizierungsversuche von Apps automatisch zu blockieren, die nicht explizit auf der Zulassungsliste stehen oder entweder überhaupt nicht signiert oder mit einem nicht vertrauenswürdigen Codesignaturzertifikat signiert sind.
So funktioniert's
Wenn eine Anwendung wie Chrome versucht, sich mit FastPass zu authentifizieren, versucht das Okta-Anmelde-Widget, eine Verbindung zu Okta Verify herzustellen, das auf dem Gerät ausgeführt wird, und stellt dann die Authentifizierungsabfrage vom Okta-Backend aus zu.
Während diese Verbindung aktiv ist, verfolgt Okta Verify den Port und den Prozess zurück, der die Verbindung auf dem Gerät erstellt hat. Wenn Port und Prozess nicht gefunden werden können, kann dies darauf hindeuten, dass der Ursprung Remote war und die Verbindung wird getrennt.
Wenn der Prozess identifiziert werden kann, erfasst Okta Verify detaillierte Signaturdaten über die ausführbare Datei und verifiziert, dass die Signatur mit dem Code-Signaturzertifikat übereinstimmt und dass das Code-Signaturzertifikat von der lokalen Vertrauenskette als vertrauenswürdig eingestuft wird.
Wir verwenden beispielsweise SecCodeCopySigningInformation (macOS) WinVerifyTrust (Windows), um detaillierte Informationen über den Prozess zu erhalten. Sobald alle diese Daten erfasst sind, werden sie zusammen mit der Management-Bescheinigung und den Gerätesignalen in einer Challenge-Response gesendet, die alle zusammen mit einem Hardware-gebundenen Schlüssel verpackt und signiert werden.
Überwachung
Wenn Sie FastPass unter macOS oder Windows verwenden, sind diese Daten derzeit in Ihren SysLogs verfügbar.
Dies ist ein Beispiel für die Anmeldung am Okta Dashboard mit Chrome für macOS.
Wenn Sie Ihre Protokolle durchsehen, können Sie sehen, mit welchen Apps sich Ihre Benutzer authentifizieren, und Workflows erstellen, um Sie auf neue Apps aufmerksam zu machen, die verwendet werden. Sie sollten ein gutes Verständnis dafür haben, welche Binärdateien mit den Apps verknüpft sind, auf die in Ihrer Organisation zugegriffen wird. Benutzer sollten sich beispielsweise nur über einen Browser oder die native Slack-Anwendung bei Slack authentifizieren.
Durchsetzung
Nachdem Sie eine vollständige Liste der Anwendungen zusammengestellt haben, die für eine bestimmte Auth-Richtlinie gelten, können Sie Trusted App Filters erzwingen, um diese Angriffe zu blockieren, bevor sie beginnen. Dies kann etwas komplex sein, daher ist es am einfachsten, separate Auth-Richtlinienregeln für jede Desktop-Plattform zu erstellen (z. B. die Plattform- oder Gerätesicherheitsregel für eine bestimmte Regel auf macOS oder Windows festlegen)..
Sobald Ihre Expression Language eingerichtet ist, wird jede Anwendung, die die Signaturprüfung nicht besteht (z. B. unsignierte Malware) wird zusammen mit dem entsprechenden SysLog-Eintrag blockiert. Signierte Anwendungen, die nicht in der Liste enthalten sind (z. B. der SSH-Daemon), werden ebenfalls blockiert.
Beispiel 1: Chrome, Firefox und Safari unter macOS
In diesem Beispiel erlauben wir alle wichtigen Browser, die unter macOS unterstützt werden, entweder mit SSO-Erweiterung oder Loopback-Bindungen. Das bedeutet, dass nur die beiden phishing-resistenten Bindungen die Regel für FastPass auslösen. Beachten Sie, dass native Anwendungen mit eigenen Webviews wie O365 diese Regel nicht erfüllen würden. Wenn Sie diese zulassen möchten, müssen Sie auch deren Kennung(en) angeben.
Beispiel 2: Edge und Chrome unter Windows
Windows ist etwas einfacher, da LOOPBACK die einzige gültige Bindung für diese Prüfung ist. Beachten Sie, dass dies auch nicht-phishing-resistente Flows verhindert, die durch CUSTOM_URL Binding ausgelöst werden.
Kombinieren von Trusted App Filtern mit FIDO oder anderen Authentifikatoren
Wenn Sie einen anderen Authentifikator als FastPass verwenden möchten, z. B. einen FIDO-Sicherheitsschlüssel, können Sie auch Trusted App Filters für diese Authentifizierungsregel erzwingen, vorausgesetzt, dass auch ein Okta Verify-Konto auf diesem Gerät registriert ist.
Erstellen Sie dazu eine Regel mit allen folgenden Elementen:
- Eine registrierte oder verwaltete Bedingung
- Die Ausdruckssprache für Filter für vertrauenswürdige Apps
- Erlauben Sie die Authentifikatoren, die Sie unterstützen möchten, oder verwenden Sie „Beliebige Methode zulassen“
Wenn Sie FastPass unter macOS oder Windows in Ihrem Unternehmen verwenden, können Sie noch heute mit der Überwachung beginnen, welche nativen Anwendungen die FastPass-Authentifizierung auslösen! Sobald Sie ein klares Bild davon haben, welche vertrauenswürdigen Anwendungen verwendet werden, sollten Sie diese Anwendungen auf die Whitelist setzen und alle anderen Anwendungen daran hindern, FastPass zu verwenden.
Wenn Sie mehr zu diesem Thema sehen möchten, einschließlich einer großartigen Demo von Zach Newton, sehen Sie sich unseren Vortrag von der Oktane 2024 an (kostenlose Registrierung erforderlich).
Haben Sie eine Frage zu FastPass oder Gerätesicherheit? Treten Sie dem Okta FastPass Community Board bei und starten Sie eine Diskussion.
Haben Sie Fragen zu diesem Blogbeitrag? Kontaktieren Sie uns unter eng_blogs@okta.com.
Entdecken Sie weitere aufschlussreiche Engineering-Blogs von Okta, um Ihr Wissen zu erweitern.
Möchten Sie Teil unseres engagierten Teams aus herausragenden Ingenieuren werden? Besuchen Sie unsere Karriereseite.
Nutzen Sie das Potenzial moderner und fortschrittlicher Identitätsverwaltung für Ihr Unternehmen. Kontaktieren Sie unseren Vertrieb für weitere Informationen.
