DKIM and injected headers

If you look at the DKIM-Signature header in any piece of email signed with DKIM you’ll see that one of the fields it contains, the h= field, lists some email header names, for example:

h=From:Subject:Date:To:MIME-Version:Content-Type

Those are the headers that were signed when the mail was sent, and they’re the only headers that will be checked by the DKIM validator. There are some header fields that can occur multiple times, but they’re seldom ones that you’d be interested in signing (if you ever are, check out the DKIM RFC for the details of how that works).
Yesterday I talked about DKIM replay attacks, how replayed messages looked a little odd and had bad To: headers, and mentioned that header duplication might be a problem. You can’t modify a signed header without breaking the DKIM signature – but what happens if someone takes your signed message, adds a new Subject: or To: header in addition to the existing one, and then sends it on to a new set of recipients?
RFC 5322 says that you can’t have multiple Subject or To headers, but violating specifications is where protocol attacks usually get interesting. If the attacker is careful, they can add a second Subject: header and some DKIM validation code will consider the resulting (invalid) message to still be validly signed – the signature says it’s signed one Subject header, and there’s one Subject header that hasn’t changed, so that one validates.
What will be displayed to the end user, if there are multiple Subjects? That’s undefined behaviour – the message is violating email standards, so the MUA could do anything and still be within spec. It could legitimately halt, play La Marseillaise, electrocute the user and then catch fire. More likely, it’ll display one of the two Subject fields – most likely it’ll predictably show either the first one or the last one.
If you’re an attacker trying to hijack someone else’s reputation by replaying signed mail this is a wonderful opportunity – it means that you’re potentially able to replay signed mail, displaying modified To: and Subject: fields to the final recipients, avoiding the red flag of having the recipient not be in the To: field. It might only work reliably for some MUAs, but even if it just worked at Yahoo or Gmail or Hotmail it’d be worth doing.
DKIM has two, slightly opposing, views on what to do about this. The first one is more theoretical: DKIM is only defined for use with email messages, if there are two Subject: headers then it’s not an email message so it’s out of scope for DKIM to even have an opinion on the situation. The operational implication of that is that ISPs receiving should reject any email they receive that violates the email specs before their DKIM validator even looks at it – and it’s likely that ISPs who aren’t already doing this will start being stricter about what violations of RFC 5322 they will accept.
The second is more practical. DKIM allows you to “sign” that a header doesn’t exist – if you tell a DKIM signer to sign, for example, Reply-To: and there’s no Reply-To: field in the message when it’s signed then adding a Reply-To: field will break the signature. And DKIM allows you to sign a repeated header field, just by including it multiple times in the list of fields to sign.
We can combine these two features to enforce that there is only a single, unchanged copy of any given header. To do that, we just need to include the Subject (and To, and From, and maybe others) twice in the list of headers to sign. The first entry is to sign the content of the Subject: header, the second entry is to assert that there isn’t a second Subject: header.
So we’d change from

h=From:Subject:Date:To:MIME-Version:Content-Type

to

h=From:From:Subject:Subject:Date:To:To:MIME-Version:Content-Type

and then any attempt to add additional From:, Subject: or To: fields will break the signature. If you configure your DKIM signer to do that, you’re protected from having those fields tampered with. This is discussed in a bit more rigorous detail in the DKIM RFC.
ESP reputations are being attacked by this approach today. You should consider updating your DKIM signing (and locking down your evaluation accounts) fairly urgently. Don’t forget that these changes only apply to new mail you send out – they won’t prevent an attacker from replaying mail you’ve sent previously unless you rotate your DKIM keys.

DKIM replay attacks
DKIM Key Rotation

Related Posts

Is Google failing DKIM keys shorter than 512 bits?

Today’s Wednesday question comes from Andrew B. and got pushed to Thursday so I could check a few more facts.

Read More

Troubleshooting tools

There have been a number of comments on my post about Hotmail moving to SPF authentication having to do with troubleshooting authentication failures. I have been helping clients troubleshoot these issues, and am able to take on new clients to solve authentication problems. Contact me for more information.
Of course, many of these issues can be solved with access to the right tools. Steve’s been working on a number of tools that may help the troubleshooting process and we’ve recently launched them on Emailstuff.org. The website itself contains a number of DNS and data related tools we use for investigations and thought we’d share with the public at large.
One of the really useful tools is the SPF record expander. Plug in any domain, like google.com, and see what IP addresses they authorize to send mail.

Read More

Gmail FBL update

Last week Gmail started contacting ESPs that signed up for their new FBL with more information on how to set up mailings to receive FBL emails.
One of the struggles some ESPs are having is the requirement for DKIM signing. Many of the bigger ESPs have clients that sign with their own domains. Gmail is telling these ESPs to insert a second DKIM signature to join the FBL.
There are a couple reasons this is not as simple or as doable as Gmail seems to think, and the challenges are technical as well as organizational.
The technical challenges are pretty simple. As of now, not all the bulk MTAs support multiple signatures. I’ve heard that multiple signatures are being tested by these MTA vendors, but they’re not in wide use. This makes it challenging for these ESPs to just turn on multiple signatures. For ESPs that are using open source software, there’s often a lot of customization in their signing infrastructure. Even if they have the capability to dual sign, if they’re not currently using that there is testing needed before turning it on.
None of the technical challenges are show stoppers, but they are certainly show delayers.
The organizational challenges are much more difficult to deal with. These are cases where the ESP customer doesn’t want the ESP to sign. The obvious situation is with large banks. They want everything in their infrastructure and headers pointing at the bank, not at their ESP. They don’t want to have that second signature in their email for multiple reasons. I can’t actually see an ESP effectively convincing the various stakeholders, including the marketing, security and legal staff, that allowing the ESP to inset a second signature is good practice. I’m not even sure it is good practice in those cases, except to get stats from Gmail.
Hopefully, Gmail will take feedback from the ESPs and change their FBL parameters to allow ESPs to get information about their customers who sign with their own domain.

Read More