ADMIN
2022
10
2022-09-29T12:00:00
Datensicherheit
PRAXIS
058
Open-Source-Tipp
Sicherheit
Kerberos
MIT-Kerberos-Bibliothek
Sicherheit nach Maß
von Thorsten Scherf
Veröffentlicht in Ausgabe 10/2022 - PRAXIS
Mithilfe des Kerberos-Protokolls gelingt eine Anmeldung an einem Service komplett transparent für den Benutzer. Die MIT-Kerberos-Bibliothek erlaubt dabei, unterschiedliche Sicherheitsanforderungen einzelner Dienste umzusetzen. Der Open-Source-Tipp in diesem Monat zeigt, wie dies funktioniert.

Wird ein Benutzer mittels Kerberos an einem Key-Distribution-Center (KDC) authentifiziert, bekommt dieser am Ende des Vorgangs ein Ticket-Granting-Ticket (TGT) ausgestellt. Hiermit ist dann eine transparente Anmeldung an weiteren Kerberos-Diensten möglich. Bevor es jedoch soweit ist, muss der Benutzer initial seine Identität gegenüber dem KDC nachweisen. Dieser Vorgang wird auch als Pre-Authentication bezeichnet und dient als Schutz vor Angreifern, die eine beliebige Anfrage an den Server senden, nur um dann mithilfe eines Wörterbuch- oder Brute-Force Angriffs zu versuchen, an das Benutzerpasswort zu gelangen.
Dies wäre ohne Pre-Authentication möglich, weil der KDC in einem solchen Fall einfach Daten mit einem vom Benutzerpasswort abgeleiteten Schlüssel codiert an den Client senden würde. Angreifer hätten dann jede Menge Zeit, eine Offlineattacke durchzuführen, um so letztendlich an das Benutzerkennwort zu gelangen.
Zuerst das Passwort bitte
Um einen solchen Angriff zu unterbinden, erfordern alle aktuellen Kerberos-Implementierungen eine Pre-Authentication. Initiiert ein Client eine Anmeldung an einem KDC, wird die Verbindung erst einmal unterbrochen und der Server fordert den Client auf, sich zu authentisieren. Im einfachsten Fall muss der Benutzer einfach sein Passwort eingeben. Hiervon erfolgt die Ableitung eines Schlüssels (long-term Key), der im Anschluss zur Codierung eines Zeitstempels dient. Dieser wird danach zur Authentifizierung des Benutzers an den KDC übertragen. Hat dies funktioniert, bekommt der Benutzer auch ein TGT ausgestellt. Diese Methode ist auch im initialen Kerberos-RFC [1] beschrieben und wird somit von sämtlichen Kerberos-Implementierungen unterstützt [1] und ist in Listing 1 dargestellt.
Wird ein Benutzer mittels Kerberos an einem Key-Distribution-Center (KDC) authentifiziert, bekommt dieser am Ende des Vorgangs ein Ticket-Granting-Ticket (TGT) ausgestellt. Hiermit ist dann eine transparente Anmeldung an weiteren Kerberos-Diensten möglich. Bevor es jedoch soweit ist, muss der Benutzer initial seine Identität gegenüber dem KDC nachweisen. Dieser Vorgang wird auch als Pre-Authentication bezeichnet und dient als Schutz vor Angreifern, die eine beliebige Anfrage an den Server senden, nur um dann mithilfe eines Wörterbuch- oder Brute-Force Angriffs zu versuchen, an das Benutzerpasswort zu gelangen.
Dies wäre ohne Pre-Authentication möglich, weil der KDC in einem solchen Fall einfach Daten mit einem vom Benutzerpasswort abgeleiteten Schlüssel codiert an den Client senden würde. Angreifer hätten dann jede Menge Zeit, eine Offlineattacke durchzuführen, um so letztendlich an das Benutzerkennwort zu gelangen.
Zuerst das Passwort bitte
Um einen solchen Angriff zu unterbinden, erfordern alle aktuellen Kerberos-Implementierungen eine Pre-Authentication. Initiiert ein Client eine Anmeldung an einem KDC, wird die Verbindung erst einmal unterbrochen und der Server fordert den Client auf, sich zu authentisieren. Im einfachsten Fall muss der Benutzer einfach sein Passwort eingeben. Hiervon erfolgt die Ableitung eines Schlüssels (long-term Key), der im Anschluss zur Codierung eines Zeitstempels dient. Dieser wird danach zur Authentifizierung des Benutzers an den KDC übertragen. Hat dies funktioniert, bekommt der Benutzer auch ein TGT ausgestellt. Diese Methode ist auch im initialen Kerberos-RFC [1] beschrieben und wird somit von sämtlichen Kerberos-Implementierungen unterstützt [1] und ist in Listing 1 dargestellt.
Listing 1: Pre-Authentication
### Ein Tracing vom kinit zeigt die ausgewählte Pre-Authentication-Methode an.
# KRB5_TRACE=/dev/stdout kinit tscherf
[20981] 1655644410.292205: Received error from KDC: -1765328359/Additional pre-authentication required
[20981] 1655644410.292208: Preauthenticating using KDC method data
[20981] 1655644410.292209: Processing preauth types: PA-FX-FAST (136), PA-ETYPE-INFO2 (19), PA-ENC-TIMESTAMP (2), PA-FX-COOKIE (133)
[…]
[20981] 1655644412.754459: Preauth module encrypted_timestamp (2) (real) returned: 0/Success
Diese Variante hat allerdings den Nachteil, dass Angreifer unter Umständen noch immer an Daten gelangen können, die mit dem Schlüssel eines Benutzers codiert sind. Somit wäre in diesem Fall immer noch eine Wörterbuch- oder Brute-Force-Attacke möglich.
Schutz vor Angriffen auf das Passwort
Glücklicherweise existieren aber noch weitere Pre-Authentication-Methoden. So ist beispielsweise im RfC 4556 das Verfahren PKINIT (Public Key Cryptography for Initial Authentication) [2] definiert. Diese Variante arbeitet mit einem öffentlichen und einem privaten Schlüssel. Der öffentliche Key ist dabei Teil eines X.509-Zertifikats, das von einer Zertifizierungsstelle signiert wurde (Listing 2). Der private Schlüssel ist in diesem Beispiel zusammen mit dem Zertifikat in einer PEM-Datei gespeichert, kann bei Bedarf aber auch auf einer Smartcard vorliegen.
Listing 2: PKINIT-Verfahren
### Mittels PKINIT weist der Benutzer seine Identität mithilfe eines Zertifikates nach..
# KRB5_TRACE=/dev/stdout kinit -X X509_user_identity='FILE:/home/tscherf/ tscherf.pem' tscherf
[107503] 1655649304.486966: Received error from KDC: -1765328359/Additional pre-authentication required
[107503] 1655649304.486969: Preauthenticating using KDC method data
[107503] 1655649304.486970: Processing preauth types: PA-PK-AS-REQ (16), PA-FX-FAST (136), PA-ETYPE-INFO2 (19), PA-PKINIT-KX (147), PA-ENC-TIMESTAMP (2), PA_AS_FRESHNESS (150), PA-FX-COOKIE (133)
[…]
[107503] 1655649304.486973: Preauth module pkinit (147) (info) returned: 0/Success
Anonymes PKINIT und FAST
Interessant ist, dass der KDC ein TGT für einen Benutzer ausstellen kann, das jedoch nicht an die Identität des Benutzers selbst gebunden ist. Dies ist in den Fällen nützlich, in denen zwischen Client und KDC ein verschlüsselter Tunnel aufgebaut werden soll. Durch diesen Tunnel können Nutzer dann sicher mit dem KDC kommunizieren, ohne dass potentielle Angreifer Zugriff auf die übertragenden Daten haben.
Dies ist gerade bei der Multifaktor-Authentifizierung (MFA) hilfreich, bei der zusätzlich zum Benutzerpasswort ein weiterer Faktor, beispielsweise ein One-Time-Passwort (OTP), im Klartext übertragen wird. Für diese Variante ist im RFC 6113 [3] die Pre-Authentication-Methode FAST (Flexible Authentication Secure Tunneling) definiert.
Für den praktischen Einsatz rufen Sie zuerst kinit mit der Option "-n" auf. Hierdurch erhalten Sie ein anonymes TGT ausgestellt:
kinit -n
klist
Ticket cache: KCM:0
Default principal: WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS
[...]
Dieses Ticket können Sie nun verwenden, um einen sicheren Tunnel zwischen dem Client und dem KDC aufzubauen (Listing 3). Erst nachdem dieser Tunnel aufgebaut wurde, findet die eigentliche Authentifizierung des Benutzers mithilfe einer beliebigen Pre-Authentication-Methode statt.
Listing 3: FAST-Tunnel
### Mittels FAST erzeugen Sie einen sicheren Tunnel.
# ARMOR_CCACHE=$(klist|grep cache:|cut -d' ' -f3-)
# KRB5_TRACE=/dev/stdout kinit -T $ARMOR_CCACHE tscherf </>
Password for tscherf@EXAMPLE.COM
[108350] 1655651317.859136: FAST armor ccache: KCM:0:45797
[108350] 1655651317.859139: Using FAST due to armor ccache negotiation result
[…]
SPAKE und Diffie-Hellmann
Mit SPAKE (Simple Password-Based Encrypted Key Exchange) [4,5] steht eine recht neue Pre-Authentication-Methode zur Verfügung, die von MIT-Kerberos seit der Version 1.17 unterstützt wird. Sie basiert auf einem asymmetrischen Diffie-Hellmann-Schlüsselaustausch [6]. Dies hat den Vorteil, dass im Gegensatz zu PKINIT hierfür keine zusätzliche Infrastruktur in Form einer PKI notwendig ist.
Bereits seit der MIT-Kerberos-Version 1.14 unterstützt die Bibliothek daneben sogenannte "Authentication Indicators". Hiermit stellen Sie bei Bedarf Anforderungen an die Stärke der initialen Benutzeranmeldung, bevor der Benutzer letztendlich ein Kerberos-Service-Ticket ausgestellt bekommt. Somit können Sie den Sicherheitsanforderungen unterschiedlicher Systeme gerecht werden, indem Sie, je nach System, eine mehr oder weniger starke Authentifizierung verlangen. In der KDC-Konfigurationsdatei "/var/kerberos/krb5kdc/kdc.conf" definieren Sie für die Pre-Authentica-tion-Methoden einfach unterschiedliche Labels:
pkinit_indicator = pkinit
spake_preauth_indicator = spake
encrypted_challenge_indicator = fast
Diese Labels setzen Sie dann für die unterschiedlichen Service-Principals ein. Wenn Sie also beispielsweise ein Kerberos-Service-Ticket für einen SSH-Bastion-Host nur dann ausstellen möchten, wenn der Benutzer bei der initialen Anmeldung die Pre-Authentication-Methode PKINIT einsetzt, setzen Sie das Label auf dem Principal wie folgt:
kadmin setstr host/ssh-bastion.example.com require_auth pkinit
Führen Sie nun eine initiale Anmeldung nur mithilfe eines Passwortes durch und versuchen dann, mittels kvno ein Service-Ticket für den Host zu bekommen, schlägt dieser Versuch fehl:
kinit tscherf
Password for tscherf@EXAMPLE.COM
kvno host/ssh-bastion.example.com
kvno: KDC policy rejects request while getting credentials for host/ssh-bastion.example.com@EXAMPLE.COM
Setzen Sie bei der initialen Anmeldung hingegen PKINIT ein, so bekommen Sie auch das gewünschte Service-Ticket für den SSH-Host ausgestellt:
kinit -X X509_user_identity='FILE:/tmp/tscherf.pem' tscherf
kvno host/ssh-bastion.example.com
host/ssh-bastion.example.com@EXAMPLE.COM: kvno = 1
Fazit
Mit Authentication Indicators erlaubt Kerberos eine feingranulierte Steuerung, welche Pre-Authentication-Methode ein Benutzer verwenden muss, um den Zugriff auf einen bestimmten Kerberos-Service zu bekommen. In Abhängigkeit davon, wie sicherheitskritisch ein Dienst ist, bietet es sich beispielsweise an, den Zugriff nur dann zu erlauben, wenn die initiale Anmeldung mittels FAST oder SPAKE stattgefunden hat.
(dr)