Wie wir unseren Mailserver absichtlich kaputt gemacht haben
Ein gezielt unsicherer Mailserver als Lernobjekt. Wir zeigen, wie man E-Mail-Sicherheit anhand realer Fehlkonfigurationen verständlich macht.
Wenn wir mit unseren Kunden sprechen, merken wir schnell: E-Mail-Sicherheit ist ein sehr individuelles Thema. Je nach Hintergrund, Infrastruktur und Art der sensiblen Daten unterscheiden sich die Anforderungen deutlich. Also beschlossen wir, einen gemeinsamen Ausgangspunkt zu schaffen – und haben einen Mailserver eingerichtet, der so falsch konfiguriert ist, dass niemand bezweifeln kann: Dieser Server ist vollkommen unsicher.
Die Grundlage: Ein geeigneter Server
Was braucht man als Erstes für einen katastrophal konfigurierten Mailserver? Richtig – einen Server. Wir fanden, dass eine einfache Serverinstanz bei AWS, dem Cloud-Dienst von Amazon, perfekt geeignet ist. Die Instanz bringt eine statische IP-Adresse mit, die im DNS-System auffindbar ist. Wir installierten darauf Postfix – einen Open-Source-Mail Transfer Agent – unter Ubuntu Server. Kurz darauf war der Server betriebsbereit.
Was ist ein „schlechter“ Mailserver?
Jetzt wird’s spannend: Welche Konfigurationselemente bieten eigentlich Sicherheit – und wie können wir sie kaputt machen? Nach nunmehr über zehn Jahren im Austausch mit SMTP-Servern weltweit haben wir jedes nur erdenkliche Fehlverhalten gesehen. Und auch wenn das vielleicht nicht Ihr Alltag ist, dürften Ihnen einige dieser Fehlkonfigurationen vertraut vorkommen. Erinnern Sie sich an die Warnmeldung Ihres Browsers: „Möglicherweise besteht ein Sicherheitsrisiko“?
Der Kleingedruckte Hinweis darunter gibt meist Aufschluss über Probleme mit dem TLS-Zertifikat der Zielseite.
Da auch E-Mail-Server TLS-Zertifikate verwenden, haben wir hier einen Ausgangspunkt. Je nach Browser erscheinen Fehler wie (Beispiele aus Firefox mit Kurzbeschreibung):
UNKNOWN_ISSUER– Der Aussteller ist unbekannt, das Zertifikat ist selbst signiert oder Zwischenzertifikate fehlen.EXPIRED_CERTIFICATE– Das Zertifikat ist abgelaufen.BAD_CERT_DOMAIN– Der Zertifikatsname passt nicht zur aufgerufenen Domain.WEAK_SIGNATURE_ALGORITHM– Der Algorithmus zur Signaturerstellung ist unsicher.
Ihr Browser warnt Sie selbstverständlich vor solchen Problemen – aber was macht Ihr E-Mail-Client? Um das herauszufinden, müssen wir ihm einen Grund liefern.
Definitiv schlecht: Abgelaufen und nicht vertrauenswürdig
Wir erstellen unser Zertifikat des Grauens mit OpenSSL – einer Open-Source-Bibliothek für TLS. Mit nur einem Befehl lösen wir sämtliche Fehler aus:
$ faketime '1970-01-01 00:00:00' openssl req -newkey rsa:1024 -x509 -sha1 -days 1 -nodes -out ssl-cert.crt -keyout ssl-cert.key -subj "/C=DE/ST=Saxony/L=Chemnitz/O=CA/OU=CA/CN=abc.xy"
Normalerweise erzeugt der Befehl req eine Zertifikatsanfrage, die bei einer Zertifizierungsstelle signiert wird. Mit -x509 signieren wir selbst – und sind damit als Aussteller unbekannt. Das reicht für den FehlercodeUNKNOWN_ISSUER.
Mit -subj geben wir die Domain des Zertifikats an. Wir wählen bewusst nicht den echten Servernamen („evaluation.comcrypto.de“), sondern die Fake-Domain „abc.xy“ – und erhalten damit den Fehler BAD_CERT_DOMAIN.
Dann setzen wir die Gültigkeit auf ein längst vergangenes Datum: Mit faketime simulieren wir die Zertifikatserstellung zum 01.01.1970. Da die Gültigkeit nur einen Tag beträgt (-days 1), ist das Zertifikat seit über 50 Jahren abgelaufen – Fehler EXPIRED_CERTIFICATE.
Noch schlimmer: Gebrochene Krypto-Algorithmen
Bisher war unser Zertifikat aufgrund der fehlerhaften Domain und fehlenden Vertrauenswürdigkeit problematisch. Doch selbst wenn ein Absender (z.B. Ihr E-Mail-System) wüsste, mit wem er kommuniziert – wie kann er sicherstellen, dass niemand mithört? Hier geht es vom Authentifizierungsteil zum Verschlüsselungsteil von TLS.
Denken Sie an Ihre Wohnungstür. Sie schützt Ihre privaten Daten vor unerwünschtem Zugriff. Was tun Sie morgens beim Verlassen der Wohnung? Zwei Mal absperren? Nur ins Schloss ziehen? Oder gar den Schlüssel unter die Fußmatte legen? Was auch immer Ihre Routine ist – die Tür einfach offen stehen lassen würden Sie sicher nicht.
Bei comcrypto sperren wir grundsätzlich zwei Mal ab: Der Versand über MXG ist nur erlaubt, wenn die TLS-Verbindung den Krypto-Empfehlungen des BSI (Bundesamt für Sicherheit in der Informationstechnik) entspricht. So stellen wir sicher, dass alle Übertragungen ein Mindestmaß an Sicherheit einhalten – unabhängig vom Inhalt oder Empfänger.
Wie sorgen wir nun für gebrochene Kryptografie? Einige Parameter des TLS-Zertifikats geben das vor. In unserem OpenSSL-Befehl erzeugen wir mit -newkey rsa:1024 einen 1024-Bit-Schlüssel. Das BSI empfiehlt mittlerweile mindestens 3000 Bit – unser Schlüssel ist definitiv zu kurz.
Mit -sha1 erzwingen wir den veralteten Hash-Algorithmus SHA1. Da dieser nicht kollisionsresistent ist, sind Fälschungen möglich – was zum Fehler WEAK_SIGNATURE_ALGORITHM führt.
Nun ist unser Zertifikat in jeder Hinsicht kompromittiert. Fehlt nur noch der TLS-Handshake: Währenddessen gibt der Server an, welche TLS-Version er unterstützt. Wir konfigurieren ihn so, dass er nur höchstens TLS 1.1 unterstützt – veraltet, unsicher, laut BSI unbedingt nicht mehr zu verwenden.
Erkennt Ihr E-Mail-System unseren kaputten Mailserver?
Da Sie gerade diesen Artikel lesen, gehören Sie vermutlich nicht zu den Menschen, die ihre Haustür im wirklichen Leben offen lassen. Aber wie sieht es mit Ihrem aktuellen E-Mail-System aus? Überprüfen Sie es! Wie sie unseren fehlerhafter Mailserver erreichen können, erfahren sie hier.
Wenn Ihr E-Mail-System nur eines der von uns eingebauten Sicherheitsprobleme erkennt, verweigert es den Verbindungsaufbau zu unserem Server, und Ihre E-Mail wird überhaupt nicht gesendet. Aber wenn Ihre E-Mail gesendet wird... Nun, wir freuen uns darauf, von Ihnen zu hören!
