Tag Archives: TLS

Sächsische Polizei benutzte gebrochene Verschlüsselung

Posted on by

Diese Geschichte spielt im September 2016 und handelt davon ..

… das 365 Full-DisclosureTimer abgelaufen sind und ..

… Wie aus einer Maus ein Elefant wird

Im Zuge einer Ermittlung zu SSL Problemen eines Kunden, bin ich über ein SSL Problem der Polizei Sachsen gestolpert. Aufmerksame Leser meines Blogs ist das Thema SSL/TLS bei Mailservern nichts neues. Es reiht sich ein in Probleme wie die des CERT-BUND vom BSI , die sich im Vergleich dazu aber schnell schliessen liessen. Der Versuch, die Sicherheitslücke der zuständigen Abteilung  zu melden, artete regelrecht in einen Instanzenlauf aller „Die Zwölf Aufgaben des Asterix“ aus. Am Ende waren 6 Behörden daran beteiligt.

Was ist eigentlich passiert ?

Wer sein Mailserverlogfiles schonmal genauer angesehen hat, wird darin Angaben wie diese finden : „X=SSLv3:AES256-SHA:256″ . Diese stammen zwar jetzt von Exim, sind so aber auch in anderen Produkten zu finden. Bei dem X= handelt es sich um das Verschlüsselungsprotokoll ( SSLv3 ) und dem genutzten Verschlüsselungsalgorithmus/Cipher ( AES-256 mit Hashalgo SHA256 ) . Am Cipher gibt es nicht viel auszusetzen, klar, es gibt bessere z.B. AES256-GCM-SHA384:256, aber das ist nicht des Pudels Kern, sondern die Version SSLv3.

SSLv3 gilt seit 2 Jahren im Rahmen der POODLE Attacke als geknackt, zudem wurde es im Bereich Email vor über 15 Jahren schon von TLS abgelöst. Seit dem es als geknackt gilt, sollte man es auch nicht mehr einsetzen. Daher haben Internetprovider weltweit SSLv3 aus Ihrem Webservern und Emailservern entfernt. Jetzt wäre es falsch zusagen „Nur die Polizei Sachsen“ nicht, denn das stimmt nicht und wäre eh nur die halbe Wahrheit, denn es gehören immer zwei Server zu einer Übertragung.

Normalerweise läuft das so ab, daß sich sich der sendende und der empfangene Mailserver beim Verbindungsaufbau auf das Protokoll, den Cipher und den SessionKey einigen. Dabei wird erst TLS1.2 , dann TLS1.1 und dann TLS1/SSLv3 ausgewählt. Der Server der Polizei in Sachsen hatte nun SSLv3, also den schlechtesten Algorithmus gewählt, obwohl bessere zur Verfügung standen. Warum er das tat ist (war) noch Ziel einer Untersuchung. Die Kripo in Leipzig hat es auf sich genommen, das an die zuständigen Stellen weiterzuleiten und dafür zu sorgen, daß das zugrunde liegende Problem behoben wird.

Das war die Maus… und jetzt der Elefant

Für die Polizei betreut ein Dienstleister als sogenannter Staatsbetrieb die Netzwerke des Bundeslandes und seiner Behörden, das ist i.d.R. eine privat organisierte Tochter des jeweiligen Bundeslandes. In Sachsen ist das die „Staatsbetrieb Saechsische Informatik Dienste“ in Dresden. Wenn man jetzt glaubt, daß man dies ja nur dieser, für die Netze zuständigen Organisation mitteilen müßte, hat das noch nie probiert 😀

Dort habe ich natürlich zuerst angerufen um rauszubekommen, wer meine Kontaktperson sein wird. Pustekuchen. Die Leute da haben sich das zwar angehört, wollten aber aus externen Input nichts tun. Ich sollte das doch an den Polizeibeamten schicken der die fragliche Email geschickt hatte übermitteln, er würde das schon weiterleiten. Das habe ich gemacht.

und ….. ???

Nix. Gar nichts. Keine Empfangsbestätigung, kein Rückruf. Wie sich heute rausgestellt hat, war die Kripo Leipzig am letzten Freitag, Tag des Maileingangs, total überlastet. Der zuständige Mitarbeiter hat die Mail einfach weggeklickt, weil er den Inhalt auch nicht ganz erfaßt hatte. Zum Glück für die Polizei hat der besorgte ITler keine Ruhe gegeben und sich heute erneut durch die Instanzen gequält bis der zuständige Mitarbeiter sich dann selbstständig bei mir gemeldet hat.

Die nicht an behördenarme Suche soll hier skizzenhaft dargestellt werden:

Polizeidirektion Braunschweig
LKA Niedersachsen
LKA Sachsen
Polizeidirektion Leipzig
Staatskanzlei Sachsen
Bundesamt für Sicherheit in der Informationtechnik

als Optionen wären noch drin gewesen :

Landesdatenschutzbehörde Sachsen
Innenministerium Sachsen
Bundesministerium des Inneren
Verfassungsschutz Sachsen
Staatsschutz

Wenn es nach dem BSI gegangen wäre, wärs gleich beim Bundesministerium des Inneren gelandet, also ganz oben 🙂

Jetzt fragt Ihr Euch vermutlich wie der Verfassungsschutz da ins Spiel kommt. Das ist ganz einfach, das Mailserversystem des Landes mailt ja nicht nur Bürger an, sondern auch andere Behörden. Wenn jetzt also ein Konfigurationsfehler vorliegt, der dafür sorgt, daß der schwächste Algorithmus ausgewählt wird, dann sind auch Behörden- und damit Staatsgeheimnisse betroffen. Und da wir nicht so enden wollen wie die Amis, wo deren Politiker private Mailserver benutzen, sollten unsere Behördennetzte sicher sein. Davon profitieren wir alle, auch ganz direkt, denn Anwälte haben auch viel Emailkontakt mit der Polizei, Staatsanwaltschaften usw. .  Es will sicherlich niemand seine Aussage/Anzeige/ V-Manninfo von irgendwelchen in- und ausländischen Gruppen dekodiert bekommen, oder ?

Hier ein paar Sätze, die sinngemäß in den Gesprächen enthalten waren:

Auf die Frage: „Können Sie nicht einfach auf dem Dienstweg die Information weiterleiten?“

„Da ist eine andere Polizeibehörde, da haben wir keinen Dienstweg.“ ( PD Braunschweig )
„Das ist ein anderes Bundesland, da sind wir nicht weisungsbefugt.“  ( LKA Niedersachsen )
„Ich habe keine Ahnung wovon Sie da reden.“ ( Staatskanzlei Sachsen )

Die Dame in der Staatskanzlei hatte aber die passende Idee und dazugehörige Nummer von der PD Leipzig, so daß ich dort anrufen konnte, was dann über weitere Umwege zur Lösung geführt hat.

Die Behörden in Sachsen sind aus der Sicht der Polizei übrigens IT mäßig von unten nach oben frageberechtig, es kann also keiner von außen oben nachfragen, wie man dem Artikel ja auch entnehmen kann, sondern man muß jemandem am Ende der Kette aka. Mitarbeiter der PD Leipzig, z.B. ein Kripobeamter, die Sache aufnehmen lassen. Der darf dann seinen ITler fragen, was er sich da grade angehört hat und DER darf dann nach oben durchreichen, was zutun ist. Args!

Das skurillste Gespräch fand aber mit dem Netzbetreuer statt, dem Staatsbetrieb Saechsische Informatik Dienste :

„Wie sind Sie an diese Nummer gekommen ?“
„Steht im Whois des IP Bereichs drin.“
„??? Und warum rufen Sie hier an?“  ( Die Formulierung könnte leicht abgewichen sein)
„Weil ich …. entdeckt habe.“ ( die Sache mit dem SSLv3 )
„Was erwarten Sie jetzt von mir ?
„Das Sie das aufnehmen und intern weitergeben, damit es abgestellt wird.“
„Nö.“

Fazit

Dieser „Wir sind aber eine andere Behörde Kram“ ist doch dem Informanten egal und der Schutz von Staatsgeheimnissen sollte doch bitte schön allen Behörden am Herzen liegen. Vor allem wundert es mich ja, das überhaupt etwas Polizeiarbeit bundeslandübergreifend stattfindet, wenn die keinen Dienstweg dafür haben, wie machen die das dann ?!?!?!

Wie sorgt man nun auf seinem eigenen Mailserver dafür, daß SSLv3 nicht mehr geht ?

Also zunächst mal wärs ratsam ein aktuelles Linux zu haben, weil darauf aktuelle OPENSSL und GNUSSL Versionen wären. Je nach dem welche Kryptobibliothek man verwendet, gibt es unterschiedliche Wege.

Für Exim hält man sich am besten an dies hier: https://lists.exim.org/lurker/message/20141017.093614.e5c38176.de.html

Um eine Neukompilierung kommt man wohl nicht drumherum. Für den Anfang reicht es natürlich schon, wenn man SSv3 ans Ende und TLSV1.2 an den Anfang der Protokollverhandlungen stellt. Damit fällt SSLv3 dann praktisch auch weg.

 

Häufigkeit von TLS Ciphern

Posted on by

Ich hatte etwas Zeit für eine kleine Analyse und wollte eigentlich mal nachsehen, ob noch jemand SSLv3 statt TLS für Verbindungen zu unseren Mailservern benutzt. Also habe ich die Logfiles der letzten 4 Wochen nach den Verbindungsparametern gefiltert. Folgende Studie kam dabei heraus:

gezähltCipher
1TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128
1TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256:
1TLSv1.2:ECDHE-RSA-AES128-SHA:128
3TLSv1:DHE-DSS-AES256-SHA:256
5TLSv1.2:DHE-RSA-AES128-SHA256:128
6TLSv1.1:ECDHE-RSA-AES128-SHA:128
6TLSv1.2:EDH-RSA-DES-CBC3-SHA:168
7TLSv1.2:AES128-GCM-SHA256:128
10TLSv1.2:DES-CBC3-SHA:168
11TLSv1.1:AES256-SHA:256
12TLSv1.1:DHE-RSA-AES256-SHA:256
13TLSv1.2:CAMELLIA256-SHA:256
24TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:
40TLSv1.2:DHE-RSA-AES256-SHA256:256
82TLSv1:EDH-RSA-DES-CBC3-SHA:168
83TLSv1:DHE-RSA-AES128-SHA:128
228TLSv1.2:ECDHE-RSA-AES128-SHA256:128
294TLSv1.2:AES256-SHA256:256
316TLSv1:DES-CBC3-SHA:168
386TLSv1:DHE-RSA-CAMELLIA256-SHA:256
455TLSv1.2:DHE-RSA-AES256-SHA:256
461TLSv1.2:AES128-SHA:128
606TLSv1.1:ECDHE-RSA-AES256-SHA:256
745TLSv1.2:AES256-SHA:256
760TLSv1.2:AES128-SHA256:128
2345TLSv1.2:DHE-RSA-AES128-SHA:128
2663TLSv1.2:ECDHE-RSA-AES256-SHA:256
3234TLSv1:AES128-SHA:128
9522TLSv1:DHE-RSA-AES256-SHA:256
9762TLSv1.2:AES256-GCM-SHA384:256
14110TLSv1:ECDHE-RSA-AES128-SHA:128
16894TLSv1.2:ECDHE-RSA-AES256-SHA384:256
18719TLSv1:AES256-SHA:256
36597TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
53900TLSv1:ECDHE-RSA-AES256-SHA:256
89330TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128
175139TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256

Grundlage der Studie sind 436.746 Emails, die unsere Server erreicht haben, also nicht, was gesendet wurde.

Was ich schonmal positiv finde, ist das Fehlen von SSL als Protokoll. Alle transportgesicherten Emails waren mit TLS gesichert. Leider konnten mich die eingesetzten/ausgehandelten Cipher nicht so beglücken z.b. TLSv1:AES256-SHA:256 . TLSv1 ist eigentlich SSLv3, nur leicht modifiziert und bereits erfolgreich gebrochen worden.

Um die Frage, die einigen Lesern auf der Zunge brennt: „Wieso lasst Ihr das zu?“ zu beantworten: Weil sonst keine Emails mehr bei den Kunden ankommen würden. Die Realität sieht nämlich leider so aus, daß die meisten Mailserver nicht auf Stand sind und es diesen Sendern auch egal ist. Die Senden zur Not auch ohne TLS. Heute erst bei der größten Film- und Fernseheproduktionfirma aus Hollywood erlebt.

Transportverschlüsselung wird also von vielen Firmen und Mailserverbetreiber immer noch als „egal, Hauptsache Mail kommt an“ abgetan und solange Ihr als Kunden nicht darauf besteht, daß der benutzte Mailserver A) TLS kann und B) den besten Cipher wählt der verfügbar ist, wird sich auch nichts ändern.

Unsere Server handeln den besten Cipher aus, der verfügbar ist. Versprochen 😉

interessant zu wissen wäre jetzt noch, welche Mailserver hinter den veralteten Ciphern stehen, nur kann ich damit leider nicht dienen.

TLS: Wie man sich selbst austrickst

Posted on by

Nicht das einer meiner geneigten Leser glaubt, ich hätte zuviel Phantasie oder mir wäre das selbst passiert und ich würde es jetzt in einer netten Story schön reden wollen, vergeßt es, es ist tatsächlich so passiert.

Was ist TLS ?

Um zu verstehen was genau passiert ist, muß ich etwas ausholen, da nicht jeder Leser wissen wird, was TLS genau macht.

Erstmal TLS ist die Transport Layer Verschlüsselung(Security) für Emailserver und Webseiten und hat SSL ( Secure Socket Layer ) abgelöst, weil es a) ein paar Vorteile gegenüber SSL hat und b) nicht komplett gebrochen ist wie SSL. (Ja, SSL ist tod, wer noch SSL 1-3 benutzt, kann es auch abschalten und die Rechenleistung anderweitig nutzen 😉 ).

Wenn ein Mailprogramm einen Mailserver mit TLS Unterstützung kontaktiert, tut er das auf den an sich unverschlüsselten Port 25. Der Mailserver meldet dem sich verbindenden Programm/Client/Server welche Möglichkeiten der Server anbietet, z.B. den Befehl STARTTLS . Finden ein sich verbindendes Programm diesen Befehl, wird es diesen Aufrufen und damit die Verbindung von unverschlüsselt auf verschlüsselt „upgraden“ .  Damit man das machen kann, sendet der Mailserver seinen öffentlichen Schlüssel in einem Zertifikat an das verbindende Programm und das baut daraus ein passendes Antwortpaket mit einem Sessionkey, der nur für diese eine Datenübertragung existiert. (Idealerweise)

Authentizität

Dabei wird geprüft, ob sich der Mailserver mit einem gültigen SSL-Zertifikat ausweist. An dieser Stelle wird es nun interessant. Unser Mailserver, kann wie die meisten Server, genau ein Zertifikat  benutzen, weil alle Domains auf seiner Hauptipadresse liegen. Für Emails ist das auch nicht tragisch, es geht ja nur um die Verschlüsselung des Transports. Also präsentiert der Mailserver sein gültiges Serverzertifikat, daß auf seinen Hostname ausgestellt ist, denn damit meldet sich der Server und damit weiß man, daß dies Zertifikat zum Host paßt. Soweit, so normal.

Die Experten

Jetzt gibt es Leute, die wollen wissen, ob sie abgehört werden, was ein naheliegendes Interesse ist. Deswegen prüfen sie, ob in dem Zertifikat das Ihnen angeboten wird, auch wirklich der Name des Mailserver drinsteht, mit dem sie sich verbinden wollen. Ist das nämlich nicht der Fall, könnte jemand an der Verbindung rumgespielt haben und sich als Man-in-the-Middle-Angreifer betätigt haben, um die Verbindung zu belauschen. Wenn ich jetzt auf Sicherheit und Authentizität wert lege, müßte ich aufhören und die EMail nicht zustellen, weil „irgendwas stimmt nicht“.

Damit Ihr mir folgen könnt, ein paar Beispiele :

$ dig mx bloggt-in-braunschweig.de
;; ANSWER SECTION:
bloggt-in-braunschweig.de. 21599 IN    MX    10 bloggt-in-braunschweig.de.

Das meint, daß die Emails für BIB.de  auf einem Mailserver mit dem Hostnamen „bloggt-in-braunschweig.de“ entgegengenommen werden. Verbindet man sich auf Port 25 dort hin, findet man das vor:

$ nc bloggt-in-braunschweig.de 25
220 s120.resellerdesktop.de ESMTP Exim 4.85_2 Sat, 27 Aug 2016 12:11:04 +0200

das meint, daß sich unser Mailserver mit „s120.resellerdesktop.de“ identifiziert, weil das sein Name ist. Entsprechend präsentiert er ein Zertifikat von s120.resellerdesktop.de . Das ist vollkommen ok so 🙂

Aber genau das ist, was einige Experten als den MITM-Angriff definiert haben, denn die haben erwartet, daß sich der Mailserver mit „bloggt-in-braunschweig.de“ meldet, was er nicht tut, weil er noch hunderte andere Domains beherbergt.

Jetzt der Catch 🙂

Statt jetzt aber die Verbindung zu trennen, wie man es bei einem MITM Angriff erwarten müßte, fällt der Expertenmailserver auf unverschlüsselte Kommunikation zurück und stellt die Email unverschlüsselt auf genau diesem Server zu!  Das ist FAIL² . Er hätte auch gleich das Zertifikat nehmen können, denn dann wäre die Email wenigstens verschlüsselt übers Netz gegangen, statt im Klartext.

Logik ist nicht jedermans Sache, wie es scheint 😀

Den Experten helfen…

Wenn man jetzt mit solchen Experten kommunizieren muß, ohne das man unverschlüsselte Emails haben will, kann man natürlich etwas tun, was allerdings mit Nachteilen daher kommt. Für den Augenblick sind diese aber vernachlässigbar.

Das Problem liegt ja in der Erwartungshaltung des sendenden Mailservers, der in unserem Beispiel bloggt-in-braunschweig.de haben wollte, aber s120.resellerdesktop.de bekommen hat. Der Name ist im DNS MX Eintrag hinterlegt, weil man so bei einem Domainumzug auf einen anderen Server lediglich einen Eintrag ändern muß. Der MX zieht quasi automatisch um.  Unsere Experten würden aber folgendes gerne sehen :

$ dig mx bloggt-in-braunschweig.de
;; ANSWER SECTION:
bloggt-in-braunschweig.de. 21599 IN    MX    10 s120.resellerdesktop.de

Wenn man also seinen MX auf den „echten“ Namen des Mailserver ändert, sind diese Expertenserver zufrieden und schicken einem ab sofort wieder reguläre TLS verschlüsselte EMails zu.

Man darf nur nicht vergessen, daß man bei einem Domainumzug auch den MX ändert, wenn der neue Mailserver anders heißt. Es ist also auch davon abhängig wie der Provider seine Umgebung betreibt.