Suche
Close this search box.

Nicht wirklich «Responsible Disclosure»: Die Extraportion Spam über die Festtage [3 Updates]

KI-generiertes Bild eines Weihnachtsbaums in Österreich mit Spam als Geschenke

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.

Die Anforderungen

Der nächste Absatz richtet sich an Mailadministratoren. Für alle anderen: Wenn die eingesetzte Mailsoftware betroffen ist, sind mit hoher Wahrscheinlichkeit Gegenmassnahmen nötig.

Nur wenn der Absender SPF und DKIM und DMARC (mit einer strikten Policy) aktiv hat und der Empfänger Mails mit SPF/DKIM/DMARC-Problemen zuverlässig ablehnt (also, nicht nur etwas am Spam-Score dreht), dann ist man von der Lücke nicht betroffen. Ansonsten bitte hier nachbessern oder die Software/Konfiguration des Mailservers aktualisieren.

«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.

Screenshot von 37c3-Eventkalender

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:

Screenshot von der SEC Consult-SMTP-Smuggling-Seite

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:

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.

dnip.ch mit Deiner Spende unterstützen

Wir wollen, dass unsere Inhalte frei verfügbar sind, weil wir es wichtig finden, dass möglichst viele Menschen in unserem Land die politischen Dimensionen der Digitalisierung erkennen und verstehen können.

Damit das möglich ist, sind wir auf deine Unterstützung angewiesen. Jeder Beitrag und sei er noch so klein, hilft uns, unsere Aufgabe wahrzunehmen.

5 Antworten

  1. Ich dachte eigentlich, die Geschichte hätte uns gelehrt, dass SysAdmins über die Feiertage an die Stätte Ihrer Geburt zurückkehren, um dort die IT Probleme ihrer Eltern zu lösen
    Ferien, was ist das? 😉

  2. «SMTP Smuggling» ist kein catchy Name für eine neue Sicherheitslücke (wie zum Beispiel «Heartbleed»), sondern Smuggling ist ein gängiger Begriff für diese Art von Angriffen.

    Siehe auch:
    https://en.wikipedia.org/wiki/HTTP_request_smuggling

    Und Verwerfen ist hier auch ein falscher Begriff. Man darf E-Mails nicht verwerfen. Man darf sie ablehnen (reject). Das ist ein entscheidender Unterschied, weil man jede Mail, die man annimmt, weitergeben muss. Man darf Mails nicht annehmen und dann löschen.

    1. Danke für das Feedback.

      1. Ich finde, dass bereits «HTTP Request Smuggling» schon ein Catchy Name ist; habe die Herkunft aber noch dokumentiert.
      2. «Verwerfen» habe ich angepasst. Klar sollte man Emails mit einem 5xx-Code refüsieren, wenn das möglich ist. (Aber bei unerkannten Malformed Requests (~Undefined Behavior) kann das schwierig werden: Wenn z.B. der Mailserver auf das Fake-Ende <LF>.<LF> schon fälschlicherweise die erste Hälfte mit 250 “bestätigt” hat, wird der Absender dies möglicherweise glauben, auch wenn die zweite Hälfte dann aufgrund eines Inhaltsfilters als Spam abgelehnt wird.)
      1. Smuggling-Angriffe sind auch durch einen anderen Grund relevanter als früher.
        Früher waren die Protokolle einfach gestrickt: Man hat eine TCP-Verbindung aufgebaut und dann einen Request (z.B. HTTP oder SMTP) geschickt und eine Antwort bekommen. Dann war die Sache gut.
        Heute macht man TLS, Zertifikatsprüfungen, DNS-Prüfungen (insbesondere bei Mail) usw. Das heisst eine neue Verbindung für jeden Request wäre ganz schön teuer. Daher gehen die Protokolle immer mehr in die Richtung, dass man eine Verbindung aufbaut und dann mehrere Requests hintereinander über derselbe Verbindung verschickt und verarbeitet. Dadurch werden Smuggling-Angriffe überhaupt erst möglich.

        Danke zurück für die guten Artikel und schöne Feiertage!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Weitere Beiträge

Rage Against The Machine

Es geht um drei Millionen elektrische Zahnbürsten. Sie sollen die Website einer Schweizer Firma angegriffen und für Stunden vom Netz

Weiterlesen »