Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Why do companies, security companies even, do something like this... " Below are the document checksums for Project_CAMERASHY_ThreatConnect_Copyright_2015.pdf

MD5: b12f118840d0aa0d5ab2fb9aa052ede3 SHA1: dbd710751a6c32ba91401fb5e5623f46b4d2475f SHA256: da6b105f1e58f860ce67b2ad2db7b15ff7b637cfb37f7d0680a20eb633bcc741"

... when you are then providing both the PDF, and the list of its supposed hashes, over an unencrypted connection! It renders it meaningless. I can't trust those hashes or that document. And creating megabyte long PDFs with colliding MD5 hashes is not even a difficult challenge anymore.

The irony here is this page is say "hey open this document, it's safe, trust us" when the document is all about APT attack methods, which often involve compromising people's computers by opening untrustworthy documents! I doubt that's what's happening here, but still kind of silly when you think about it.

Please, all the companies out there. Stop adding a list of hashes to appear more legitimate when you clearly don't know what you are doing.



Well, not meaningless. You can monitor the original values of the hashes, and verify they haven't been changed. The PDFs will be copied around and around.

Also - There is no known method to (within the lifetime of this universe) create a different document with the same MD5 and SHA1 and SHA256. Adding the MD5 doesn't weaken things, and might improve them.


Are you saying that some random ISP(s), some third party or even their hosting provider can't modify the PDFs and the sums on the fly to inject malware? Do you really think most people checks the sums?


Here is the way this works.

The person who posts PDFs on websites with MD5/SHA1/SHA256 hashes adds a watchdog to verify that those hashes aren't changing - Once you get the framework together, adding a new page with hashes to the watchdog takes just a few seconds. That way, if the random ISP(s) or third parties are modifying those sums on the fly, will trigger the watchdog.

As to whether most people check the sum - I have no idea, but at least anybody who wants to take 90 seconds to authenticate the document can just go:

x=Project_CAMERASHY_ThreatConnect_Copyright_2015.pdf ; md5 $x; shasum -a 1 $x; shasum -a 256 $x;

Keep in mind - I totally agree with you that this isn't a great mechanism, but I would argue it's better than nothing at all. (as long as someone has a watchdog to confirm the hashes aren't being modified in flight - they could probably help their case a little by at least serving those pages with HTTPS).

A much better mechanism would be to use OpenBSDs signify (http://www.openbsd.org/papers/bsdcan-signify.html) which solves this whole problem of trying to sign documents with something simple that doesn't involve byzantine chains of trust in a very elegant way.

They could just create a key pair:

   signify -G -p threatpub -s sec
And make their public key, which is short, and easy to copy/distribute everywhere - looks like this:

   untrusted comment: signify public key
   RWQw2u3UPjm6spK9OYJxylK2jSKz2agskG2EKPsxwFN4IjHVw66dYPhT
And then, with each document they create, they just sign the PDF:

   signify -S -s sec -m Project_CAMERASHY_ThreatConnect_Copyright_2015.pdf
Which provides a signature file, signed with their private key:

   untrusted comment: signature from signify secret key
   RWQw2u3UPjm6svkWhs4fgy1Qi0P72hp+uDuTxX8bDSvd/qr/7vc55v+PndgDdWOWj0JiLco/CCfOzw6Alau9RTi5gBiHSzuRHAs=
Now, those two documents, the PDF and the Signature file - can be distributed everywhere - and are not subject to a malware attack because everyone has ThreatConnect's public key, which they can use to verify any threatconnect file and signature, with the simple command:

   signify -V -p threatpub -m Project_CAMERASHY_ThreatConnect_Copyright_2015.pdf
I'm presuming that's the better mechanism you have in mind for this sort of thing? I think I'll forward our thread over to the threatconnect team, see if they are willing to upgrade their procedures.


> creating megabyte long PDFs with colliding MD5 hashes is not even a difficult challenge anymore.

Source, please? Suppose the hashes and PDF were provided over HTTPS. How would it be easy to create another document that collided with all 3 hashes?

Not trying to be facetious - just wondering.


ahhh. Was mixing pre-image attacks with collision attacks in MD5. so ignore that.

If its not over HTTPS, it doesn't matter there are 3 hashes. I change the doc. I generate the 3 hashes for my changed doc. I can serve those new hash values.


A few years ago it was popular to serve files via a not-really-trusted mirror (e.g. Sourceforge), while serving the website via a personal server.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: