 Der nächste Talk handelt über den Drown-Attack. Und das wird Spaß. Hat Sebastian Chinsel der Referent gesagt, er hat sich für IT-Sicherheit interessiert, seit einer langen Zeit. Er hat einen Doktortitel an der FH Münster und erinnert euch vielleicht an seine Talks von 31C3, 28C3 oder sogar 29C3. Heute geht es um den Drown-Attack und wie man TLS angreift mit einem Server der SSL-Version 2 unterstützt. Bitte gibt einen Jubiläums-Applaus für Sebastian Chinsel. Vielen Dank für die Einführung. Es ist großartig, wieder hier zu sein und ich bin sehr froh, dass jetzt niemand geht, denn wir haben hier eine neue Verwundbarkeit von SSL 2. Das ist irgendwie koalte. Aber der Attack hat einen Namen und hat eine Website und sogar ein Logo. Und als ich das gesagt habe, bin ich jetzt sehr froh, dass niemand geht. Auch deswegen, der Talk geht um einen Einbruch in TLS. Und ich denke, werder weniger alle in diesem Raum verwenden, TLS wahrscheinlich sogar jetzt genau in diesem Moment, weil eure Mobiltelefone jetzt auf Twitter nachschauen, was los ist, oder Facebook, also HTTPS benutzen, oder ihr schaut nach euren E-Mails über dem Browser oder über ein E-Mail-Programm. Ja, es ist also wirklich wichtig und der Drown-Attack hat 15 Autoren, die natürlich nicht alle herkommen konnten. Sechs von uns auf dem Bild hier, das ist die größte Anzahl von Menschen, die wir auf einem einsten Bild unterbringen konnten. Und wenn ihr genau hinschaut, ich bin hier sehr froh, dass wir den ersten Pony Award bekommen haben für den besten Krypto-Angriff 2016. Wir sind sehr, sehr froh darüber. Aber wenn wir über SSL Version 2 reden, was ist das eigentlich? SSL Version 2 wurde im Jahr 1995 erstellt und sofort im Jahr 1995 auch gebrochen. Im gleichen Jahr nur nach wenigen Monaten. Wie sah das Internet damals aus in dieser Zeit? Naja, ziemlich genau so wie hier auf diesem Bild. Das ist das Internet der 1990er-Jahre mit einigen kryptografischen, einfachen Dingen wie DS, RC4, RC2. Die meisten davon sind also schon gebrochen und einige wirklich interessante Dinge. Also hier zum Beispiel 40 Bits für Exportstärke. Also eine Kryptografie-Reguritmus der aus politischen Gründen erzeugt wurde. Kryptografische Regulierung in den 1990er-Jahren sagten, dass für Export nur Kryptografie verwendet werden durfte mit einer bestimmten Stärke, mit einer bestimmten Maximalstärke für Export aus den USA heraus. Und das sehen wir hier. Im Jahr 1995 ist die SSL Version 2 sofort gestorben. Und der Grund ist, dass die Ersteller-Netscape hat das veröffentlicht, nicht den Handshake authentifiziert haben. Also ein aktiver Mensch in der Mitte konnte einfach den Handshake abfangen und dann den Server auf beiden Seiten, Server und Kleintag, zwingen, eine sehr, sehr schwache Verschlüsselung zu verwenden. Und das konnte man nicht fixen. Das war ein Protokoll-Problem. Das war also nicht fixbar. Ein Jahr später, 1996, gab es SSL Version 3, was immer noch die Basis auf der Protokoll-Ebene ist für all das TLS, was wir heute sehen und das wir benutzen. Wir können also sagen, SSL Version 2 wurde 1995 veröffentlicht und gebrochen in 1995. Niemand, jeweils wird das noch benutzen, oder? Ich habe einige Daten für euch. Dies ist ein internetweiter Scan des IPv4-Internet im Jahr 2016. Und was ihr hier seht, ist nicht die Anzahl Haus, sondern der Prozentanteil von all den TLS und SSL unterstützenden Systemen auf dem Internet. Und hier seht ihr zum Beispiel, dass 28 Prozent aller Servers, die auf Prots 25 SMTP zuhören, SSL Version 2 verwenden. Was wirklich sehr seltsam ist. Ich komme zu diesem Punkt später noch, was war der Grund? Und sogar für HTTPS, also Port 443, sehen wir immer noch 17 Prozent aller Hosts da draußen, die direkt SSL Version 2 unterstützen, was wirklich seltsam ist, oder? Man könnte also direkt sagen, diese alten Dinosaurier, die kommen alle zurück irgendwie und verfolgen uns User im Internet. Um euch einen Überblick zu geben, worum geht es bei Drown? Drown ist ein ziemlich geschickter, eine Kette von Exploits. Und es wird einige Zeit brauchen, all die Puzzlestücke zu erklären. Also nur ein kurzer Überblick über die Voraussetzungen, die ein Angreifer braucht, um einen Drown Exploit zu fahren. Zunächst mal können wir also eine von 1000 TLS Verbindungen brechen, nicht alle, nur ein Promille. Das heißt also im Wesentlichen, um eine eurer TLS Verbindungen zu brechen, muss der Angreifer im Durchschnitt 1000 Verbindungen von euch einsammeln zuhören können. Es kann Verbindung sein, die vor langer, langer Zeit vor der Bekanntheit von Drown entstanden sind. Es ist ein passiver Angriff. Also einfach auf Rekord zu klicken in eurem Wireshark reicht bereits aus. Und wenn ihr dies nun beim Kongressvortreiter für Jahre gemacht habt, dann könnt ihr die TLS Verbindungen, die ihr damals aufgezeichnet hat, jetzt unter bestimmten Voraussetzungen vielleicht noch brechen. Okay. Das ist nicht kostenlos. Ihr braucht etwa zwei hoch 50 Verschlüsselungen durchführen. Das ist fehl. Das ist machbar, aber wir müssen ziemlich gute Hardware brauchen, ziemlich fette Hardware. Und wir müssen etwa 40.000 Verbindungen zu diesem Server aufbauen, der dieses SSLV2 noch unterstützt. Und ein sehr wichtiger, ein sehr wichtiges Ding ist, Clients unterstützen eigentlich SSLV2 nicht mehr seit langer Zeit. Der letzte Browser, der das uns schützte, war Internet Explorer 6 auf Windows XP. Okay. Also selbst Internet Explorer 6 würde immer SSL Version 3 bevorzugen. Wenn es also Version 3, wenn es möglich war, Version 3 auszuhandeln, würde das immer benutzt werden. Es ist also so, dass wir wirklich TLS brechen wollen. Das, was eure wirklich aktuelle Client benutzt unter der Voraussetzung, dass derselbe Server auch SSL Version 2 unterstützt, was wirklich seltsam ist. Aber wir machen das so. Wir brechen TLS unter Benutzung von SSLV2. Okay. Wir haben einen Exploit gemacht und wir haben auch eine Menge Aufwand verwendet, diesen Angriff zu optimieren. Und das Beste, was wir machen konnten, ist eine einzelne TLS-Verbindung auf Amazon IS2 für 400 Dollar zu brechen. Also wenn jeder von euch vielleicht 50 Cent spendet, das würde bereits ausreichen, um eine einzige TLS-Verbindung zu brechen. Und ich muss nicht viel TLS-Verbindung brechen, nur eine einzige reicht aus, eine, die euer Pop3-Mail-Client vielleicht pro Minute verwendet, um eure E-Mails abzurufen. Und da ist dann euer Passwort drin, im Klartext, wenn das, wenn die Verschlüsselung gebrochen ist. Und wenn wir das haben, dann können wir natürlich alles ermögliche weitere brechen. Also eine einzige Verbindung, die richtige Verbindung, reicht in den meisten Fällen aus. Okay, ich habe gesagt, dass wir viele Puzzlestücke haben, die wir brauchen. Und ich versuche die jetzt mal zu gruppieren in Haufen, um das besser verdaulich zu machen. Das erste, was ich reden werde, ist ein besonderer Angriff, über den ich vor zwei Jahren bereits berichtet habe. Ich werde kurz erklären, wenn ihr euch interessiert dafür in die Details für den Bleichenbacher Angriff, also 98, dann schaut euch meinen Talk beim 31 zu 3 an. Ich werde euch ein neues Protokollproblem in SSL Version 2 zeigen und ich werde erklären, was das mit den 40-Bit Export- kriptografischen Algorithmen zu tun hat. Und wenn wir diese drei Stücke kombinieren, haben wir einen praktischen Angriff gegen SSL Version 2, was nicht wirklich relevant ist, weil niemand eigentlich mehr SSL Version 2 im Internet spricht. Wir müssen aber die Server finden, die das immer noch unterstützen. Wir konnten keinen Klein finden, der immer noch SSL Version 2 aushandelt in der Kommunikation. Eine zweite Sache, die wir brauchen, ist geteilte Schlüsse zwischen verschiedenen SSL- oder TLS-Versionen. Wenn ihr also einen SSL Server aufsetzt und unterstützt SSL Version 2, 3 und TLS 1.0 bis zu 1.2, werden eigentlich immer dieselben RSA-Schlüsselpaare benutzt. Und wenn wir das berücksichtigen, dann wird auf einmal down ein praktikabler Angriff gegen viele TLS-Server. Es ist machbar, in einem akademischen Sinne praktikabel, immer noch teuer, aber durchführbar. Wir können uns das leisten, wenn wir zum Beispiel das Geld zusammenlegen. Und wenn wir jetzt zwei, wir haben zwei Implementierungsfehler, außerdem in OpenSSL, wenn wir also all das verbinden, dann können wir eigentlich alle SSL Version 2 Implementierungen brechen, die es dort gibt. Und hier schauen wir uns jetzt zwei Implementationsfehler in OpenSSL an. Und wenn wir das kombinieren mit dem bereits vorhandenen Drown Attack, haben wir auf einmal einen trivialen Angriff. Das heißt, es braucht dann vielleicht ein paar Minuten auf einem Lacktop-Geben sehr viele TLS-Server. Okay, also fangen wir an mit Bleichenbachers Angriff von 1998. Bevor ich mit dem anfange, möchte ich nur schnell wiederholen, was der RSA-Schlüsselaustausch für TLS ist, wie der aussieht. Es gibt verschiedene Wege, die Schlüssel auszuhandeln. Wenn ich sage Schlüssel, dann meine ich den symmetrischen Schlüssel für die Session. Also als symmetrische Verschlüsselung mit RSA, zum Beispiel, ist sehr teuer. Deswegen machen wir einen Schlüsselaustausch für einen symmetrischen Schlüssel über RSA. Das ist also nicht sehr viel, nicht sehr viel Daten. Und dann die eigentliche, der Inhaltsverschlüsselung für das, was man wirklich austauscht oder die SSL oder TLS-Verbindung, wird dann AIS oder Triple Des oder AC4 oder irgendwas für den Inhalt benutzen, eine symmetrische Verschlüsselung. Und was wir uns jetzt anschauen, ist also nur diese Aushandlung des Schlüssels für die symmetrische Verschlüsselung. Wir haben also ein TLS-Client und ein TLS-Server. Der TLS-Client fängt immer mit einem Client Hello an und darin halten ist eine Zufallszahl des Clients. Das ändert sich mit jedem Request. Der Client ändert diese Zahl mit jedem Request. Und dies wird im Klartext versendet, so der Angreifer kennt diesen Schlüssel. In der Antwort des TLS-Servers ist dann das Server Hello. Dort drin enthalten ist auch eine vom Server generierte Zufallszahl und auch diese ändert sich mit jeder neuen Verbindung. Und auch die wird im Klartext ausgetauscht. Also beide Seiten sind einem Angreifer bekannt. Und außerdem wird dann dieses Zertifikat übersendet, was man zum Beispiel von Commodo oder der anderen Zertifizierungsstelle kauft. Also das kann man vielleicht auch mit Last Encrypt kostenlos bekommen. Und in diesem Zertifikat ist ein öffentlicher RSA-Schlüssel enthalten. Und dieser öffentliche Schlüssel wird mit dem Zertifikat also gesendet. Und mit der nächsten Nachricht, mit dem kleinen Key Exchange, wird der TLS-Client etwas erzeugen, was ein Primast, was sich Primast the Secret nennt. Und dies ist der einzige Teil, der wirklich völlig geheim ist in den ganzen Austausch. Dies wird also nicht im Klartext gesendet, sondern verschlüsselt über RSA mit dem Schlüssel des Zertifikats, das gerade vom Server empfangen wurde. Und das wird dann wieder gesendet. Im nächsten Schritt, und dies ist ein sehr wichtiger Schritt, wird der TLS-Server, den das Primast the Secret entschlüsselt, das er gerade empfangen hat. Und davon leitet er, leiten sowohl Klein als auch Server denselben symmetrischen Schlüssel ab, okay? Also das heißt, der Angreifer kennt die Zufallszahl des Kleins und die des Servers und er sieht eine verschlüsselte Version des Primast the Secret. Und wenn der Angreifer dies entschlüsseln kann, dies Primast the Secret, dann kennt er das Master Secret, also den symmetrischen Schlüssel, der für die Inhaltsverschlüsselung verwendet wird. Mit welchem Algorithmus auch immer. Das ist also der heilige Graal, den wir brechen wollen. Der brechenbacher Angriff in 1998 erreicht genau das. Das ist wichtig. Was ich außerdem erwähnen muss, ist, diese Entschlüsselung kann fehlschlagen. Wenn der Angreifer, sagen wir mal, einen beliebigen Cyphertext, irgendwelche Junkdaten sendet, muss der Server dies zunächst entschlüsseln, diesen Cyphertext, um herauszufinden, ob dies ein gültiges Primast the Secret ist oder nicht. Um das zu machen, wir brauchen ein Oracle. Das ist ein cryptographischer Word. Das bedeutet ein Service, das bekommt ein beliebiger Cyphertext. Davon geht nur zurück mit ein 1 oder 0. Das hängt an, ob etwas gut verschlüsselt war oder nicht. Wenn diese erste Verbindung sieht valide aus, dann wäre das entweder mit 1 oder 0 oder mit 1 oder 0 zurück schicken. Wir haben einen Client und Server und einen Angreifer, das in der Mitte zuhört. Dann vielleicht verändert einige Parameter in dieser Verbindung. Dann können diese Oracles etwas unverschlüsseln und davon wissen, ob es etwas gut gemacht war oder nicht. Jedes Mal, dass ein Oracle mit einem 1 zurückkommt, weiß dieser Angreifer, dass etwas gut unverschlüsselt war. Wenn ein Angreifer das macht, so für 1.000 Mal gemacht, kann ein Angreifer der wahre, versicherte Verschreibung verstehen. In dem Original Bleichenbacher Papier hatte er das normale TLS-Error-Message. Es gab eine Fehler-Nachricht, dass das ganz klar zurückkommt. Die haben nicht versucht, diese TLS-Standard zu verbessern. Wir machen als eine falsche Idee, dass ein unversichertes PMS, der PMS-Standard, der PMS-Standard in der Menge ergibt, es lief aber etwas später. Wenn wir mit dem Flow weitermachen, gibt es dann einen späteren Fehler, weil der symmetrische Key herauskommt. Es gibt verschiedene Schlüssel. wird das Primaster Secret entschlüsseln und immer ein zufälliges Primaster Secret erzeugen. Und abhängig davon, ob die Entschlüsselung erfolgreich war oder nicht, wird Folgendes passieren. Im Erfolgsfall wird das Primaster Secret entschlüsselt und falls das Fehl schlägt, wird ein neuen Zufalls Primaster Secret fortgefahren. Und das bedeutet, dass all die Implementierungen, die wir angeschaut haben, sind in diesem Punkt gleich. Dadurch wird es im AfD ja so eine Implementierungsverbesserung eingebaut worden, ist es da nicht zu unterscheiden von außen, ob das Fehl geschlagen ist oder nicht. Und wir haben jetzt einen neuen Bleicherbacher-Angriff entwickelt. Schauen wir uns also mal SSL Version 2 an das Protokoll. Es ist ein wenig unterschiedlich zur Version 3, aber das ist jetzt nicht so wichtig. Wir haben also auch ein Kleinhello und ein Serverhello und wir haben auch diesen kleinen Key-Austausch nur mit einem anderen Namen, in dem wir diesen symmetrischen Schlüssel, der beim Klein erzeugt wird, senden und dann würden beide ihre symmetrischen Schlüssel erzeugen. Und was hier interessant ist, ist der erste, der mit einer verschlüsselten Nachricht antwortet ist der Server. Und das hat sehr wichtige Schlussfolgerungen, Erfolgerungen folgen, wenn der Klein, das Server Verify ist also ein Hörfluss und Nachricht mit einem Schlüssel, dem Master Key, den beide Seiten jetzt wissen sollten. Und der Klein erhält diese Nachricht, ohne beweisen zu können, dass er denselben symmetrischen Schlüssel hat. In SSL Version 3 und TLS ist das anders. Diese Nachricht wird nur gesendet, nachdem der Klein benutzt hat durch eine fertige Nachricht, dass er denselben Schlüssel besitzt. Wir kommen jetzt aber eben einen Ciphertext, der mit einem unbekannten Schlüssel verschlüsselt ist, denn wir kennen den Schlüssel eigentlich noch nicht. Und die Frage jetzt, bitte akzeptiert, dass dies eine wichtige Frage ist, die wir aufwerfen müssen und ich werde das in den nächsten paar Folien erzählen. Können wir diesen Schlüssel kennenlernen? Wir bekommen diesen Ciphertext. Können wir den Schlüssel kennenlernen, der mit der Verschlüsselung dieser Nachricht verwendet würde? Und wenn wir uns die Spezifizierung von SSL Version 2 anschauen, dann sehen wir, dass es sehr sogenannte Export-Krypto-Algorithmen gibt, die nur 40-Bit stark sind. Dies ist also wie eine Cipher Suite vom Namen aussieht. Also die Namen haben ein solches Format, sagt uns. Es gibt eine symmetrische Verschlüsselung, ein Algorithmus hier RC2. Es werden 128-Bit Schlüssellängen verwendet. Es wird CVC als Verschlüsselungsmodus benutzt und es wird Export 40 mit MD5 als Hash Algorithmus verwendet. Wir haben also 128-Bit Schlüssel, aber nur 40-Bit von diesen 128 sind wirklich für die Verschlüsselung. Ich habe gesagt, der Klein erzeugt den Schlüssel und verschlüsselt das mit dem öffentlichen Schlüssel des Servers und sendet das. Und hier ist es so, dass also nicht 128-Bit Vollverschlüssel sind, sondern nur 40. Und diese 40 werden verschlüsselt und 68 werden im Klartext versendet und können von allen gesehen werden. In den 90er-Jahren hat die Clinton-Administration diese Regel aufgestellt. Sie haben gesagt, okay, also 40-Bit sind genug, um Leute mit Online-Banking oder so zu schützen. Aber offensichtlich wollte die US-Regierung in SSL-Verbindungen hineinschlüffeln, was auch von den Ländern, allen Ländern, die sowas verwenden. Wenn wir uns die Implementierung anschauen, dann wurde der Master Schlüssel auf eine Weise gebaut, dass die klar Text-Bits angehängt wurden an die verschlüsselten Geheimen 40-Bit. Und für Nicht-Export-Kryptoagorithmen hat man dieselben Cypher ohne diese Export-40-Markierung. Dann ist es so, dass die Länge der Bits, die Anzahl der Bits, die unverschlüsselt gesehen werden, einfach null ist. Also vielleicht nicht so die allerklarste Art, das zu tun auf der computerwissenschaftlichen Sicht, aber es ging so in den 90er-Jahren. Okay, schauen wir uns nun dieses Server Verify an. Dieser eine Nachricht, die wir bekommen und in der wir wissen wollen, was der Schlüssel ist. Wenn wir uns die Spezifizierung anschauen, sehen wir, dass das Server Verify nichts anderes ist als das Tufallster des Kleint, die gerade empfangen worden ist. Wir kennen deswegen den Klartext dieser Nachricht und das wurde dann mit dem Master Key verschlüsselt. Wir kennen also den plain Text und wir kennen den Cypher-Text. Und wir möchten außerdem, wir wissen auch, wenn das mit 40-Bit-Export-Cypher ausgenut wurde und das können wir erzwingen, dann sind nur 40 dieser Master Keybits wirklich geheim. Und das heißt, wir können jetzt einen Blood-Force-Angriff, eine Blood-Force-Suche machen. Wir haben den plain Text mit dem Cypher-Text und wir können den Schlüssel suchen und brauchen dafür nur 240 Möglichkeiten, die wir durchprobieren müssen. Und das dauert auf fette Hardware ein paar Sekunden oder vielleicht Minuten. Aber wir könnten das in einem Tag auch auf meinem Laptop machen. Das ist also nichts wirklich kritisch Schwieriges. Okay, lasst mich nun sagen, warum das wichtig ist und warum das ein neues Bleichenbacher-Oracle ist. Nehmen wir an, dass wir einen neuen Geheimtext, ein neues Verschüssel des Primaster Secret erzeugen und 40-Bits geheim halten und das senden. Und das tun wir zweimal mit dem gleichen Cypher-Text. Dann haben wir zwei Server Verify Nachrichten. Wenn wir nun den Schlüssel verrechnen, den der Server verwendet für das Server Verify, falls das Primaster Secret nun korrekt war, können wir diesen Part hier gehen und gehen dann weiter mit dem entschlüsselten PMS. Das Primaster Secret ist gleich, da jetzt auch das Master Secret gleich und dann haben wir den selben Master Key. Falls das Primaster Secret ungültig war, folgen wir diesem Pfad. Und das bedeutet, dass der Master Key für beide Server Verify Nachrichten verschieden sein wird, weil der Server ein neues Primaster Secret generiert für jeden neuen Versuch, der reinkommt. Und das können wir unterscheiden als Angreifer. Und dies ist dann ein neues Bleichenbacher-Oracle mit dem einzigen Bedingungen, dass wir, wenn wir keine Fehlermeldung vom Server kriegen, alles ist korrekt verschlüsselt, wie in dem Standard-Tokument, in der RFC. Das Problem ist aber, wenn wir den gleichen Text senden mit dem Server Verify, wird der Server für das Server Verify denselben Schlüssel zweimal verwenden und dann wissen wir, das war ungültig und sonst wissen wir, dass es gültig war. So, wenn wir das gemacht haben und es wäre eine viel große Gruppe, dass diese Angreif gefunden hat, dann haben wir eine praktische Angreif für SSL zweite Version. Man muss vorstellen, dass viele akademische Leute ganz froh, das gefunden zu haben, so in Ivory Tower gefunden, aber es ist gar nicht für gar nicht relevant. So müssen wir ein bisschen weiter suchen. Was kann man dann, das ist ein cooles akademische Angreif, aber wie ist es, dass du im Ende Internet relevant? So, wir müssen jetzt besser verstehen, wie man echt SSL und TLS benutzt, wie es es konfiguriert. Wenn man ein Server baut mit Apache oder Engines oder sowas, es gibt kein Weg zu sagen, wenn ein Klient eine Verbindung macht mit TLS 1.2 und dann noch eine Verbindung mit SSL Version 3 bekommt, bekommt man zwei verschiedene Keys. Jetzt, wenn man ein Server baut oder ein System baut, ist es immer die gleichen privacy und öffentlich key Schlüssel gibt. Was ist auch sehr wichtig oder ist sehr interessant? Eine Valid Frage ist, wer Leute die gleichen TLS-Zertifikat für verschiedene Protokollen benutzen? Zum Beispiel, wenn jemand ein Zertifikat vom Lesson Cup kauft und dann man es benutzt für SMTP, IMAP, POP3 und alle die andere verschiedene Protokollen, normalerweise machen Leute das. Und das ist jetzt problematisch, weil jeder schaut HTTPS an, aber Leute schauen die TLS-Konfiguration für die andere Protokollen, SMTP, IMAP, POP3 und sowas. Und dann geht man in die Richtung von Bleichenbach Tag und es geht gegen RSA Cypher Text. Und es hängt nicht an welchen TLS Version benutzt, es geht für alle Typen von TLS Versionen. So, wenn man zehn verschiedene Systeme hat und alle die gleichen Zertifikat haben und nur eine von diesen Systemen kann man von Drown angegriffen werden, dann sind alle zehn Systemen vielleicht auch angriffbar von Drown. So, zum Beispiel ist es klar, und wenn es ein Server gibt, das TLS und SSL erlaubt, dann kann ein Angreifer, kann man auf diese TLS Verbindung analysieren und dann kann man dieses System als Bleichenbacher Oracle benutzen, um diese Schlüssel zu verbrechen. So, wenn man das System SSL Version 2 erlaubt ist, kann man auch die anderen Versionen verbrechen. So was hier neu ist, wenn man zwei Systeme hat und dann die beiden die gleichen Schlüssel oder die gleichen Schlüssel, aber vielleicht verschiedene Zertifikat benutzen. Zum Beispiel mit Heartbleed, haben wir bemerkt, dass Heartbleed angreift wird, diese Keys und Kompromieren. So, mit ein Heartbleed-Angriff könnte man diese Privatschlüssel lernen. So, dann muss man eine neue Zertifikat kaufen. Und was viele Leute gemacht haben, dann haben Leute eine neue Zertifikat gekauft, aber mit die gleichen RSA für Schlüssel und das ist gar keine Idee. So ist es auch möglich, dass die zwei benutzen die verschiedenen Zertifikat, aber benutzen immer noch die gleichen RSA Schlüssel. In diesem Fall sagen wir als Beispiel, vielleicht ist diese zweite Server nicht zum Drown reichbar oder angriffbar. Zum Beispiel kann man auf diese erste Verbindung zu dieser unangreifbar Server schauen und dann zu einer zweiten greifbarer Server diese gleichbar angreif machen. So, wenn wir durch diese Internet schauen. So, wer benutzt die gleichen RSA Schlüsselpaar von verschiedenen Ports und es gibt eine zustandzielle Nummer von Schlüsselpaaren, die so gleich sind. Hier ist man nicht so, diese erste, für diese Kolumn von Port 25 SMTP, wo hat man diese Zertifika auf einer anderen Port gefunden? So sicher, so für alle Systeme, die SMTP hat, haben wir auch gefunden, dass 30 Prozent haben diese gleichen Zertifikat am Portrier und 31 oder 29 haben eine App. Und was interessant ist, ist, dass Leute diese gleichen Schlüsselpaar über gleichen Protokoll benutzen. Zum Beispiel mit HTTPS, für viele Servers auf HTTPS, haben wir bemerkt, dass sie viele Servers angreifbar sind. Man schaut auf die Konfiguration von HTTPS, aber man schaut auf die Konfiguration von SMTP nicht so viel. Für SMTP, wenn man nicht eine TLS-Verbindung bauen kann, es wird sehr schnell zurück zum plaintext zurückgehen. So für SMTP eine schlechte Verschlusslung ist besser als plaintext. Aber das bedeutet, dass wenn man eine Schwachheit in SMTP findet, kann man auch etwas auf 443 HTTPS verbrechen. So das bedeutet, dass ungefähr zweimal so viele Systeme sind jetzt, es sind die möglichen, die sind angreifbar zu Drown. Und wenn diese Angriff weiter machen, sogar wenn es ein System, das HTTPS nicht zum Drown angreifbar ist, aber wenn wir eine andere Port anschauen, können wir sehen, dass diese andere Port auch angreifbar ist. So das bedeutet, dass 50% von SMTP-Servers von Drown angreifbar sind. Für Port 443, das bedeutet ungefähr ein Drittel von allen Systemen sind angreifbar, weil irgendwo die gleichen Schlüsselpaar ist auf einer andere Port benutzt. Es ist wirklich substanziell, wie viel dieser Angriff erweitert ist bei dieser Fehler. Und so, wir wissen, dass Drown immer noch ziemlich schwierig ist. Es ist nicht eine einfache Angriff. So wie können wir es mehr effizient machen? Wir müssen zwei zum viertrücksten Stärkeit, wir müssen ungefähr 1.000 Oracle Verbindungen machen. Wir haben einige Code-Schnitten von OpenSL gemacht und dann haben wir eine Implantation von MD2 und OC4 und OpenSL gemacht. Das bedeutet, dass für einen Vollangreif, das ist ungefähr 50 Tage, dann haben wir Leute von Hashcat gefragt. Das war eine von Hashcat Team, ist auch eine Mitschreiber von Drown. Wie kann du uns helfen, weil es ist wirklich ähnlich zu, wie wenn man ein Kennwort sucht. Es ist wirklich ähnlich zu Kennwort-Kracken, sodass er über Nacht etwa 30-mal so schnell gemacht, wenn wir diese optimale Hashcat benutzt haben. Und das war unglaublich schön. Dann haben wir es zum Amazon EC2 gemacht und für nur 440 Dollar könnte man das in 8 Stunden machen. Das ist eine substantielle Verweiterung von dieser Angriff. Jetzt haben wir eine pratriere Angriff für viele SSL Servers und das ist die Drown Angriff, das geht gegen jede SSL Version 2. Und jetzt haben wir noch zwei weitere Fehler in OpenSL, dass Drown wirklich verbessert. Zuerst haben wir etwas mit dieser Cypher Suite. Wenn man SSL oder TLS-Konfigurationen hat, dann hat man immer eine Protokoll-Version und eine Cypher Suite. Und mit jeder neuen Protokoll-Version gibt es einen Haufen neuen Cypher-Suite, die herausgekommen sind. Und was nun viele Leute machen, ist die Konfigurieren ihres Cypher-Sweets. Sie sagen, wir nehmen nur noch die sicheren Cypher-Sweets für der Crypto-Argument und nehmen also Dinge heraus wie SSL Version 2, um den Pudelattack zu verhindern. Aber SSL Version 2 wird aber jetzt nicht explizit deaktiviert. SSL Version 2, zwar deaktiviert, aber nicht alle Cypher-Sweets, also Crypto-Argumenten werden auch explizit ausgeschlossen. So sollte Drown nicht funktionieren. Also wie macht nun SSL Version 2 das Aushandeln der Cypher-Suite des Algorithmes? So funktioniert es im Klein. Gibt es das Hello? Der Klein fragt, hey Server, möchtest du mich vielleicht mit Export Crypto-Argumenten unterhalten? Und die Antwort in SSL Version 2 wird er dann lauten, nein, tut mir leid, ich mache keine Export Crypto-Argumenten. Und der Klein wird dann sagen in SSL Version 2, oh schade, okay, ciao, klangts zum nächsten Mal oder man versucht eine andere, eine Protokoll-Version, eine andere. Und dies hier ist der relevante Code, der benutzt wird dann nach, nach dem Handshake, den ich euch gerade gezeigt habe. Nehmen wir also an, der Klein sagt, nicht, ciao, tut mir leid, zu schade, dass wir nicht mit Export Crypto-Argumenten reden können. Wenn der Klein aber stattdessen sagt, okay, ich werde auch nicht Export verwenden, schauen wir mal, was dann der Code macht. Also hier empfangen wir die Daten aus dem Netzwerk. Dies ist also die, die Nachricht, die, das verschlüsselte Primaster-Suite enthält und außerdem den Crypto-Argutmus, den der Klein gerade ausgewählt hat für die Aushandlung. Und dann bekommt man also die Cypher-Suite über den String, der herein kam, also über den K, das Zeichen. Jede Suite hat ein Zeichen, gibt es so ein Byte, das einen bestimmten Crypto-Argutmus angibt und dadurch bekommt man einen Point dazu, irgendwie überlegen, Crypto-Code. Und wenn das nicht erfolgreich war, was bedeutet, dass der Crypto-Argutmus, dass ein Crypto-Argutmus ausgehandelt werden soll, der nicht im Code einkompiliert ist. Wenn er einkompiliert ist, wird er benutzt. Aber wer sieht nun den Teil, der wirklich die Konfiguration überprüft? Er ist nicht da, also wir haben ihn nicht gefunden. Und was also wirklich passiert ist, eine Nicht-Standard SSL-Version, zwei Implementierungen, die sich nicht an den Standard hält, kann also erzwingen, dass ein Crypto-Argutmus verwendet wird. Also können dann sagen, okay, wir verwenden trotzdem Export 40 Algorithmus und das wird dann auch funktionieren, das wird dann passieren. Die Geschichte dahinter ist also die folgende Nimrod hat das getan, hat SCAPI, eine sehr schlechtes SCAPI-Implementierung verwendet, Implementierung eines Scanners, um zu schauen, wie viele Systeme im Internet SSL-Version 2 unterstützen. Ich habe den ersten Scan ausgeführt und ich fand diese unglaubliche Anzahl von Servern die SSL-Version 2 unterstützen. Dann nahm ich einen anderen Scanner, der nach SSL-Version zusuchte und der sagte uns dann ganz oft, nein, wird nicht unterstützt und dann habe ich die Backt und die Backt und das Nimrod ist einfach zu faul und diese Nachricht zu passen. Also Nimrod hat dann gesagt, du magst nicht gerne Export 40, egal, ich rede trotzdem Export 40 und es war immer so egal, was der Server ausfällt und das war also der Unterschied, warum dieses Scanner so viel mehr fand und da hatten wir einfach Glück, dass wir diese Implementierung verwendet haben, diese Scanner Implementierung. Wenn wir diesen Fehler in der Scanner Implementierung nicht gehabt hätten, hätten wir vielleicht gar nicht diesen Bug in OpenSSL bemerkt. Also unabhängig von eurer Konfiguration, in eurer Krypto-Algorithmen Konfiguration. Diesen Bug gegen OpenSSL zu verwenden, bedeutet, dass ihr alles mögliche aushandeln könnt über OpenSSL, was ihr wollt, mit einer Implementierung, die sich halt nicht genau an die Standards hält, mit einem kleinen, der sich nicht genau an die Standards hält. Das heißt, dieser Server ist dann angreifbar mit Drown und das ist cool. Das zweite Ding ist ein spezielles Drown. Das ist es wirklich sehr speziell. Das ist ja auch ein Fehler in der Implementierung, nicht in der Implementierung, ein Fehler. Verwenden wir also wieder diese Export 40 Cyphersuite, RC2 und 128-Bitschlüsseln, aber wir übertragen alle bis auf 40-Bits im Klartext, das habe ich schon erklärt, das heißt, nur 40-Bits sind effektiv die Verschlüsselung und es ist nun durch eine Implementierungstheorie erlaubt, dass diese Klartext-Bits benutzt werden können, auch in Kombination mit Nichtexport-Krypto-Algorithmen, mit stärkeren Algorithmen. Also ein Kleint, der sich an den Standards hält, würde jetzt für einen Nichtexport-Krypto-Algorithmus alle 16-Bits oder 128-Bits verwenden und die würden alle mit dem geheimen Teil des Schlüsseln, den wir gerade aus dem verschlüsselten Primaster Secret Enormum haben, verwenden, wenn wir aber vier Klartext-Bits senden. Zusammen mit einem 16-Bit Primaster Secret, das verschlüsselt war, wird dies immer noch vorne angehängt an das verschlüsselte Primaster Secret und das heißt, dass das Schlüssel 15 oder 13 bis 16 einfach wegfallen. Wenn wir also jetzt 15 Klartext-Bits senden, dann auf einmal haben wir ein Server Verify, das verschlüsselt wurde, mit einem 128-Bit-Schlüssel, bei dem wir alle bis auf 1-Bit kennen und damit können wir eine Brutforce-Suche im Durchschnitt 128 Verschlüsselungsversuchen. Und wenn wir das nun schrittweise tun, wir schicken 15 Null-Bytes im Klartext, dann haben wir ein byte, dann lernen wir byte 1 des Schlüsseln. Dann im nächsten Schritt senden wir 14 Null-Bytes. Wir empfangen bereits das bekannte byte 1 in Nummer 15 und das nächste byte können wir dann herausfinden mit Brutforce und das können wir dann schrittweise tun. Wenn wir also in diesem Fall, dass wir Null-Bytes senden und bereits die ersten 15 bytes kennen, dann müssen wir eben nur für das letzte byte, wieder nur eben durch 128 Verschlüsselungsversuche für Brutforce ausführen. Das ist also dieses special down, also eine spezielle Version dieses Angriffs. Das generische down hat immer noch die Komplexität 42 pro orake-Request und wir müssen sowas für 1.000 orake-Requests durchführen. Das ist also relativ viel, aber mit dieser 240 Komplexität, diese 240 Komplexität verringert sich jetzt auf 15 Probeverbindungen und in jedem Schritt brauchen wir 128 Angriffe. Das sind also insgesamt 1920 Verschlüsselungsversuche und das kriegen wir in wenigen Minuten auf einem normalen Laptop hin und das ist also wirklich ein neuer Schritt. Was hier interessant ist, ist dieser Bug wurde gefixt bei den Entwicklern von OpenSSL, ohne zu wissen, dass dieser Bug vorhanden war. Es wurde also ein Bug-Report eingereicht, der überhaupt nichts mit down zu tun hatte. Das war vor eineinhalb Jahren, da war down noch gar nicht bekannt und OpenSSL hat einen patch veröffentlicht und dieser Bug wurde gepatched, ohne den Bug erkannt zu haben. Also nicht wirklich ein geheimlicher Fix, sondern ein Fix, in dem niemand gesehen hatte, was eigentlich los war. Und später fanden wir aber heraus, dass es eben ein sehr wesentliches Problem war und warum erkläre ich das? Wir können jetzt gerne wieder das Internet danach scannen und suchen wer hat ihre seine OpenSSL-Implementierung nicht gepatched, obwohl der patch eineinhalb Jahre alt ist. Und dies ist also die Anzahl der Internet-House der Server, die eine Art, irgendeine Verschlüsselung verwenden mit OpenSSL, mit einer Version von OpenSSL, die überall eineinhalb Jahre alt ist. Die Leute patchen also nicht wirklich. Wenn man das vergleicht mit der Anzahl des Servers, die für down angreifbar sind, dann wird ihr sehen, dass die meisten eben dieses OpenSSL-Problem haben. Die Anzahl ist sehr ähnlich. Okay, also fassen wir zusammen. Einsatz, den ich nur sagen muss, uralte SSL Version 2 bricht immer noch heutiges TLS und wir machen nichts anderes, müssen nichts anderes tun, außer SSL Version 2 zu deaktivieren und dann ist das für immer erledigt. Also wen müssen wir jetzt hier, wie müssen wir die Schuld geben für down? Wer hat den Fehler gemacht? Also zunächst mal sehr offensichtlich. Wir haben einen Fehler im Crypto-Design aus den 90er Jahren. Das ist also nicht so überraschend. Etwa vor 20 Jahren passiert natürlich viele Dinge seitdem. Dann haben wir einige Fehler in einer Crypto-Inventierung aus den 90er Jahren, die OpenSS-Leute würden sagen, okay, ich habe niemals irgend eine SSL Version 2 Code angeschaut, also das ist eine uralte Implementierung. Was ein größeres Problem ist, sind die Probleme in der Crypto-Konfiguration. Weil Leute also ihre Server konfiguriert haben auf eine sehr schlechte Art und Weise. Und was auch sehr interessant ist, die Export40-Krypto-Algorithmen sind ein wesentlicher Teil von Drone. Drone wäre kein praktikabler Angriff, wenn wir nicht durch die Politik, durch die Clinton-Administration, die Tatsaraten, dass eine Regulierung aufgezwungen wurde, nämlich dass eben Export-Kryptografie 040-Bit stark sein darf. Okay, was sind nun die Möglichkeiten, dies abzumildern für Administratoren? Deaktiviert SSL Version 2 und wo ihr gerade dabei seid, deaktiviert auch gleich SSL Version 3. SSL ist unsicher, verwendet es nicht mehr. Aktualisiert euer OpenSSL regelmäßig. Das ist etwas, was ihr für jede Library tun solltest. Jede Library, die irgendwie was mit ihr durch die Security zu tun hat. Das ist also etwas, was die Admins tun können. Was Bürgerinnen und Bürger tun können, ist, stimmt ab gegen Hintertüren in Kryptografie. Vielen Dank. Vielen Dank, Sebastian. Haben wir Fragen aus dem Publikum? Okay, wir haben eine Frage, glaube ich, wir fragen mal mit dem Mikrofon 3 an. Es gibt zwei Fragen. Erste, wie spezifisch ist das für RSA? Wird das auch für Diffy-Helven-Besirte-Füssigungen? Und nachher, haben viele Leute durch OpenSSL geschaut und auch Volks gebaut. Hat diese Sindsachen mit OpenSSL verbessert? Ja, die erste Frage war also, ist das nur RSA vorhandens Problemen? Ja, wir können den Server hier nun, die Rolle des Servers einem wirklich guter Hardware können, den Server nachspielen, schwer zu erklären ohne, ohne Folien dafür. Also schaut euch das, schaut ihr den Aufsatz an. Wir können Diffy-Helmen brechen, aber das ist kein Offline-Angriff mehr. Da brauchen wir einen aktiven Angreifer in der Mitte. Das war die erste Frage und das ist dann beschränkt auf RSA. Ja, also Diffy-Helmen können wir so nicht angreifen. Die zweite Frage ist, ist OpenSSL oder andere Implementierungen verbessert? Sind es Hard-Bleed? Also dieser Bug ist nicht in einer Code-Überprüfung vorgefunden worden, wahrscheinlich, weil die Leute sich gar nicht mehr um SSL Version 2 gekümmert haben. Das ist ja sowieso völlig kaputt. Also das war eigentlich eine gute Code-Überprüfung. Okay, danke. Haben wir Fragen aus dem Internet? Nein? Mikrofon 1, bitte. Ein Nachricht, wenn man sagt, dass man OpenSSL ein Update machen muss, man kann nicht nur ein Update machen, aber man muss auch alle die Prozesse weiterbauen und weil alle die rennende Prozesse sind immer mit die andere Prozesse verbunden. Ja, und so macht das durch eure tolle Abteilen von 1000 Tagen kaputt. Ja, aber muss sein. Das ist die Faktor von 1000, das zu 416, wovon kommt das? Das kommt vom Algorithmus in Breichenbacher. Als der Algorithmus von Breichenbacher 98 publiziert wurde, hieß es der Million-Fahr-Anfragen-Angriff, weil man musste in bürgern eine Million Nachrichten verschicken zwischen Client und Server, um eine Entschlüsselung des Cybertexts hinzukriegen. Das hat sich nun dramatisch geändert in den Jahren seitdem. Es gibt viele Paper, die Herr Verbesserungen des Angriffs hobiziert haben und nun sind es 1000 ungefähr. Das hängt von der Größe ab, vom Primaster-Secret, aber im Durchschnitt 1000 Verbindungen sind nötig. Eine parenotische Frage, wenn man das für ein Library benutzt und wenn man sagt Disabled Protocols, bedeutet das, dass man ein Funktionkohl macht, no SSL Funktion. Warum schaut man das nicht daran? Warum schaut die Cyber-Sweets nicht daran? Wie sind wir sicher, dass wir geschützt sein werden, wenn wir sagen, no SSL V2, wenn ich eine Verbindung oder ein Library baue? Also OpenSSL hat diesen Code gelöscht, nachdem wir das Ihnen gesagt haben. Also aktuell ist einfach OpenSSL und dann wird ist das weg und nicht mehr im Repo und startet euren Server neu oder zumindest den Serviceprozess. Dankeschön. Ich würde gerne fragen, haben Sie auf andere Kryptolibräe anders als OpenSSL geschaut? Ja, also die meisten modernen Kryptolibräes mit modernen, meine ich, solche, die in den letzten paar Jahren herausgekommen sind, die implementieren einfach SSL V2 gar nicht mehr. Libre SSL zum Beispiel haben den Code einfach gelöscht. Dieses andere auch, also die Python-Libräes zum Beispiel haben das nicht mehr implementiert und so weiter. Aber all diejenigen, die wir angeschaut haben, zum Beispiel der Code in IS im S-Channel drin ist, der unterstützt immer noch SSL V2 und hat denselben Protokollfehler. Also wenn ihr SSL V2 unterstützt, seid ihr verwundbar, unabhängig von eurer Implementierung, egal was eure Implementierung ist, jedenfalls soweit wir das gesehen haben. Warum die Name Drown? Ja, warum ertrinken Drown? Eine gute Frage. Also Nimrod hat diese Ursprungsidee gehabt und das ist sein Lieblingsfilm, spielt ja eine Rolle, dann haben wir einen Background ausgeführt, dass ich es gar nicht mehr im Kopf habe. Es steht im Papier, sorry. Ich weiß nicht mal mehr, wie das Backroom heißt. Es ist ein Arbeitstitel gewesen und der hat sich dann fortgesetzt. Und natürlich mehr Informationen im Fahrplan. Okay, weitere Fragen? Okay, in dem Fall habe ich eine Frage. Normalerweise sagt man, welche Politiker wollte, wir sind zwei Sicherheit abschwächen. Auf der Bühne hört man sie nicht so gut. Also eine allgemeinere Frage. Wir haben die Politiker, die versuchen die Schlüssel und die Sicherheits abzuschwächen. Wer war das noch gleich? Das war die Clinton-Administration. Also alle Politikerinnen und Politiker wollen das im wesentlichen Terrorismus und so. Ja, weil wir alle so schlimme Leute sind. Also wenn wir das jetzt machen, wenn wir jetzt Kryptoregulierungen haben in neuen Projekten, dann sollten wir versuchen, dass in fünf bis zehn Jahren mit neuen Kryptodoktoranden die das dann hoffentlich angreifen. Das ist vielleicht eine gute Folge davon, aber generell ist es keine gute Idee. Andere Fragen in der Zwischenzeit? Ist das eine Frage? Nein, setz dich noch hin. Ah, hier ist eine Frage. Hi. Du hast gesagt, für ein Mail Server ist immer noch keine gute Erinnerung, dass man all die Krypto erlauben. Da habe ich das nicht verstanden? Also es gibt ein Argument dafür, SSL Version 3 zu unterstützen, obwohl es gebrochen ist. Es ist gebrochen in einer Weise. Na ja, der Pudelangriff ist verbraucht, offensichtlich mehr Aufwand, um Version 3 zu brechen, als den plaintext zu lesen. Mit dem Drown-Angriff ist es eine andere Sache. Denn selbst, wenn man sichere TLS-Verbindungen verwenden, kann man die immer noch brechen, indem man SSL Version 2 für den Angriff verwendet. Also das nennt sich opportunistische Verschlüsselung. Also irgendwelche schlechte Verschlüsselung ist immer noch besser als keine Verschlüsselung. Dieses Motto ändert sich durch Drown, weil hier etwas ist, was sich über Protokollgrenzen hinweg auswirkt. Kompromiert das nicht diese RSA-Privatenschussung? Man muss keine neuen Schlüssel kaufen, also eine RSA-Schlüssel. Man sollte einfach nur Version 2 aus der Konfiguration entfernen, den Server neu starten oder die Services und OpenSSL aktualisieren und dann seid ihr fein raus. Okay, irgendwelche andere Fragen? In dem Fall, bitte, gibt einen Jubiläums-Aplaus an Sebastian Schinzel. Ja, und gibt uns Feedback in der Besetzungskabine einen weiteren Sebastian.