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

Kurze Einführung zu Kerberos

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:

• Client
• Autenthentication Server (AS)
• Ticket Granting Server (TGS)
• Server

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.

Tücken mit Kerberos

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.

Kerberos Key Distribution Center Proxy

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.

Client zu Proxy Kommunikation

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.

Beispiel Protokollablauf

Die folgende Abbildung stellt beispielhaft den Protokollablauf dar.

1. Der Client ruft die Methode ProxyMessge(), die die Nachricht KRB_AS_REQ enthält, auf.
2. Der KKDCP Client stellt einen sicheren Kommunikationskanal via TLS mit dem KKDCP Proxyserver her.
3. Anschliessend wird die Nachricht KDC_PROXY_MESSAGE (die die KRB_AS_REQ Nachricht beinhaltet) gesendet.
4. Nach dem Empfang der KDC_PROXY_MESSAGE Nachricht extrahiert der KKDCP Server die KRB_AS_REQ Nachricht und leitet diese an den KDC Server weiter.
5. Der KDC Server sendet ein KRB_AS_REP zum KKDCP Proxyserver.
6. Der KKDCP Proxyserver platziert die KRB_AS_REP Nachricht in einer KDC_PROXY_MESSAGE und sendet diese zum KKDC Client.
7. Nach Empfang der KDC_PROXY_MESSAGE, leitet der KKDCP Client die KRB_AS_REP Nachricht weiter zum Kerberos Client.
8. Der Kerberos Client ruft die Methode ProxyMessage() und initiiert die KRB_TGS_REQ Nachricht.
9. Der KKDCP Client sendet die KDC_PROXY_MESSAGE beinhaltend die KRB_TGS_REQ Nachricht.
10. Nach dem Empfang extrahiert der KKDCP Server die KRB_TGS_REQ Nachricht und leitet sie an den KDC Server weiter.
11. Der KDC Server generiert das TGT und sendet eine KRB_TGS_REP Nachricht zum KKDCP Server.
12. Der KKDCP Proxyserver sendet die Nachricht vom KDC Servers in einer KDC_PROXY_MESSAGE an den KKDCP Client.
13. Der KKDCP Client übermittelt die KRB_TGS_REQ Nachricht an den Kerberos Client.
14. Der Kerberos Client sendet die KRB_APS_REQ Nachricht an den Applikation Server um den Service anzufordern.
15. Der Applikation Server returniert die 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.

Sicherheitsimplikationen

Die Kerberos Authentisierung ins Internet zu erweitern, hat sicher seine Vorteile. Es existieren aber auch einige Risiken, an die gedacht werden sollte.

Sicherheit der Kerberos Nachrichten

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:

• Die Identität des Clients, des Servers und des TGS
• Den Gültigkeitszeitraum für das TGT und/oder ST

Zusätzlich zu obigen Informationen könnte er den Verkehr manipulieren und damit:

• Die Identität der Destinationssysteme, die der Client ansprechen möchte, verändern
• Die Gültigkeitsdauer so verändern, dass der Client nie authentisiert wird
• Jegliche verschlüsselte Kerberos Nachricht verändern, dass weder AS, TGS oder der Server diese verarbeiten können

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.

Fazit

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.

Über den Autor

Oliver Kunz ist seit 2010 im Bereich der Informationssicherheit aktiv. Hauptsächlich setzt er sich mit Incident Response, Computerforensik und der Sicherheit von mobilen Geräten auseinander.

Links

• http://msdn.microsoft.com/en-us/library/hh553774.aspx
• http://tools.ietf.org/html/rfc4120
• https://vuldb.com/?id.12370
• https://vuldb.com/?id.12819