Mensch und KI
Marisa Tschopp
In diesem Artikel möchte ich Ihnen einen Einblick in ein Microsoft-Protokoll geben – Kerberos Key Distribution Center Proxy. Es ist eine offene Spezifikation Microsofts, deren Ziel es ist, Kerberos Clients ausserhalb der Organisationsinfrakstruktur eine Kerberos-Authentisierung zu ermöglichen.
Kerberos, im RFC 4120 definiert, basiert auf dem Needham-Schröder Trusted-Third Party Authentisierungsprotokoll. Einfach gesagt, das Ziel von Kerberos ist die gegenseitige Authentisierung zwischen Client und Server Und die Überprüfung, dass der Client autorisiert ist auf den Server zu verbinden.
In einer Kerberos Umgebung existieren mindestens vier Entities:
Die Kerberos Authentisierung durchläuft folgende Schritte:
Erstens, der Client meldet sich an der AS an und erhält ein Ticket Granting Ticket (TGT). Der AS ist authentisiert indem er eine Zufallszahl, die der Client generiert hat, verschlüsselt und an den Client retourniert. Der Client selbst wird nicht explizit vom AS authentisiert. Es wird eine implizite Überprüfung seiner Identität vorgenommen, indem nur der Client in der Lage sein sollte, die Antwort vom AS zu entschlüsseln und jegliche weitere Kommunikation vom Entschlüsseln dieser Antwort abhängig ist.
Als nächstes sendet der Client das TGT zum TGS, zusammen mit seinem Service-Request für den Server. Der TGS prüft ob der Client autorisiert ist auf den Server zuzugreifen. Ist dies der Fall stellt der TGS ein Service Ticket (ST) aus und sendet dieses an den Client zurück.
Zuletzt sendet der Client das erhaltene ST zusammen mit seinem Request an den Server. Der Server und Client authentisieren sich gegenseitig mittels Austausch von verschlüsselten Zeitstempeln. War die gegenseitige Authentisierung erfolgreich, ist der Client nun in der Lage den zur Verfügung gestellten Service des Servers zu konsumieren.
Für eine erfolgreiche Kerberos Authentisierung müssen AS und TGS verfügbar sein, sobald der Client sich authentisieren möchte. Jedes ausgestellte Ticket (TGS und ST) verfügt über eine bestimmte Gültigkeitsdauer und kann nicht vor Ablauf dieser Dauer annulliert werden. Zeitsynchronisierung ist ein wichtiger Punkt bei Kerberos, da Zeitstempel auch als Challenge-Werte bei der Authentisierung verwendet werden. Daher sind synchronisierte Uhren unumgänglich. Zusätzlich muss jeder Client ein Langzeit-Secret (geteilt mit dem AS) speichern. Eine weitere Grundvoraussetzung ist das Vertrauen in den AS und TGS, dass sie ihre zentrale Position und Funktion nicht ausnutzen.
Ein Angriff auf das Kerberos Protokoll ist möglich, wenn der Angreifer Zugriff auf den Session Key K
(erstellt durch den AS und verwendet durch den Client wie auch den Server um ihre Kommunikation zu sichern) und der Server offline ist. Es ist keine Voraussetzung von Kerberos, dass der Server in den ersten Interaktionen zwischen Client und AS/TGS online sein muss. Ein Angreifer könnte sich als Server ausgeben und auf den Request des Clients mit einer gültigen Nachricht antworten, da er Kenntnis über den Session Key K
hat. Weiter könnte er sich auch als Server beim Client authentisieren.
Das Ziel dieser offenen Microsoft-Spezifikation ist es, den Anwendungsbereich von Kerberos ins Internet zu verlagern, wo das Kerberos-System im privaten, internen Netzwerk der Organisation nicht erreichbar ist.
Der KKDCP Server wird in einer Demilitarisierten Zone (DMZ) als Standalone System platziert. Mit einem Listener wartet es auf Kerberos Nachrichten der Clients aus dem Internet, die eine Authentisierung mit dem AS durchführen wollen.
Der Client hat Kenntnis, wo der Proxyserver zu lokalisieren ist. Dies geschieht über eine URL (KKDCPServerURL
). Gemäss der Spezifikation kann für die Kommunikation entweder HTTP oder HTTPS verwendet werden. Aus Sicherheitsgründen ist offensichtlich, dass HTTPS zum Schutz der Kerberos Nachrichten im Transit, zu bevorzugen ist. Standardmässig ist auch HTTPS in der Spezifikation vorhergesehen.
Der Client wie auch der Server senden sich Nachrichten mit dem Typ KDC_PROXY_MESSAGE zu. Dies ist ein neu spezifizierter Nachrichtentyp, der die originale Kerberos Nachricht und zusätzliche Informationen beinhaltet.
Der Proxy wird für alle Requests verwendet, bis der TGS das Service Ticket an den Client retournier hat. Die Kommunikation mit dem Server wird dann direkt abgehandelt.
Die folgende Abbildung stellt beispielhaft den Protokollablauf dar.
ProxyMessge()
, die die Nachricht KRB_AS_REQ
enthält, auf.KDC_PROXY_MESSAGE
(die die KRB_AS_REQ
Nachricht beinhaltet) gesendet.KDC_PROXY_MESSAGE
Nachricht extrahiert der KKDCP Server die KRB_AS_REQ
Nachricht und leitet diese an den KDC Server weiter.KRB_AS_REP
zum KKDCP Proxyserver.KRB_AS_REP
Nachricht in einer KDC_PROXY_MESSAGE
und sendet diese zum KKDC Client.KDC_PROXY_MESSAGE
, leitet der KKDCP Client die KRB_AS_REP Nachricht weiter zum Kerberos Client.ProxyMessage()
und initiiert die KRB_TGS_REQ
Nachricht.KDC_PROXY_MESSAGE
beinhaltend die KRB_TGS_REQ
Nachricht.KRB_TGS_REQ
Nachricht und leitet sie an den KDC Server weiter.KRB_TGS_REP
Nachricht zum KKDCP Server.KDC_PROXY_MESSAGE
an den KKDCP Client.KRB_TGS_REQ
Nachricht an den Kerberos Client.KRB_APS_REQ
Nachricht an den Applikation Server um den Service anzufordern.KRB_AP_REP
Nachricht.Die obige Beschreibung ist etwas gekürzt. Die Empfänger müssen natürlich stets die Validität, Integrität und Authentisierung etc. in den Phasen überprüfen. Zusätzlich wird angenommen, dass alles ohne Probleme funktioniert und der Client autorisiert ist, den angefragten Service des Applikationsservers zu benutzten.
Die Kerberos Authentisierung ins Internet zu erweitern, hat sicher seine Vorteile. Es existieren aber auch einige Risiken, an die gedacht werden sollte.
Ein generelles Problem mit öffentlich zugänglichen Services sind Denial of Service (DoS) Attacken. Ein boshafter Client könnte eine Verbindung zum KKDC Proxyserver aufbauen und eine nachgemachte, falsche aber üblicherweise ungültige Kerberos Anfrage senden. Der Proxy muss diese Nachricht annehmen und verarbeiten um die Gültigkeit zu erkennen. Für diesen Vorgang werden Ressourcen gebunden und diese wiederum sind limitiert. Die Spezifikation von KKDCP besagt, dass der Proxyserver die Kerberos Nachrichten welche in einer KRB_KDC_PROXY_MESSAGE
gesendet werden, evaluiert. Die Verbindung sollte abgebrochen und die Verarbeitung gestoppt werden, sobald klar wird, dass es sich nicht um eine well-formed Nachricht handelt. Das sollte demnach die Ausbreitung einer DoS-Attacke vor den internen Kerberos Elementen abfangen und limitiert die negativen Effekte auf externe Clients.
Die zentrale Frage ist: Was wird vom KKDCP Proxyserver validiert? Hält der Proxyserver ein Acceptance Window für Nonces (Zufallszahlen die einmal gebraucht werden – number used once) und Zeitstempel um Replay-Nachrichten zu erkennen? Falls dies nicht der Fall ist, könnte der KKDCP Proxyserver verwendet werden um well-formed, aber ungültige – da wiederholte – Nachrichten an die internen Kerberos Systeme weitergeleitet werden. Die Konsequenz wäre illegitimer Datenverkehr hinter der Firewall. Der KKDCP Proxy wäre nur in der Lage nach Replay Kerberos Nachrichten zu suchen, wenn er das Wissen über Verschlüsselungs-Keys hätte und die Kerberos-Nachrichten entschlüsseln könnte. Das wiederum sollte nicht der Fall sein, da dies im Falle einer Kompromittierung des Proxyservers die Möglichkeiten eines Angreifers ungemein erhöht.
Obwohl HTTPS als standardmässiges Transportprotokoll in der Microsoft-Spezifikation definiert wurde, ermöglicht der Standard den Gebrauch von HTTP. Was wiederum Risiken wie Integritätsverlust oder Informationsenthüllung einführt. Wäre ein Angreifer in der Lage den Verkehr abzufangen und zu manipulieren könnte er folgendes lernen:
Zusätzlich zu obigen Informationen könnte er den Verkehr manipulieren und damit:
Diese drei Szenarien würden die Client Aktivitäten stören und letzten Endes in einem Denial of Service resultieren.
Wäre es für einen Angreifer möglich, den KKDCP Proxyserver zu kompromittieren, würde er nicht viel erreichen. Der Proxyserver hat keine Kenntnis über die Verschlüsselungs-Keys für die Kerberos Nachrichten. Er würde daher nur so viel lernen, wie bei einem Szenario in dem HTTP eingesetzt wird. In Bezug auf eine DoS Attacke bedeutet dies, dass er in der Lage wäre die Kommunikation eines spezifischen Clients zu stören.
Es ist verständlich, dass die Kerberos-Authentisierung für Organisationen von grossem Wert wäre, wenn sie auch im Internet verfügbar sein würde. Ich wurde auf KKDCP aufmerksam, als ich in einem Projekt MobileIron 6.0 analysieren durfte. Es ermöglicht Unternehmen, die gleiche Authentisierungsmethode für externe Clients zu verwenden, welche auch bereits die Internen verwenden. Aber: Vorsicht ist geboten, damit keine Informationen aus und über das interne Netzwerk an die Öffentlichkeit gelangen. Nicht nur wenn HTTP-only verwendet wird, auch mit HTTPS können unvorhergesehene Incidents auftauchen. Die diesjährig publizierten SSL/TLS Faux-pas (goto-fail und Heartbleed) zeigen auf, dass HTTPS nicht gezwungenermassen als Silver Bullet betrachtet werden sollte. Vorsicht ist geboten bei der Konfiguration und Wartung von SSL/TLS und/oder Clients könnten dadurch Risiko einer Denial of Service Attacke ausgesetzt sein. Würden die Proxyserver mehr Kenntnis über die Keys erhalten, würde das Schadenspotential im Fall einer Kompromittierung dramatisch erhöht werden. Obwohl dies das Risiko eines DoS auf die interne Infrastruktur vermindern könnte.
Unsere Spezialisten kontaktieren Sie gern!
Marisa Tschopp
Michèle Trebo
Andrea Covello
Michèle Trebo
Unsere Spezialisten kontaktieren Sie gern!