In my last two posts, I pointed out that the anti-spam technique known as "DKIM" cryptographically verifies emails. This can be used to verify that some of the newsworthy emails are, indeed, correct and haven't been doctored. I offer a 1 btc (one bitcoin, around ~$600 at current exchange rates) bounty if anybody can challenge this assertion.
Unfortunately, bounties attract lamers who think they deserve the bounty.
This faked email show _undetectable_ addition of cc: field (& other fields) and whitespace in email body; no tricks #PayUpRob @ErrataRob https://t.co/X8oUplx2UL— ((( Matt Beebe ))) (@VoteBeebe) October 25, 2016
This guy insists he wins the bounty because he can add spaces to the email, and add fields like "Cc:" that DKIM doesn't check. Since DKIM ignores extra spaces and only checks important fields, these changes pass. The guy claims it's "doctored" because technically, he has changed things, even though he hasn't actually changed any of the important things (From, Date, Subject, and body content).
No. This doesn't qualify for the bounty. It doesn't call into question whether the Wikileaks emails say what they appear to say. It's so obvious that people have already contacted me and passed on it, knowing it wouldn't win the bounty. If I'd pay out this bounty for this lameness, one of the 10 people who came up with the idea before this lamer would get this bounty, not him. It'd probably go to this guy -- who knows it's lame, who isn't seeking the bounty, but would get it anyway before the lamer above:
@ErrataRob super lame i know, but this does pass DKIM sig check in thunderbird. base64 here https://t.co/14EyaBKfNL pic.twitter.com/dG94f5lH8o— Philip (@_miw) October 22, 2016
Let me get ahead of the lamers and point to more sophisticated stuff that also doesn't count. The following DKIM verified email appears to say that Hillary admitting she eats kittens. This would be newsworthy if true, and a winner of this bounty if indeed it could trick people.
This is in fact also very lame. I mean, it's damn convincing, but only to lamers. You can see my trick by looking at the email on pastebin (http://pastebin.com/wRsnz0Y6) and comparing it to the original (https://wikileaks.org/podesta-emails/emailid/2986).
The trick is that I've added extra From/Subject fields before the DKIM header, so DKIM doesn't see them. DKIM only sees the fields after. It tricks other validation tools, such as this online validator. However, email readers (Thunderbird, Outlook, Apple Mail) see the first headers, and display something that DKIM hasn't checked.
I've taken a screenshot of the raw email to show both From fields:
I've taken a screenshot of the raw email to show both From fields:
Since I don't rely upon the "magic" of tools to verify DKIM, but look at the whole package, I'll see the added From/Subject fields. Far from fooling anybody, such modifications will be smoking gun that somebody has attempted illicit modifications. Not just me, mostly anybody viewing the "raw source" that Wikileaks provides would instantly see shenanigans.
The Wikileaks emails can be verified with crypto, using DKIM. Anybody who can doctor an email in such a way that calls this into question, such that they could pass something incriminating through ("I eat kittens"), they win the full bounty. Any good attempts, with something interesting and innovative, wins partial bounty.
Lamers, though, are unwelcome.
BTW, the same is true for bug bounties. Bounties are becoming standard in the infosec industry, whereby companies give people money if they can show ways hackers might hack products. Paying bounties allows companies to fix products before they actually get hacked. Even the U.S. military offers bounties if you can show ways to hack their computers. Lamers are a pox on bug bounty systems -- administrators must spend more time telling lamers to go away than they spend on dealing with real issues. No bounties rules are so tight that lamers can't find a way to subvert the rules without finding anything that matches the intent.
8 comments:
"Since DKIM ignores extra spaces and only checks important fields, these changes pass. The guy claims it's "doctored" because technically, he has changed things, even though he hasn't actually changed any of the important things (From, Date, Subject, and body content)"
So cc: isn't an important thing? Seriously? In the provided sample, "Barry Soetoro" was added as a cc: recipient as a joke -- would that have been "unimportant" if he was really a cc: on some of the WikiLeaks emails??
Also, the DKIM header signature CAN include the cc: line (and generally does WHEN IT IS INCLUDED in the original email). Gmail does this.
So it was technically detectable IF you compare the DKIM h fields with the actual email headers (e.g. if there was no cc: parameter in the h field, but a cc: line present in the email AND you knew confidently that the MTA routinely would have added cc: into the DKIM signature had there been a cc: in the original email (MTA's aren't required to do this per RFC), THEN you can surmise the forgery of the cc: line).
The reality here is that no email DKIM verifiers appear to recognize the surreptitious addition of a cc: field, and many email readers show the user fake from/to/subject lines when the DKIM validated from/to/subject lines are available in the email. Curiously, the Microsoft email clients I've tested actually show the correct DKIM verified from/to/subject lines, so it isn't impossible to do that part right.
Maybe it would make sense to encourage MUA developers to properly check DKIM fields instead of maligning the guy who highlights the issues as a "lamer"?? Asking for a friend...
This is a well known issue with DKIM. In most cases if there are multiple versions of a header, it only checks the last one. It doesn't matter whether the header is before or after the signature. It is easy to sign in a way so that adding extra headers will break the signature, but few signers bother since as you note, it's a pretty lame attack. It also doesn't work very well since some mail programs will show the first header and some will show the second.
Just like writing software a good spec will help control this. Every time a bounty is offered it needs to be controlled with a set of rules.
- adjusting whitespace doesn't count as altering
- duplicating blah blah doesn't count as tool X will ignore it
- etc
Alternatively you can state that they must insert the magic phrase into the ${specifiedLocation}.
Magic Phrase: "Silly rabbit, Trix are for kids!"
This avoids the need to even state that whitespace doesn't count etc.
@Matt: Note that if one can provide an email with cc: (or even To:) header - it doesn't prove that recipient actually received the message, that it was actually sent and not ignored by the recipient / trashed by their spam filter.
Regarding encouraging MUA developers - I can't agree more. However, it should be done in relevant MUA's bug trackers, and not in bounty programs like this one :)
@xyz -- yes, but when your bounty gets called, just move the goalposts and call everyone lamers...
@Lex -- TOTALLY. Which is the whole point: don't use DKIM to claim non-repudiation of sender and delivery to receivers.
But @errataRob is getting too much media run to clearly acknowledge that:
(1) the cc: line is, in fact an important and relevant field (despite him trying to waive it off as unimportant because he didn't want to pay a bounty) that COULD be forged by adding it _AND_ the resulting email would still pass DKIM validation (the point of the bounty -- "doctoring the above email"); and
(2) that he didn't actually understand how cc: lines work with DKIM, since the fraudulent addition of a cc: field DOES in fact pass DKIM validation -- so in one narrow, corner case, DKIM doesn't "work" (The fact that this WOULD be subsequently detectable is irrelevant for purposes of the bounty -- unless you move the goalposts like Rob is want to do -- it simply shows again that DKIM doesn't always "work")
NOTE: the undetected (e.g. doesn't break the DKIM sig) addition of a field that would typically be protected by DKIM is not the same as adding extra to/from/subject fields to confuse crappy mail readers is not even close to the same vector here.
field
"Well that's just like EroticRobs opinion man" :)
If you want to exclude lame bounty claims, would requiring a deposit to make a claim work? Possibly with some sort of escrow system to ensure against moving goalposts?
Hello Robert Graham, if you're interested, there's a public commitment to increase your offer of a 1BTC bounty, raising it to $2,000, over at http://kgov.com/hillary.
Post a Comment