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