Trust Me if You Can - Part 2

Risiken bei der Authentifizierung mit X.509v3 Zertifikaten am Beispiel eines Angriffsszenarios auf eine Webanwendung auf der Basis von Java und Tomcat. 

Im ersten Teil dieses Blog Beitrags haben wir Grundlagen von X.509 Zertifikaten und hierarchische Vertrauensmodelle kritisch beleuchtet. Dieser zweite Teil von „Trust me if you can“ untersucht die Prüfung von Zertifikaten in der Praxis und zeigt einen möglichen Angriff auf einer Webanwendung, in der Java JSSE für die Authentifizierung eingesetzt wird. Im Rahmen eines Responsible Disclosure haben wir diese Angriffsmöglichkeit mit Oracle besprochen. Oracle hat daraufhin die Logik zur Zertifikatsprüfung angepasst und im Rahmen des Critical Patch Update in Januar 2020 veröffentlicht. Hier wird die Cologne Intelligence als Contributer genannt.

Mit dem Versuchsaufbau klären wir, wie Zertifikatsprüfungen in Java-Komponenten ausgeführt werden und welche Prüfschritte ausgeführt werden. Um die Test-Möglichkeiten zu erweitern, erstellen wir CA-Zertifikat und signieren mit diesem zwei EE-Zertifikate, eines für Alice und eines für Bob. Wir nutzen OpenSSL, Keytool und KeystoreExplorer, um die in Tabelle 1 gelisteten Artefakte zu erzeugen.

Um die Zertifikatsprüfung in einem realistischen und weit verbreiteten Szenario zu testen, etablieren wir die Kommunikation zwischen zwei TLS Endpunkten. Im Rahmen des TLS Handshakes stellt der Server dem Client eine Certificate Chain zur Verfügung und weist durch Signatur den Besitz des privaten Schlüssels des verwendeten EE Zertifikates nach. Es wird also ein Java-Programm als TLSServer gestartet und eines als TLSClient. Der TLS Kanal wird über die Klassen SSLServerSocket und SSLSocket aus dem Paket javax.net.ssl aufgebaut. Tabelle 2 zeigt die durchgeführten Versuche und deren Ergebnisse.

Tabelle 2: Versuche

Grundsätzlich verhält sich der Verbindungsaufbau wie erwartet. Ist ein EE-Zertifikat im Truststore enthalten, wird der TLS-Kanal erfolgreich aufgebaut. Ist es nicht zu finden, wird ein SSL Alert erzeugt. Auch Manipulation an den Zertifikaten wird zuverlässig erkannt. Was aber auffällt, ist die unterschiedliche Reaktion des Clients je nachdem ob in dessen Truststore das EE-Zertifikat oder das ausstellende CA Zertifikat hinterlegt ist. Ein ungültiges (weil abgelaufenes) Zertifikat wurde akzeptiert, wenn dieses Zertifikat direkt im Truststore des Clients enthalten ist. In diesem Fall wird die Verbindung auch dann aufgebaut, wenn Zertifikate mit schwacher Kryptografie eingesetzt werden, die z.B. von Curl abgelehnt werden. Es empfiehlt sich also in jedem Fall, entweder bei der Zusammenstellung des Truststore ein besonderes Augenmerk auf die Algorithmen der vertrauenswürdigen Zertifikate zu legen, oder eine entsprechende Abfrage in der Prüfroutine zu ergänzen. Um dieses Verhalten genauer zu untersuchen, wird der Versuchsaufbau etwas abgewandelt.

Unser zweiter Testaufbau bildet ein fiktives Szenario ab, in dem ausschließlich authentifizierte und autorisierte Clients auf eine Webapplikation zugreifen dürfen. Als Server verwenden wir einen Tomcat 8, der einen TLS Endpunkt auf Port 8443 mit der folgenden Konfiguration bereitstellt:

In dieser Konfiguration kommt für die TLS-Terminierung und die Zertifikatsprüfung Java JSSE zum Einsatz. Installiert ist openjdk 11.0.5. auf Ubuntu. Der auf diese Weise erstellte Endpunkt akzeptiert nur Clients, die sich im Rahmen des TLS Handshakes mit einem Zertifikat ausweisen können, das im Truststore des Servers vorliegt . Zusätzlich müssen die Clients den Nachweis über den Besitz des privaten Schlüssels erbringen. Wird kein Zertifikat vorgelegt oder eines, das nicht auf den Truststore zurückgeführt werden kann, so wird der Request abgewiesen. Soll der Zugriff entzogen werden, wird das EE-Zertifikat aus dem Truststore gelöscht. Auf dem Tomcat installieren wir ein Servlet, welches die Common Names aus den Zertifikaten auswertet und den Zugriffen hierüber eine Rolle zuordnet. In unserem Beispiel vergeben wir für Bob die Rolle „Admin“ und für Alice die Rolle „User“.

Alices Zertifikat ist korrekt als EE Zertifikat konfiguriert, wir haben es ist mit den folgenden kritischen Extensions versehen:

• Certificate Authority: No
• Max Path Length: 0

Als Security-Testfall leiten wir nun dennoch von Alices EE-Zertifikat ein weiteres Zertifikat ab. Wir vergeben als Common Name CN=‘Bob‘ ab. Mit diesem Zertifikat als Client-Cert schicken wir einen Request gegen die wie oben beschrieben gesicherte Webanwendung. Ergebnis: Der Request wird akzeptiert und ihm wird die Rolle „Admin“ zugewiesen. Alice hat damit durch die Erzeugung eines neuen Zertifikates ihre Rechte auf „Admin“ erweitert, obwohl ihr Zertifikat als EE Zertifikat konfiguriert ist.

Dieser Angriff funktioniert, wenn der Connector für das NIO 2 Protokoll konfiguriert wird, also Java JSSE zum Einsatz kommt. Er funktioniert nicht bei Nutzung von OpenSSL durch Konfiguration des ARP Protokolls wie folgt:

Der Angriff funktioniert unabhängig davon, ob Alices eingesetztes EE Zertifikat wie oben beschrieben von einer CA abgeleitet wird oder selbst-signiert (self-signed) ist. Es war im vorliegenden Szenario offensichtlich keine gute Idee, den Zugriff durch die Platzierung der EE-Zertifikate im Truststore zu gewähren. In diesem Szenario konnte Alices unerlaubter Zugriff vermieden werden, wenn statt der EE-Zertifikate die CA im Truststore enthalten ist.

Die Recherche unterstreicht diese Erkenntnis. Apache warnt in der Dokumentation zu Tomcat 8 vor dem Einsatz von self-signed Zertifikaten: „While self-signed certificates can be useful for some testing scenarios, they are not suitable for any form of production use.“ (https://tomcat.apache.org/tomcat-8.0-doc/ssl-howto.html). Auch OWASP positioniert sich eindeutig: „The use of self signed certificates is never acceptable.“ (https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Transport_)

Grundsätzlich zeigt sich in den Versuchen die Komplexität, die mit dem Einsatz von Zertifikaten verbunden ist. Es ist daher besonders wichtig, für die Zertifikatsnutzung die eigene Zielsetzung zu definieren, ein Lösungskonzept zu entwickeln und das fertige System zu testen. Im Detail werden die folgenden „Lessons Learned“ aus den Versuchen abgeleitet:

1. Das Team muss bei der Architekturplanung eine bewusste entscheiden, ob ein öffentlicher Truststore oder ein individueller Truststore genutzt wird.
2. Vor dem Einsatz von self-signed-EE-Zertifikaten muss gewarnt werden. Die Versuche zeigen, dass es ein Unterschied ist, ob ein EE-Zertifikat oder dessen CA in einem Truststore hinterlegt ist: 
   • Abgelaufene EE-Zertifikate werden akzeptiert, wenn sie im Truststore hinterlegt sind.
   • Ist nur die CA im Truststore, wird das abgelaufene EE-Zertifikat nicht akzeptiert.Unter Umständen werden von EE-Zertifikaten abgeleitete Zertifikate akzeptiert. Auch Apache und OWASP warnen vor dem Einsatz von Self-Signed-Zertifikaten.
3. Die Entwickler müssen wissen, welchen Truststore Java nutzt und wie der verwendete Truststore konfiguriert ist. Java fällt u.A. auf den öffentlichen Default-Truststore zurück, wenn kein individueller Truststore definiert wird oder dieser nicht gefunden wird. Es greifen weitere Automatismen die in der Java Specification definiert sind.
4. Eigene Zertifikate zu erzeugen und sicher einzusetzen ist nicht trivial. Die Auswirkung der Attributierung sowie die Verarbeitung durch die eingesetzten Werkzeuge müssen verstanden werden, um ein sicheres System zu bauen. Sicherheitstests der entwickelten Lösung sind absolut notwendig, sie müssen in agilen Entwicklungsteams als Regression Tests umgesetzt werden

So weit, so einleuchtend. In der Realität sieht es aber häufig anders aus: Die Entwickler müssen in kurzen Zyklen fuktionale Releases erzeugen und haben meist keine Zeit für eine detaillierte Analyse von IT-Security-Fragen. Cologne Intelligence bietet Entwicklungsteams daher gezielte Unterstützung in Form des Security Champions an.