Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Encryption Google Security Technology

How a Google Headhunter's E-Mail Revealed Massive Misuse of DKIM 115

Posted by Unknown Lamer from the insecurity-through-blatant-idiocy dept.
concealment writes with a tale of how an email sent to a mathematician led to him discovering that dozens of high profile companies were using easily crackable keys to authenticate mail sent from their domains. From the article: "The problem lay with the DKIM key (DomainKeys Identified Mail) Google used for its google.com e-mails. DKIM involves a cryptographic key that domains use to sign e-mail originating from them – or passing through them – to validate to a recipient that the header information on an e-mail is correct and that the correspondence indeed came from the stated domain. When e-mail arrives at its destination, the receiving server can look up the public key through the sender's DNS records and verify the validity of the signature. Harris wasn't interested in the job at Google, but he decided to crack the key and send an e-mail to Google founders Brin and Page, as each other, just to show them that he was onto their game."
This discussion has been archived. No new comments can be posted.

How a Google Headhunter's E-Mail Revealed Massive Misuse of DKIM More

How a Google Headhunter's E-Mail Revealed Massive Misuse of DKIM

Comments Filter:

  • Vote for me (Score:4, Funny)

    by Anonymous Coward on Wednesday October 24, 2012 @12:30PM (#41754365)

    This is Obama, please vote for me. This email is from me, you can verify it using DKIM public keys.

    Regards
    Romney

  • Strong DKIM keys and compatability issues (Score:1)

    by Anonymous Coward

    It's possible that some of the short DKIM keys were due to concerns over compatibility with other systems. When you have a large heterogeneous environment like email, you sometimes get caught catering to the lowest common denominator.

    DKIM keys can exceed the TXT DNS record limit or the UDP byte limit. Some software may not handle joining split TXT DNS records. Others may handle DNS over UDP but not handle TCP for long records.

    • The Reality (Score:5, Insightful)

      by MightyMartian ( 840721 ) on Wednesday October 24, 2012 @12:39PM (#41754461) Journal

      So the reality is that, on top of being useless as an anti-spam mechanism, it now turns out to be even worse, and in fact vulnerable to malicious attacks. In other words, it's useless and uselesser.

      I was heavily involved in a lot of the discussions surrounding SPF, DKIM and related "solutions" back in the early 2000s, and about the most that we could say about these "solutions" was that you could add a positive number to the score of an email in a weighting system if things checked out, but other than that, there was little to recommend them.

      • Re: (Score:2)

        by 1s44c ( 552956 )

        Serious question - What does DKIM do that SPF doesn't?

        • DKIM has a key. Not that that makes it any more useful.

        • Re: (Score:3, Insightful)

          by Medievalist ( 16032 )

          Serious question - What does DKIM do that SPF doesn't?

          DKIM is intended to allow mail sent through any server to be shown to be originally from a specific domain, thus preventing spoofing which is the basis of most spamming. SPF just allows server(s) to be identified as valid mailers for a domain, it doesn't work if you forward mail through other undesignated systems (which is still pretty significant, and covers most legitimate use cases).

          If you're not checking SPFv1 on incoming mail, you're not a competen

          • Re: (Score:3)

            by XanC ( 644172 )

            Except SPF is broken by design and shouldn't be used nor its use encouraged, ever.

            • Care to explain why?

                • And that's why they created DMARC. DMARC allows you to specify exactly how mail servers should treat your SPF and DKIM policies. Additionally, you'll get reports from the providers processing it what the origin IPs claiming to deliver email from you are and whether or not they were allowed.

                  There's also one little note that the entire linked "why not spf" article is based on too...the DMARC reports also include whether or not the mail was forwarded so that mail servers know how to handle it.

                  The three techn

              • If you are doing mail forwarding or certain kinds of mailing list paradigms, you can have difficulties with SPF - you'll have to go straight to DKIM or change the way you use mail.

                However, the absolute statement the prior poster made is the cry of a butthurt spammer - SPF keeps him from spoofing your address, so it's hurting his v14gr/-\ sales. Spammers hate SPF more than taxes... it's so trivially easy to implement that it's a real threat to their business model. DKIM's even worse for them, but it's also

                • Thats why I like SPF. If it doesnt fit your needs, dont use it. But for those of us who have SMB clients who mail from one mailserver and dont use forwarders, its wonderful-- the first time someone reports forged email from our addresses, I can take 5 mins and implement SPF, problem solved for folks with decent spamfiltering.

          • Oh, and also DKIM serves as a message checksum, so you can be reasonably sure an email wasn't tampered with after it left the sender.

          • Re: (Score:2)

            by 1s44c ( 552956 )

            Thanks for the explanation.

        • In a nutshell:
          In DKIM
          -Email provider sets up DNS records with a public DKIM key.
          -Email provider's MTA signs valid outgoing email with the private key.
          -Recipient MTAs can verify the signature of incoming mail from the email provider with the public key and use this when classifying the message.
          -The MTA has to receive the message contents to verify the signature.

          In SPF
          -Email provider sets up DNS TXT records that specify which hosts are allowed to send mail for a domain.
          -Email recipient verifies that the mail

      • I wonder how many convictions and court judgments relied solely on DKIM evidence that an email came from a defendant, all other evidence being circumstantial. I wonder what potential exist for such decisions to be overturned.

        • Re: (Score:2)

          by TheCarp ( 96830 )

          As for convictions, very few. Based first on my small amount of exposure to trial related forsensics, lawyers are nowhere near so familiar with technology that I am willing to believe that this type of technological point comes up that often.

          Beyond that though, very few cases ever actually go to trial, mostly because the past few decades have seen the "justice" system ramp up its program of making sure that the list of charges that you are threatened with if you don't take a plea deal is so large, that even

          • Re: (Score:2)

            by psmears ( 629712 )

            As for convictions, very few. Based first on my small amount of exposure to trial related forsensics, lawyers are nowhere near so familiar with technology that I am willing to believe that this type of technological point comes up that often.

            Plus of course the fact that DKIM usually identifies the domain, rather than the user, so it would generally only be evidence that the email came from a specific ISP (or company), rather than a specific person, which is much less useful.

      • Re: (Score:2)

        by Qzukk ( 229616 )

        was that you could add a positive number to the score of an email in a weighting system if things checked out

        If things don't check out, I have spamassassin assign -4 (out of -5 to be spam). If things check out it gets +0.

        • Oh Christ! The last thing on Earth I would ever do is give a negative score to SpamAssassin's rating based on failed or missing SPF and DKIM records. Hell, even missing reverse records, which is popular with some anti-spam folks, lead to way too many false positives.

          • Hell, even missing reverse records, which is popular with some anti-spam folks, lead to way too many false positives.

            There is a current email by radio system that is intended for use in catastrophic events as a way of communicating outside the disaster area for things like requests for aid and other important traffic. The radio to internet mail transport checks for MX records for every destination server, and silently throws the email away if there isn't one. The sender gets no notice of failure. The recipient doesn't get anything. Just no communications.

            And none of the inbound email servers for the internet to radio si

            • I can understand using SPF and DKIM to that degree in specialized situations. But if you're running a general-use mail server, I think negative scoring based on faulty or missing SPF and DKIM records is asking for an unacceptable number of false positives. I know a lot of mail admins over the years have stood on principle over this sort of thing, and the ISP I was working for did for a while, but increased customer complaints finally lead us to the conclusion that the amount of spam SPF and DKIM scoring sto

      • So the reality is that, on top of being useless as an anti-spam mechanism, it now turns out to be even worse, and in fact vulnerable to malicious attacks. In other words, it's useless and uselesser.

        So if the reality is that it was already useless as an anti-spam mechanism, who cares if it is made "uselesser" as an anti-spam mechanism? Less that zero is still less than zero. If you already can't trust it to mean what it says, why is there such a tizzy that you still can't trust it to mean what it says?

        • The problem is that inexperienced mail admins seem to have a considerable amount of faith in SPF and DKIM, and a good decade or so has passed since these methods were first developed, so the debate around why they are fundamentally flawed is in the past.

          The only reason I even have SPF and DKIM records on our mail servers is because some dumb-asses out there do negative weight based on an absence of those records.

      • How exactly do you spoof SPF without having the ability to redirect mail flow (ie, control over DNS records)?

  • There was no misuse (Score:5, Insightful)

    by hawguy ( 1600213 ) on Wednesday October 24, 2012 @12:38PM (#41754457)

    This was not a misuse of DKIM, or perhaps it was his own misuse in that he thinks DKIM validates the sender of an email. All it does is validate that the email originated from Google's mail servers, but it doesn't neccessarily mean that the address in the From: header wasn't spoofed before it was signed.

    In any case, he found that Google (and others) are using an easily cracked 512 bit key, which they silently fixed with a 1024 bit key after he reported it to them by spoofing an email to appear as though it originated at Google.

    There was no misuse, 512 bit keys are allowable under the DKIM spec, though they aren't recommended for long-lived keys.

    • Re: (Score:1)

      by griego ( 1108909 )

      Yeah, one guy cracks a key and sends two emails with it. Where is the "massive misuse"?

    • It was bad phrasing. Google didn't misuse DKIM as much as it negligently implemented DKIM. The big news was that HSBC and other high-security websites were using weak implementations of DKIM. The problem is that people may rely on DKIM authentication as a sign that it's not phishing. ("Hey, this email from HSBC was signed by DKIM so it's not fake. I guess I'll send a $10,000 check to these guys.")

      I am also curious how many keys is used in the Google Apps Premier DKIM. I have a domain with Google Apps, and i

    • Re: (Score:3)

      by SSpade ( 549608 )

      It's more than "aren't recommended".

      RFC6376: "Signers MUST use RSA keys of at least 1024 bits for long-lived keys."

      Given Google were using a long-lived key, they were violating a MUST provision in the DKIM spec. (Pedantically, that means they weren't sending DKIM compliant mail at all).

      • Keep in mind that RFC 6367 was issued in September 2011. Prior versions did allow 512-bit keys.
        • That update changed what it meant to be DKIM compliant. From the time of their initial DKIM implementation to September 2011 they were DKIM compliant, as of September 2011 Google was not DKIM compliant, since they have fixed the issue they now are compliant again.
      • Oh, sorry. I didn't notice you were the same person I replied to above. Please excuse the repetition (though I'll point out that it was triggered by your repetition :-) ).
    • From hawguy:

      which they silently fixed with a 1024 bit key after he reported it to them...

      From TFA:

      Harris made sure the return path for the e-mails went to his own e-mail account, so that Brin and Page could ask him how heâ(TM)d cracked their puzzle. But Harris never got a response from the Google founders. Instead, two days later, he noticed that Googleâ(TM)s cryptographic key had suddenly changed to 2,048 bits. And he got a lot of sudden hits to his web site from Google IP addresses.(emphasis mine)

  • Individual's sharp-mindedness against corporate stupidity. Happens all the time. I'm proud to be an individual having studied mathematics, even if I landed in IT later on...

  • that Swordfish was a premonition — Hugh Jackman really does crack encryption...

    • that Swordfish was a premonition - Hugh Jackman really does crack encryption...

      He also apparently likes to channel DaVinci and write backwards from his POV

  • Sigh (Score:5, Insightful)

    by EdwinFreed ( 1084059 ) on Wednesday October 24, 2012 @12:46PM (#41754535)
    Shame on Google for using a weak key, but also shame on this article for being more than a little hyperbolic.

    If you, you know, actually read the standard, or even the Wikipedia page, you'll see that DKIM is not intended to be used as a signature mechanism in the same way as S/MIME or PGP. Rather, it's a means to assert responsibility for sending the message, it's done at the domain rather than user level, and verification results are intended to be used for message filtering, not for asserting that so-and-so actually signed the message.

    Sure, the underlying technology is based on hashes, signatures, signature verification, and so on but that's because there's no other way to do it. The fact that DKIM allows for the application of relaxed interpretation of both message header and body data kinda tells you it's not intended to be used to provide an absolute assurance that what you got is authentic in every way.

    DKIM is also not intended to be the ultimate source of information for filtering. Rather, DKIM results are supposed to be combined with other metrics to form an overall assessment of message validity. And that's a very good thing, since I get all sorts of spammy stuff that makes it through Google, including getting a legitimate DKIN signature attached. Other filtering mechanisms are needed to block such crap.

    All that said, it's very disappointing to see yet another case where Google has seen fit to play fast and loose with standards. This is happening much too often.

    • Re: (Score:1)

      by Anonymous Coward

      The problem is that signing implies a level of trust that spam filters at Google take into account. So, unless you are a spammer, it is indeed a giant problem to have weak keys.

    • Re: (Score:2)

      by fm6 ( 162816 )

      Rather, DKIM results are supposed to be combined with other metrics to form an overall assessment of message validity.

      Which is exactly how my Tuffmail account is configured to use it. Unfortunately, there are many borderline cases where using DKIM is just enough to make my filters decide to forward it. I'm seeing the protocol as pretty useless.

    • All that said, it's very disappointing to see yet another case where Microsoft has seen fit to play fast and loose with standards. This is happening much too often.

      Fixed that for you. Well, at least it's true in general if maybe not so much in this specific case.

      • I fail to see the relevance. Yes, Microsoft has played fast and loose with various standards, including some critical ones in email. And the surrounding the handling of text/plain as text/each-long-line-is-a-paragraph plus the failure to support format=flowed is arguably the email standards violation with far and away the most impact.

        But this doesn't mean Google doesn't also have a lot to answer for. Gmail IMAP compliance in particular is pretty bad, and SMTP handling of error conditions pushes things ri

  • Is it this guy's supposition that Brin and Page were using weak, crackable keys deliberately?

    • Re: (Score:3)

      by malakai ( 136531 )

      It's a horrible article. It's really trying to make out like it was some cloak and dagger, crypto-cracking fu used by this 'mathmatician' against the founders of Google. He mentions ( many times, like The Lady Doth Protest Too Much, methinks... ) that he thought it was an elaborate test. I read his take on this to be a defensive argument, in case they choose to go after him for spoofing e-mails. Which is what he did.

    • Comment removed based on user account deletion

  • I had until more recently been getting a bunch of "backscatter" hits to my gmail hosted account.
    While the return message seemed legit, the email that supposedly went out from (an nonexistent account) at my domain was not.

    I wonder if the spammers were already taking advantage of this vulnerability. I do notice that more recently I haven't got any of these.

  • Half the spam that makes it through my filters is DKIM-signed. Spammers use it to make the email look less bogus. Of course, that means that they have to use a real domain and hosting provider that they eventually lose — but domains are cheap, and changing hosts is no big deal.

    • > Half the spam that makes it through my filters is
      > DKIM-signed.

      Same here, and half of that is signed by Yahoo. I'm seriously considering telling Spamassassin to increase the spam score of DKIM-signed messages, not decrease it.

      • Re: (Score:2)

        by fm6 ( 162816 )

        I've configured Sieve to bounce all mail from Yahoo, except for a few relatives who use it.

  • Ru-oh!

    I'd better take a closer look at the automatically generated DKIM keys for the several Google Apps domains I oversee....

  • Vulnerability Note VU#268267 (Score:5, Informative)

    by DERoss ( 1919496 ) on Wednesday October 24, 2012 @01:22PM (#41754949)

    This problem has been reported by the US-CERT (part of the US Department of Homeland Security [Insecurity?]) at http://www.kb.cert.org/vuls/id/268267 [cert.org]. See that link for an authoritative report on the meaning of this problem and how to avoid it.

  • That's what I would think as well! (Score:3)

    by SoTerrified ( 660807 ) on Wednesday October 24, 2012 @01:34PM (#41755087)

    From the article, the line:
    Harris thought there was no way Google would be so careless, so he concluded it must be a sly recruiting test to see if job applicants would spot the vulnerability.

    That's exactly how I would think.

  • I don't know if it is still true. I no longer attend all those export compliance meetings. But when I used to we used worry about the cryptographic key lengths. If we use any crypto algo that is stronger than a certain threshold we need to run them through some national security agency (lack of capitalization very intentional). It is very much possible they were using a weaker key when those regulations were in place. Either they completed the paper work to release a software produce stronger than 512 bits
  • Instead, two days later, he noticed that Googleâ(TM)s cryptographic key had suddenly changed to 2,048 bits. And he got a lot of sudden hits to his web site from Google IP addresses.

    So, googlers: How'd misc react to this? I can see all sorts of spoofing fun going on...

    -B

  • There's no way he seriously believed this was a sly test the recruiters were sending out to weed applicants. He's just saying that to cover his ass if Google actually peruses him legally for what he did.

    But really though, all this system is for is for certifying that mail actually did come from a specific domain, not a specific sender. I'm not seeing the huge misuse here.

Slashdot Top Deals

If it wasn't for Newton, we wouldn't have to eat bruised apples.

Close