In den letzten Wochen scheint es eine Phishing-Welle gegeben zu haben, bei der in den E-Mails die Absenderadresse @emails.dkb.de, die auf die Deutsche Kreditbank AG (DKB) hinweist, verwendet wurde. Ein Leser hat mich darauf hingewiesen, dass die DKB durch einen Konfigurationsfehler die DMARC-Prüfung ihrer Domain versehentlich wohl abgeschaltet hat. Ich stelle den Sachverhalt mal hier zur Information im Blog ein.
Anzeige
Phishing-Mails von der DKB-Mail-Domain
Zum Sachverhalt so viel: Es war eine Phishing-Mail, die Anfang Oktober 2024 sehr oft bei Jan im Unternehmen eingetrudelt ist. Diese Phishing-Mail seit größtenteils vom eingesetzten Spam-Schutz abgefangen worden, schrieb der Leser.
Was den Blog-Leser jedoch wunderte, in der Phishing-Mail wurde die Absenderadresse @emails.dkb.de verwendet. Daher ist Jan der Frage, warum können die Phisher diese Adresse als Absender benutzen können, nachgegangen. Die erste Mail endete mit: "Du könntest einen interessanten Artikel dazu schreiben, denn die DKB hat ihre Hausaufgaben in Sachen E-Mail-Sicherheit nicht gemacht (DMARC deaktiviert)."
Analyse der Problematik
Jan hat mir über einen Share dann die Kopfdaten der Mail sowie seine Analyse zukommen lassen. Seine Antwort: Im Gegensatz zum Branchenstandard bei Banken hat die DKB zwar einen DMARC-Datensatz für die Domain dkb.de definiert. Aber die Policy für diesen Eintrag steht auf "none", womit DMARC effektiv ausgeschaltet ist. Hier der DMARC-Datensatz der Domain dkb.de, den Jan mir zugeschickt hat:
v=DMARC1; p=none; pct=100; rua=mailto:dmarc-reports@dkb.de; ruf=mailto:dmarc-reports@dkb.de; fo=1:d:s
Das Problem sieht man in diesem Header:
Anzeige
Authentication-Results: mx-gate78-hz1.hornetsecurity.com 1; spf=fail reason=mailfrom (ip=85.214.6.194, headerfrom=emails.dkb.de) smtp.mailfrom=emails.dkb.de smtp.helo=emails.dkb.de; dmarc=fail hse.action=pass header.from=emails.dkb.de orig.disposition=pass
Dort steht, dass SPF und DMARC-Prüfung fehlgeschlagen sind. Durch die deaktivierte Policy wurde aber die Mail auf "hse.action=pass" gestellt. Nachfolgend ist noch der komplette Header der Phishing-Mail abgebildet.
Authentication-Results: mx-gate78-hz1.hornetsecurity.com 1; spf=fail reason=mailfrom (ip=85.214.6.194, headerfrom=emails.dkb.de) smtp.mailfrom=emails.dkb.de smtp.helo=emails.dkb.de; dmarc=fail hse.action=pass header.from=emails.dkb.de orig.disposition=pass Received: from ip85-214-6-194.pbiaas.com (85.214.6.194) by mx-gate78-hz1.hornetsecurity.com; Mon, 30 Sep 2024 06:21:41 +0200 From: DKB <kundeninformation@emails.dkb.de> To: ######@#####.de Subject: =?UTF-8?B?SW5mb3JtYXRpb24gw7xiZXIgSWhyZSBLb250b2RhdGVuIGJlaSBES0IgQmFuaw==?= Date: 30 Sep 2024 04:21:31 +0000 Message-ID: <20240930042131.2F12C7470D85DEB5@emails.dkb.de> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-antispameurope-sender: kundeninformation@emails.dkb.de X-antispameurope-disclaimer: This E-Mail was scanned by www.antispameurope.com E-Mailservice on mx-gate78-hz1 with ##### X-antispameurope-Connect: ip85-214-6-194.pbiaas.com[85.214.6.194],TLS=0;EMIG=0 X-antispameurope:INCOMING: X-antispameurope-LES: d8f880bdda X-antispameurope-orig-ip:85.214.6.194 X-antispameurope-orig-host:ip85-214-6-194.pbiaas.com X-antispameurope-SPFRESULT: FAIL X-antispameurope-detected-infomail:yes X-antispameurope-Spamstatus:SPAM X-antispameurope-REASON:ASESPF7-2:FAIL:85.214.6.194
Anzeige
Da sind leider Telekom und co. nicht besser, man hat sich dagegen entschieden. Stört ja alles nur, wenn User Drölf Millionen Postfächer hat und alles einfach oder mehrfach weiterleitet über zig Anbieter hinweg…
Ein Quarantäne Flag sollte mindestens sein im SPF und DMARC.
Blödes Geschwätz! Seit Jahren verhindert man argumentativ den Spamschutz wegen „Weiterleitungen" und „Mailinglisten". Zu vernachlässigende Einzelfälle!
Google und Co greifen aber jetzt durch und schalten entsprechende Schutzmaßnahmen scharf. Dann wird auch t-online, entweder mitziehen oder in der Bedeutungslosigkeit verschwinden.
Weiß ich, zumal ne DKIM Signatur beim Weiterleiten bestehen bleibt und ein ARC Eintrag im Header gibt.
Zudem könnten Anbieter Weiterleiten auch abschaffen und Kunden zwingen sein Kram per pop3 Sammler abrufen zu lassen, aber dass würde den Kunden ja einschränken.
Und was Spam angeht, Google und Microsoft selbst sind Spam Schleuder, großteils was an Spam rein kommt an den Blacklisten vorbei sind die beiden genannten. Wird von beiden mit eigenen Regeln entsprechend abgestraft dass diese dann zumindest im junk landen.
Von DKB bisher aktuell nichts gesehen in Logs.
"sein Kram per pop3 Sammler abrufen zu lassen" ist für Kunden wie Anbieter deutlich aufwändiger (==teurer), da $Kunde aller n Minuten jenen POP3-Abruf machen muss, um halbwegs a jour zu sein (== (bei z.B. "aller 15 min") 20160 POP3-Abrufe pro Kunde und Monat vs. nur Weiterleitung der wenigen betreffenden Mails).
Ich verstehe nach wie vor nicht, wieso irgendwas irgendwo irgendwas einsammeln muss. Ich habe auf jedem Gerät mit Internetzugang die Möglichkeit, unendlich Mailkonten einzubinden. Das geht soweit, dass ich, wie bei Apple schon ewig und drei Tage üblich, alle Mails in einem Posteingang zu sehen bekomme. Ich muss also nicht einmal mehr von Postfach zu Postfach springen. POP3 ist obsolet, ein Sammeldienst völliger Bullshit. Und weiterleiten muss ich nur etwas, wenn es jemand anders als ich lesen soll. Das mache ich dann manuell.
@Daniel: Wenn ich ARC richtig verstehe, muss aber der Empfänger dem ARC-Header explizit vertrauen?
MS beschreibt es für ihre Tenants so:
"A Microsoft 365 organization needs to identify trusted ARC sealers only when messages delivered to Microsoft 365 recipients are regularly affected in the following ways:
– The intermediary service modifies the message header or email content.
– The message modifications cause authentication to fail for other reasons (example, by removing attachments).
After an admin adds a trusted ARC sealer in the Defender portal, Microsoft 365 uses the original email authentication information that the ARC sealer provides to validate the messages sent through the service into Microsoft 365."
Fazit: Ohne Admin-Eingriff nutzt der ARC-Header des "Zwischen"-Versenders nichts.
@JohnRipper: Momentan fordern Google, Yahoo und Apple-Mail nur einen DMARC record mit p=none.
"p=none" muss nicht unbedingt ein Konfigurationfehler sein. Wenn man DMARC neu einrichtet, größere Änderungen an SPF/DKIM vornimmt, oder Zustellprobleme hat, setzt man das, um vorübergehend Rejects zu verhindern und sich die DMARC-Reports anzusehen. Ist (wieder) alles i.O., wird es dann auf "p=reject" oder "p=quarantine" geändert.
SPF ist simpel, aber DKIM sorgt öfters für Stress, da manche Einstellungen (welche Header-Felder gesichert werden) in bestimmten Situationen zu Fehlen führen. Da gibt es z.B. eine große EMail-Plattform, die ein spezielles Header-Feld einfügt, wenn es noch nicht vorhanden ist. Hat der Sender in den DKIM-Einstellungen das Feld mit drin, aber nicht im Header, wird das Feld vom DKIM als nicht vorhanden markiert. Die große Mail-Plattform ergänzt das Feld und schon validiert DKIM nicht mehr. Und von solchen Spässen gibt es nicht nur ein paar wenige. Übrigens, Mailingslisten stolpern tatsächlich öfters über DKIM.
@Anonymous: Weiteres Beispiel für "solche Spässe":
Weiterleitung eines LIDL-Newsletters von einem großen Free-Email-Provider:
Fehlermeldung: DKIM=hardfail (body hash did not verify [final])
DKIM-Signierte Header von LIDL:
h=From:To:Subject:Date:List-Unsubscribe:List-Unsubscribe-Post:MIME-Version:
Reply-To:Message-ID:Content-Type;
Kann ich jetzt mit diesen Informationen herausfinden, welchen Header der Email-Provider als "Weiterleiter" des Original-LIDL-Emails verändert hat?
Eventuell hat ja auch das empfangende Email-Gateways einen Header geändert?
Wie kann ich die Ursache herausfinden?
Da wurde der Nachrichtentext verändert, z.B. irgendein Text eingefügt.
@Anonymous: Danke für den Hinweis. Hab's jetzt auch beim Googlen gefunden:
"The "DKIM body hash not verified" status means the computed hash of the message body doesn't correspond to the body hash value stored in the "bh=" tag of the DKIM signature."
Wir wollten neulich für unsere eingehenden Emails die DMARC-Prüfung aktivieren.
Neben eindeutigen Spam-/Phishing-Emails gingen aber auch sehr viele legitime Emails (vor allem Out-of-Office-Meldungen und Non-Delivery-Reports) von MS365-Tenants auf "reject" oder "quarantine" – je nach Einstellung im DMARC Record.
Warum?
Die Emails waren alle von Microsoft korrekt DKIM signiert – allerdings mit der Standard-Domain tenantname.onmicrosoft.com (die sogenannte MOERA-Domain), die sich dann nicht mit der Versand-Domain z.B. firma.de deckten.
Damit ging das DKIM Alignment auf "fail". SPF geht bei Automatic Replies und bestimmten NDRs wegen leerem Envelope_from auch auf fail. Somit DMARC-Prüfung insgesamt= fail, somit quarantine oder reject.
Die Administratoren der Sende-Seite haben hier schlicht vergessen DKIM-Signing in ihrem MS365-Tenant für ihre produktive Domain firma.de einzuschalten.
Das ist ja leicht korrigierbar. Auffällig war nur, dass dieser Konfigurationsfehler bei recht vielen MS365-Tenants auftrat. Dies liegt wohl daran, dass MS standardmäßig immer mit der MOERA-Domain signiert.
@alle: Können andere Admins diese Beobachtung bestätigen?
Unternehmen die meinen mit onmicrosoft was zu versenden, landen bei mir eh im Spam. Solche unprofessionellen Versender interessieren mich nicht, sollen die an Mails ersticken. Postmaster Adressen gibt es oft nicht, oder erfolg eh keine Antwort. Also beratungsresistent, daher wird da von mir auch nichts zugelassen um solchen Murks durchzuwinken, im Gegenteil, landet gewollt im Spam.
@Daniel: Es geht nicht den Envelope_from oder Header_from. Diese waren selbstverständlich mit der produktiven Unternehmens-Domain gefüllt z.B. sap.de oder ibm.com.
Nur die DKIM-Signatur verwendete die Domain d=tenantname.onmicrosoft.com. Somit passt die DKIM-Domain d=x nicht zu header_from=y. Damit DMARC-Alignment für DKIM = fail.
In dem Fall greift Deine Blockierung gar nicht. Wenn Du DMARC prüfst, werden diese Emails "quarantine" oder "reject", sind aber legitime Geschäfts-Emails –> Problem!
Weiß ich, wie geschrieben geht bei mir in Spam gewollt:
OriginatorOrg enthält onmicrosoft
Oder
Exchange-CrossTenant-AuthAs=Anonymous
Oder
X-MS-Exchange-Authentication-Results =spf=fail
Oder
X-ClientProxiedBy ist enthalten
Ähnliches bei Google was forward header drinnen hat.
Weiterhin aktuell kein DKB Spam bekommen bisher. Die IP aus dem Artikel steht auch nur auf 2 Blacklisten beim schnellen check.
@Daniel: Danke für die exakte Angabe der Header. Ich hab' mal eine normale Emails aus unserem MS-Tenant geprüft: Die würde bei Dir ankommen und nicht im Spam landen ;-)
Ich bekomme momentan massenweise Phishingmails "von" Toom, ADAC, UPS, Booking, Lidl, Decathlon, TotalAV (angeblich ein Antivirus weil mein AV "bald" abläuft), Volkswagen, T-Online, Douglas, Rokyo (was auch immer das sein soll), und noch ein paar andere, was sich momentan im Spam-Ordner tummelt, das ist nicht mehr normal. Die Links die man klicken solllen gehen alle irgendwo zu t.co oder amazon-aws.
Die Fall und die Diskussion hier beweisen mal wieder, das gegenwärtige E-Mail-Protokoll ist veraltet, instransparent, anfällig, kriminalitätsbegünstigend und verwirrend – selbst für Admins.