Thread: Is This Digital Signature To Be Trusted?

It has been known that as a cryptographic tool, MD5 has been broken for some time, and that it as better for people to use SHA. It is interesting to note, to those who know about certificates, that MD5 has been used to create hash collisions (i.e. two files having the same checksum). This has allowed false intermediary root certificates to be issued by unscrupulous individuals.

When making these changes to the binaries, even if the digest hash is SHA512, will Windows warn that the file has been invalidated? While I beg the question as to how much damage could be done by 200 bytes of additional data, it looks like you have identified a serious flaw in digital file signing.

And again, you were actually able to modify 4 bytes of the digital signature itself and add 200 bytes of additional data at the end of the binary? But only if it was signed with MD5? Fortunately, it looks like most installer executables are being signed with SHA1 and MD5 has been abandoned by most programmers right now.

Originally Posted by Mike

It has been known that as a cryptographic tool, MD5 has been broken for some time, and that it as better for people to use SHA. It is interesting to note, to those who know about certificates, that MD5 has been used to create hash collisions (i.e. two files having the same checksum). This has allowed false intermediary root certificates to be issued by unscrupulous individuals.

When making these changes to the binaries, even if the digest hash is SHA512, will Windows warn that the file has been invalidated? While I beg the question as to how much damage could be done by 200 bytes of additional data, it looks like you have identified a serious flaw in digital file signing.

And again, you were actually able to modify 4 bytes of the digital signature itself and add 200 bytes of additional data at the end of the binary? But only if it was signed with MD5? Fortunately, it looks like most installer executables are being signed with SHA1 and MD5 has been abandoned by most programmers right now.

I read about that yes, it seems this flaw was taken advantage of to copy some signatures of some files (not to name any names, Adobe ), and this allowed the bad file to appear legit with a valid signature signed by Adobe to the end user.

When making these changes to the binaries, even if the digest hash is SHA512, will Windows warn that the file has been invalidated?

Nope... But.... The 'okay' thing for now, is that no-one (that I know of) has found a way to make this junk data enable remote code execution to make it dangerous to the person running the file on their system. This becomes questionable though with a hash like MD5 though as a collision could be created in order to allow modification of other sectors of the file, which is perhaps the ONLY thing needed to add a jmp instruction to run code elsewhere in the file's binary data. Depending on what the person modifying the file wants to do...

And again, you were actually able to modify 4 bytes of the digital signature itself and add 200 bytes of additional data at the end of the binary? But only if it was signed with MD5?

I can do this with any file that has a digital signature, but in order for this to be a dangerous security flaw from my understanding, it would have to be signed with an MD5 digest hash, and you'd have to create an MD5 collision to match.

The 4 bytes I refer to, is actually are a size specification as an integer value (which takes up 4 bytes). The reason for modifying those 4 bytes is to increase the size of the certificate as specified within the data directory itself for how much data you added to EOF in the beginning (to make things coincide with the changes you originally made to the file itself.)

512 bytes though, not 200 sorry, the (0x)200 was a hex value for the number of bytes modified. I did this with a hex editor.

Fortunately, it looks like most installer executables are being signed with SHA1 and MD5 has been abandoned by most programmers right now.

Yes I noticed most on Windows 8 here are signed by SHA256.

The thing is though, is that perhaps SHA based hashes will become broken someday, so this is really a cat and mouse game until there is some other method used to secure a certificate

It's been a while, but I haven't tested this on the RTM version of Windows 8. I should do that now and see... They are working on this though as far as I know.