Kerberos verhindert eindeutig, dass ein Angreifer in einem SSH-Man-in-the-Middle-Szenario (bei dem der Angreifer den Benutzer dazu gebracht hat, dem öffentlichen Schlüssel seines Servers zu vertrauen und den Datenverkehr über diesen Server umleitet) an die Anmeldeinformationen eines Benutzers gelangt. Was aber, wenn es einem Angreifer nichts ausmacht, die Anmeldeinformationen des Benutzers nicht zu erhalten, weil er die Sitzung nach der Authentifizierung abhören und möglicherweise wertvolle Informationen, einschließlich später eingegebener Anmeldeinformationen, abgreifen kann?
Um es klar zu sagen, hier ist das Szenario:
- SSH-Server (Server1) und Client (Benutzer1) sind für Kerberos eingerichtet. Server1 verfügt über ein standardmäßiges öffentliches/privates Schlüsselpaar zur Authentifizierung usw.
- Benutzer1 versucht zunächst, eine Verbindung zu Server1 herzustellen, seine Verbindung wird jedoch von einem Angreifer zu Server2 umgeleitet.
- Benutzer1 sieht sich den angezeigten öffentlichen Schlüssel von Server2 nicht genau an und akzeptiert ihn als bekannten Hostschlüssel für Server1 (und richtet so den MITM ein).
- Benutzer1 durchläuft die Kerberos-Authentifizierung mit Server1 über Server2 (Server2 richtet zwei separate SSH-Sitzungen ein und überträgt Informationen zwischen ihnen). Aufgrund der Funktionsweise von Kerberos erhält der Angreifer während der Authentifizierung keine wertvollen Informationen.
- Nach der Authentifizierung beginnt Benutzer1 jedoch mit der Ausführung von Vorgängen auf Server1, einschließlich sudo. Der Angreifer kann den gesamten Inhalt der Sitzung sehen, während er Server2 durchläuft.
Würde das funktionieren? Dieses Szenario würde offensichtlich durch die Verwendung einer Authentifizierung mit öffentlichem Schlüssel während des Authentifizierungsschritts vereitelt. Aber gibt es etwas im Kerberos- oder SSH-Protokoll, das diese Situation verhindern würde?
Antwort1
Etwas erweitert aus der Diskussion in den Kommentaren:
Ihre Frage lautet: Wenn Sie den SSH-Verkehr vom Client auf einen nicht autorisierten SSH-Server umleiten, kann dies für einen Replay-Angriff verwendet werden, indem das Kerberos-Ticket des Clients vom nicht autorisierten SSH-Server erfasst und an den echten Server1 weitergeleitet wird?
Dies beruht auf den SSH-Sicherheitsmechanismen, die das Scheitern von MiTM-Angriffen verhindern, d. h. der Client hat den echten Serverschlüssel von Server1 noch nicht zwischengespeichert oder, falls doch, StrictHostKeyCheckingwurde er deaktiviert oder ignoriert.
Da SSH + Kerberos GSS-API für die Datenverschlüsselung auf SSH angewiesen sind, gehen Sie davon aus, dass der Man-in-the-Middle-SSH-Server bei erfolgreicher Authentifizierung gegenüber Server1 auf alle übertragenen Informationen zugreifen kann, da SSH zusätzlich zur SSH-Verschlüsselung keine auf Kerberos basierende Datenverschlüsselung verwendet.
Ja, das würde theoretisch funktionieren, aber nur, wenn es Ihrem betrügerischen SSH-Server Server2 gelingt, sich gegenüber Server1 als Client auszugeben.
Ich denke, dass der echte Server1 die weitergeleiteten Anmeldeinformationen ablehnen würde (oder zumindest sollte). Als Teil der Kerberos-Authentifizierung sendet der Client zwei Nachrichten, dieServiceticket und der AuthenticatorAuch wenn ein weitergeleitetes Serviceticket gültig ist, wäre der zugehörige Authentifikator dies nicht.
RFC 4121Die von SSH verwendete Kerberos GSS-API-Spezifikation enthält die Kanalbindungsinformationen als Teil der Authentifikatornachricht:
„Die Kanalbindungs-Tags sollen dazu dienen, den bestimmten Kommunikationskanal zu identifizieren, für den die GSS-API-Sicherheitskontext-Einrichtungstoken bestimmt sind. Dadurch wird der Umfang eingeschränkt, in dem ein abgefangener Kontext-Einrichtungstoken von einem Angreifer wiederverwendet werden kann.“
Die Authenticator-Nachricht enthält die IP-Adresse und den Quellport des Absenders sowie die Ziel-IP-Adresse und die Portnummern. Wenn diese nicht mit denen der tatsächlichen Verbindung übereinstimmen, sollte der Kerberos-Austausch von Server1 abgelehnt werden.