My friends at the Certified Senders Alliance put on a fantastic (if I do say so myself) webinar this week, where Sebastian Kluth (CSA), Fredrik Poller (Halon) and yours truly (Al Iverson) shared our thoughts and understanding about DKIM Replay Attacks. If you missed it, never fear! I've got a recap and recording for you below.
An Overview of DKIM Replay: Email forwarding with malicious intent
A DKIM replay attack involves taking an already sent message and re-injecting it via SMTP to new recipients. Often, lots of recipients. Bad guys utilize a loophole in the concept of DKIM authentication in that DKIM was meant to allow for email forwarding without failing authentication, so authentication signatures are based on the domain, content and headers, without any consideration for what server (or what IP address) transmitted that email message. Authentication is effectively divorced from infrastructure and encased entirely with the email message itself.
Bad guys attempt DKIM replay attacks to steal domain reputation, with hopes of getting their unwanted garbage mail delivered. If I'm able to send an email to a million people using a DKIM signature published and signed by gmail.com, I look like gmail.com to mailbox providers and spam filters. If gmail.com has a good reputation, I get good inbox delivery -- at least until I send enough bad mail to negatively impact that domain's reputation. And if I'm the real deliverability manager or postmaster for gmail.com, I could see my domain reputation tank and deliverability problems appear, based on sends I didn't initiate or intend to allow -- and might not even know about!
Executing DKIM replay is very simple from a technical perspective.
Log in to Gmail.
Send a message from your Gmail account to some other webmail account, like Yahoo or Outlook.com.
Go into your other account, and "view source" or select "download message" to get the full raw email headers as a TXT or EML file.
Now, anybody with access to a unix server that can send mail (a barrier, but a low one), can easily re-inject this message into SMTP using a variety of methodology, starting as simply as typing out the unix commands "cat message.eml | /usr/sbin/sendmail new-recipient@example.com"
The resulting message passes DKIM authentication successfully, as long as neither the message body or signed message headers were modified at any point. The message likely will fail SPF authentication, as the IP address of the server sending the mail is a new one -- but with DKIM passing, DMARC is likely to pass, and the mail effectively passes enough authentication checks to be considered legitimate. This is not to say that authentication success bypasses spam filtering -- inbox placement isn't guaranteed, but if a bad guy executes this against a domain with a good reputation, they may be able to leverage that good reputation for a period of time.
Content is part of the equation as well. A bad guy wants to send you his bad content, to get you to click on his bad links, to buy his bad product or fall prey to his bad scheme. The risk level here varies for different types of email sending engines or platforms, and it's partly based on that ability to customize content.
ESPs or CRM tools, aka email service providers and customer relationship management tools. Though the content is defined by the user, that user generally has to pay to sign up for access to these tools. A bad guy is (at least somewhat) dis-incentivized to take ESP/CRM content and execute a DKIM replay to a million other people, as they had to pay to even get into the editor to be able to send that initial message. And they might have also had to configure their own DKIM domain, meaning they'd be stealing … from themselves.
A bad guy could instead just take a bulk email message they received (like, say, a message selling shoes from Adidas) and replay that message to a million people -- but without being able to change the message content. Thus they could "replay to annoy" but without little option for financial gain.
MBPs or ISPs, aka mailbox providers and internet service providers. If anyone (or nearly anyone) can create an account in your platform and send mail for free, they could compose a message with customized content, send one copy to an external account, then capture that sent message and replay it to millions of people. That's the core risk of DKIM replay: customized (bad) content with somebody else's DKIM signature. In this case, the DKIM signature of the mailbox provider.
B2B or Enterprise Mail accounts. Think Google Workspace or Office365. There's a barrier to entry here, but it's lower compared to ESPs and CRMs. While bad guys could perhaps utilize these platforms in a way similar to MBPs/ISPs to create and replay messages, the ease and value for a bad guy is much lower. And many of these platforms have default DKIM domains or subdomains (like gappssmtp.com or onmicrosoft.com) that don't have ready-made large-volume good sending reputations to leverage.
There's no easy way to fully prevent DKIM replay attacks today. But there are things that domain owners and platform owners can do to help prevent and mitigate replay attacks, and those things include:
Using the DKIM x= setting in DKIM to expire signatures quickly to prevent long term replay of messages. Be aware: The DKIM spec says don't do this. This merits further discussion, so I'll leave it at "it's something to think about" for today.
DKIM key rotation -- increment that selector and implement a new key. A great way to prevent bad guys from building up a long term corpus of messages for them to replay over time. And if you have a DKIM key rotation plan in place, you'll be well prepared to manually rotate out a key if/when you observe your domain's reputation being subject to a DKIM replay attack.
Oversigning -- meaning linking your DKIM signature to various header fields even if they're not included in the original message. This prevents bad guys from customizing content post-send by adding headers. As mentioned above, reducing the ability to create/modify content limits the usefulness of a DKIM replay attack.
Limit free access to bulk email sending tools. If your ESP/CRM platform isn't the easiest target as far as free access to create/send emails, the bad guys will be likely to skip over you and look elsewhere.
Impose limits on new free webmail/MBP accounts to try to limit signups created just to create content for DKIM replay and nothing else.
Filter outbound mail, if at all possible. Bad guys want to link to bad things and those bad things sometimes have their own bad domain reputation. Prevent their inclusion in content and you reduce the ease by which a bad guy can implement their DKIM replay attack plans.
Receivers can help mitigate the impact of DKIM replay attacks, too. Here's a few thoughts on how:
Check and enforce RFC 5322 header compliance, like Gmail does. This closes off yet another exploitable feature utilized by bad guys engaging in replay attacks.
Demand successful results, and alignment, for both SPF and DKIM. This is controversial as it changes DMARC authentication checks from "either/or" passing to "both are required to pass." Would it help stop DKIM replay attacks? Likely so. It opens up a whole other can of worms -- for example, how it would affect email discussion lists (mailing lists) -- you can find more on my thoughts on DMARC and mailing lists all over Spam Resource (and it's the same problem), so I won't go into that deeper here.
Check for inbound traffic peaks. If a domain sends little mail but suddenly sees an influx of DNS traffic to validate DKIM signatures in vast quantities of email, this could indicate DKIM replay in progress.
Count number of equal inbound DKIMs/To's. Similarly, a disparity between expected amount of DKIM keys used/messages sent versus what you're observing out in the world, could indicate a replay attack.
And what about the future? Future enhancements to the DKIM spec -- or MBPs customizing how they handle inbound authentication, to require both DKIM and SPF pass and alignment (instead of either/or today) or bringing the sending IP address back into the authentication equation, either or both of these steps seem likely. Gmail seems to be taking a step in this direction today.
The three of us freely offered up our thoughts and experiences in this week's webinar -- and I've done my best to recap it all here, but please don't fault either Sebastian or Fredrik for any typos or bits I might have gotten wrong above. And please don't think this is the full, definitive guide to DKIM replay! It is meant to be a starting point, and something to build on.
My friends at the Certified Senders Alliance put on a fantastic (if I do say so myself) webinar this week, where Sebastian Kluth (CSA), Fredrik Poller (Halon) and yours truly (Al Iverson) shared our thoughts and understanding about DKIM Replay Attacks. If you missed it, never fear! I've got a recap and recording for you below.
An Overview of DKIM Replay: Email forwarding with malicious intent
A DKIM replay attack involves taking an already sent message and re-injecting it via SMTP to new recipients. Often, lots of recipients. Bad guys utilize a loophole in the concept of DKIM authentication in that DKIM was meant to allow for email forwarding without failing authentication, so authentication signatures are based on the domain, content and headers, without any consideration for what server (or what IP address) transmitted that email message. Authentication is effectively divorced from infrastructure and encased entirely with the email message itself.
Bad guys attempt DKIM replay attacks to steal domain reputation, with hopes of getting their unwanted garbage mail delivered. If I'm able to send an email to a million people using a DKIM signature published and signed by gmail.com, I look like gmail.com to mailbox providers and spam filters. If gmail.com has a good reputation, I get good inbox delivery -- at least until I send enough bad mail to negatively impact that domain's reputation. And if I'm the real deliverability manager or postmaster for gmail.com, I could see my domain reputation tank and deliverability problems appear, based on sends I didn't initiate or intend to allow -- and might not even know about!
Executing DKIM replay is very simple from a technical perspective.
The resulting message passes DKIM authentication successfully, as long as neither the message body or signed message headers were modified at any point. The message likely will fail SPF authentication, as the IP address of the server sending the mail is a new one -- but with DKIM passing, DMARC is likely to pass, and the mail effectively passes enough authentication checks to be considered legitimate. This is not to say that authentication success bypasses spam filtering -- inbox placement isn't guaranteed, but if a bad guy executes this against a domain with a good reputation, they may be able to leverage that good reputation for a period of time.
Content is part of the equation as well. A bad guy wants to send you his bad content, to get you to click on his bad links, to buy his bad product or fall prey to his bad scheme. The risk level here varies for different types of email sending engines or platforms, and it's partly based on that ability to customize content.
ESPs or CRM tools, aka email service providers and customer relationship management tools. Though the content is defined by the user, that user generally has to pay to sign up for access to these tools. A bad guy is (at least somewhat) dis-incentivized to take ESP/CRM content and execute a DKIM replay to a million other people, as they had to pay to even get into the editor to be able to send that initial message. And they might have also had to configure their own DKIM domain, meaning they'd be stealing … from themselves.
A bad guy could instead just take a bulk email message they received (like, say, a message selling shoes from Adidas) and replay that message to a million people -- but without being able to change the message content. Thus they could "replay to annoy" but without little option for financial gain.
MBPs or ISPs, aka mailbox providers and internet service providers. If anyone (or nearly anyone) can create an account in your platform and send mail for free, they could compose a message with customized content, send one copy to an external account, then capture that sent message and replay it to millions of people. That's the core risk of DKIM replay: customized (bad) content with somebody else's DKIM signature. In this case, the DKIM signature of the mailbox provider.
B2B or Enterprise Mail accounts. Think Google Workspace or Office365. There's a barrier to entry here, but it's lower compared to ESPs and CRMs. While bad guys could perhaps utilize these platforms in a way similar to MBPs/ISPs to create and replay messages, the ease and value for a bad guy is much lower. And many of these platforms have default DKIM domains or subdomains (like gappssmtp.com or onmicrosoft.com) that don't have ready-made large-volume good sending reputations to leverage.
There's no easy way to fully prevent DKIM replay attacks today. But there are things that domain owners and platform owners can do to help prevent and mitigate replay attacks, and those things include:
Receivers can help mitigate the impact of DKIM replay attacks, too. Here's a few thoughts on how:
And what about the future? Future enhancements to the DKIM spec -- or MBPs customizing how they handle inbound authentication, to require both DKIM and SPF pass and alignment (instead of either/or today) or bringing the sending IP address back into the authentication equation, either or both of these steps seem likely. Gmail seems to be taking a step in this direction today.
The three of us freely offered up our thoughts and experiences in this week's webinar -- and I've done my best to recap it all here, but please don't fault either Sebastian or Fredrik for any typos or bits I might have gotten wrong above. And please don't think this is the full, definitive guide to DKIM replay! It is meant to be a starting point, and something to build on.
And now, if you missed it, here's the recording of our DKIM Replay Attacks webinar:
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.