Unterstützen des erweiterten Schutzes für die Authentifizierung (EPA) in einem Dienst

Artikel
10/23/2023

Feature	Gilt für:
EPA	alle unterstützten Windows-Betriebssysteme
EPA-Überwachungsmodus	Windows Server 2019 Windows Server 2022 Windows Server 23H2

Was ist das Problem?

Es gibt eine Klasse von Angriffen auf authentifizierte Dienste, die als Weiterleitungsangriffe bezeichnet werden. Diese Angriffe ermöglichen es Angreifern, die Authentifizierung zu umgehen und als anderer Benutzer zu fungieren. Da es sich hierbei um Angriffe auf den Dienst und nicht um das Authentifizierungsprotokoll selbst handelt, liegt es an dem authentifizierten Dienst, um Weiterleitungsangriffe zu verhindern.

Wie funktionieren Weiterleitungsangriffe?

Wenn ein Dienst oder eine Anwendung die API AcceptSecurityContext aufruft, um einen Client zu authentifizieren, übergibt er ein Blob mit Daten, die vom Aufruf des Clients an InitializeSecurityContextempfangen wurden. Das Authentifizierungsprotokoll ist für die Überprüfung verantwortlich, ob das bereitgestellte Blob vom angegebenen Benutzer stammt. AcceptSecurityContext kann keine Assertionen über die Authentizität des Rests der Anwendungsnachricht machen, die nicht angezeigt wurde.

Ein häufiger Sicherheitsfehler in Anwendungen behandelt den Anwendungsdatenverkehr nach einer erfolgreichen Authentifizierung des inneren Authentifizierungsprotokoll-BLOB als authentifiziert. Dies geschieht am häufigsten bei Anwendungen, die TLS für ihr Drahtprotokoll verwenden. TLS verwendet in der Regel keine Clientzertifikate, es bietet dem Server Integritäts- und Vertraulichkeitsgarantien, aber keine Authentifizierung. Die innere Authentifizierung stellt die Clientauthentifizierung bereit, aber nur für sein BLOB. Es authentifiziert den TLS-Kanal oder den Rest des darin enthaltenen Anwendungsprotokolls nicht.

Ein Angreifer führt einen Weiterleitungsangriff aus, indem er einen Authentifizierungs-BLOB aus einer Quelle mit einer erstellten Anforderung eines Angreifers einfügt. Beispielsweise kann ein Angreifer den Authentifizierungsdatenverkehr im Netzwerk beobachten und dies in eine eigene Anforderung an den Server einfügen. Dadurch kann der Angreifer über den erfassten Authentifizierungsdatenverkehr Zugriff auf den Server als Client erhalten.

Das wichtigste Konzept hier ist, dass SSPI-Authentifizierungsnachrichten für die Bereitstellung auf dem Draht konzipiert sind. Es wird nicht erwartet, dass sie geheim gehalten werden. Dies unterscheidet sich von vielen webbasierten Authentifizierungssystemen, die Inhaber-Token verwenden, die innerhalb von TLS-Kanälen stets vertraulich behandelt werden.

Was ist die Lösung?

Die bevorzugte Lösung besteht darin, den Sitzungsschlüssel des Authentifizierungsprotokolls zu verwenden, um anderen Datenverkehr (MakeSignature, EncryptMessage) zu signieren oder zu verschlüsseln. Da der Sitzungsschlüssel während des Authentifizierungsprotokollaustauschs kryptografisch abgeleitet wird, werden seine authentifizierten Daten und jeder Datenverkehr, der durch diesen Schlüssel geschützt ist, garantiert vom authentifizierten Client stammen.

Dies ist nicht immer eine Option. In einigen Fällen ist das Format der Anwendungsprotokollnachricht durch Standards festgelegt, die für Inhaber-Token entwickelt wurden. In diesem Fall kann der erweiterte Schutz für die Authentifizierung (EPA), auch als Kanalbindung bezeichnet, vor der Weiterleitung über einen TLS/SSL-Kanal schützen.

Was ist EPA?

EPA bindet den TLS-Sitzungsschlüssel kryptografisch an den Sitzungsschlüssel des Authentifizierungsprotokolls, sodass TLS dieselbe Clientauthentifizierung wie der Schlüssel des Authentifizierungsprotokolls bereitstellt. Weitere Informationen finden Sie unter Übersicht über Erweiterten Schutz für Authentifizierung.

Dienstbindung

Der zweite Teil der EPA wird als Service Binding bezeichnet. Im Gegensatz zur Kanalbindung bietet dies den Dienst nicht mit kryptografischen Garantien und dient als Verteidigung des letzten Auswegs, in dem die Kanalbindung nicht möglich ist. Mit diesem Mechanismus kann der Server QueryContextAttributes aufrufen, um das Attribut SECPKG_ATTR_CLIENT_SPECIFIED_TARGET abzurufen, das den Namen enthält, den der authentifizierte Client an InitializeSecurityContext übergeben hat.

Stellen Sie sich beispielsweise einen Dienst vor, der sich hinter einem TLS-Endlastenausgleich befindet. Er hat keinen Zugriff auf den TLS-Sitzungsschlüssel und kann nur aus der Kanalbindung ermitteln, dass die Authentifizierung des Clients für einen TLS-geschützten Dienst vorgesehen war. Der vom Client angegebene Name sollte derselbe Name sein wie der Name, der zum Überprüfen des TLS-Serverzertifikats verwendet wird. Durch die Überprüfung, dass der Client mit einem Namen authentifiziert wurde, der mit dem Server-TLS-Zertifikat vom Lastenausgleich übereinstimmt, erhält der Dienst hohe Zuverlässigkeit, dass die Authentifizierung von demselben Client wie der TLS-Kanal stammt.

In diesem Artikel wird nicht erläutert, wie die Dienstbindung unterstützt wird. Für weitere Informationen siehe Wie funktioniert das Festlegen einer Dienstbindung in der Konfiguration.

Wie unterstützen Sie EPA?

Bei der Durchführung von EPA können Dienste feststellen, dass Clients aufgrund von Kompatibilitätsproblemen nicht authentifiziert werden. Daher haben wir einen EPA-Überprüfungsmodus geschaffen, in dem Dienste die Überprüfung aktivieren können, so dass Administratoren beobachten können, wie Clients reagieren, bevor sie EPA anwenden.

Microsoft-Dienste, die den Überwachungsmodus unterstützen, umfassen:

LDAP

Hinweis

Nachfolgend finden Sie optionale Schritte zum Aktivieren der EPA-Überwachungsfunktionen. Bitte beachten Sie, dass die Aktivierung der EPA-Überwachungsfunktionen ohne Umsetzung der EPA nicht vor Relay-Angriffen schützt. Wir empfehlen, dass Dienste, die sich dafür entscheiden, EPA zunächst nur im Audit-Modus zu aktivieren, später Maßnahmen zur Behebung inkompatibler Clients ergreifen und schließlich EPA strikt durchsetzen, um mögliche Relay-Angriffe zu vermeiden.

Hinweis

Die an AcceptSecurityContext übergebenen Kanalbindungen müssen keine reinen Audit-Bindungen sein, um die Auditing-Ergebnisse zu erhalten. Dienste können den Überwachungsmodus ausführen und gleichzeitig EPA erzwingen.

Client

Verwenden von QueryContextAttributes(TLS) zum Abrufen von Kanalbindungen (Ausfüllen eindeutiger vs-Endpunkt)
Aufrufen von InitializeSecurityContext und Übergeben von Kanalbindungen in SECBUFFER_CHANNEL_BINDINGS

Server

Verwenden von QueryContextAttributes(TLS) wie auf dem Client
(Optional) Wird durch den Aufruf von SspiSetChannelBindingFlags in einen reinen Audit-Modus umgewandelt
(Optional) Fügen Sie dem Ausgabepuffer für ASC Kanalbindungsergebnispuffer hinzu.
Angeben der EPA-Ebene und anderer Konfigurationen durch Aufrufen von AcceptSecurityContext mit SECBUFFER_CHANNEL_BINDINGS
(Optional) Verwenden Sie Flags, um das Verhalten in Eckfällen zu steuern:
- ASC_REQ_ALLOW_MISSING_BINDINGS – Führen Sie keine Fehler von Clients durch, die überhaupt nichts gesagt haben, wie z. B. alte Geräte von Drittanbietern. Optimierte Clients, die keine SECBUFFER_CHANNEL_BINDINGS erhalten haben, senden eine leere Bindung anstatt nichts.
- ASC_REQ_PROXY_BINDINGS – Ein seltener Fall für TLS-Endlastenausgleichsgeräte. Wir haben keine SECBUFFER_CHANNEL_BINDINGS zu übergeben, möchten aber dennoch durchsetzen, dass Clients Anforderungen in einen TLS-Kanal stellen. Dies ist am nützlichsten bei Dienstbindungen, um sicherzustellen, dass der Client auch in einen TLS-Kanal eingefügt wurde, für den das Serverzertifikat mit unserem Namen übereinstimmt.

Wie erzwingen Sie EPA?

Sobald ein Dienst EPA unterstützt, können Administratoren den EPA-Status bis hin zur vollständigen Durchsetzung kontrollieren. Dies bietet Diensten die Tools, um die Bereitschaft ihres Ökosystems für EPA zu bewerten, inkompatible Geräte zu beheben und die EPA schrittweise zu erzwingen, um ihre Umgebung zu schützen.

Die folgenden Attribute und Werte können verwendet werden, um verschiedene Ebenen von EPA in Ihrer Umgebung zu erzwingen:

Name	Beschreibung
Keine	Keine Kanalbindungsvalidierung wird durchgeführt. Dies ist das Standardverhalten aller nicht aktualisierten Server.
Zulassen	Alle aktualisierten Clients müssen Kanalbindungsinformationen für den Server bereitstellen. Dies gilt nicht für nicht aktualisierte Clients. Dies ist eine Zwischenoption, durch die Anwendungskompatibilität gewahrt wird.
Erforderlich	Alle Clients müssen Kanalbindungsinformationen bereitstellen. Authentifizierungsanfragen von Clients, bei denen dies nicht der Fall ist, werden abgewiesen.

Diese Attribute können mit Überwachungsfunktionen gekoppelt werden, um Informationen zur Gerätekompatibilität auf verschiedenen Ebenen der EPA-Erzwingung zu sammeln. Sie übergeben Ihre gewünschte Konfiguration an SspiSetChannelBindingFlags.

Überwachung – Der Überwachungsmodus kann in Verbindung mit einem der oben genannten EPA-Durchsetzungsstufen verwendet werden.

Wie interpretieren Sie DIE EPA-Überwachungsergebnisse?

Überwachungsergebnisse sind eine Reihe von Bit-Flags:

Flag	Beschreibung
SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT	Der Client hat angegeben, dass er Kanalbindungen herstellen kann.
SEC_CHANNEL_BINDINGS_RESULT_ABSENT	Der Client hat keine Bindung an einen äußeren Kanal bereitgestellt.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH	Die Clientbindungen geben einen anderen Kanal als der Server an.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING	Fehler bei der Kanalbindung aufgrund von SEC_CHANNEL_BINDINGS_RESULT_ABSENT.
SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED	Die Kanäle wurden erfolgreich gebunden.
SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY	Der Client hat eine Bindung an einen äußeren Kanal angegeben, der aufgrund von ASC_REQ_PROXY_BINDINGS übergeben wurde.
SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING	Die Kanalbindung wurde aufgrund von ASC_REQ_ALLOW_MISSING_BINDINGS übergeben.

Es gibt auch Definitionen für Sätze von Bits:

Flag	Beschreibung
SEC_CHANNEL_BINDINGS_RESULT_VALID	Wird verwendet, um auf alle SEC_CHANNEL_BINDINGS_VALID_*-Fälle zu testen.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID	Wird verwendet, um auf alle SEC_CHANNEL_BINDINGS_NOTVALID_*-Fälle zu testen.

Überwachungsablauf

Jedes Betriebssystem, das die Ergebnisse unterstützt, legt immer mindestens ein Bit von SEC_CHANNEL_BINDINGS_RESULT_VALID und SEC_CHANNEL_BINDINGS_RESULT_NOTVALID fest.

Fehler bei der Kanalbindung: Testen Sie alle Bits aus SEC_CHANNEL_BINDINGS_RESULT_NOTVALID. Bei Bindungen, die nicht nur überwacht werden, entspricht dies einem ASC-Fehler mit STATUS_BAD_BINDINGS oder SEC_E_BAD_BINDINGS.

SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH: Der Client und der Server kennen beide die Kanalbindungen, sind sich aber nicht über den Kanal einig. Dies ist der Angriffsfall oder eine unsachgemäße Sicherheitskonfiguration, die von einem Angriff nicht zu unterscheiden ist, da die Konfiguration HTTPS kompromittiert hat, um Datenverkehr zu prüfen (z. B. Fiddler). Es könnte auch der Client und der Server sein, der nicht über eindeutige und Endpunktbindungen abstimmt.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING unterteilt sich in zwei Fälle:
- Bei SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORTbedeutet dies, dass der Client bestätigt, dass er über Kanalbindungen Bescheid weiß und gesagt hat, dass es keinen Kanal gibt. Dabei kann es sich um einen Weiterleitungsangriff von einem Nicht-TLS-Dienst handeln. Wahrscheinlich handelt es sich jedoch um eine unaufgeklärte Anwendung, die auf dem Client läuft und TLS verwendet, aber die interne Authentifizierung nicht darüber informiert.
- Ohne SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT ist es ein Client, der nicht in der Lage ist, Kanalbindungen zu binden. Alle unterstützten Windows-Versionen sind in der Lage, Kanalbindung zu erstellen. Dies ist also entweder Drittanbieter oder ein System, das den Registrierungswert SuppressExtendedProtection festgelegt hat. Dies ist der Fall, der in SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING umgewandelt wird, wenn Sie ASC_REQ_ALLOW_MISSING_BINDINGS übergeben.

Die Kanalbindung war erfolgreich: Dies ist die Umkehrung der Überprüfung auf Fehler oder der Test für SEC_CHANNEL_BINDINGS_RESULT_VALID.

SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED ist der Erfolgsfall. Der Sicherheitsschutz funktioniert (oder würde funktionieren, wenn EPA als reines Audit aktiviert ist).
SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING bedeutet, dass ASC_REQ_ALLOW_MISSING_BINDINGS übergeben wurde, daher haben wir einen Client zugelassen, der keine Unterstützung für die Kanalbindung beanspruchte. Clients, die auf diesen Fall treffen, sind nicht geschützt und sollten untersucht werden, um herauszufinden, was los ist. Sie müssen entweder aktualisiert werden, um die Kanalbindung zu unterstützen, oder der Registrierungswert SuppressExtendedProtection sollte gelöscht werden, sobald die defekten Anwendungen aktualisiert sind.
SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY ist ein Sonderfall, der dem Flag ASC_REQ_PROXY_BINDINGS zugeordnet ist, das verwendet wird, wenn TLS bei einem Lastenausgleich beendet wird, anstatt den Server zu erreichen. Der Server kann nicht überprüfen, ob der Client die gleiche TLS-Verbindung verwendet, die am Load Balancer (Lastenausgleich) beendet wird. Für Überwachungszwecke wird dies genauso behandelt wie SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED.