Windows 7 Is This Digital Signature To Be Trusted?

AceInfinity

Senior Member
Microsoft MVP
Joined
Aug 12, 2011
I'm going to post this in efforts to help prevent individuals from getting a possible Virus. I've known this for a while now, and the fact is, Digital Signatures may not all be legit. Therefore, not all are to be trusted.

It is possible to modify a file and append junk data to EOF of a file without the signature becoming invalidated. I did a test in Windows 7 a few months ago with the installation file for Microsoft Security Essentials (mseinstall.exe). As long as the additional bytes were of a multiple of FileAlignment specified in the Optional Header (FileAlignment property for this Microsoft Security Essentials was 200 bytes in this case), you could increase the size of the certificate within the Data Directories along with a few other binary modifications to change the size of the certificate itself in the first 4 bytes, and you would not trigger the conditions for the file's certificate to invalidate. This means that the file was modified, but still shown to be signed by Microsoft, and supposedly unchanged/unmodified since the time the signature was added to the file, which we know was not true because I did in fact change the file.

This shouldn't happen... The point of Digital Signatures is so that if a file is modified in ANY way, that signature is invalidated, telling the user that it has been changed since it was last signed by the author.

After that, you'd be able to update the checksum in Optional Header as well without the file signature invalidating too, but that's only necessary if the file was a boot program really.

But until that much can be further taken advantage of, (and myself nor the Microsoft security team were able to find a problem with it yet,) this only becomes even more critical if the digest hash used with the certificate IS a broken hash algorithm like MD5.

So the moral of my story, don't trust Digital Signatures, that were signed with the MD5 hashing algorithm!!!

You can see what hash was used through the file properties of a file containing a digital signature:

wmnpY.png


Proof of concept, with testing I did in Windows 7:

dTFSN.png


oacZd.png


z5Yon.png
 
Last edited by a moderator:
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.
 
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 :shame:), 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.
 
Last edited by a moderator:
IMPORTANT NOTE; This is not fixed by Windows 8 RTM! I just tested today. Do not trust any signatures with an MD5 digest at all until further notice!

Updated security directory size as specified within data directories, and updated the checksum in the optional header. With modified binary data, and all these updated size specifications in the headers, this signature still shows as valid.

y2pFL.gif


I noticed some minor change, but they did not fix this yet. Yikes, that's not good :(... I was convinced that this was fixed for a few minutes until further testing.

EDIT: I have re-sent this to my MVP lead to see about it.

EDIT: This does not work on most Windows 8 PE formats. Seems they have changed something otherwise, it's added security given by a file with a hash digest of SHA256 (only one's I have seen). It appears some files have been fixed, but not all. I wouldn't be able to figure it out though. SHA256 seems 100% safe though.
 
Last edited by a moderator:
Back
Top Bottom