Auf der Jagd nach Sicherheitslücken in TLS-Bibliotheken // Open-Source-Testsuite TLS-Anvil

Fachartikel in "IT-Sicherheit – Magazin Management und Technik" – Forschungsprojekt KoTeBi

TLS ist der wichtigste kryptographische Standard für digitale Kommunikation im Internet. Durch Implementierungsfehler entstehen jedoch immer wieder Sicherheitslücken, die für komplexe Angriffe auf TLS-Server und -Verbindungen ausgenutzt werden können. Durch spezielle Software können Entwickler:innen und Sicherheitsforscher:innen solche Fehler erkennen und noch vor Release beheben. Das Forschungsprojekt KoTeBi zeigt wie es geht.

Transport-Layer-Security (TLS) ist mit Abstand die wichtigste kryptographische Sicherheitskomponente in der digitalen Kommunikation: Neben seinem bekannten Einsatz in HTTPS wird TLS auch in vielen anderen Protokollen wie bspw. SMTPS, POP3S, oder FTPS genutzt. Auch mobile Apps setzen TLS als Baustein ein, um Softwareupdates abzusichern und Daten vertraulich und vor Manipulation geschützt zu übertragen. Die Sicherheit von TLS als Komponente muss daher für alle möglichen Einsatzgebiete garantiert werden. Ohne die Sicherheitsgarantien, die diese Komponente bietet, können sensible Daten abgehört werden oder Schadsoftware kann in die Datenübertragung eingeschleust werden.

Dabei ist die Aufgabe, welche die TLS-Bibliothek übernehmen muss, keine einfache. Das Ökosystem, in dem eine TLS-Bibliothek agieren muss, ist hochkomplex und in einem ständigen Wandel. Neue Standards, wie beispielsweise TLS 1.3 oder DTLS, müssen integriert werden, während auch ältere Standards weiterhin unterstützt werden müssen. Zudem ist die eingesetzte Kryptographie hochsensibel gegenüber Implementierungsfehlern und immer komplexeren Seitenkanalangriffen. Hierdurch können auch schon kleine Fehler in der Implementierung zu einem kompletten Verlust der Sicherheitseigenschaften führen.

Die Komplexität von TLS und DTLS, aber auch die ständige (Weiter-) Entwicklung von neuartigen Angriffen, machen es den Entwickler:innen sehr schwer, alle Schwachstellen für Angriffe schon während der Implementierung zu beseitigen. Daher benötigen sie Werkzeuge, welche die TLS-Bibliotheken auf Fehler testen können. Dieses Testen gestaltet sich in der Praxis allerdings äußerst schwierig: Während funktionale Basistests (das heißt Tests, die überprüfen, ob TLS im normalen Betrieb funktioniert) relativ leicht zu implementieren sind, gibt es noch keine befriedigenden Lösungen für andere Bereiche des Testens.

Forscher:innen des Projekts KoTeBi (“Kombinatorisches Testen von TLS-Bibliotheken”) haben nun eine TLS-Testsuite entwickelt, welche helfen soll, diese Probleme zu beseitigen. Sie soll künftig vollautomatisch und umfassend die Entwicklung und den Einsatz von TLS-Bibliotheken überwachen und analysieren können.

Wie funktioniert TLS?

Das TLS-Protokoll ermöglicht es zwei Endpunkten, einen sicheren Kommunikationskanal aufzubauen. Zu diesem Zweck führen die Kommunikationspartner einen TLS-Handshake durch. Ein beispielhafter TLS-Handshake ist in Abbildung 1 zu sehen. Der Client und der Server senden dabei verschiedene Handshake-Nachrichten, um kryptografische Parameter auszuhandeln und TLS-Sitzungsschlüssel abzuleiten. Die wichtigsten Nachrichten sind dabei das ClientHello und das ServerHello. Im ClientHello teilt der Client mit, welche Funktionen, Protokolle und Algorithmen er unterstützt. Im ServerHello wählt der Server anschließend aus, was genau davon verwendet werden soll. Die ausgehandelten Parameter und Schlüssel werden dann innerhalb des Kanals verwendet, um die Vertraulichkeit, Integrität und Authentizität der ausgetauschten Nachrichten (AppData) zu schützen.

Ein TLS-Handshake enthält viele kryptographische Parameter und kann durch optionale Erweiterungen, sogenannte TLS-Extensions, ergänzt werden. Handshakes unterscheiden sich außerdem abhängig von der TLS-Version. Die derzeit aktuellen TLS-Versionen sind TLS 1.2 und TLS 1.3. Ein Parameter, welcher ausgehandelt wird, ist die Cipher-Suite. Sie legt die Algorithmen für Schlüsselaustausch, Authentifizierung, Verschlüsselung sowie einen zu verwendenden Hash-Algorithmus fest. Eine Cipher-Suite für TLS 1.3 könnte bspw. so aussehen: TLS_AES_128_GCM_SHA256.

Ablauf eines TLS 1.3 Handshakes – vereinfachte Darstellung der gesendeten Nachrichten. (Abbildung 1)

TLS-Extensions werden im Handshake mit ausgehandelt und können Veränderungen des Handshake-Ablaufes bewirken. Beispielsweise können sie verändern, wie Nachrichten authentifiziert werden (“Encrypt-Than-Mac”), welche zusätzlichen Nachrichten geschickt werden (“Heartbeat”) und vieles mehr. Insgesamt ist die Anzahl der veränderbaren Parameter in einem TLS-Handshake sehr groß, was zu Problemen beim Testen führen kann, wie später gezeigt wird.

Wie ist TLS spezifiziert?

TLS ist in mehreren Dokumenten, sogenannten RFCs, spezifiziert. Da TLS iterativ gewachsen ist, alte Dokumente durch neue ergänzt oder invalidiert wurden und es eine Vielzahl an verschiedenen Versionen und Erweiterungen gibt, ist die Anzahl der TLS-spezifischen RFCs sehr groß.

 
Zeitlinie zur Veröffentlichung von für TLS relevanten RFCs (Abbildung 2)
(Quelle: https://www.usenix.org/conference/usenixsecurity22/presentation/maehren)

Die große Anzahl von Protokollversionen, Erweiterungen und kryptografischen Algorithmen erhöht die Komplexität von TLS und macht die Implementierung einer sicheren TLS-Bibliothek sehr schwierig. Aus Gründen der Abwärtskompatibilität müssen Standard-TLS-Bibliotheken mehrere TLS-Versionen ab TLS 1.0 und auch veraltete kryptografische Algorithmen wie 3DES unterstützen. Die Komplexität von TLS und die Anforderungen an die Abwärtskompatibilität führten in der Vergangenheit zu mehreren kritischen Angriffen (beispielsweise POODLE oder ROBOT).

Den Vorgaben in den RFCs zu folgen, ist also von großer Bedeutung für die Sicherheit der Implementierung.
Ein Beispiel für so eine sicherheitsrelevante Anforderung aus RFC 5246 ist die folgende:

Die Vorgabe ist eine Gegenmaßnahme gegen sogenannte “Padding Oracle”-Angriffe und muss von der Implementierung unabhängig von anderen gewählten Parametern erfüllt werden, um die Sicherheit der Verbindung sicherzustellen.

Parameter und Sicherheitsverhalten

Während frühere Versionen von TLS noch die wichtigsten kryptographischen Parameter ausschließlich über die Cipher-Suite ausgehandelt haben, gibt es inzwischen eine Reihe von weiteren Mechanismen, um der gewachsenen Zahl von kryptographischen Primitiven gerecht zu werden. Beispielsweise kann über die Cipher-Suite zunächst der Schlüsselaustausch über Elliptische Kurven vereinbart werden. Die Auswahl der konkreten elliptischen Kurve, einem zentralen Pfeiler der Sicherheit des aufzubauenden Kanals, läuft dann zusätzlich über die “Supported Groups”-Extension ab. Außerdem definiert die Cipher-Suite zwar einen Schlüsseltyp für die Authentifizierung, lässt Details dazu, wie etwa die Frage nach der verwendeten Hashfunktion, aber offen. Auch hier erfolgt das Aushandeln über eine TLS-Extension. Bei der Interaktion von diesen drei beispielhaften Parametern gilt es zunächst zu beachten, dass jeder einzelne das Sicherheitsniveau der aufgebauten TLS-Verbindung beeinflussen kann. Beispielsweise kann der Sicherheitseffekt einer starken Elliptische Kurve durch die Wahl einer schwachen Hashfunktion für die Signatur negiert werden. Außerdem gibt es für jeden der drei Parameter Auswahlmöglichkeiten, die die zulässigen Optionen für die jeweils beiden anderen einschränken. In der Vergangenheit haben invalide Kombinationen von Parametern immer wieder Ausnahmefälle in Bibliotheken ausgelöst, durch die Sicherheitsüberprüfungen umgangen werden konnten. Sicherheitstests sollten daher Parameter nicht isoliert betrachten, sondern besonderen Fokus auf die Interaktion von Parametern untereinander legen.

Kombinatorisches Testen

Die Komplexität von Schwachstellen in Softwaresystemen kann stark variieren. Um manche Schwachstellen zu finden, reicht es aus, einfache Softwaretests zu implementieren, da die Schwachstellen unabhängig von weiteren Parametern auftreten. Andere komplexe Schwachstellen treten nur auf, wenn eine bestimmte Kombination von Parametern zum Einsatz kommt. Um diese Art von Fehlern finden zu können, sollten Tests parametrisiert werden, wobei die gleichen Tests mit unterschiedlichen Parametern durchgeführt werden. Jedoch kann die steigende Anzahl an Parametern zu einer kombinatorischen Explosion führen, wodurch nicht mehr alle möglichen Kombinationen getestet werden können. So kann es beispielsweise bei einem Test mit 10 Parametern, bei dem jeder Parameter 10 unterschiedliche Werte annehmen kann, zu 10.000.000.000 Parameterkombinationen kommen, welche die Testausführung unpraktikabel machen. Es ist zudem unwahrscheinlich, dass alle 10 Parameter einen bestimmten Wert annehmen müssen, damit eine Schwachstelle auftritt. Wahrscheinlich ist, dass lediglich eine Untermenge der zu testenden Parameter gewisse Werte annehmen muss, damit die Schwachstelle auftritt.

An dieser Stelle setzt kombinatorisches Testen an, welches in Abbildung 3 beschrieben wird. Beim kombinatorischen Testen wird eine Teststärke k (im Beispiel 2) definiert, um dann gezielt alle Kombinationen zu testen, welche aus insgesamt k Parametern bestehen. Dabei wird versucht, die Parameter so auszuwählen, dass möglichst wenige Tests ausgeführt werden müssen, um alle Kombinationen der Teilmenge zu testen.

Kombinatorisches Testen am Beispiel von 3 Parametern mit je zwei Werten. Nach naiven Ansatz ergeben sich 2³=8 Kombinationen. Durch kombinatorisches Testen mit k=2 reichen 4. (Abbildung 3)
(Quelle: https://www.usenix.org/conference/usenixsecurity22/presentation/maehren)

Design einer Testsuite

Im Rahmen des Forschungsprojektes KoTeBi wurde nun eine Testsuite namens “TLS-Anvil” entwickelt, welche durch kombinatorisches Testen Fehler in TLS-Bibliotheken finden soll. Die Testsuite baut auf dem TLS-Analyse-Werkzeug “TLS-Attacker” auf. Seit 2015 wird TLS-Attacker in Kooperation von der Ruhr-Universität Bochum, der Universität Paderborn, dem Technology Innovation Institute (TII, Abu Dhabi) und der Hackmanit GmbH entwickelt, um damit TLS-Bibliotheken auf Schwachstellen zu untersuchen. TLS-Attacker enthält eine eigens zur Analyse von TLS-Bibliotheken entwickelte TLS-Implementierung, welche Sicherheitsanalyst:innen einfachen Zugriff zu allen Aspekten einer TLS-Verbindung gibt.

Die Tests selbst sind als sogenannte Test-Templates definiert. Ein Test-Template ist eine Vorlage, basierend auf einer Anforderung an die zu testende Software. Test-Templates definieren, welche TLS-Nachrichten gesendet werden und welche Antworten von der Testsuite erwartet werden. Außerdem definiert es, wann ein Testfall erfolgreich ist oder fehlschlägt.

In TLS-Anvil sind verschiedene Test-Templates implementiert, die hauptsächlich auf den Anforderungen aus 13 verschiedenen TLS RFCs basieren. Der Fokus lag dabei auf Anforderungen, die in den RFCs durch die Schlüsselwörter „MUST“, „SHALL“ und „REQUIRED“, sowie „MUST NOT“ und  „SHALL NOT“ als besonders wichtig gekennzeichnet sind. Weiterhin wurden Tests zu impliziten Anforderungen entwickelt, welche zwar aus dem Kontext des RFCs hervorgehen, jedoch nicht explizit genannt werden. Ergänzend kommen Tests zur Einhaltung der im RFC definierten State Machines und zur Vermeidung aus der Literatur bekannter Fehler hinzu.

TLS-Anvil geht bei einer Testausführung in drei Phasen vor:

1. Feature Extraction: In dieser Phase wird die zu untersuchende Software zunächst auf ihre Funktionalität gescannt. Dazu zählen unter anderem die unterstützten Cipher-Suites und TLS-Versionen. Nach der Feature Extraction können Tests ausgeschlossen werden, welche Funktionen voraussetzen, die die Software nicht unterstützt.
   
   
2. Test-Phase: Im nächsten Schritt werden hintereinander alle Tests mit Hilfe von TLS-Attacker ausgeführt. Dabei wird jedes Test-Template nach dem Prinzip des kombinatorischen Testens mehrmals mit unterschiedlichen Parametern gestartet. Bei einem Test werden ein oder mehrere Handshakes mit der zu testenden Software durchgeführt und die Antworten gespeichert.
   
   
3. Testauswertung: Im letzten Schritt wird ausgewertet, inwieweit die geprüfte Software die Tests bestanden hat. Dabei werden die Ergebnisse für jedes Test-Template in vier Kategorien unterteilt: erfolgreich bestanden, konzeptuell bestanden, teilweise fehlgeschlagen oder komplett fehlgeschlagen. Eine Auswertung kann anschließend über Einsicht in den generierten Report erfolgen.
   
   

Screenshot der Benutzeroberfläche von TLS-Anvil. – Übersicht eines Testreports: oben eine generelle Übersicht sowie Verweise auf Richtlinien, unten einzelne Testfälle geordnet nach RFC. (Abbildung 4)

TLS-Anvil ist damit viel mehr als nur ein einfacher Scanner. Die Testsuite kann Implementierungsfehler und Interoperabilitätsprobleme aufdecken. Dabei geht sie systematisch vor und kombiniert verschiedene Parameter, um eine möglichst hohe Code-Abdeckung zu erhalten. Die Tests basieren auf den Anforderungen aus den TLS-Standards und decken somit die wichtigsten Fälle ab. Durch ein visuelles Interface können die Testreportorts ausgewertet werden. Dabei geben verschiedene Filter und Werkzeuge die Möglichkeit, gefundenen Fehlern auf den Grund zu gehen. Die Software dient als hilfreiches Werkzeug für Sicherheitsforscher:innen, Prüfstellen sowie TLS-Hersteller.

Fehler vor der Veröffentlichung beseitigen

Um zu vermeiden, dass sicherheitskritische Fehler in Software vorkommen, welche bereits in Geräten und Produkten zum Einsatz kommt, setzt die Testsuite “TLS-Anvil” auf den Ansatz des Continuous Testings. Das bedeutet, dass die Testsuite bereits während der Entwicklung als Teil des Produktions- und Updatezyklus eingesetzt werden kann.

Dieser Schritt ist sowohl für TLS-Entwickler:innen als auch Produkthersteller relevant. Sie können während der Entwicklung mit Hilfe der Testsuite gezielt nach Problemen in ihrer Implementierung suchen. Die Tests der Testsuite können als System-Integration-Test verwendet werden. Somit sparen die Hersteller Ressourcen, die für die Entwicklung solcher aufwändigen Tests aufgewendet werden müssten. Gleichzeitig können sich die Hersteller sicher sein, dass sie die komplexen TLS-Standards richtig verstanden und implementiert haben und somit Konformität zum Standard einhalten. Dies sorgt für eine bessere Effizienz und eine geringere Fehlerquote in der Entwicklung.

In der Praxis ist der Ablauf wie folgt: Ein Code-Update einer TLS-Bibliothek oder eines Produktes, welches TLS nutzt, wird gepusht. Dieser Vorgang triggert die CI-Pipeline des Projektes — ein Development-Build wird erstellt. Als nächstes wird TLS-Anvil gestartet und führt automatisiert Tests auf dem Development-Build aus. Es wird ein Test-Report generiert. Wurden Implementierungsfehler gefunden, blockiert dies den Release-Zyklus und der fehlerhafte Code kann nicht im finalen Produkt landen, bevor er behoben wurde (siehe auch Abbildung 5).

Nutzung der Testsuite innerhalb des Produktlebenszyklus.
Links während der Entwicklung von TLS-Bibliotheken, rechts während der Herstellung von Produkten, welche TLS nutzen. (Quelle: kotebi.de) (Abbildung 5)

Wie sicher sind unsere TLS-Bibliotheken?

In einer ersten Evaluation des kombinatorischen Testansatzes für RFC-Anforderungen konnte TLS-Anvil bereits erfolgreich eingesetzt werden, wie M. Maehren et al. in ihrer Veröffentlichung “TLS-Anvil: Adapting Combinatorial Testing for TLS Libraries” auf der USENIX Security 2022 zeigten. Die automatisierte Analyse von 13 bekannten quelloffenen TLS-Bibliotheken zeigte dabei neben einer Vielzahl von unkritischen Abweichungen vom Standard auch Interoperabilitätsprobleme und Sicherheitslücken auf. Für die kommerziell eingesetzte Bibliothek MatrixSSL konnte beispielsweise gezeigt werden, dass für bestimmte Cipher-Suites eine Padding Oracle-Schwachstelle ausgelöst werden kann, über die die Vertraulichkeit der TLS-Verbindung gebrochen werden kann. Außerdem konnten durch manipulierte Längenfelder einzelner Nachrichten Parsingfehler ausgelöst werden, die die CPU-Auslastung deutlich erhöhten und so für Denial-of-Service-Angriffe genutzt werden könnten. Die Evaluation bestätigte außerdem, dass es gerade für TLS sinnvoll ist, Tests aus den Standards abzuleiten, da diese insbesondere für die neueste Version (TLS 1.3) die Erfahrungen aus Implementierungsfehlern der Vergangenheit widerspiegeln. So konnte bei der Bibliothek wolfSSL festgestellt werden, dass durch das Versenden invalider Zertifikatnachrichten die Authentifikation des Servers vollständig umgangen werden konnte. Dadurch wären Verbindungen eines Clients anfällig für Person-in-the-Middle-Angriffe, die alle Sicherheitsziele von TLS brechen. Der RFC enthält genau für diesen Fehlerfall eine Anforderung, die die Detektion solcher invaliden Nachrichten sicherstellen soll. Diese gravierende Sicherheitslücke hätte daher durch RFC-basierte Tests, wie sie in TLS-Anvil implementiert sind, vor der Veröffentlichung der Bibliothek festgestellt werden können. Als eines von 15 festgestellten Interoperabilitätsproblemen hat sich gezeigt, dass MatrixSSL bei bestimmten Kombinationen aus Cipher-Suite und elliptischen Kurven falsche kryptographische Parameter in TLS 1.3 Verbindungen eingesetzt hat. Für einen Kommunikationspartner wäre dieses Fehlverhalten nicht von einem Angriff auf die Verbindung zu unterscheiden, sodass die Verbindung sofort terminiert werden müsste.

Die Zukunft von TLS-Testing

TLS ist inzwischen als Standard für Verschlüsselung im Internet nicht mehr wegzudenken. Viele Entwickler:innen und Produkthersteller verlassen sich dabei einfach auf TLS-Bibliotheken, welche die Verschlüsselung für sie übernehmen. Dass in der Entwicklung solcher Bibliotheken Fehler passieren können, zeigen Forschungsergebnisse regelmäßig. Auch bei der Implementierung können Fehlkonfigurationen zu Sicherheitsrisiken führen.

Diese Fehler zu erkennen war bisher schwer. Doch mit modernen Testansätzen, wie dem kombinatorischen Testen, können automatisiert sicherheitskritische Fehler erkannt werden. Das Projekt KoTeBi hat eine open-source Testsuite erarbeitet, die bereits unter Beweis gestellt hat, welchen großen Beitrag sie zur Erhöhung der Sicherheit von TLS-Bibliotheken leisten kann. TLS-Entwickler:innen können solche Werkzeuge nutzen und sie in ihren Produktlebenszyklus einbauen. Dadurch werden Schwachstellen und Kompatibilitätsprobleme bereits vor der Veröffentlichung aufgedeckt. Die Entwicklung der Testsuite des Projekts KoTeBi geht stetig voran; die Testsuite kann allerdings bereits von allen interessierten Personen und Unternehmen genutzt werden. Mehr Informationen finden Sie hier: www.kotebi.de

Autor und Verfasser des Artikels – Conrad Schmidt

IT-SICHERHEIT 5/2024
Ausgabe Oktober/November hier erhältlich >> https://www.itsicherheit-online.com/downloads/it-sicherheit-5-2024/

• Mit DevSecOps zu sicherer Software
• Threat Hunting als Geheimwaffe der Cybersicherheit
• Sichere Anwendungsentwicklung mit der Power Platform
• Best Practice für ein risikobasiertes Lieferantenmanagement
• S/4HANA-Transformation als Booster für mehr SAP-Sicherheit
• Optimierte Tickets in der agilen Softwareentwicklung durch KI und Rags
• Auf der Jagd nach Sicherheitslücken in TLS-Bibliotheken
• NIS-2 und DORA: Wie haften betroffenen Unternehmen?
• Kollektive Intelligenz für die Bewertung von IT-Sicherheitslösungen
• und vieles mehr!

Homepage >> https://www.itsicherheit-online.com/ 

 

Unsere Experten entwickeln die optimale Lösung für Sie

TLS – CI/CD (Continuous Integration/Continuous Delivery) – Kryptographie

Möchten Sie sicherstellen, dass die Implementierung von TLS in Ihrem Projekt sicher ist?
Oder planen Sie Ihre entwickelte TLS-Bibliothek auf Schwachstellen zu überprüfen?

Wir beraten Sie gerne; kontaktieren Sie uns für eine unverbindliche Erstberatung.
So stehen wir Ihnen mit folgenden Services und Lösungen zur Seite:

IT-Sicherheitsberatung  |  IT-Sicherheitsschulungen   |  Penetrationstests

Zögern Sie nicht und finden Sie mit uns Ihren Weg zur sicheren Entwicklung und Implementierung von TLS.
Wir freuen uns darauf Sie bei Ihren Projekten zu unterstützen.

Ihr Ansprechpartner für Kryptographie und TLS

Prof. Dr. Juraj Somorovsky
juraj.somorovsky@hackmanit.de