SpamChannel: Spoofing-E-Mails von über 2 Millionen Domains senden und praktisch zu Satan werden [PDF]

 (media.defcon.org)
1 Punkte von GN⁺ 2023-09-24 | 1 Kommentare | Auf WhatsApp teilen
  • Die DEFCON-31-2023-Präsentation SpamChannel behandelt ein Spoofing-Problem, das mehr als 2 Millionen Domains betrifft, ausgehend von dem Versuch, E-Mails über Cloudflare Workers zu versenden
  • Das zentrale Experiment beginnt damit, den E-Mail-Versand nicht manuell, sondern programmatisch abzuwickeln und ihn in den Worker-Bereitstellungsablauf einzubinden
  • Cloudflare Workers werden als auf JavaScript, TypeScript und WASM basierende serverlose Computing-Umgebung vorgestellt
  • Der grundlegende Ablauf besteht darin, mit npm create cloudflare@latest ein Projekt zu erstellen und es mit npx wrangler deploy bereitzustellen
  • Der Hinweis zum Versand von E-Mails aus Workers ergibt sich aus dem Cloudflare-Blogbeitrag zur MailChannels-Integration

Ausgangspunkt der SpamChannel-Präsentation

  • SpamChannel ist ein auf der DEFCON 31 2023 von Marcello Salvati(@byt3bl33d3r) vorgestelltes PDF, das das Thema behandelt, Spoofing-E-Mails von mehr als 2 Millionen Domains zu senden
  • Ziel der Präsentation ist es, den E-Mail-Versand unter den folgenden Bedingungen umzusetzen
    • E-Mails programmatisch senden
    • Über einen Cloudflare Worker senden
  • Im Zusammenhang mit rechtlicher Verantwortung ist ein Haftungsausschluss enthalten: „Begeht keine Verbrechen“

Cloudflare Workers und Hinweise zum E-Mail-Versand

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-09-24
Meinungen auf Hacker News

  • Video des Vortrags: https://www.youtube.com/watch?v=NwnT15q_PS8
    Oder auch hier. In meinem Firefox funktionierte das Videoformat nicht, aber mit VLC ließ es sich abspielen: https://media.defcon.org/DEF%20CON%2031/DEF%20CON%2031%20vid...

  • SPF ist auf noch viel mehr Arten kaputt, als in diesem Vortrag behandelt wird. Aus meiner Sicht als Engineer für E-Mail-Sicherheitsverbesserung/Zustellbarkeits-Support lautet der Rat immer, sich stärker auf DKIM + DMARC als auf SPF zu konzentrieren.
    Aus Legacy-Gründen ist SPF weiterhin notwendig, aber man sollte sich weder bei der Zustellbarkeit noch beim Schutz vor Impersonation darauf verlassen.
    Folie 54 sagt, dass DKIM + DMARC gegen diesen Angriff nicht helfen, aber das ist nicht ganz richtig.
    Eine DMARC-Policy p=reject kann man erst dann sicher aktivieren, wenn DKIM für alle delegierten Absender eingerichtet ist; sobald man dieses Niveau erreicht hat, kann man beginnen, Drittanbieter-Absender per neutralem Modifier ? in SPF aus SPF herauszunehmen.
    Zum Beispiel wird aus v=spf1 include:relay.mailchannels.net ~all dann v=spf1 ?include:relay.mailchannels.net ~all.
    Dadurch werden E-Mails von MailChannels bei DMARC-fähigen Empfängern per SPF neutral behandelt und müssen DKIM verwenden; auch ältere Legacy-Maildienste sollten ein neutrales Ergebnis akzeptieren.
    Das ist keine perfekte Lösung, aber E-Mail kann ohnehin nie zu 100 % vertrauenswürdig oder sicher werden.

    • Dann frage ich mich, was genau das Problem mit SPF ist. Da das Spoofing von Quell-IP-Adressen bei TCP ziemlich schwierig ist, habe ich mich immer gefragt, welchen Vorteil DKIM gegenüber SPF hat.
      Ich habe SPF so konfiguriert, dass nur $myIP erlaubt ist. Um Spam unter meinem Domainnamen zu verschicken, müsste man zuerst meinen ISP oder Registrar kompromittieren, und an dem Punkt könnte man auch TLS-Zertifikate für meine Domain bekommen.
      Selbst bei großen Organisationen, die mehrere sendende Systeme auf eine Allowlist setzen müssen, verstehe ich nicht, wie man sich als einer der legitimen SPF-Absender ausgeben soll, wenn DKIM-Records nicht gefälscht werden können.
      Wenn man wie im eingereichten Vortrag öffentlich von jedem nutzbare IP-Bereiche auf die Allowlist setzt, ist das einfach eine dumme Konfiguration.
      Um den gesamten Mailaustausch zu fälschen, bräuchte man für eine E-Mail von ein paar Bytes Traffic im Terabyte-Bereich, und wenn STARTTLS erzwungen wird, ist es unmöglich.

  • Wir verwenden in Produktion Cloudflare Workers + MailChannels. Das ist beunruhigend.
    Wir waren ohnehin schon dabei, von CF Workers auf echte Server umzuziehen, aber jetzt sieht es so aus, als müssten wir auch MailChannels verlassen.
    Das Sicherheitsrisiko ist die Bequemlichkeit nicht wert.

    • Seit Juni 2023 kann man über Workers keine E-Mails mehr via MailChannels senden, wenn man nicht einen _mailchannels-Record im DNS veröffentlicht.
    • Zur Klarstellung: Das Problem hierbei ist, dass MailChannels Absender nicht authentifiziert, also nicht prüft, ob sie verifizierte Besitzer der sendenden Domain sind. CF Workers sind nicht das Problem.

  • „Für alle E-Mails ohne DKIM-Signatur, die von einer Domain stammen, die DKIM implementiert hat, ein Banner anzeigen“ ist nach meinem Verständnis größtenteils unmöglich. Denn es gibt keine zuverlässige Methode, sicher festzustellen, ob eine Domain DKIM implementiert hat.
    Theoretisch kann man eine DNS-Abfrage auf "_domainkey.example.com" machen und prüfen, ob NXDOMAIN oder NOERROR zurückkommt. Letzteres bedeutet normalerweise, dass es Subdomains gibt, und könnte daher heißen, dass im DNS einige DKIM-Schlüssel vorhanden sind.
    Aber man kennt den Selector-Namen nicht, und man weiß auch nicht, ob dieser Schlüssel aktiv ist oder erst später aktiviert werden soll.
    Eine Domain kann mehrere authentifizierte Absender haben, von denen einige DKIM-Signaturen verwenden und andere nicht.
    Nicht alle DNS-Server halten sich korrekt an die Standards, daher funktioniert auch die Unterscheidung zwischen NXDOMAIN und NOERROR nur grob.

    • Ein Anbieter, der einen statistisch signifikanten Anteil des Mail-Traffics sieht, kann alle oder fast alle DKIM-Selectoren sehen.
      Der zitierte Satz scheint zu bedeuten, dass man E-Mails von MailChannels ohne DKIM-Signatur ablehnen sollte.

  • „Die Hauptkunden von MailChannels sind Webhosting-Anbieter, die die Domains der von ihnen versendeten E-Mails nicht besitzen“ ist die schlechteste Ausrede, die ich seit einer Weile gehört habe.
    Webhosting-Anbieter „besitzen“ die gehosteten Domains normalerweise nicht, wissen aber sehr genau, welche Domains sie hosten. Domains auf Kundenkonten/Verzeichnisse zu routen, ist der Kern von Webhosting.
    Nötig wäre nur eine Integration wie bei cPanel, die die Domainliste meldet und jede Domain an einen zufällig generierten Schlüssel bindet.
    All das kann und sollte automatisiert werden, ohne Endnutzer zu belästigen.

    • Was ist mit Mailinglisten? Mit Mail-Weiterleitung?

  • Es wäre gut, wenn sich die DMARC-Spezifikation so weiterentwickeln würde, dass man für die Validierung nur DKIM verwenden kann und nicht SPF. Leider schlagen Dinge wie Google-Calendar-Einladungen immer noch bei DKIM fehl

    • In der nächsten DMARC-Version wird sehr wahrscheinlich eine Option enthalten sein, SPF aus der DMARC-Validierung auszuschließen. Das Google-Team treibt das auf der IETF-DMARC-Mailingliste voran:
      https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukL...
      Ich halte das für eine sehr gute Idee, weil Domaininhaber damit trotz DMARC festlegen können: „Der Mechanismus, der den Traffic meiner Domain wirklich authentifiziert, soll ausschließlich DKIM sein“
      In der Branche gibt es viele Möglichkeiten, Schwächen von SPF und DMARC zu umgehen, etwa SPF-Makros, die die Authentifizierung dynamisch anhand von Kriterien anpassen, die erst zum Zeitpunkt der SPF-Auswertung bekannt sind
      Aber keine Umgehung ist besser, als zu sagen: „Bitte verwendet für meine Domain nur DKIM“

  • Ich habe kürzlich selbst die E-Mail-Einrichtung für meine Domain durchgemacht, und besonders frustrierend war ein ISP, der festgelegt hat: „Wenn man von eigener Hardware E-Mails senden will, braucht man ein Geschäftskonto.“ Solche Dinge machen mich wirklich wütend
    Ich bemühe mich verbissen, ein verantwortungsvolles Mitglied des Netzwerks zu sein, und habe mich bis zum aktuellen Stand der Technik durchgearbeitet, um mein System korrekt einzurichten
    Und dann gibt es solche Leute nicht nur, sondern sie betreiben das Ganze praktisch leichtfertig wie ein Open Relay, und fast die Hälfte des Internets zahlt den Preis dafür. Das ist absurd

  • Kurz gesagt: Es geht darum, dass in vielen SPF-Records enthaltene Open Relays gefunden wurden

    • Von den 2 Millionen Domains, die sich per SPF selbst geöffnet hatten, hatten weniger als 1.000 DKIM/DMARC-Records eingerichtet, und selbst wenn DKIM eingerichtet und dann liegengelassen wurde, geht es bei Gmail weiterhin als authentifiziert durch
    • Es ist noch schlimmer. Die Plattform selbst hat nicht einmal versucht, Domaininhaberschaft zu verifizieren, sodass man im Namen beliebiger Personen senden konnte
    • Streng genommen ist es kein Open Relay. Wenn MailChannels Spam und Phishing nicht aggressiv kontrollieren würde, könnte es im Internet nicht existieren
      Der DEFCON-Vortrag hat nicht die Existenz eines riesigen Lochs bewiesen, sondern etwas gezeigt, das es seit den Anfangstagen von Internet-E-Mail gibt
      Ohne Nachrichtensignaturen wie S/MIME oder DKIM lässt sich die Absenderdomain nicht ausreichend authentifizieren
      Selbst mit DKIM ist durch DKIM-Replay-Angriffe weitreichender Missbrauch möglich

  • Interessant ist, wie sich ARC-Header auf den Spam-Score auswirken. Kann ich als Betreiber eines privaten Mailservers die Zustellrate erhöhen, indem ich meiner E-Mail einfach einen Satz bedeutungsloser ARC-Header hinzufüge?

    • Ich würde gerne sagen, dass dem nicht so ist. Denn wenn es wahr wäre, wären vermutlich alle meine Posteingänge bei verschiedenen Anbietern voller Spam
      Organisierte und sachkundige Spammer dürften all diese Dinge längst durchleuchten und sie mit Sicherheit für Durchbrüche ausnutzen
    • In der E-Mail-Branche gilt ARC nicht als vollständige Methode, um die Spamfilter großer Empfänger zu umgehen. Der DEFCON-Vortragende war nicht ausreichend vorbereitet, um ein solches Urteil zu fällen

  • Das scheint schon im Mai 2022 festgestellt worden zu sein: https://news.ycombinator.com/item?id=30533032

    • Der CEO soll gesagt haben:
      „Wir verfügen über umfassende Fähigkeiten zur Spam- und Phishing-Erkennung und können Missbrauch handhaben“
      Ach so :D