DKIM doppelte Header
Wenn Sie z.B. eine Mail von NoSpamProxy bekommen und die DKIM-Signatur betrachten, dann könnte ihnen die "Dopplung" der Felder auffallen:
d=Netatwork.de; s=key1e; t=1597183513; bh=yA/GiIxq//FpFGqZfEcNfUmwtE8e3mlrla1e1HJSlws=; h= "Subject:Subject:From:From:Date:Date:ReplyTo:ReplyTo:Cc:Cc:Message-Id:Message-Id";
Hiermit gibt NoSpamProxy bekannt, dass der Hashwerte aus dem Body und den Feldern generiert wurde. Die Doppelung soll gegen "doppelte/veränderte Felder" schützen und ist sogar eine Empfehlung in der RFC 6376:
https://tools.ietf.org/html/rfc6376#page-38
“INFORMATIVE NOTE: A header field name need only be listed
once more than the actual
number of that header field in a message at the time of
signing in order to prevent
any further additions. For example, if there is a single
Comments header field at the
time of signing, listing Comments twice in the "h=" tag is
sufficient to prevent any
number of Comments header fields from being appended; it is
not necessary (but is
legal) to list Comments three or more times in the "h="
tag.”
Die Dopplung schützt die Mails vor mehrfachen Headern und dem nicht klar definierten Verhalten von Mailclients. Ein Schlüsselfeld ist ja "FROM" im Header und diese Feld gibt es gewöhnlich auch immer nur genau einmal und könnte so auch signiert werden. Stellen sie sich vor, ich sende eine Mail mit folgendem Header:
From: user1@msxfaq.com To: User2@uclabor.de Subject: Test
Diese Mail wird nun übertragen und auf dem Weg verändert jemand die Mail in der folgenden Form:
From: gf@badguy.carius.de From: user1@msxfaq.com To: User2@uclabor.de Subject: Test Message .
Eine doppelte "From"-Zeile ist natürlich nicht erlaubt aber die meisten Mailserver scheren sich nicht darum, denn die nutzen nur den Envelope. Es liegt dann wieder beim Client, wie er diese Mail verarbeitet und wie der DKIM-Validator diese Mail prüft. Es kann nämlich folgendes passieren:
- DKIM-Validator nutzt das erste FROM
Er könnte ja von oben nach unten die Mail nach den geforderten Headern lesen und den ersten Treffer übernehmen. Der Angreifer kann die Mail einfach korrekt per DKIM signieren und auch der SPF-Check kann positiv sein. Die Mail passiert den Spamfilter - Mail Client nimmt die letzte FROM-Zeile
Der Mailclient beim Anwender hingegen nimmt z.B. die zweite Adresse und zeigt diese an. Der Anwender sieht die "gute" Adresse und vertraut darauf, dass die Mail gut ist
Auch umgekehrt wäre es möglich, dass ein Angreifer, der eine Kopie einer gültig signierten Mail einfach weitere Zeilen addiert und drauf hofft, dass der DKIM-Verifier dies nicht bemerkt aber der Client die bekannte Mailadresse weiter anzeigt. Das Szenario ist real.
Exchange nimmt so eine Mail problemlos an und Outlook zeigt einfach die erste "From:"-Zeile an.
NoSpamProxy erkennt übrigens diese und andere Fehler und lehnt die Mail ab
550-5.7.1 The FROM header contains multiple email addresses
Mit Outlook müsste der Angreifer also die "vertrauenswürdige Adresse" an erster Stelle schreiben und der Mailserver die zweite Adresse für die DKIM-Verifikation nutzen. Solche "Replay-Attacken" sind durchaus real und haben es auch in die RFC gefunden:
“RFC 6376 also suggests that DKIM
signers should “oversign”, i.e., repeat important headers,
to prevent replay attacks, such as using “h=from:from:subject:subject:to:to.
. . ”. This
technique takes advantage of two DKIM features. First, each
parameter of the “h=” tag
matches a single occurrence of a header. Therefore, if a
message has two Subject headers
(which normally it will not), “h=subject:subject” will
prevent an attacker from tampering
with either of them.Second, DKIM allows signing nonexistent
headers. For example, if a
message lacks a Subject header, “h=subject” will prevent an
attacker from adding one to
the signed message.
Source:
https://www.usenix.org/system/files/sec20fall_chen-jianjun_prepub_0.pdf
page 13
Weitere Links
- DKIM mit Office 365
- Mailingliste mit DMARC, DKIM, SPF, ARC
- ARC - Authenticated Received Chain
-
DKIM Test: How to test DKIM signature
https://www.appmaildev.com/en/dkim