7 ms·

BIMI and DMARC Can't Save You: The Overlooked DKIM Exploit

123 points by obscurette 2y ago

hultner 2y ago
Interesting, does anyone have a list of known providers vulnerability to this in the past? I'm thinking big providers like G-Suite, Office 365, Zoho, Fastmail, etc.
dsr_ 2y ago
BIMI is useless. SPF and DKIM are flawed. DMARC is a patch on top of SPF and DKIM. If you want to be able to trust email, you need a trustworthy PKI. If you want to communicate with people who don't or can't participate in the PKI, you need a mail client that rigorously and clearly distinguishes the anonymous from the verifiable. Given the existence of two parallel email systems, some people will run gateways that create artificial verification of non-verifiable messages. Now you need to figure out reputations for all the gateways. In the end, you always end up with spam and forgeries.
- throwaway984393 2y ago
  [dead]
- brightball 2y ago
  100%. BIMI is the carrot for the marketing department to get on board with the DMARC project while giving the same people who sold you EV-SSL something else to sell you. But this is a solid explanation of a DKIM issue that should be simple enough to avoid. Good write up.
  - egberts1 2y ago
    BIMI gives you ONLY logo spreading of your choice. BIMI, marketers' dream. BIMI, yours for only $999.99 per year. Just for $999.99, you too could enjoy stuffing Ensure's pocket too!
- Avamander 2y ago
  I think BIMI works well as a motivator and spotlight to bring attention to these issues. I also think your average user won't mind it. Implementing it as a receiver is full of pitfalls, as we can see.
- detourdog 2y ago
  I was thinking this was the next step for me and mail server. https://www.validity.com/blog/how-to-explain-authenticated-received-chain-arc-in-plain-english/ https://www.validity.com/blog/how-to-explain-authenticated-r...
throwaway984393 2y ago
[dead]
gjsman-1000 2y ago
This is all ridiculous. Maybe I’m not that bright, but it seems like you don’t need that much. 1. A TXT record containing a public key and a unique identifier 2. Message Body and Headers hashed with SHA512, and then the hash is encrypted with the private key to the TXT record. This hash, and the address for the public key, is then added to the headers as the only permitted “untrusted” headers 3. Email receiver, if present, ignores all headers if the two are present. Looks up DNS public key, decrypts hash, removes the two headers, checks hash matches. If so, contents trusted if: 4. The domain the email was sent from, and claims to be sent from, is the same domain hosting the TXT record. What did I miss?
- jerf 2y ago
  You don't need all that much to ensure integrity in a brand-new system without decades of legacy. I mean, still non-trivial, getting that "not much" right is a professional cryptographer's job, but you don't need all that much. Getting it right in a system the size of the world with decades of legacy in an environment where right up until DKIM came out pretty much every player in the system expected and used the ability to make arbitrary modifications to emails passing through it is really hard. It makes even the simplest thing takes decades. Unfortunately, there isn't going to be a replacement to email either, because at this point anyone with the resources to pull it off will also insist on making it a closed box that you have to pay way, way too much to use.
  - gjsman-1000 2y ago
    I’m a bit nuts, so bear with me: Maybe we should seriously have discussions about, let’s just call it, Email2. We have a new DNS record type, MX2, with a proper signing algorithm that’s mandatory. Meanwhile, we put it in spec that every MX2 mailbox, must be a valid MX mailbox, if the receiver chooses to accept MX. This might sound insane - except, I argue, with proper planning, it would be like the HTTPS transition. If you could even just get Gmail, Outlook, Zoho, and Yahoo on board - every piece of software would be forced to start supporting Email2. Especially, especially, if they announced that come 2030, all non-Email2 letters always go to Junk. They’ll still arrive - possibly forever - but the incentive to fix it will be there.
jesprenj 2y ago
What is the intended use case for the l= parameter? Why not sign the entire email all the time? Why would anyone want to use l=1 ?!!1
- ajross 2y ago
  Presumably because RFC822 is a legacy format and there are weird implementations out there that do things (e.g. something as simple as adding a header or signature!) that would mutate data used in a signature. This allows you to carve out a spot for the insecure stuff you can't otherwise get rid of. Obviously it also carves out a spot for an attacker to put their own stuff in, and thus relies on downstream parsing to not get fooled[1]. Which is terrible security design in a from-scratch system. But with legacy stuff... there often isn't a choice. Security is just hard. [1] The article isn't clear, but the closest to a root cause bug in this particular instance is actually that the mail client is validating the signature, but failing to recognize that there is unsigned data being presented to the user as part of the message. That's a tall order for client code, but that's where this particular design put the responsibility.
- crote 2y ago
  Because email has been used in a wide range of ways in the past, including some where genuine email passes through relays which add random crap to the end of them. The same applies with email headers: you can't sign all of them, because random headers will be added in-flight. The parameter is a hack to prevent such relays from completely breaking it. But I agree, it should've never been used in the first place because it completely undermines the whole concept of signing email. There should be a very clear separation between signed and unsigned.
  - CodeWriter23 2y ago
    > genuine email passes through relays which add random crap to the end of them Including your receiving SMTP server
- mschuster91 2y ago
  Because every server an email passes through will at least add its own Received header, and every antispam, DLP and antivirus crap appliance in the chain adds another one or more. Usually, you have 1-3 Received header from the sending email organization (record I've seen is five - three ordinary mailservers and two for AV and DLP crap), then you got Proofpoint adding 2-3 layers, and then MS Exchange or whatever adding 4-6... That's why the sender only signs those headers he himself is aware of and sent out. Oh, and then you got the even worse cases, email servers actually modifying the body to add "Inspected by <Bullshit Snakeoil>" footers.
crote 2y ago
Aw geez, that's a really nasty bug. So with DKIM you're signing some headers and the body. DKIM has a "body length" tag, "l=". Contrary to its name it doesn't say anything about the body length, but it specifies the length of the content being signed - so an attacker can add random crap to the end of the message without invalidating the signature. This combines with multi-part email to essentially let an attacker completely overwrite the message body. To make it even worse, the spec is written quite vague and heavily suggests that inserting "l=" is mandatory, despite also mentioning cases where it isn't present. That's pretty much asking for trouble. And of course all that is made a Serious Problem because DMARC is fundamentally broken and considers a message valid when either SPF or DKIM passes - so it'll happily accept a message with a valid DKIM signature coming from a host who fails SPF.
- citrin_ru 2y ago
  > spec is written quite vague and heavily suggests that inserting "l=" is mandatory RFC [1] suggest the opposite: "To avoid this attack, Signers should be extremely wary of using this tag" > message valid when either SPF or DKIM passes DMARC is already fragile with many legit messages failing DMARC after a forwarding (redirecting) by a mail servers (which change headers and/or body to varying degree with MS mail products being among the worst). If you would require both SPF and DKIM pass even more legit messages will fail DMARC check so more servers will have to ignore it results. [1] https://datatracker.ietf.org/doc/html/rfc6376#section-8.2 https://datatracker.ietf.org/doc/html/rfc6376#section-8.2
- flumpcakes 2y ago
  > because DMARC is fundamentally broken and considers a message valid when either SPF or DKIM passes You can specify if you both to pass and in fact it will enforce strict alignment which is more than SPF or DKIM will do on their own. I think SPF/DKIM is probably broken without strict alignment as it's trivially easy to change your mail from header which is transparent to end users and pass SPF on its own.
riedel 2y ago
Can someone explain to me why this was only disclosed to Microsoft, Google and Apple? Is this considered responsible in this case?
- guipsp 2y ago
  Given that they are the biggest email service providers, yes
- obscurette 2y ago
  The article mentions that this was also disclosed to the local CERT. In Europe, it is usually their task to disseminate such information more widely.
deleted 2y ago
[deleted]
neglesaks 2y ago
I'm impressed that email with POP, SMTP and slightly later, IMAP has served up so well for 30+ years, but by golly, it's an uphill battle running any sort of mail service yourself these days. I starting to understand the businesses that (claim to) run without email to and from customers.
tedunangst 2y ago
The over signing part of DKIM is really confusing. It's easy to overlook and can blow the whole thing wide open. And yet it's not the default, presumably for some reason, so it's unclear what happens if you just go ahead and over sign every header. Is it surprising people get this wrong?
awulf 2y ago
Shameless plug: My DMARC Checker at https://dmarcchecker.app/ https://dmarcchecker.app/ displays a warning message if it encounters a DKIM signature header with an 'l=' tag: "The 'l=' tag limits how many bytes of the email body are included in the body hash. This may allow an attacker to alter/expand the message in a way that it still passes DKIM validation." Additionally, the tool alerts you to the use of weak RSA keys or SHA1. By the way, less than 0.4% of all emails checked make use of the 'l=' tag.
- focusedone 2y ago
  Cool, this is helpful. Thank you!
- telesilla 2y ago
  Dmarcchecker is one of those great things on the internet that you never knew you needed it until you really needed it. Thank you so much for your work on this note project, it's really helpful to us in monitoring our mail security.
LeonM 2y ago
This is an excellent writeup, and great example of responsible disclosure done right. However, I can't get over the clickbait title. This seems like a real cheap shot at BIMI, and DMARC for that matter. BIMI never pretended to be a 'security' protocol of any kind. It's a branding opportunity to incentivize DMARC adoption. That's what is literally explained on the front page of the BIMI workgroup website [0]. I won't go into the discussion whether the price of a VMC is justifiable or not, but saying 'BIMI can't safe you' as if BIMI ever promised it would is just ridiculous in my opinion. DMARC on the other hand is more of a policy protocol than an additional layer of security. Yes, it does strengthen the underlying protocols (SPF & DKIM) a little bit by adding the alignment requirement, which more-or-less patches the worst flaws of both protocols, but it doesn't magically make email secure. Saying 'DMARC won't safe you', as if DMARC was somehow ever capable of fixing 0-days in the underlying protocols is, again in my opinion, ridiculous. I get that the company is proud of the discovery of this security flaw, and that such a publication is a great opportunity them to get your name out. But I just can't shake off the thought of the engineers having to witness some guy from PR slapping a cringy clickbait title on their otherwise excellent work. [0] https://bimigroup.org/ https://bimigroup.org/
- obscurette 2y ago
  While I agree with you, I think that the problem with titles is the battle lost long time ago. In the age of online and social media titles are seen as a way to get an attention. I write regularly columns for a local media and while I'm free to write in any way I want, coming up with titles is the job for an editor, there are sometimes A/B tests done with these etc. Titles for my texts are often too clickbaity for my taste and I hate it, but that's how it's handled today.

123 points by obscurette 2y ago

Interesting, does anyone have a list of known providers vulnerability to this in the past? I'm thinking big providers like G-Suite, Office 365, Zoho, Fastmail, etc.

dsr_ 2y ago

BIMI is useless. SPF and DKIM are flawed. DMARC is a patch on top of SPF and DKIM. If you want to be able to trust email, you need a trustworthy PKI. If you want to communicate with people who don't or can't participate in the PKI, you need a mail client that rigorously and clearly distinguishes the anonymous from the verifiable. Given the existence of two parallel email systems, some people will run gateways that create artificial verification of non-verifiable messages. Now you need to figure out reputations for all the gateways. In the end, you always end up with spam and forgeries.

throwaway984393 2y ago
[dead]
brightball 2y ago
100%. BIMI is the carrot for the marketing department to get on board with the DMARC project while giving the same people who sold you EV-SSL something else to sell you. But this is a solid explanation of a DKIM issue that should be simple enough to avoid. Good write up.
- egberts1 2y ago
  BIMI gives you ONLY logo spreading of your choice. BIMI, marketers' dream. BIMI, yours for only $999.99 per year. Just for $999.99, you too could enjoy stuffing Ensure's pocket too!
Avamander 2y ago
I think BIMI works well as a motivator and spotlight to bring attention to these issues. I also think your average user won't mind it. Implementing it as a receiver is full of pitfalls, as we can see.
detourdog 2y ago
I was thinking this was the next step for me and mail server. https://www.validity.com/blog/how-to-explain-authenticated-received-chain-arc-in-plain-english/ https://www.validity.com/blog/how-to-explain-authenticated-r...

throwaway984393 2y ago

[dead]

gjsman-1000 2y ago

This is all ridiculous. Maybe I’m not that bright, but it seems like you don’t need that much. 1. A TXT record containing a public key and a unique identifier 2. Message Body and Headers hashed with SHA512, and then the hash is encrypted with the private key to the TXT record. This hash, and the address for the public key, is then added to the headers as the only permitted “untrusted” headers 3. Email receiver, if present, ignores all headers if the two are present. Looks up DNS public key, decrypts hash, removes the two headers, checks hash matches. If so, contents trusted if: 4. The domain the email was sent from, and claims to be sent from, is the same domain hosting the TXT record. What did I miss?

jerf 2y ago
You don't need all that much to ensure integrity in a brand-new system without decades of legacy. I mean, still non-trivial, getting that "not much" right is a professional cryptographer's job, but you don't need all that much. Getting it right in a system the size of the world with decades of legacy in an environment where right up until DKIM came out pretty much every player in the system expected and used the ability to make arbitrary modifications to emails passing through it is really hard. It makes even the simplest thing takes decades. Unfortunately, there isn't going to be a replacement to email either, because at this point anyone with the resources to pull it off will also insist on making it a closed box that you have to pay way, way too much to use.
- gjsman-1000 2y ago
  I’m a bit nuts, so bear with me: Maybe we should seriously have discussions about, let’s just call it, Email2. We have a new DNS record type, MX2, with a proper signing algorithm that’s mandatory. Meanwhile, we put it in spec that every MX2 mailbox, must be a valid MX mailbox, if the receiver chooses to accept MX. This might sound insane - except, I argue, with proper planning, it would be like the HTTPS transition. If you could even just get Gmail, Outlook, Zoho, and Yahoo on board - every piece of software would be forced to start supporting Email2. Especially, especially, if they announced that come 2030, all non-Email2 letters always go to Junk. They’ll still arrive - possibly forever - but the incentive to fix it will be there.

jesprenj 2y ago

What is the intended use case for the l= parameter? Why not sign the entire email all the time? Why would anyone want to use l=1 ?!!1

ajross 2y ago
Presumably because RFC822 is a legacy format and there are weird implementations out there that do things (e.g. something as simple as adding a header or signature!) that would mutate data used in a signature. This allows you to carve out a spot for the insecure stuff you can't otherwise get rid of. Obviously it also carves out a spot for an attacker to put their own stuff in, and thus relies on downstream parsing to not get fooled[1]. Which is terrible security design in a from-scratch system. But with legacy stuff... there often isn't a choice. Security is just hard. [1] The article isn't clear, but the closest to a root cause bug in this particular instance is actually that the mail client is validating the signature, but failing to recognize that there is unsigned data being presented to the user as part of the message. That's a tall order for client code, but that's where this particular design put the responsibility.
crote 2y ago
Because email has been used in a wide range of ways in the past, including some where genuine email passes through relays which add random crap to the end of them. The same applies with email headers: you can't sign all of them, because random headers will be added in-flight. The parameter is a hack to prevent such relays from completely breaking it. But I agree, it should've never been used in the first place because it completely undermines the whole concept of signing email. There should be a very clear separation between signed and unsigned.
- CodeWriter23 2y ago
  > genuine email passes through relays which add random crap to the end of them Including your receiving SMTP server
mschuster91 2y ago
Because every server an email passes through will at least add its own Received header, and every antispam, DLP and antivirus crap appliance in the chain adds another one or more. Usually, you have 1-3 Received header from the sending email organization (record I've seen is five - three ordinary mailservers and two for AV and DLP crap), then you got Proofpoint adding 2-3 layers, and then MS Exchange or whatever adding 4-6... That's why the sender only signs those headers he himself is aware of and sent out. Oh, and then you got the even worse cases, email servers actually modifying the body to add "Inspected by <Bullshit Snakeoil>" footers.

crote 2y ago

Aw geez, that's a really nasty bug. So with DKIM you're signing some headers and the body. DKIM has a "body length" tag, "l=". Contrary to its name it doesn't say anything about the body length, but it specifies the length of the content being signed - so an attacker can add random crap to the end of the message without invalidating the signature. This combines with multi-part email to essentially let an attacker completely overwrite the message body. To make it even worse, the spec is written quite vague and heavily suggests that inserting "l=" is mandatory, despite also mentioning cases where it isn't present. That's pretty much asking for trouble. And of course all that is made a Serious Problem because DMARC is fundamentally broken and considers a message valid when either SPF or DKIM passes - so it'll happily accept a message with a valid DKIM signature coming from a host who fails SPF.

citrin_ru 2y ago
> spec is written quite vague and heavily suggests that inserting "l=" is mandatory RFC [1] suggest the opposite: "To avoid this attack, Signers should be extremely wary of using this tag" > message valid when either SPF or DKIM passes DMARC is already fragile with many legit messages failing DMARC after a forwarding (redirecting) by a mail servers (which change headers and/or body to varying degree with MS mail products being among the worst). If you would require both SPF and DKIM pass even more legit messages will fail DMARC check so more servers will have to ignore it results. [1] https://datatracker.ietf.org/doc/html/rfc6376#section-8.2 https://datatracker.ietf.org/doc/html/rfc6376#section-8.2
flumpcakes 2y ago
> because DMARC is fundamentally broken and considers a message valid when either SPF or DKIM passes You can specify if you both to pass and in fact it will enforce strict alignment which is more than SPF or DKIM will do on their own. I think SPF/DKIM is probably broken without strict alignment as it's trivially easy to change your mail from header which is transparent to end users and pass SPF on its own.

riedel 2y ago

Can someone explain to me why this was only disclosed to Microsoft, Google and Apple? Is this considered responsible in this case?

guipsp 2y ago
Given that they are the biggest email service providers, yes
obscurette 2y ago
The article mentions that this was also disclosed to the local CERT. In Europe, it is usually their task to disseminate such information more widely.

deleted 2y ago

[deleted]

neglesaks 2y ago

I'm impressed that email with POP, SMTP and slightly later, IMAP has served up so well for 30+ years, but by golly, it's an uphill battle running any sort of mail service yourself these days. I starting to understand the businesses that (claim to) run without email to and from customers.

tedunangst 2y ago

The over signing part of DKIM is really confusing. It's easy to overlook and can blow the whole thing wide open. And yet it's not the default, presumably for some reason, so it's unclear what happens if you just go ahead and over sign every header. Is it surprising people get this wrong?

awulf 2y ago

Shameless plug: My DMARC Checker at https://dmarcchecker.app/ https://dmarcchecker.app/ displays a warning message if it encounters a DKIM signature header with an 'l=' tag: "The 'l=' tag limits how many bytes of the email body are included in the body hash. This may allow an attacker to alter/expand the message in a way that it still passes DKIM validation." Additionally, the tool alerts you to the use of weak RSA keys or SHA1. By the way, less than 0.4% of all emails checked make use of the 'l=' tag.

focusedone 2y ago
Cool, this is helpful. Thank you!
telesilla 2y ago
Dmarcchecker is one of those great things on the internet that you never knew you needed it until you really needed it. Thank you so much for your work on this note project, it's really helpful to us in monitoring our mail security.

LeonM 2y ago

This is an excellent writeup, and great example of responsible disclosure done right. However, I can't get over the clickbait title. This seems like a real cheap shot at BIMI, and DMARC for that matter. BIMI never pretended to be a 'security' protocol of any kind. It's a branding opportunity to incentivize DMARC adoption. That's what is literally explained on the front page of the BIMI workgroup website [0]. I won't go into the discussion whether the price of a VMC is justifiable or not, but saying 'BIMI can't safe you' as if BIMI ever promised it would is just ridiculous in my opinion. DMARC on the other hand is more of a policy protocol than an additional layer of security. Yes, it does strengthen the underlying protocols (SPF & DKIM) a little bit by adding the alignment requirement, which more-or-less patches the worst flaws of both protocols, but it doesn't magically make email secure. Saying 'DMARC won't safe you', as if DMARC was somehow ever capable of fixing 0-days in the underlying protocols is, again in my opinion, ridiculous. I get that the company is proud of the discovery of this security flaw, and that such a publication is a great opportunity them to get your name out. But I just can't shake off the thought of the engineers having to witness some guy from PR slapping a cringy clickbait title on their otherwise excellent work. [0] https://bimigroup.org/ https://bimigroup.org/

obscurette 2y ago
While I agree with you, I think that the problem with titles is the battle lost long time ago. In the age of online and social media titles are seen as a way to get an attention. I write regularly columns for a local media and while I'm free to write in any way I want, coming up with titles is the job for an editor, there are sometimes A/B tests done with these etc. Titles for my texts are often too clickbaity for my taste and I hate it, but that's how it's handled today.