Md5?

Discussion in 'ProcessGuard' started by TNT, Dec 4, 2005.

Thread Status:
Not open for further replies.
  1. TNT

    TNT Registered Member

    Joined:
    Sep 4, 2005
    Posts:
    948
    Ok, I just noticed that Process Guard actually uses md5 checksums of executables for handling signatures for "known" programs. Sorry, but I am really, really disappointed by this. :mad:

    Md5 has been proven completely broken for more than a year now. There have been proof-of-concept demonstrations of just how broken md5 is, for X.509 certificates (http://eprint.iacr.org/2005/067), executables http://www1.corest.com/corelabs/projects/research_topics.php?, meaningful documents http://www.cits.rub.de/MD5Collisions/, and there are tools for creating collisions in a really brief time on a common notebook http://eprint.iacr.org/2005/075.

    If you don't believe this really affects Process Guard go ahead and try using these two executables: http://www1.corest.com/corelabs/projects/research_topics/Richarte_md5-2-collisions.zip. Try permanently allowing one and then replace it with the other different executable. Process Guard won't complain that the exe changed at all.

    I just don't understand why Process Guard actually still uses md5 instead of something like sha256 or sha512 (sha-1 has been proven broken as well, however NOT NEARLY as broken as broken as md5). Not only md5 is broken now, but its weaknesses are going to become trivial to exploit in a very short time (if they are not trivial already).
     
    Last edited: Dec 4, 2005
  2. LuckMan212

    LuckMan212 Registered Member

    Joined:
    Aug 19, 2004
    Posts:
    252
    Hmm.. this is actually quite interesting to me. I had no idea how "weak" MD5 was. When I looked at a Hex compare of those two apps they were indeed significantly different. I wonder what the performance hit would be for calculating a SHA-256 hash vs. an MD5.
     
  3. Gavin - DiamondCS

    Gavin - DiamondCS Former DCS Moderator

    Joined:
    Feb 10, 2002
    Posts:
    2,080
    Location:
    Perth, Western Australia
    I'm sure PG will move to SHA soon, however this is not really a vulnerability as such. It would actually however be VERY hard to create an executable you can attack PG with. Care to demonstrate one ? :)

    First, you need to know a process which is on the target PC, allowed to run permanently, AND has the desired ALLOW options in the protection list. No point if it can run, but then can't DO anything.

    Your trojaned version of the file must remain functional, so as not to draw attention to itself. It must also have the functionality to then compromise the system.

    This program also needs to be replaceable, so it cannot be running when you send over the new one.

    Doesn't sound so easy now, does it ? :)
     
  4. Paranoid2000

    Paranoid2000 Registered Member

    Joined:
    May 2, 2004
    Posts:
    2,839
    Location:
    North West, United Kingdom
    Good to hear that this will be addressed. It's true to say it is not yet a vulnerability - what has been demonstrated is the ability to find two files which resolve to the same MD5 checksum, for it to become a compromise it would be necessary to find a file with the same checksum as an existing one (a pre-image attack). However a pre-image attack is the next step so changing to SHA256 now would certainly be a prudent move.
     
  5. collisions

    collisions Guest

    Well collison attacks can in theory hurt you as much as preimage attacks.

    For example, the attacker might prepare two files that have the same hash using this attack, one is a perfectly clean file with some useful function- some freeware for example and another is a trojan. He then offers the first file for free on his website. Using the freeware and giving it permissions would mean giving the same permissions as the trojan right? So the next time you update it, maybe an autoupdate in the same place, he replaces it with the trojan. And he's home free, the trojan would be free to at least start without your permission, and probably a lot more depending on what other previlages given.

    Though of course if you are sharp, you might wonder why an update didn't trigger a hash check.

    A (second) preimage attack would be even worse, since he doesn't have to induce you to use and accept the first file. He will probably target some commonly used file and make sure his program has the same hash as that.

    Still all this seems very far sketched to me, but it's possible.
     
  6. vlk

    vlk AV Expert

    Joined:
    Dec 26, 2002
    Posts:
    618
    TNT, it's really not as hot as you might think. An attack consisting of a creation of a malicious program with an arbitrary (runtime generated) MD5 hash is still computationally unfeasible, and nothing suggests that this situation should change in the near future...
     
  7. Paranoid2000

    Paranoid2000 Registered Member

    Joined:
    May 2, 2004
    Posts:
    2,839
    Location:
    North West, United Kingdom
    And totally improabable too. If an attacker could lure you into downloading his file in the first place, why bother with a non-malicious one? It would make more sense to include the trojan with the initial download and provide some reasonable explanation ("It's a security app guvnor - it needs ta do wossitsface to your antivirus and firewall to 'elp them along...") for granting it privileged access (or bundle it with PunkBuster...).
     
  8. Sure but you would likely to be very supicious at first. You would do all sorts of things to check if it's okay, run it in vmware or something similar with restricted rights, check it with a full battery of antivirus , look at it with a hex editor and more stuff ten i can name.

    The point is to lull you into a sense of what's the word, gain your trust as you give it all sorts of permissions and then spring the trap. So maybe you had this nice little app for ages , it works as advertised, Then they do a bait and switch.
     
  9. Paranoid2000

    Paranoid2000 Registered Member

    Joined:
    May 2, 2004
    Posts:
    2,839
    Location:
    North West, United Kingdom
    An attacker can "build trust" with a standard trojan containing a conditional or delayed payload (like most viruses have) - there's little point in them making the extra effort of creating a second download with a matching hash, especially when the vast majority of users (and most compromises aim for the more numerous "low hanging fruit") aren't using any hash-checking execution-blocking software.
     
  10. Trojans that carry their payloads (delayed or conditional) with them could be possibly sniffed out before they have the chance to gain trust. But if by conditional you mean it replaced itself it only after a certain amount of time, it could be probed as much as you like and still be seen to be clean.

    Strange logic, since in this case we _are_ talking about people using hash checking execution blocking software. And obviously I'm pointing out a scenario in which such defenses can be circumvented. That's the reason for this thread after all.

    Granted people using such defenses are rare, but that's hardly the point.
     
  11. TNT

    TNT Registered Member

    Joined:
    Sep 4, 2005
    Posts:
    948
    Or... Bob developed a little server application for the company he works with. However, Bob has been in contact with another company for a new job for a couple of months; now, the night before he leaves for the new company, Bob substitutes the executable for the server application with one carefully developed containing a backdoor but resulting in the same md5 checksum; and the system administrator had given Bob rights to upload his files only in that directory. Being a paranoid (:D), though, the system administrator had even compiled the executable himself and stored the md5 checksum on his private HD to check.

    Now the system administrator put faith in the fact that if the executable had been replaced, it would be noticed. After all, if Bob had replaced the executable the night before he left, it would definitely look suspicious. In reality, it goes unnoticed, even though the old one is clean and this one has a backdoor.
     
    Last edited: Dec 5, 2005
  12. Paranoid2000

    Paranoid2000 Registered Member

    Joined:
    May 2, 2004
    Posts:
    2,839
    Location:
    North West, United Kingdom
    Then perhaps you should look at more obvious and exploitable issues like the RunDLL32 one - or an attacker coding their wares in Java. These are far more plausible options and PG will only flag these if users have chosen to Allow Once for rundll32.exe/javaw.exe which most won't.
    Riiight...a server admin that relies on a complier to look for backdoors? One paranoid enough to take checksums manually but trusting enough to accept a new code version on the eve of a programmer's departure without doing a diff on the source code? Not to mention a company seemingly lacking a source code control system.

    I'm sure that there be one-in-a-million situations where MD5 can be exploited using post-image attacks, just as there will be occasions when people will get kicked to death by an angry goat when crossing the road. However the view that most should take is to focus on the most likely (and practical) dangers and protect against those - like looking out for cars when crossing a road rather than goats (or goats driving cars).
     
  13. TNT

    TNT Registered Member

    Joined:
    Sep 4, 2005
    Posts:
    948
    What does this have to do with the compiler and source code? The admin doesn't have the source of the trojaned executable, only the source of the clean one. Who said the programmer even did it at work instead of programming the trojaned executable at home? Just take the previous example of the two executables with the same md5 hash... who said the programmer had to tell the admin that he had "a new version"? I never did, nor did the little story... nor did Bob the programmer, and that is the point: since the programmer can upload the binary himself and the md5 doesn't change, if the admin completely trusts that the md5 changes if the binary changes, he won't notice that it has been replaced.

    I can't believe you think this situation is so unlikely. You know, I am a programmer and if were able to make two executables with same md5 checksum I can tell you that I would probably be able to put in place a similar scenario right now (not that I would do it, but).
     
    Last edited: Dec 6, 2005
  14. Gavin - DiamondCS

    Gavin - DiamondCS Former DCS Moderator

    Joined:
    Feb 10, 2002
    Posts:
    2,080
    Location:
    Perth, Western Australia
    Said prudent ADMIN would check with a HASHING specific tool ? one which hashes all files not just executables and DLL's :) I would, if relying so much on checksums. It would use SHA-256 minimum !

    He would also see the change in his logs if he allowed access. However I do agree somewhat with the previous basic outline that an executable could be done like this.

    SHA-256, 384, or 512 are the likely choices for future hashing in PG. I'd suspect we will go with one of the higher ones.
     
Thread Status:
Not open for further replies.