Am 1. Dezember 2021 begannen wir, sporadische Berichte über Zustellungsfehler von proton.me-Adressen an Gmail zu erhalten. Dies ging einher mit einem dramatischen Rückgang der Domain-Reputation von proton.me, wie über die Gmail Postmaster Tools ersichtlich, und einem Anstieg des Sendens von bekannten schlechten IP-Adressen.
Es war sowohl anhand der schlechten Sendungs-IPs (meist in Russland) als auch unserer eigenen Metriken klar, dass die Spam-E-Mails, die die Domain-Reputation von Proton Mail schädigten, nicht von unseren Servern kamen. Allerdings zeigten die Postmaster Tools an, dass alle E-Mails, die von proton.me bei Gmail eingingen, „vollständig authentifiziert“ waren, einschließlich der betrügerischen.
Dies führte wiederum dazu, dass die betrügerischen E-Mails in Googles Algorithmus zur Bestimmung der Domain-Reputation einflossen und diese so weit senkten, dass auch die Zustellbarkeit legitimer E-Mails von unseren Servern beeinträchtigt wurde.
Wir vermuteten einen DKIM-Replay-Angriff, bei dem eine einzelne Spam-E-Mail, die ursprünglich von Proton Mail gesendet wurde, an viele Gmail-Nutzer weitergeleitet wurde, um unsere Zustellbarkeit und Reputation auszunutzen und Googles Anti-Spam-Maßnahmen zu umgehen. Zu einem Zeitpunkt waren etwa 98% der E-Mails, die Gmail als von Proton Mail kommend empfing, tatsächlich Spam, was bedeutet, dass die Spammer eine Menge an E-Mails versendeten, die dem 50-fachen unseres normalen ausgehenden Verkehrs zu Google entsprach.
Wir wechselten sofort unseren DKIM-Signaturschlüssel, um (vorübergehend) zu verhindern, dass die E-Mails DKIM bestanden und kontaktierten Googles Counter-Abuse-Team, das schnell eine Lösung für die Spamfilter von Gmail implementierte und die legitime E-Mail-Zustellung wiederherstellte.
E-Mails, die von proton.me, proton.me/mail und eigenen Domains gesendet wurden, waren von diesem Problem nicht betroffen.
Wie DKIM-Replay-Angriffe funktionieren
Bevor wir erklären können, wie dies passiert ist, müssen wir zuerst darstellen, wie E-Mails strukturiert, zugestellt und im Internet authentifiziert werden.
E-Mails sind MIME (Multipurpose Internet Mail Extensions)-Nachrichten, bestehend aus Kopfzeilen und Abschnitten, die den Nachrichtentext und möglicherweise Anhänge enthalten. Die Kopfzeilen enthalten einige Felder, die jedem E-Mail-Nutzer bekannt sind (An, CC, Von, Betreff), aber auch versteckte Informationen, die zur Authentifizierung der E-Mail verwendet werden.
Jedoch werden keine der Kopfzeilen tatsächlich verwendet, um die E-Mail an ihr endgültiges Ziel zu leiten. Der Empfänger und Absender der E-Mail werden separat als Teil des E-Mail Umschlags angegeben, was eine sehr passende Metapher ist. Wenn die E-Mail-Nachricht inklusive ihrer Kopfzeilen einer Papierbrief ist, dann enthält der E-Mail-Umschlag, in den der „Brief“ gelegt wird, die Empfänger- und Rücksendeadressen, wie ein echter Umschlag.
Der entscheidende Punkt ist, dass der Empfänger auf dem Umschlag nicht mit einem Empfänger in den An– oder CC-Kopfzeilen übereinstimmen muss — typische Beispiele dafür sind E-Mails, die per BCC gesendet oder an „unbekannte Empfänger“ adressiert sind.
Vielleicht noch überraschender ist, dass der Umschlagabsender nicht mit der E-Mail Von-Kopfzeile übereinstimmen muss. Dies hat auch einen legitimen Zweck — Massenmailings geben oft eine andere „Rücksendeadresse“ als die Von-Kopfzeile an, um Zustellungsprobleme zu analysieren oder Drittanbieterdienste zum Versenden von E-Mails zu nutzen. Diese Flexibilität ist auch wichtig, um Nutzern das Weiterleiten von Nachrichten von einem Postfach zu einem anderen zu ermöglichen.
Diese Rücksendeadressen werden über SPF (Sender Policy Framework) authentifiziert, das das Senden von Nachrichten durch spezifische Server oder IP-Adressen mittels spezieller DNS-Einträge autorisiert. Aber dies validiert nur den Server, der die E-Mail sendet; es stellt nicht sicher, dass der Inhalt der E-Mail nicht manipuliert wurde. Dafür benötigen wir DKIM (DomainKeys Identified Mail).
DKIM verwendet ebenfalls spezielle DNS-Einträge, aber anstatt einer Liste von IP-Adressen enthalten diese Einträge Schlüssel, die zum Signieren des E-Mail-Inhalts und bestimmter zugehöriger Kopfzeilen verwendet werden. Die resultierende kryptografische Signatur wird der Nachricht als spezielle Kopfzeile hinzugefügt, und der Empfänger-Mailserver oder Client kann diese Signatur bei der Zustellung gegen den E-Mail-Inhalt überprüfen. Aber die DKIM-Domain in der Signatur kann auch anders sein als die im Von-Header in der Nachricht selbst. Wenn die DKIM-Signatur verifiziert wird, bestätigt dies nur, dass die Nachricht durch die Mailserver der signierenden Domain gegangen ist und seitdem nicht verändert wurde, nicht dass die Nachricht von dort stammt, wo sie behauptet.
Um tatsächlich zu überprüfen, ob die Domain im From Header die Nachricht gesendet hat, benötigen wir DMARC (Domain-based Message Authentication, Reporting, and Conformance). Um DMARC zu bestehen, muss eine E-Mail entweder SPF oder DKIM bestehen, und die Domain im From Header muss mit der entsprechenden SPF- oder DKIM-Domain „abgestimmt“ sein. Der From Header ist das, was der Nutzer letztendlich sieht, daher ist DMARC ein entscheidender Teil, um sicherzustellen, dass eine E-Mail tatsächlich von dort stammt, wo sie zu stammen behauptet, da es die einzige Richtlinie ist, die den From Header entweder mit der sendenden oder der signierenden Domain verbindet.
(new window)Kehren wir nun zum Angriff zurück. Der Grund, warum DKIM-Replay-Angriffe funktionieren und warum Gmail diese wiedergespielten Spam-Mails als „authentifiziert“ angesehen hat, liegt daran, dass DMARC eine DKIM oder SPF-Abstimmung erfordert, aber nicht beides. Die wiedergespielte Nachricht selbst hatte eine gültige DKIM-Signatur von proton.me, was bedeutete, dass sie DMARC bestanden hat. Diese Nachricht wurde dann so oft gesendet, dass sie den Domain-Ruf von proton.me in Gmails System beeinflusste, und schließlich niedrig genug wurde, um die Zustellbarkeit für legitime E-Mails zu beeinträchtigen.
Wie wir Replay-Angriffe verhindern
Die Tatsache, dass DMARC besteht, wenn entweder die DKIM-Domain oder die SPF-Domain mit der From Domain übereinstimmt, ist eine Funktion der Spezifikation, kein Fehler. Insbesondere ermöglicht es das Weiterleiten von E-Mails und das Senden von E-Mails durch vertrauenswürdige Drittanbieter. Für E-Mail-Dienstanbieter wie Proton, Gmail oder Yahoo ermöglicht dies jedoch auch solche Replay-Angriffe, da jeder Nutzer eine E-Mail senden, sie von der entsprechenden Domain signieren lassen und dann mit der intakten Signatur erneut senden kann.
Das ist ein Grund, warum Proton und andere E-Mail-Anbieter stark in ihre eigene Anti-Spam-Technologie und -Systeme investieren. Diese Systeme sind komplex und verlassen sich oft auf komplizierte Heuristiken, um Spam von legitimen E-Mails zu trennen. In diesem Fall haben die Angreifer eine Schwachstelle in Gmails Anti-Spam-System gefunden und ausgenutzt.
Wir schätzen Googles Reaktionsfähigkeit bei der Behebung des Problems.
Wie du Domain-Imitationen auf deiner Domain verhindern kannst
DKIM-Replay-Angriffe sind hauptsächlich ein Problem für E-Mail-Dienstanbieter oder andere Organisationen, die E-Mail-Adressen auf einer gemeinsamen Domain anbieten. Allerdings sind E-Mail-Authentifizierungsangriffe im Allgemeinen ein Risiko für jede Organisation. Hier sind einige Tipps, um sicherzustellen, dass niemand anderes deine Domain imitieren oder verwenden kann, um betrügerische Nachrichten zu senden.
- Richte SPF, DKIM und DMARC ein – diese Richtlinien sind zwar nicht perfekt, aber entscheidend dafür, dass deine E-Mails zugestellt und vor Fälschungen geschützt werden. Wenn du Proton verwendest, um deine Domain zu hosten, wird unser Domain-Einrichtungsassistent erklären, wie du sie einrichtest und vor Imitation schützt.
- Wechsle deine DKIM-Schlüssel regelmäßig – Das Rotieren unserer DKIM-Schlüssel ermöglichte es uns, den Angriff schnell zu stoppen und Zeit für die dauerhafte Lösung zu gewinnen. Obwohl es mühsam und riskant ist, dies manuell zu tun, ermöglichte uns Protons DKIM-Key-Management-System(new window), dies in Minuten zu tun, und dieses System wird für alle bei Proton gehosteten Domains verwendet. Das System rotiert auch automatisch regelmäßig Schlüssel, um das Risiko eines Schlüsselkompromisses zu verringern.
- Signiere From-, To- und CC-Header zusätzlich – Die meisten DKIM-Implementierungen signieren immer die From, To und CC Header, wenn sie in einer E-Mail vorhanden sind, um zu verhindern, dass sie geändert werden, wenn die Nachricht erneut gesendet wird. Fehlen diese Header jedoch, sind sie oft unsigniert, was die Tür für Replay-Angriffe mit gefälschten Headern öffnet, die die betrügerischen E-Mails legitim erscheinen lassen. Das zusätzliche Signieren dieser sensiblen Header in allen Fällen, selbst wenn sie leer sind, mildert diese Angriffe. Wenn du Proton zum Senden deiner E-Mail verwendest, wird dieses zusätzliche Signieren automatisch von unseren Mailservern durchgeführt.
- Sei vorsichtig mit Subdomains – Wenn du CNAME-Einträge verwendest, um Teile deiner Website an Dritte zu delegieren, ermöglichst du diesen Dritten möglicherweise auch, E-Mails im Namen deiner Hauptdomain zu senden. Das liegt daran, dass DMARC standardmäßig Domains als abgestimmt betrachtet, wenn sie eine Eltern-Kind-Beziehung haben — das heißt, sub.example.com stimmt mit example.com überein. Du kannst mit den Optionen aspf und adkim in deiner DMARC-Richtlinie eine genaue Übereinstimmung für SPF, DKIM oder beides erzwingen. Sei dir jedoch bewusst, dass dies Auswirkungen auf die Integration von Diensten Dritter für den E-Mail-Versand haben kann.
Nachdem du in Proton Mail auf Senden klickst, passiert eine Menge
Wenn wir alles richtig machen, scheint das Zustellen einer E-Mail so einfach wie ein einziger Klick zu sein, aber in Wahrheit beruht es auf einem komplexen Geflecht von ineinandergreifenden und voneinander abhängigen Richtlinien. Ereignisse wie dieser Replay-Angriff zeigen, wie kompliziert es sein kann, etwas scheinbar Einfaches wie „Wer hat diese E-Mail gesendet?“ zu verifizieren.
Bei Proton Mail untersuchen wir ständig neue Protokolle und Richtlinien, um sicherzustellen, dass die Millionen von E-Mails, die täglich über unsere Plattform gesendet werden, zuverlässig und sicher zugestellt werden. Wir überwachen auch kontinuierlich eingehende E-Mails, um sicherzustellen, dass unsere Authentifizierungsprüfungen optimiert sind, und wir haben rund um die Uhr Systeme und Analysten im Einsatz, um Spam- und Phishing-Angriffe abzuwehren.
Das ist ein wesentlicher Teil der Schaffung eines Internets, in dem Privatsphäre der Standard ist, und wir könnten es nicht ohne die Unterstützung der Proton-Community tun. Vielen Dank.
