[HN Gopher] BIMI and DMARC Can't Save You: The Overlooked DKIM E...
___________________________________________________________________
BIMI and DMARC Can't Save You: The Overlooked DKIM Exploit
Author : obscurette
Score : 112 points
Date : 2024-05-17 13:42 UTC (9 hours ago)
(HTM) web link (www.zone.eu)
(TXT) w3m dump (www.zone.eu)
| hultner wrote:
| 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_ wrote:
| 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.
| brightball wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I was thinking this was the next step for me and mail server.
|
| https://www.validity.com/blog/how-to-explain-authenticated-r...
| gjsman-1000 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| cameronh90 wrote:
| If we were going to do this, can we come up with a well
| defined subset/derived specification of HTML5 for email,
| along with a conformity test ala Acid2/Acid3?
|
| Outlook for Windows still uses the venerable Microsoft Word
| HTML rendering engine.
| dsr_ wrote:
| Sure. My primary request is that it not be allowed to
| show links as anything other than full URLs.
|
| My secondary priority is in not loading anything from an
| external site.
| gjsman-1000 wrote:
| Unfortunately, we know that most people who aren't in
| tech, are terrible at reading and understanding URLs to
| begin with, so I'm not sure that there's any point to be
| gained here.
| mvid wrote:
| The benefit of email is its ubiquity and existing
| deployment. Throwing it away for a new protocol loses all
| existing value.
| gjsman-1000 wrote:
| The same could be said of HTTP, but we threw it away in
| favor of HTTPS. Thank goodness we did - and I don't think
| anyone wants to go back to the time we tried securing
| HTTP without HTTPS.
|
| Again, my proposal is not that we completely kill classic
| email - but rather, we make a new standard, the big
| players get on board, and there's a clear deadline that
| says "your emails will always be junk past this date if
| they don't comply." They'll still arrive though. Nobody
| wants their emails to go to Junk automatically - that's
| incentive enough.
|
| This is like what we did with HTTP. There came a day
| where HTTP login screens now have warnings in many
| browsers. But they still work.
| crote wrote:
| But we didn't. There are still plenty of HTTP-only
| devices out there, and there isn't a single browser out
| there which refuses to work with HTTP servers. Heck, you
| don't even get a warning if you're just reading the
| website - you only get that when you try to log in!
|
| If we can't do the equivalent of "your emails will always
| be junk past this date if they don't comply" with HTTP,
| what makes you think we can do it with email?
| gjsman-1000 wrote:
| I answer that, email is a very different beast than HTTP.
|
| 1. If we were to transition to my hypothetical Email2,
| that doesn't mean it's all or nothing. The transition to
| HTTPS, does not mean that HTTP no longer is readable.
| Similarly, the transition would not mean classic emails
| are automatically unreadable either - but there's a
| strong incentive for corporations relying on it to fix
| it.
|
| Hypothetically, there would be an MX2, and an MX record.
| MX would be the fallback for if MX2 sending is not
| available. So if an out-of-date client from 10 years ago
| sends an email, it finds the MX record and sends it, no
| problem. However, the receiver expecting MX2,
| automatically classifies the email as Insecure and Junk.
| Meanwhile, an MX2-enabled sender could identify the MX
| record for a website that does not support MX2 yet, and
| still deliver the message.
|
| 2. Email is not the same as a device. Most emails are
| sent from an email server with hundreds of inboxes. Take
| Google and Microsoft - they are 40% of global email
| traffic. Add Yahoo, GoDaddy, and the other big names, and
| you're well on the way. Unlike HTTP, the transition may
| actually be much quicker, because self-hosting email is
| not very popular (and those that do, are using commercial
| or open-source packages which could easily add support).
| j-bos wrote:
| I use firefox and always get a warning when accessing an
| http only site.
| jerf wrote:
| "If you could even just get Gmail, Outlook, Zoho, and
| Yahoo"
|
| Well, that's where you hit the blocker I'm talking about.
| They're only on board if there's some sort of benefit they
| can get from closing the standard.
|
| I didn't think of this when I wrote my post first, but
| we've basically been down this road in something close
| enough to be relevent: Instant messaging. Such interop as
| was supported has been the result of the open source
| community laboriously fighting against the commercial
| interests... and, ultimately, losing comprehensively.
| Nobody is interested in a standardized instant messaging
| system.
| jeffbee wrote:
| You missed basically all of the practical details of sending
| and receiving mail. The people who wrote these RFCs and mail
| systems have been doing this for decades and have the
| experience to avoid the "why don't we simply [[wave arms]]"
| traps.
|
| The reason that DKIM signs only enumerated headers is because
| mailers add more headers as the message is in transit, and
| there is no way to sign _those_.
| kbolino wrote:
| Well, the expanded payload could be signed again, just not
| with the same key.
| toast0 wrote:
| You missed that servers processing email routinely add or
| adjust headers. And some servers add trailing content.
|
| DKIM was designed to work with email as it exists, so the
| signer can pick which headers to include in the signature. And
| l= was included to allow for mailing list servers and other
| things to add trailers without breaking signatures or needing
| to sign again.
| magicalhippo wrote:
| But does the recipient need to trust those headers?
|
| Couldn't it just remove those non-signed headers before
| decoding.
|
| If not, what does it really buy you? Slight fuzzy feeling?
|
| In the article they describe an attacker changing Content-
| Type as it's typically not signed. That seems like exactly
| the kind of header you'd want to ignore if not signed.
| Avamander wrote:
| > In the article they describe an attacker changing
| Content-Type as it's typically not signed. That seems like
| exactly the kind of header you'd want to ignore if not
| signed.
|
| That would result in a lot of unreadable emails
| unfortunately. It would also take over-signing the Content-
| Type to mitigate this issue, having everything signed that
| way would certainly break even more.
| anamexis wrote:
| You've more-or-less described DKIM. You can see some issues
| with it here:
| https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail#Wea...
| SAI_Peregrinus wrote:
| Step 2 is wrong, you want a signature, not encryption. For RSA
| that's more like a decryption with the private key, though
| still different because the padding isn't the same.
| peanut-walrus wrote:
| How often should the key be rotated? How is the rotation done?
| How are body and headers normalized? Which header determines
| who sent the email? How do you know the email was sent to you?
| Where do you store the on-path routing information?
| jesprenj wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > genuine email passes through relays which add random crap
| to the end of them
|
| Including your receiving SMTP server
| mschuster91 wrote:
| 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.
| X-Istence wrote:
| The length header in DKIM only pertains to the body of the
| message. Received headers should never be signed by DKIM, and
| those are added to give you a way to trace how a message was
| handled.
| crote wrote:
| 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 wrote:
| > 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
| riedel wrote:
| Can someone explain to me why this was only disclosed to
| Microsoft, Google and Apple? Is this considered responsible in
| this case?
| guipsp wrote:
| Given that they are the biggest email service providers, yes
| obscurette wrote:
| 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.
| neglesaks wrote:
| 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 wrote:
| 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 wrote:
| Shameless plug: My DMARC Checker at 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 wrote:
| Cool, this is helpful. Thank you!
| LeonM wrote:
| 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/
___________________________________________________________________
(page generated 2024-05-17 23:02 UTC)