Nicht wirklich «Responsible Disclosure»: Die Extraportion Spam über die Festtage

Wenige Tage bevor alle Systemadministratoren sich zu ihren Familien in die verdienten Weihnachtsferien zurückziehen, lässt SEC Consult die Bombe platzen: Die Antispam-Massnahmen der weitverbreitesten Mailserver können ausgehebelt werden. Sogar die Vortragsreise dazu ist schon geplant. Nur: Der weitverbreiteste Mailserver weiss davon nichts, seine User sind ungeschützt.

Ich führe eine Liste der von SMTP Smuggling betroffenen Mailsysteme (aktuell 12), über die SEC Consult berichtete (11), welche informiert wurden (3) und welche unabhängig davon gefixt wurden (2).

Wenn die Katze (=Admin-/Security-Team) ausser Haus ist, dann freuen sich die Spammer und Phisher. Auch wenn inzwischen die meisten Spams während den europäischen und nordamerikanischen Arbeitsstunden verschickt werden, die Stunden und Tage mit langen Reaktionszeiten sind immer noch beliebt.

Wenn man also die Wahl hat, eine Sicherheitslücke zu veröffentlichen, macht man das nicht kurz vor Feiertagen und dem Jahresendestress. Doch das Team von SEC Consult, einer vor allem im deutschsprachigen Raum tätigen Cybersecurity-Firma hat nach 6 Monaten Vorarbeit ausgerechnet den Montag vor Weihnachten dafür ausgewählt. Ohne zuvor wichtige Player zu informieren.

Uns bei DNIP liegt die richtige Kommunikation bei einem IT-Sicherheitsvorfall und der verantwortungsvolle Umgang mit der Veröffentlichung von Sicherheitsproblemen sehr am Herzen. Deshalb hat uns dieses Vorgehen doch etwas, sagen wir, überrascht. Was wissen wir?

[Update 13:45: SEC Consult reagiert auf die Vorwürfe.]

Die Sicherheitslücke: «SMTP Smuggling»

Jede Sicherheitslücke, die etwas auf sich hält, braucht heute einen catchy name. Heute heisst sie «SMTP Smuggling», das einschmuggeln (von zusätzlichen Mails) via SMTP (in Anlehnung an ein ähnliches Problem bei HTTP).

SMTP ist das Protokoll, mit dem Mailserver im Internet untereinander Mail austauschen. Also wenn beispielsweise eine Nutzerin bei GMX eine Mail an einen Hotmail-User schreiben will, sprechen GMX und Hotmail miteinander dieses «Simple Mail Transfer Protocol», welches 1982 in den frühen Jahren des Internet entstand. Wie viele andere Protokolle (nicht nur aus dieser Frühzeit) benutzt es menschenlesbare Kommandos, da dies die Fehlersuche ohne Zusatzsoftware massiv vereinfacht.

Programme, die als Mailserver—genauer, sogenannte Mail Transfer Agents oder MTA—zum Austausch untereinander SMTP nutzen, gibt es viele. Standarprogramme heissen z.B. Postfix, Exim oder Sendmail. Aber grosse Anbieter wie Google, Microsoft oder GMX haben häufig ihre eigenen Systeme programmiert.

Ein immer wieder auftauchendes Problem bei der (digitalen) Übermittlung von Informationen: Wo beginnen und enden eigentlich meine Nachrichten (bzw. die verschiedenen Teile davon)? Timo Longin von SEC Consult hat eine solche uneinheitliche Ende-Erkennung zwischen verschiedenen Mailservern gefunden. Mit ihr lässt sich eine Mail in einer anderen Mail mitschmuggeln: Der sendende Mailserver glaubt, dass es eine Mail sei, der Empfänger macht daraus aber zwei separate Nachrichten.

Für den Empfänger scheint es so, als ob diese geschmuggelte Mail eine legitime Mail vom Absenderserver sei, obwohl die Mailadresse des Absenders gefälscht ist. Damit kann man falsche Benutzernamen (z.B. “admin@” oder den Namen des Chefs) vorgeben; auf einem Mailserver, der mehrere Domains betreibt (wie Google, Microsoft oder eben GMX), kann man auch die Absenderdomain fälschen.

Erkannt werden diese Fälschungsversuche nur, wenn die Mailserver eine spezifische Reihe von Anforderungen erfüllt, und zwar alle davon. Ansonsten hat der Spammer freie Hand.

Und wie SEC Consult im eigenen Artikel festhält: Sie wussten davon! Sie wussten von 1.4 Millionen Mailservern, die Postfix einsetzen (mit mutmasslich Dutzenden oder Hunderten Millionen Nutzern) bei denen diese Sicherheitslücke immer noch besteht. Und sie wussten von 160’000 fehlerhaften Sendmail-Servern. Das bedeutet: bei beiden Programmen können solche Nachrichten untergejubelt werden.

«Responsible Disclosure», …

Timo Longin von SEC Consult hat laut eigenen Angaben im Juni herausgefunden, dass GMX und Microsoft (Exchange Online) solches SMTP-Schmuggelgut verschicken können und dass der Cisco Secure Email (Cloud) Gateway (so der unhandliche Name des Produkts, welches u.a. gegen Spam und Phishing schützen soll…) solche Nachrichten annimmt.

Im Juli wurden die drei Hersteller informiert; GMX und Microsoft behoben die Probleme im August. Cisco meinte Ende November, dass es dafür kein Sicherheitsupdate brauche.

Und am 4. Dezember wurde der Vortrag am 37. Chaos Communication Congress (“37C3”) inkl. Abstract angekündigt.

… ein seeeehr breiter Begriff

So weit, so gut: Die Hersteller hatten mehrere Monat Zeit und die Probleme gelöst oder sich entschieden, sie nicht lösen zu wollen.

Das ganze Internet ist wieder sicher. Das ganze Internet? Nein! Eine von unbeugsamen Admins bevölkerte Nische im Internet hört nicht auf, seine Emails nicht von GMX, Microsoft oder Cisco verwalten zu lassen. Sie betreiben ihre eigenen Mailserver.

Und wie SEC Consult im eigenen Artikel festhält: Sie wussten davon! Sie wussten von 1.4 Millionen Mailservern, welche mit der Software Postfix betrieben werden (mit mutmasslich Dutzenden oder Hunderten Millionen Nutzern) und sie wussten von 160’000 Sendmail-Servern. Und dass beiden Programmen solche Nachrichten untergejubelt werden können:

Und trotzdem wurde scheinbar niemand von den beiden Open-Source-Projekten informiert. Zumindest schreibt Wietse Venema, der Kopf hinter Postfix, in seiner sehr guten Zusammenfassung, dass er vor der Publikation nicht informiert worden sei.

Ähm.

Wenn Timo Longin und SEC Consult nicht gewusst hätten, dass Postfix angreifbar ist oder niemand erreichbar gewesen wäre, dann wäre diese fehlende Vorabinformation verständlich. So bleibt uns nur, den Kopf zu schütteln.

Timo Longin werden am nächsten Mittwoch am 37C3 neben technischen Fragen sicher auch unzählige Fragen erwarten, wieso nur die zentralen kommerziellen Hersteller informiert wurden. Ich hoffe, er hat gute Antworten dazu. Ich an seiner Stelle würde sogar 1-2 Folien des Vortrags für eine proaktive Erklärung reservieren. (Und eine davon wäre: “Sorry, tut uns leid; aber wir haben Folgendes daraus gelernt: 1. …; 2. …; 3. …”.)

Uns anderen bleibt zu hoffen, dass die betroffenen Admins sich jetzt am letzten Tag vor den Ferien noch reinknien und uns so eine Spam- und Phishing-Welle ersparen. Danke, liebe Mailadmins!

Danke

Ich möchte an dieser Stelle Jonas Schäfer, Suran/Morten Linderud und dem ganzen Fediverse für Informationen zum Thema danken. Und natürlich Wietse Venema für die Entwicklung und den Unterhalt von Postfix, einem Mailserver, den auch ich einsetze; und seine kurze und knappe Zusammenfassung der Lücke sowie eines Workarounds. (Selbstverständlich auch Timo Longin und SEC Consult für das Finden der Sicherheitslücke. Aber bitte lernt daraus. Danke!)

[Neu 14:15] An dieser Stelle danke ich auch Hanno Böck, der seit gestern an einem Tool («smtpsmug») bastelt, mit dem man testen kann, ob der eigene Mailserver verwundbar ist.

Update um 13:45

Vor einer Stunde erreichte mich die Nachricht, dass SEC Consult ihren Artikel um Hintergrundinformationen ergänzt habe: Das «Update on SMTP smuggling and responsible disclosure».

Darin legt SEC Consult dar, dass sie einen Teil der Aufgabe dem CERT/CC, dem in den USA angesiedelten Koordinationszentrum der Computer Emergency Response Teams (deutsch: Computersicherheits-Ereignis- und Reaktionsteam) und deren VINCE-Plattform übergeben hätten. Über diese sei, so SEC Consult, die Diskussion mit Cisco erfolgt.

Im Rahmen dieser Diskussion auf der VINCE-Plattform des CERT/CC mit mehreren Herstellern (SEC Consult äussert sich dazu nicht genauer), hätte niemand etwas gegen die Veröffentlichung gehabt, schreibt SEC Consult weiter. (Cisco wollte das Problem laut Darstellung weder als Fehler anerkennen, noch seine Kunden informieren.) Im Rahmen des bevorstehenden 37C3-Vortrags sei am 5. Dezember auch das CERT-Bund des BSI informiert worden.

Aufgrund dieser Äusserungen sei SEC Consult davon ausgegangen, dass nichts gegen die Publikation spreche. Sie würden sich aber zukünftig mehr Gedanken über die Auswirkungen machen, wenn sie mit betroffenen Herstellern reden würden. Und sie wollten auch die Zusammenarbeit und Kommunikation mit allen Beteiligten verbessern.

Eigene Zusammenfassung des Update on SMTP smuggling and responsible disclosure aus dem SEC Consult-Blogbeitrag

Offen bleibt:

1. Wieso über diesen Kanal die Entwickler von Postfix (und mutmasslich Sendmail) nicht erreicht wurden.
2. Und ob SEC Consult nicht eine direkte Kontaktaufnahme hätte anstreben sollen. (Die Kontaktdaten z.B. von Wietse Venema sind auf der Postfix-Webseite nur schwer zu übersehen.)
3. Aufgrund der Automatisierung der Tests wäre es ein Leichtes gewesen, auch noch weitere verbreitete Systeme zu testen. Wieso war die Liste nicht länger? [Neu 2023-12-23]
4. Wieso ist die Firmenkultur so gestaltet, dass solches Verhalten toleriert (mutmasslich sogar gefördert) wird? [Neu 2023-12-25, basierend auf Input von Jonas Schäfer im Fediverse]

Insbesondere bei den ersten beiden Punkten hätte ich klarere Antworten erwartet.

Ich bin gespannt, wie sich das entwickeln wird.

Update 2023-12-26

In der Nacht vom 22. auf den 23. Dezember (MEZ) fand noch eine Diskussion auf der Postfix-Users-Mailingliste statt, dankenswerterweise initiiert von Tim Weber und sehr rasch kommentiert von Wietse Venema (Autor der Postfix-Mailsoftware), Vijay S Sarvepalli (vom CERT/CC) und Weiteren. Hier mein Versuch, die Diskussion zusammenzufassen:

• Das CERT/CC habe die Angriffe nicht verstanden, möglicherweise, weil SEC Consult nicht klar genug kommuniziert habe oder SEC Consult die Aufgabenteilung innerhalb der Mailserver selbst nicht verstanden habe, da sie gegen Live-Systeme getestet hätten. Resultat: (a) CERT/CC wusste nicht, wie der Angriff funktioniert, (b) dem CERT/CC war nicht klar, dass der Schutz von SPF gegen Absenderfälschung übertölpelt werden könne und (c) dem CERT/CC war auch nicht klar, dass erst spezifische Kombinationen mehrerer Mailserver zum Verhängnis führten. Entsprechend sei der Impact unterschätzt worden.
• Das Postfix-Team sei vorgängig vom CERT/CC-Team per Email informiert worden (eine genauere Zeitangabe wird nicht erwähnt).
• Dem Postfix-Team sei zu keinem Zeitpunkt klar gewesen, dass man damit SPF übertölpeln könne und der Angriff zwei verschiedene Mailserver benötige.
• Zusätzlich wird betont, dass, jetzt, wo man wüsste, wie es funktioniert, SMTP Smuggling nicht nur ein Problem der erwähnten Plattformen sei und in gewissen Zusammenhängen auch den eigentlich stärkeren DKIM-Signaturschutz austricksen könnten.

Eine mögliche Interpretation aus diesem Mailverkehr könnte sein, dass SEC Consult der volle Impact dieser Lücken erst sehr spät (im Rahmen der Vortragsvorbereitung?) klar wurde. Aber auch dann wäre eine kurzfristige Vorab-Information der Betreiber und Entwickler besser gewesen als erst zur Veröffentlichung des Blog-Eintrags.

Wietse Venema wünscht sich, dass nun, da die Katze aus dem Sack sei, die Betroffenen (Mailprovider, Hersteller, …) möglichst rasch und breit informiert werden sollten. Und das CERT/CC hofft, ihre Prozesse im Umgang u.a. mit Multi-Vendor-Fällen und Open-Source-Software weiter zu verbessern.

Update 2023-12-28

Laut einem (Livestream-)Augenzeugen stellte Timo Longin das gestern am 37C3-Vortrag wie folgt dar:

1. Sie (SEC Consult) hätten CERT/CC informiert.
2. CERT/CC hätte das Problem unterschätzt.
3. CERT/CC hätte schlecht mit Postfix kommuniziert; auch Sendmail hätte aufgrund der CERT/CC-Information kein Interesse gezeigt.
4. Auf die Rückfrage, ob sie (SEC Consult) publizieren können, hätte CERT/CC grünes Licht gegeben, mit der Bitte, nach der Publikation informiert zu werden.

Punkte 1 und 2 werden im obigen Mailinglistenverkehr bestätigt. Es kann aber gut sein, dass die Nachricht ans CERT/CC weniger klar und eindringlich war als der Blogpost; das CERT/CC spricht davon, dass weder die Information der Umgehung der Anti-Spam-Massnahmen noch die Notwendigkeit zweier verschiedener Mailserver klar geworden sei. Also scheint definitiv eine Miskommunikation stattgefunden zu haben. Vielleicht erfahren wir irgendwann mehr darüber.

Die Frage aber, wieso SEC Consult nur auf drei kommerzielle Hersteller/Anbieter direkt zugegangen ist, bleibt unbeantwortet. Rein an der Grösse kann es nicht liegen; da via Postfix wohl mehr Mailkonten verwaltet werden als über GMX.

Den Vortrag gibt es inzwischen online zum Nachschauen. [Neu 15:00]

Ein (englischer) Überblick über 12 von SMTP Smuggling betroffenen Mailsysteme und ihren Status findet sich hier, inklusive wörtlicherer Zitate aus den Mails.