Google durch DKIM-Replay-Angriff gespooft: eine technische Analyse

• Ein Fall, in dem Angreifer mithilfe eines DKIM-Replay-Angriffs erfolgreich Phishing-E-Mails versendeten, die wie von Google aussahen
• Absenderadresse und Authentifizierungsergebnisse der E-Mail wirken wie bei einer echten offiziellen Google-Mail, wodurch Nutzer leicht getäuscht werden können
• Die Angreifer nutzten Google Sites, um eine Website zu erstellen, die wie eine offizielle Support-Seite aussieht und so die Glaubwürdigkeit erhöht
• SPF, DMARC und DKIM bestehen die Prüfung, doch der Kern des Angriffs ist das erneute Weiterleiten der E-Mail ohne Änderungen an Inhalt und Signatur-Headern
• Als praktische Gegenmaßnahmen werden ein regelmäßiger Wechsel der DKIM-Schlüssel und eine bessere Sensibilisierung der Nutzer empfohlen

---

Einstieg: Eine Phishing-Mail, die normal wirkt

• Am Morgen erhielt ein Bekannter eine E-Mail, in der es angeblich um eine Anforderung rechtlicher Dokumente für ein Google-Konto ging
• Als Absender wurde eine offizielle Google-no-reply-Adresse angezeigt; ohne Tippfehler, verdächtige Links oder auffällige Domains war die Nachricht sehr sorgfältig gestaltet
• Der Empfänger konnte die Echtheit nur schwer beurteilen und zog daher einen Experten hinzu

Detaillierte Analyse der E-Mail

• E-Mail-Header und Link-Vorschau wurden in einer Sandbox-Umgebung untersucht
• Absenderadresse, Branding, Sprachqualität und das Fehlen von Anhängen wirkten allesamt normal
• Beim Prüfen der Authentifizierungsergebnisse von SPF, DKIM und DMARC wurden jedoch auffällige Anzeichen entdeckt

Wichtige Hinweise zu Phishing-Mails

• Es wird ausdrücklich betont, keine Links in verdächtigen E-Mails anzuklicken oder Anweisungen daraus auszuführen
• Wird auf die E-Mail außerhalb einer Sandbox reagiert oder ein Anhang geöffnet, besteht die Gefahr von Datenabfluss, Kompromittierung geschäftlicher E-Mail-Konten, Kontoübernahme und Netzwerkverletzungen
• In Verdachtsfällen ist umgehend eine fachkundige Analyse und Meldung an das Sicherheitsteam erforderlich

Angriffsablauf: Einsatz von Google Sites

• Der Link in der Angriffs-E-Mail führt, wenn man bereits angemeldet ist, direkt zu Google Sites
• Google Sites ist eine offizielle google.com-Subdomain, auf der jeder kostenlos Seiten erstellen kann, der Inhalt ist jedoch nicht automatisch eine offizielle Support-Seite
• Der Dienst wird für interne Wikis, Projekt-Dashboards, Dokumentation, Event-Websites und viele weitere Zwecke genutzt und kann wie in diesem Fall missbraucht werden

Wenn vertrauenswürdige Infrastruktur zur Bedrohung wird

• Google Sites (seit 2008 verfügbar) ist mit Google Workspace integriert und bietet einfache Erstellung und Verteilung, SSL-Zertifikate sowie Markenvertrauen
• Angreifer können dadurch ohne eigene Domain oder eigenes Hosting mit geringem Aufwand Phishing-Seiten aufbauen, die offiziell wirken

Detaillierter Ablauf des DKIM-Replay-Angriffs

Schritt 1: Eine echte Google-E-Mail beschaffen

• Die Angreifer empfangen zunächst eine legitime E-Mail vom Konto [e-mail] und speichern den ursprünglichen Nachrichtentext sowie die Header

Schritt 2: Vorbereitung der erneuten Zustellung der signierten Nachricht

• DKIM versieht Teile des E-Mail-Inhalts und bestimmte Header mit einer digitalen Signatur
• Bleiben Originalnachricht und Signatur-Header erhalten, bleibt die Authentifizierung auch beim erneuten Versand bestehen

Schritt 3: Weiterleitung über Outlook

• Die Angreifer versenden die Angriffs-Mail über ein Outlook-Konto
• Ein Teil der Absender- und Routing-Informationen ändert sich, die DKIM-Signatur bleibt jedoch gültig

Schritt 4: Nutzung des Jellyfish-SMTP-Relayservers

• Microsoft routet die E-Mail über das Jellyfish-System weiter, wodurch zusätzliche Distanz zum eigentlichen Absendeserver entsteht

Schritt 5: Versand über Namecheap PrivateEmail

• Der Dienst PrivateEmail von Namecheap nimmt die E-Mail entgegen und fungiert als zusätzlicher Relay-Schritt
• Dabei wird eine neue DKIM-Signatur hinzugefügt, die den DMARC-Anforderungen jedoch nicht entspricht
• Die ursprüngliche Google-DKIM-Signatur ist weiterhin passend und gültig, sodass die DMARC-Prüfung erfolgreich ist

Schritt 6: Endgültige Zustellung an Gmail

• Am Ende erhält der Empfänger eine E-Mail, die wie eine offizielle Google-Mail aussieht
• Das Ergebnis: SPF, DKIM und DMARC bestehen alle Authentifizierungsprüfungen

Warum die gefälschte Vorladungs-E-Mail gefährlich ist

• Eine E-Mail mit dem Betreff oder Inhalt „Vorladung“ erzeugt beim Empfänger Angst, Dringlichkeit und Verwirrung
• Sie weicht von der tatsächlichen Zustellpraxis echter Vorladungen ab, die normalerweise physisch oder über offizielle Kanäle erfolgt
• Diese Art von Phishing ist äußerst überzeugend, sodass selbst technisch versierte Nutzer leicht darauf hereinfallen können

Fazit und Gegenmaßnahmen

• Gerade bei unerwarteten dringenden E-Mails ist stets eine Prüfung der Echtheit und die Einbindung von Fachleuten erforderlich
• Keine Links anklicken, nicht antworten und nichts ausführen
• Es wird empfohlen, die E-Mail vom Sicherheitsteam oder von spezialisierten Ermittlungs- bzw. Analysekräften prüfen zu lassen

Zusatz: Nachstellung des Angriffs

• Die Angreifer registrierten bei Namecheap eine Domain und erhielten den kostenlosen PrivateEmail-Dienst
• Danach meldeten sie sich für Google Workspace (kostenlose Testversion) an, verifizierten die Domain und erstellten eine bösartige Google-OAuth-App
• Über das Feld App Name lässt sich ein beliebiger Name festlegen, etwa Google Support
• Von Google versendete Konto-Benachrichtigungen werden an PrivateEmail zugestellt; dabei lassen sich Absender- und Antwortadresse manipulieren
• Am Ende wird die Angriffs-Mail an das gewünschte Ziel zugestellt

Häufig gestellte Fragen

• DKIM-Replay-Angriff: Ein Angreifer fängt eine legitime E-Mail mit gültiger DKIM-Signatur ab und versendet sie mit identischem Inhalt und identischen Headern erneut
• Grenzen von SPF- und DMARC-Blockierung: SPF prüft nur den sendenden Server bzw. die IP; bei Replay-Angriffen kann auch DMARC bestehen, wenn die DKIM-Ausrichtung korrekt ist
• Warum die Erkennung schwierig ist: Ohne Veränderungen an Nachrichtentext oder Headern ist der Angriff allein über die Signaturprüfung schwer zu identifizieren
• Google-OAuth-Umgehung im Angriff: Die Angreifer erstellen eine bösartige OAuth-App und leiten offizielle Google-Benachrichtigungen weiter, um zusätzliches Vertrauen zu erzeugen
• Gegenmaßnahmen: Wichtig sind ein regelmäßiger Wechsel der DKIM-Schlüssel (Zyklus von höchstens 30 Tagen) und Nutzerschulungen (Vorsicht bei verdächtigen Links, URL-Prüfung, stärkere Meldekultur)

[GN⁺]

Hacker-News-Kommentare

• Ich arbeite an einer Lösung für dieses Problem (zusammen mit Mitautoren von Google und Yahoo, es ist ein vertrauenswürdiges Projekt)
  Siehe das Dokument Draft: DKIM2 Motivation
  Dieser Ansatz verhindert nicht, dass von Nutzern eingegebener Text tatsächlich von Google versendet wird, aber er verhindert zumindest, dass solche Nachrichten ohne tatsächliche Absicht von Google weitergeleitet werden
  Denn die SMTP-Felder FROM/TO werden geschützt
  Der Motivation-Draft enthält keine technischen Details; die Entwürfe sind in den zugehörigen Dokumenten zu finden
  Siehe den Link DKIM Working Group Documents

  • Die Datatracker-Seite zeigt Kandidaten-Dokumente nicht besonders gut an, deshalb hier die Direktlinks
    Draft: dkim2-dns
    Draft: dkim2-header
    Draft: dkim2-modification-algebra
    Draft: dkim2-bounce-processing
    Draft: dkim2-message-examples

  • Ich frage mich, wie dieser Ansatz bei Mailinglisten oder Gruppen funktionieren würde
    Zum Beispiel werden E-Mails von außen an [e-mail] oft automatisch an Teammitglieder weitergeleitet
    Ich frage mich, ob das System des Endempfängers so konfiguriert sein müsste, dass es dem Mailinglisten-Forwarder vertraut, oder ob es interne Logik bräuchte, die nachverfolgt, in welchen Listen etwas enthalten ist
    Es müsste möglich sein zu verifizieren, dass accounts-payable der ursprüngliche gültige Empfänger war

• Ich habe tatsächlich erlebt, dass das FBI nach einer Verurteilung wegen Computer-Hacking den kompletten Inhalt meines Google-Kontos beschlagnahmt hat
  Einmal 2016 und dann noch einmal 2018
  Tatsächlich machen sie es nicht so wie in diesem Artikel
  Meiner Erfahrung nach läuft die offizielle Kommunikation über E-Mails an eine bestimmte Google-Abteilung
  Strafverfolgungsbehörden gehen sehr vorsichtig vor, damit die Zielperson der Ermittlungen möglichst nichts bemerkt

  • Für Neugierige hier mehr Details
    Ich erhielt eine E-Mail von [e-mail] mit folgendem Inhalt:

Dear Google user,

Google received and responded to legal process issued by the United States Department of Justice (<FEDERAL DISTRICT>) compelling the release of information related to your Google account. A court order previously prohibited Google from notifying you of the legal process. We are now permitted to disclose the receipt of the legal process to you. The agency reference number or case number on the legal process is <DISTRICT COURT CASE NUMBER>.

For more information about how Google handles legal process, view our transparency report at http://google.com/transparencyreport/userdatarequests/….

Google is not in a position to provide you with legal advice or discuss the substance of the legal process. If you have other questions regarding this matter, you may wish to contact an attorney.

Please reply to this email and/or include the case identification number located in the subject line in any further communications regarding this matter.

Regards, 
Legal Investigations Support
Google LLC

Bei einer Federal Grand Jury subpoena wird normalerweise verlangt, dass der Dienstanbieter (Google usw.) dich 1–2 Jahre lang nicht benachrichtigen darf
Die Vorladung liefert nur allgemeine Datensätze (Abrechnungsinformationen, Login-Protokolle usw.), aber keine Inhalte (wie E-Mails)
Für tatsächliche Daten wie E-Mails braucht es einen separaten Durchsuchungsbeschluss, und Google benachrichtigt in der Regel nicht gesondert darüber, dass ein solcher Beschluss vollstreckt wurde

• Es ist Freitag, und dieser Kommentar hat mich zu 10 % wacher gemacht
  Ich bin neugierig auf die ganze Hintergrundgeschichte

• Interessant
  Ich frage mich, ob so eine Anfrage im Rahmen von DSGVO-Anfragen wie „Gebt mir alle Daten zu meinem Konto“ in der vollständigen Datenauskunft zu meinem Konto protokolliert oder markiert wird

• Meine Vermutung ist, dass der Durchsuchungsbeschluss wegen eines Verstoßes gegen den CFAA, Wire Fraud oder Conspiracy ausgestellt wurde
  Ich hoffe, du hattest einen guten Anwalt und konntest die Sache gut klären

• Ich habe kürzlich selbst einen ähnlichen Angriff erhalten
  Der Angreifer schickt eine E-Mail von [e-mail] (genau nicht gmail.com), leitet dann die Bounce-Nachricht vom Mailserver von Google an [e-mail] weiter und fügt am Ende eine Spam-Nachricht an
  Damit bestehen alle Sicherheitsprüfungen
  Die Kombination aus einem Postmaster-Fehler und einer Phishing-Kampagne ist wirklich ungewöhnlich
  Für Nichttechniker könnte man leicht darauf hereinfallen
  In meinem Fall behauptete die Phishing-Mail, ich hätte Bauwerkzeuge gewonnen

  • Ich bekomme solche Mails seit einigen Wochen auch
    Inzwischen habe ich das Gefühl, Google hat bei E-Mail einfach aufgegeben

• Ich war beim Lesen des Artikels ziemlich verwirrt
  Es wird sehr ausführlich so beschrieben, als habe der Angreifer den E-Mail-Text manipuliert und einen Phishing-Link eingefügt, aber tatsächlich gab es dafür keine Belege und keine solche Manipulation
  DKIM-Signaturen enthalten einen Hash des Bodys
  Technisch kann man den gehashten Bereich mit dem I=-Feld einschränken, aber ich habe überprüft, dass Google diese Option bei kurzen E-Mails nicht verwendet (durch direkte Prüfung von Mails von [e-mail])
  Das heißt: Damit DKIM- und DMARC-Prüfungen erfolgreich sind, darf der Body nicht verändert worden sein, also stammt auch der Phishing-Link aus einer ursprünglich von Google versendeten Nachricht (nur vermutlich für einen anderen erwarteten Empfänger)
  Damit ist der Kern eher ein „beängstigender falsch weitergeleiteter E-Mail-Fall“, und der Titel „DKIM replay attack“ kann auf Menschen, die mit dem Thema nicht vertraut sind, deutlich gravierender wirken
  Edit: Ich dachte nach „The Takeaway?“ in TFA, der Artikel sei zu Ende, aber im Update darunter wird erklärt, dass der Link tatsächlich in den Namen einer Google-OAuth-App eingefügt wurde und dadurch in die Google-E-Mail-Vorlage gelangte
  Das ist der wichtigste Punkt dieses Angriffs, aber die Struktur des Artikels ist so schlecht, dass er vergraben wird und den falschen Eindruck erweckt, als könne beliebiger Inhalt zugestellt werden
  Zusatz: In einem anderen Kommentar wurde auch darauf hingewiesen, dass der Screenshot der E-Mail in der Mitte abgeschnitten wurde, sodass der feste Teil der Google-E-Mail-Vorlage nicht sichtbar ist
  Der Angriff selbst ist viel schlampiger, als es zunächst wirkt

  • Dieser Artikel scheint absichtlich so geschrieben zu sein, dass er missverstanden wird
    Es wird so dargestellt, als sei der im Screenshot gezeigte Ausschnitt die ganze E-Mail gewesen, dabei wäre danach wahrscheinlich weiterer Text gefolgt, der zur Vorsicht Anlass gegeben hätte

  • So wie ich es verstanden habe, wird DKIM validiert, weil der Angreifer eine tatsächlich von Google erhaltene E-Mail unverändert weiterleitet
    Der eigentliche Angriffsvektor ist, dass Google dazu gebracht wird, eine E-Mail mit Text zu versenden, den der Angreifer kontrolliert

• Meiner Meinung nach ist die eigentliche Schwachstelle hier, dass man in den Namen einer Google-OAuth-App eine URL einfügen kann und diese dann auf der Root-Domain von Google ungefiltert in no-reply-Mails an beliebige Adressen gerendert wird
  Auch wenn der Link nicht anklickbar ist, ist die Wahrscheinlichkeit hoch, dass ein Opfer ihn manuell aufruft, wenn der umgebende Text nur bedrohlich genug wirkt
  Dass sich Forwarding-Dienste, die DKIM-Integrität erhalten, in mehreren Schichten stapeln können, ist eher ein zusätzlicher lehrreicher Aspekt
  Man sollte URLs in OAuth-App-Namen komplett verbieten, insbesondere URLs mit google.com

• Endlich!
  Ich habe vor einigen Monaten fast dieselbe E-Mail erhalten (für einen Google-Domains-Administrator)
  Mir lief dabei definitiv ein Schauer über den Rücken
  Auch ich habe nicht vorschnell auf den Link geklickt, sondern abgewartet und nach anderen Referenzen zu diesem Betrug gesucht
  Was seltsam war: Alle E-Mail-Adressen waren maskiert, und das Muster dieser Maskierung passte nicht zu den E-Mails, die ich verwalte
  Die E-Mail selbst war legit, und beim Googeln stellte ich fest, dass auch der Text im Body übereinstimmte
  In meinem Fall ging es um ein Konto einer verstorbenen Person, was bei mir überhaupt nicht zutraf
  Trotzdem war ich fast zu 100 % überzeugt, dass jemand Google irgendwie dazu gebracht haben könnte zu glauben, ich sei tot, und nun versuche, mein gesamtes Google-Konto zu übernehmen
  Das war eine extrem beängstigende Erfahrung

• Step 3: Der Angreifer sendet eine E-Mail von Outlook
  Soweit ich weiß, ist es unmöglich, den Pfad in den Received:-Headern zu spoofen
  Jeder Server fügt immer weiter seine eigenen Pfadinformationen hinzu
  Deshalb prüfe ich diese Information immer, wenn ich die Herkunft einer E-Mail verifiziere
  Eine von Google kommende Mail würde niemals über Microsoft-Server laufen

  • Der Header des letzten „vertrauenswürdigen“ Servers lässt sich nicht spoofen, der Rest des Pfads schon

  • Ich frage mich, ob du wirklich die Header jeder einzelnen E-Mail manuell prüfst
    Oder verwendest du ein Tool, das das anzeigt oder visualisiert?

• Eine wirklich beängstigende Situation
  Stell dir vor, du müsstest einem Verwandten die Lehre aus diesem Artikel erklären
  Der Gedanke, sagen zu müssen, dass man selbst dann immer misstrauisch bleiben soll, wenn eine Mail von einer vertrauenswürdigen Domain kommt und dkim/dmarc/spf in genau dieser Reihenfolge alle bestehen, ist schon bedrückend
  Allerdings ist dieser Angriff in dem, was er tun kann, ziemlich eingeschränkt
  Man kann zum Beispiel keine Nachrichten aus dem Gmail-Konto einer anderen Person fälschen und versenden
  „Wenn eine Nachricht weitergeleitet wird, bleibt die DKIM-Signatur erhalten, solange der Body und die signierten Header nicht verändert werden“
  Überraschend ist eher, dass der To:-Header nicht Teil dessen ist, was von DKIM signiert wird
  Ich denke, entweder sollte die Signaturkonfiguration geändert werden, oder E-Mail-Clients sollten warnen können, wenn die Mail zwar gültig ist, aber To geändert wurde

  • Stell dir vor, du müsstest einem Verwandten die Lehre aus dem Artikel erklären – dass man immer misstrauisch sein soll
    Da fängt das Problem schon damit an, dass man erst einmal erklären muss, was dkim/dmarc/spf überhaupt sind
    Eigentlich sind das Backend-Technologien, die Nutzer gar nicht kennen müssen sollten
    Dieser Angriff ist nicht so beängstigend, wie er wirkt
    Der Artikel ist teilweise übertrieben formuliert, offenbar um ein Produkt zu verkaufen
    Dass der To:-Header nicht in der Signatur enthalten sei, ist in Wirklichkeit auch nicht besonders wichtig
    Tatsächlich muss To in E-Mails nicht zwingend den endgültigen Empfänger angeben

  • Die Haltung, bei E-Mails grundsätzlich misstrauisch zu sein, ist schon lange der Default
    Am besten vertraut man dem From-Feld grundsätzlich nie

  • Du sagtest, es überrasche dich, dass To: nicht in DKIM enthalten sei, aber tatsächlich ist es enthalten
    Deshalb musste der ursprüngliche To:-Wert beibehalten werden
    Im Screenshot im Reproduktionsabschnitt ist die ursprüngliche To:-Adresse zu sehen
    Das bedeutet nicht, dass die Nachricht an diese Adresse zugestellt wurde
    Im Grunde kann E-Mail an jede Adresse zugestellt werden, mit beliebigem To:-Wert

  • Mein Standardrat ist: Wenn eine E-Mail zu irgendeiner Handlung auffordert, gehe direkt auf die betreffende Website
    Klicke auf keinen Link
    Das ist unpraktisch, aber am Ende löst es das Problem
    Gerade bei Banken oder wichtigen Systemen lohnt sich diese Unbequemlichkeit absolut

  • In meinem Arbeitsumfeld ist der Umgang mit solchen Bedrohungen längst in die Richtlinien eingeflossen
    Im Internet ist es gute Praxis, grundsätzlich alles zu hinterfragen
    Viele kleine Unternehmen und Freelancer nutzen noch immer kein MFA, und selbst wenn, fallen sie leicht auf Token-Diebstahl herein
    Wenn solche Konten kompromittiert werden, kommen plötzlich bösartige E-Mails an, die wirklich wie von internen Nutzern aussehen
    Für Nutzer wirkt das dann vollkommen legit
    Deshalb sollte man E-Mail immer mit Misstrauen behandeln

• Der Autor schreibt
  „Here is the URL from that email [...] https://sites.google.com[...]“
  Genau dieser Link ist das erste Warnsignal
  Ich finde, der Autor hätte diesen Punkt direkt am Anfang hervorheben sollen und nicht erst drei Absätze später

  • Nicht jeder kennt alle Subdomains von google.com
    Das eigentliche Problem ist, neben der Frage zulässiger Felder in SSO, dass Google User-Content auf Subdomains der Hauptdomain ausliefert
    Andere Dienste wie Drive könnten das ebenfalls tun

  • Für dich mag das ein Warnsignal sein, für meine Eltern vielleicht nicht

• Insgesamt zeigt dieser Fall, wie fragil E-Mail-Sicherheit als System ist
  In diesem Forum gibt es so viele kluge Leute, dass ich glaube, man könnte gemeinsam eine Alternative entwickeln, die solche Probleme auf einmal löst
  Ich finde auch, Google sollte solche Seiten nicht auf der Hauptdomain, sondern auf einer getrennten Domain wie hostedbygoogle.com bereitstellen
  Ich frage mich, warum das bis heute nicht getrennt wurde

  • Alle realistisch umsetzbaren Alternativen laufen am Ende auf ein System hinaus, in dem die gesamte Kontrolle an ein einzelnes Unternehmen abgegeben wird
    Damit ginge der vielleicht wichtigste verbleibende Wert von E-Mail verloren: ein System zu sein, das niemand vollständig kontrolliert
    Die technischen Probleme sind gut lösbar, aber die Probleme mit Menschen und Interessenlagen sind viel schwieriger
    Die Akteure mit den Ressourcen, um das Problem zu lösen, haben meistens keinen Anreiz, eine vollständig offene Plattform zu schaffen
    Wenn sie nicht das ganze Geld und die ganze Kontrolle bekommen, werden sie sich die Mühe kaum machen
    Umgekehrt wollen auch nicht alle sämtliche Kontrolle an ein einziges Unternehmen abgeben
    Genau deshalb ist das kein technisches, sondern ein geschäftliches Problem
    (Der gleiche Grund erklärt, warum es im Metaverse praktisch unmöglich ist, dass alle Dienste Avatare und Items teilen
    Nicht, weil es technisch unmöglich wäre, sondern weil die Rechteinhaber es niemals zulassen würden)

  • Vorstellung des neuen von Thiel finanzierten Startups Shadowfax!
    Unser sicherer, zentralisierter Monopol-Dienst mit AI- und Blockchain-Layer wird das veraltete E-Mail-System ersetzen
    Ein Auftrag des US-Verteidigungsministeriums ist bereits gesichert, und bis 2027 soll es zum Standard für sämtliche interne und externe Kommunikation der US-Bundesbehörden werden