'Ook gesigneerde Windows-bestanden gevoelig voor md5-collision'

Samengevat: Het vervalsen van eigen werk is nog wel te doen, maar het vervalsen van andermans werk (voorlopig nog) niet. Zeker als de ander geen MD5 gebruikt maar SHA1.

Het verder genoemde "clustertje" moet ook wel heel erg groot zijn en de "dagen" heel erg lang als je "x" of "y" niet zelf kan kiezen. Het op die manier kraken is nog niet vertoond.

Wat je zegt is niet helemaal waar. Er is een methode ontwikkelt die twee totaal verschillende executables zo aan te passen dat ze dezelfde MD5 hash bevatten. Ik heb de link verder in het artikel al geplaatst, maar voor de volledigheid:
http://www.win.tue.nl/hashclash/SoftIntCodeSign/

[edit: Ook hier geld, ik heb niet goed gelezen . We zijn het eens. Je kan twee files laten colliden, maar om jouw bestand dezelfde hash te laten hebben als de hash van een ander bestand kan niet. Tenzij je uiteraard over beide bestanden beschikt.]

[Reactie gewijzigd door flijten op dinsdag 20 januari 2009 14:49]

MD5 heeft de eigenschap dat als MD5(x1) == MD5(x2) dan is MD5(x1 + y) == MD5(x2 + y).

Pertinent onwaar. Dat geldt alleen als x1 = x2 (duh), en verder met een kans van 2¹²⁸ op 1 als x1 ≠ x2.
.edit: excuus, ik las md5(x1+y1) = md5(x2+y2) als md5(x1) = md5(x2). Als ook geldt dat y1 = y2 klopt het natuurlijk wel.

Het signen van een file gebeurt door een hash te berekenen over de file, en die hash vervolgens te encrypten middels public key encryption, met je eigen privésleutel die niemand anders weet. Jouw publieke sleutel is bekend, dus iedereen kan je signature decrypten, en dat vergelijken met de door hunzelf berekende hash van de file. Zijn die identiek, dan is het de bedoeling dat er aangenomen kan worden dat de file niet gewijzigd is, en dat die file van jou afkomstig is. Want als de file wijzigt, dan wijzigt (doorgaans) ook de hash, en aangezien anderen jouw privésleutel niet hebben kan de nieuwe hash niet opnieuw gesigned worden.

Maar wat is er nu aan de hand? Er bestaat mogelijkheden om bij MD5 een collision te genereren. Oftewel, om een file zo aan te passen, dat de hash na de aanpassing identiek is aan de originele hash. Op die manier heb je de privésleutel van iemand niet nodig, omdat de hash identiek is, waardoor de al geencrypte originele hash als signature gebruikt kan worden. Er zijn meerdere van dit soort mogelijkheden. Er werd ontdekt dat, door een 128 byte blok in het bestand op een bepaalde manier aan te passen, het mogelijk is om de hash identiek te laten zijn.

Om dan terug te komen op jouw eigen opmerking:

Wat het artikel pertinent niet doet is, wat hier gesuggereerd wordt, executables maken die dezelfde hash hebben als een andere. Dus geen gefakete gesignde explorer.exe.

Dat kan dus wél! Alleen het enige wat de onderzoeker gedaan heeft is uitgaan van een bestaande applicatie en zijn collision counterpart (good.exe en evil.exe dus), waarbij hij good.exe via de officiele manier gesigned heeft, en voor evil.exe de signature simpelweg heeft gekopiëerd. Evil.exe is dus niet via de officiele manier gesigned, en kan dus net zo goed door een kwaadwillende zijn geproduceerd, door minimale aanpassingen op good.exe uit te voeren.

Natuurlijk, het blijft een vrij lastig probleem om een applicatie met minimale aanpassingen iets anders te laten doen. Maar je hoeft 'm natuurlijk maar zo aan te passen dat exploits van buitenaf mogelijk worden. Als er ook maar 1 bit in de code wijzigt dan kunnen de rapen al gaar zijn. Op zichzelf dan natuurlijk nog geen explorer.exe met een virus, maar dus wel een met exploit mogelijkheden

[Reactie gewijzigd door .oisyn op dinsdag 20 januari 2009 16:05]