CWI: Flame-malware gebruikte nog onbekende md5-aanval

Nederlandse cryptologen hebben ontdekt dat de Flame-malware een nog onbekende collision-aanval voor md5 toepaste, wellicht nog ouder dan hun eigen baanbrekende methode. Flame zou door cryptografische experts ontwikkeld zijn.

Marc Stevens van het Centrum Wiskunde & Informatica in Amsterdam heeft zijn eigen forensische tool gebruikt om samen met Benne de Weger van de Technische Universiteit Eindhoven de Flame-malware onder de loep te nemen. Ze ontdekten dat Flame gebruikmaakt van een tot nu toe onbekende md5 chosen-prefix collision-aanval. De twee Nederlandse cryptologen zijn niet onbekend met dit soort aanvallen; in 2007 waren ze verantwoordelijk voor deze baanbrekende nieuwe aanvalsmethode op md5, nadat de Chinees Xiaoyun Wang de collision-kwetsbaarheid blootlegde.

Bij collision-aanvallen worden verschillende invoerwaarden gecombineerd om dezelfde hash-waarde te krijgen. De bruikbaarheid van hashes ligt er juist in dat de kans klein is dat twee verschillende inputs tot dezelfde uitvoer leiden en dat het dus lastig is twee inputs te vinden die tot dezelfde hash leiden. Stevens en De Weger toonden in 2008 aan dat hun methode met relatief eenvoudige middelen gebruikt kon worden om valse certificaten te genereren. Dat was ook precies wat bij Flame gebeurde; de malware kon zich als authentieke Windows-update voordoen, omdat hij gesigneerd was met een frauduleus certificaat dat van Microsoft afkomstig leek.

De analyse van de Nederlanders toont echter aan dat niet hun methode is gebruikt, maar een nieuwe variant. "Het is niet ondenkbaar dat deze variant al in ontwikkeling was voor juni 2009 (toen de cryptologen hun methode publiceerden, red.)", schrijft Stevens. "Dit heeft ons tot de conclusie gebracht dat het ontwerp van Flame deels gebaseerd is op cryptanalyse van het hoogste niveau."

Vanaf 15 januari 2009 werden op md5 gebaseerde handtekeningen eigenlijk niet meer geaccepteerd, ook niet door Microsoft, omdat het systeem aantoonbaar kwetsbaar was. Om deze redenen besloten Stevens en de zijnen hun methode in juni 2009 uit de doeken te doen. Ze nemen het Microsoft dan ook kwalijk dat desondanks op md5-hashes gebaseerde handtekeningen nog geaccepteerd werden door de Terminal Server Licensing Service. De collision-aanval van Flame op een Microsoft TSLS Certification Authority vond namelijk in februari 2010 plaats. "De mogelijkheid om aan te vallen stond feitelijk sinds juni 2009 open voor aanvallers met kennis van zaken", concluderen de wiskundige onderzoekers.

Reacties (70)

[Orion84]

[quote]Bij collision-aanvallen worden verschillende invoerwaarden gecombineerd om dezelfde hash-waarde te krijgen. De bruikbaarheid van hashes ligt er juist in dat ze uniek zijn en dat twee verschillende inputs niet tot dezelfde uitvoer leiden.[/quote]
Dat is niet helemaal correct. Inmiddels aangepast in de tekst van het nieuwsbericht

Hashes leveren juist per definitie niet-unieke waardes op. De bedoeling van een cryptografisch hashalgoritme is echter wel dat het praktisch onmogelijk is om twee invoerwaardes te vinden die dezelfde hash opleveren.

Daarvan zijn twee varianten:

Strong collision resistance:
De mate waarin het lastig is om twee volledig zelf te bepalen invoerwaardes te vinden die dezelfde hash opleveren.

Weak collision resistance:
De mate waarin het lastig is om gegeven een invoerwaarde en bijbehorende hash, een tweede invoerwaarde te vinden die dezelfde hash oplevert.

De aanvallen waar het hier om gaan zitten daar een beetje tussenin, aangezien de invoerwaardes niet compleet vrij te kiezen zijn, maar een deel van de invoerwaarde wel en dat is dankzij zwakheden in MD5 voldoende om twee invoerwaardes te vinden die dezelfde hash opleveren.

Dit is interessant voor aanvallers om de volgende reden:
Veel beveiliging is gebaseerd op digitale certificaten. Zo'n certificaat wordt vertrouwd vanwege de handtekening die een Certificate Authority heeft geplaatst. Een CA ondertekent echter niet het certificaat. maar een hash van het certificaat (dat is sneller).

Als je dus twee verschillende certificaten kan maken die dezelfde hash opleveren, dan kan je de ene (die geen gekke dingen bevat) laten ondertekenen en vervolgens kan je die handtekening gebruiken om vertrouwen te wekken in het tweede certificaat.

Dat tweede certificaat was in dit geval een aangepast certificaat waarin allerlei informatie om het certificaat te kunnen valideren ontbrak, waardoor het door de betreffende software als valide beschouwd werd.

[Reactie gewijzigd door Orion84 op 24 juli 2024 22:04]

[.oisyn]

De aanvallen waar het hier om gaan zitten daar een beetje tussenin

Nee, het gaat hier louter om een weak collision attack. Er moet een andere input gevonden worden die exact dezelfde al bestaande hash oplevert.

Bij een strong collision attack heb je niet te maken met een bestaande hash maar gaat het er puur om dat je twee inputs hebt die dezelfde (volledig arbitraire) hash opleveren. Meestal door een basis-input op 2 verschillende manieren te manipuleren zodat beide manipulaties een identieke hash opleveren. Dit is bijvoorbeeld handig als de authentieke identity en de attacker een en dezelfde persoon is. Zo zou hij een geprepareerd certificaat van zijn eigen domein kunnen laten signen door een vertrouwde CA als Verisign, en vervolgens die handtekening kunnen gebruiken om onder een zelfgegenereerd certificaat van een compleet ander domein dat hij helemaal niet bezit te plakken.

[Reactie gewijzigd door .oisyn op 24 juli 2024 22:04]

[Orion84]

Aangezien ze zelf beide certificaten kunnen opstellen zouden ze op zich bij het eerste certificaat al rekening kunnen houden met de attack, maar ik moet zeggen dat ik niet heb uitgezocht of ze dat ook gedaan hebben.

Als ze inderdaad gewoon een certficaat hebben gegenereerd en hash hebben berekend en daarna pas zijn gaan proberen om daar een tweede certificaat bij te maken met dezelfde hash, dan is het inderdaad een voorbeeld van een attack tegen weak-collision resistance.

[.oisyn]

Nee, wat ze gedaan hebben is een standaard Microsoft certificaat gepakt dat is ondertekend, en die handtekening hebben ze vervolgens onder een zelfgegenereerd certificaat geplakt. Een vereiste daarbij is dat de hash van het gemanipuleerde certificaat overeenkomt met die van het origineel, en dus is het een weak collision attack.

[Orion84]

Niet helemaal. Het certificaat waarvan ze de signature hebben 'misbruikt' is voor zover ik begrijp wel specifiek aangevraagd voor de collision attack:
http://blogs.technet.com/...gn-the-flame-malware.aspx

Ze hebben dus een certificaat aangevraagd (wat ze onder XP ook direct kunnen gebruiken voor code signing) en vervolgens middels de collision attack een tweede certificaat gemaakt dat dezelfde signature heeft, maar waaruit bepaalde validatieinfo verwijderd was om het certificaat ook op Vista en hoger door de controles te laten komen.

Als ik het goed begrijp hebben ze daarbij profijt getrokken uit het feit dat het certificaatgeneratie proces van terminal service dinges deels voorspelbaar was. (wat dus vergelijkbaar is met het deels kunnen kiezen van beide inputs van de collision attack).

Volgens mij is het zelfs gewoon de definitie van een chosen prefix attack dat het weliswaar sterker is dan een random collision attack, maar het niet hetzelfde is als het vinden van een tweede input die dezelfde hash oplevert als een gegeven input.

[.oisyn]

De bruikbaarheid van hashes ligt er juist in dat ze uniek zijn en dat twee verschillende inputs niet tot dezelfde uitvoer leiden.

Euh, nee. Een hash is per definitie niet uniek, omdat de output eindig is en de input oneindig. Waar het in het geval van cryptografische hashes vooral om gaat is dat je niet makkelijk:
• een input kan vinden voor een bepaalde hash (preimage resitance),
• een bestaande input zo kan manipuleren dat de hash hetzelfde blijft (weak collision resistance), en
• twee verschillende inputs kunt genereren met dezelfde hash (strong collision resistance).

Punt 2 is van toepassing op de nu gevonden kwetsbaarheid.

[Reactie gewijzigd door .oisyn op 24 juli 2024 22:04]

[wow7]

Flame wist de certificaten te vervalsen door een gat in een oud encryptie-algoritme te misbruiken, waarna diens makers hun geschreven code digitaal konden ondertekenen met een Microsoft-stempel.

Bron: http://www.zdnet.be/news/...h-als-microsoft-software/

Het wil dus zeggen dat windows update gehijacked word , dus in plaats van dat je bij MS updates ophaalt er op een andere door Flame geïnfecteerde servers deze updates werden gedownload.

Bron: http://www.techrepublic.c...ate-system-patch-now/7980

Na een aanval kom Flame zich zelf vernietigen.

Bron: http://www.cio.com.au/art...emove_all_traces_malware/

[_BladE2k_]

Wat dit bericht juist zo bijzonder maakt is dat er dus een *ander* MD5 collission techniek is gebruikt dan dat op dit moment openbaar is. We weten al dat MD5 collissions met bepaalde algorithmes te voorspellen zijn. Hierdoor 'weten' we welke input we nodig zijn om een collision te genereren.

De input die ze hier hebben gevonden is dus NIET hetzelfde als hetgene dat de huidige 'bekende' algorithme zou genereren. Dat is waarom het juist zo bijzonder is, want dat geeft tegelijk aan dat er niet een 'scriptkiddie' is geweest die het al bekende algorithme heeft toegepast.

Voeg dat samen met het feit dat dit een behoorlijke nasty virus is en het wordt alleen maar NOG aannemelijker dat het een creatie is van een organisatie met erg veel resources (zowel in kennis als geld). Dan komt natuurlijk de volgende vraag: Wie?

[.oisyn]

Wie?

Chuck Norris natuurlijk.

[Koos Ofzo]

Dit is toch een beetje boven mijn pet als hobbyist, kan iemand mij het in lekentaal een beetje uitleggen?

[EpicEraser]

Om aan te tonen dat gegevens bij een legitieme bron vandaan komen gebruik je certificaten. Hierbij worden twee sleutels gebruikt, waarvan er eentje alleen in handen is van de maker van de certificaten, en de andere is publiek. Met de "private" sleutel kun je certificaten maken, en met de publieke sleutel kun je controleren of ze echt met de private sleutel gemaakt zijn.
Het is niet mogelijk (in de praktijk) om met enkel een publieke sleutel een certificaat te genereren dat gevalideerd wordt.
Maar als je door een zwakheid in de methode die een certificaat aan de gecertificeerde gegevens koppelt (een hash van de gegevens zelf) een zwakheid hebt (je kunt gegevens genereren met dezelfde md5 hash), is het al snel bekeken.
Je kunt zo een bestaand, ondertekend certificaat gebruiken om je eigen gegevens vals mee te certificeren.

En als je gecertificeerd bent, heb je plotseling heel veel meer mogelijkheden om fratsen uit te halen.

De zwakheid in md5 is echter al een hele tijd bekend, en certificaten die een md5 hash gebruiken horen niet meer geaccepteerd te worden. Blijkbaar werd dit toch gedaan is dit hoe Flame binnenkwam.

Ik geloof dat dit zo'n beetje de strekking is.

EDIT: Rick was me voor, maar dit sluit wel lekker aan op dat verhaal

[Reactie gewijzigd door EpicEraser op 24 juli 2024 22:04]

[Verwijderd]

Certificaten zijn per definitie onveilig, want als ik het cert op een USB stick heb kan ik het cert potentieel op elke systeem mibruiken, zolang de datum niet is verlopen. Ik heb het nooit begrepen dat hele Cert en SSL verhaal zo slecht in elkaar steekt. Ik verbaas mij er nog steeds over. Hoe moeilijk is het nou om een certificaat te exporteren? En ergens anders weer te importeren? Belachelijke beveiliging en vragen om problemen.

Bijna alle Rootkits gaan trouwens op deze manier te werk.

[.oisyn]

Certificaten zijn per definitie onveilig, want als ik het cert op een USB stick heb kan ik het cert potentieel op elke systeem mibruiken

Autogordels zijn per definitie onveilig, want als ik inbreek en ze onklaar maak dan vlieg jij gewoon door de voorruit bij de eerstvolgende frontale botsing.

Wachtwoorden op accounts zijn per definitie onveilig, want als ik de server hack kan ik gewoon alles doen met die accounts.

Je argumentatie rammelt aan alle kanten. Certificaten zijn helemaal niet bedoeld als beschermingslaag op een systeem dat al compromized is. Je hoeft dan niet eens jouw cert te installeren, je kan ook gewoon het de hele cert checking onklaar maken. Certificaten zijn ervoor bedoeld om de authenticiteit van een object (bestand, domeinnaam, identiteit, etc.) te valideren. Die hele validatie heeft geen nut meer als het systeem dat de validatie probeert te doen zelf al aangevallen is. Maar het heeft wel nut bij man-in-the-middle attacks, want niemand kan (voor zover de hash- en encryptie-algoritmen niet gebroken zijn) zomaar even een aanpassing maken.

[Reactie gewijzigd door .oisyn op 24 juli 2024 22:04]

[TDeK]

Met een hash (met een vaste output lengte) bewijs je dat er met een bestand niet gerommeld is. Verander je 1 bitje in het bestand, dan krijg je een heel andere hash. Tenzij je het bestand kunt aanpassen terwijl de hash toch hetzelfde is. Dat heet een collision. Eigenlijk is dat ook heel logisch, aangezien een hash een vast lengte heeft (vb 256 karakters) en of je nou één letter als input geeft of 18GiB als input, de output is altijd 256 karakters lang. Er moeten dan dus duplicaten zijn, maar die zijn (bij een goed algoritme) niet te voorspellen. Zo gauw je collisions kunt genereren of kunt voorspellen spreken we van een 'gekraakt' hash algoritme, omdat je je dan als iemand/iets anders kunt voordoen (in dit geval als een legitieme Windows Update).

[Koos Ofzo]

Nu vat ik het, hartelijk bedankt

[hardwareaddict]

In lekentaal: de NSA's van bepaalde landen zijn heftig actief en hebben 'flame' ontwikkeld om onze computer te besmetten en over te nemen. de exacte methode is niet zo interessant, maar een leek gaat het niet voor elkaar krijgen om 2 totaal verschillende update files dezelfde MD5 hash te laten genereren en dan ook nog internet te rerouten (om het creatief te zeggen) zodat je direct je update uit Iran krijgt in plaats van van Microsoft.

Iran is als voorbeeld hier gekozen maar het is geen fictief voorbeeld.

Als huis en tuingebruiker ben je kansloos tegen NSA's van vijandelijke mogendheden die je machine aanvallen.

[SED]

Maar de vraag die ik graag beantwoord zou zien.. is er ergens een voorbeeld van een gecompromiteerde windows update service of praten we hier over updates die zich voordoen alsof ze van Microsoft komen en die zonder tussen komst van windows update ( de site) geinstalleerd zijn.

Om de windows update site te spoofen moet je meer doen dan alleen een certificaat hebben en iets signen. Je moet via een host aanpassing (lokaal) of man in the middle (dns) de mensen naar de foutieve windows update lokken.. of zie ik iets over het hoofd?

[Sizzla]

Klopt, dat is wat de MUNCH module doet http://www.securelist.com..._Update_MITM_proxy_server

[Rob Coops]

Het hangt er van af hoe je de update site spooft. Ik heb het vermoeden dat het volgende gebeurt is.

• Malware komt een systeem binnen via een van een aantal 0-day exploits
• Malware doet het systeem denken dat het geldige Microsoft DLL's zijn door met een Microsoft certificaat te wapperen.
• Vervolgens kunnen op basis van de beschikbare hardware extra onderdelen van de malware worden binnen gehaald door het te laten lijken als of het een Microsoft update is, die van de Microsoft update server komt.
• Natuurlijk hebben deze nieuwe onderdelen ook een Microsoft certificaat en worden dus ook door de virus scanner met rust gelaten.

Op deze manier heb je maar een hele kleine kans dat jouw virus gevonden wordt immers alleen op het moment dat je het systeem binnen dringt zou je eventueel gezien kunnen worden daarna zul je goed deels met rust gelaten worden omdat niemand een geldige Microsoft DLL verdenkt van fout gedrag.
Het zou me dan ook niet geheel verbazen als Microsoft niet geheel zonder reden de certificaten niet heeft terug getrokken. Het is en blijft een Amerikaans bedrijf en met de huidige wetgeving zou het me niets verbazen als ze zich gedwongen zagen de staat te helpen.

Hoe het ook zij dat dit door een staat is gedaan moge duidelijk zijn en dat dit virus geheel toevallig voornamelijk in Iran de grootste vijhand van Amerika en Israel is is vast ook helemaal toeval...

[SKiLLa]

Een virusscanner die op basis van een certificaat een bestand niet eens scanned lijkt me niet erg realistisch. Dat mensen eerder geneigd zijn zo'n melding dan als false-positive af te doen, is een tweede, maar dan nog: er bestaan al jaren virussen met gestolen certificaten, process injection en rootkits die bestanden 'valide' doen lijken, maar het niet zijn ...

[gerwim]

Klopt. Er werd ook een MITM aanval gedaan.

Op het moment dat er een node (lees: PC/laptop) geinfecteerd was en een andere node wil Windows Update doen, zegt de besmette node "hier heb je een update". Deze werd dan geinstalleerd en zijn er 2 besmette nodes in het netwerk.

[Verwijderd]

"De bruikbaarheid van hashes ligt er juist in dat ze uniek zijn en dat twee verschillende inputs niet tot dezelfde uitvoer leiden. "

Een MD5-hash is een string van 32 karakters en MD5 kan een input hebben van een string van variabele lengte (hell, er worden hashes gemaakt van hele DVD ISO's).

Dan is het juist logisch dat een MD5 hash een onvoorstelbaar aantal input mogelijkheden heeft en dus dat een hash per definitie niet uniek is (dus niet 1 op 1 gekoppeld met een input).

[Reactie gewijzigd door Verwijderd op 24 juli 2024 22:04]

[.oisyn]

Een MD5-hash is een string van 32 karakters

Een MD5 has is meer een string van 128 bits. Als je dat in hexadecimale notatie opschrijft, wat meestal wordt gedaan met dergelijke hashes, dan krijg je inderdaad een string van 32 karakters (waarbij alleen 0-9 en a-f gebruikt worden). Maar je zou ook een andere notatiewijze kunnen gebruiken, zoals base64 (24 tekens in het geval van 128 bits aan data). Of gewoon letterlijk de 16 bytes.

[Reactie gewijzigd door .oisyn op 24 juli 2024 22:04]

[Verwijderd]

De wiskundige term hiervoor is het duiventilprincipe (pigeonhole principle). Die zegt: als je meer duiven dan duivenhokken hebt, en alle duiven zitten in een hok, dan is er minimaal 1 hok met 2 of meer duiven.

Dit is ook in compressie-algoritmes van toepassing. Als elke input van lengte x een gecomprimeerde output y oplevert (waarbij de lengte van x groter is dan die van y, en er vanuitgaande dat de compressie lossless is), dan is het niet mogelijk dat elke output y 1-op-1 terug te mappen is naar een unieke input x. Voor elk compressie-algoritme is er dus een input waarbij de output groter moet zijn dan de input.

Als elke MD5-hash uniek zou zijn voor *elke* mogelijke input, zou het de optimale compressie zijn. Je zou elke DVD kunnen comprimeren tot 128 bits.

[locke960]

Klopt. De zin had dan ook moeten luiden.
"De bruikbaarheid van hashes ligt er juist in dat de kans heel klein is dat twee willekeurige verschillende inputs tot dezelfde uitvoer leiden EN dat het heel erg moeilijk is met opzet 2 verschillende inputs te creeren met dezelfde hash."

Met andere woorden een ander programma, dat ook nog moet werken natuurlijk, met dezelfde hash als het origineel creëren zodat het geaccepteerd wordt als het origineel zou moeilijk moeten zijn.

[MSalters]

Dat laatste (met opzet) geldt alleen voor de zogenaamde Crypografische hash functies. Nu is MD5 ontworpen als cyrptografische hash, dus dan mag je het verwachten. Maar bij een simpele datastructuur als een hashtable (zoals bijvoorbeeld in Java) zijn collisions helemaal niet zo'n groot probleem. Je kunt dan een simpelere, snellere hash functie gebruiken.

[darkfader]

Het ASP.NET hash collision probleem geeft dan weer duidelijk aan dat je goed moet nadenken als je het gebruikt in een netwerkprotocol. Maar goed, dat is niet echt een veiligheidsprobleem.

[Verwijderd]

Hmm in het artikel op cwi.nl lees ik het volgende

"Het maken van zo’n variant vereist cryptanalyse van wereldniveau," zegt Marc Stevens. "Het is dus zeer belangrijk om te investeren in cryptografisch onderzoek, om deze ontwikkelingen in de praktijk voor te blijven"."

Ik krijg sterk de indruk dat Marc nu de publiciteit zoekt om fondsen te werven voor zijn eigen onderzoek.

Dat er cryptanalyse van wereldniveau nodig zou vraag ik me af.

In een publicatie van Tao Xie en Dengguo Feng genaamd "How To Find Weak Input Differences For MD5 Collision Attacks" vinden script kiddies met talent genoeg informatie om zelf MD5 collisions te kunnen berekenen.

http://eprint.iacr.org/2009/223.pdf

[Reactie gewijzigd door Verwijderd op 24 juli 2024 22:04]

[.oisyn]

Ik krijg sterk de indruk dat Marc nu de publiciteit zoekt om fondsen te werven voor zijn eigen onderzoek.

Natuurlijk doet ie dat. En met recht, want wat hij zegt is gewoon waar.

[Reactie gewijzigd door .oisyn op 24 juli 2024 22:04]

[hardwareaddict]

En dat md5 gecompromitteerd is, dat is natuurlijk allang bekend en was al jarenlang bekend natuurlijk en voor het gepubliceerd werd, kon iedereen het ook wel vermoeden als je kijkt naar hoe weinig bits de md5 output is.

Interessanter is de vraag of SHA512 die toch redelijk snel berekend kan worden, terwijl md5 pokketraag is, of die SHA512 zijn mannetje weet te staan tegen de Islamitische cryptografen.

[.oisyn]

En dat md5 gecompromitteerd is, dat is natuurlijk allang bekend

Maar dat is niet relevant voor zijn argument. Als er nieuwe ontdekkingen gedaan worden voor wat voor algoritme dan ook terwijl de resultaten geheim blijven, dan kun je je afvragen wat dat betekent voor de andere algoritmes. Ook diegene waar nog geen flaws van ontdekt zijn. Het beste dat je kunt doen is met onderzoek zelf die flaws ontdekken en publiceren, zodat ze niet meer misbruikt kunnen worden.

kon iedereen het ook wel vermoeden als je kijkt naar hoe weinig bits de md5 output is.

Iedereen die er een beetje verstand van heeft snapt ook wel dat de 128 bits van MD5 hier compleet niets mee te maken hebben. Al heb je hardware tot je beschikking die in staat is om een biljard hashes per seconde uit te rekenen, dan nog kost het middels brute force gemiddeld 10¹⁶/me jaar om een collision te vinden met een specifieke hash. Maar dit gaat niet over of iets brute force te kraken is, dit gaat over een zwakheid in het algoritme wat te manipuleren valt. Al had MD5 een 1024 bits resultaat gegeven, dan nog was dezelfde hack mogelijk geweest.

Interessanter is de vraag of SHA512 die toch redelijk snel berekend kan worden, terwijl md5 pokketraag is

En wederom ga je de mist in, SHA512 is langzamer dan MD5 en MD5 is absoluut niet pokketraag. Sterker nog, omdat MD5 zo snel te bereken is wordt het afgeraden om te gebruiken als password hashing algoritme, waarbij een gemiddelde thuis-PC binnen een minuut alle alphanumerieke wachtwoorden van 7 tekens lang kan afgaan.

En voor je gaat zeuren dat ik mezelf hier tegenspreek tov mijn vorige opmerking over de lengte van MD5, het aantal mogelijkheden in typisch gebruikte wachtwoorden ligt veel en veel lager dan het aantal mogelijk verschillende MD5 hashes. Ook hier geldt, al was MD5 1024 bits, dan nog was het niet geschikt. En ook SHA-512 is om die reden ongeschikt, want ook die is nog te snel te berekenen. Je zult eerder moeten gaan denken aan algoritmes waarvan het aantal iteraties aanpasbaar is zodat het mee kan groeien met de hardwarematige ontwikkelingen, zoals PBKDF2 of bcrypt.

Islamitische cryptografen

Ach ja, natuurlijk. Een dergelijke opmerking past wel prima in een verder zo ontzettend ongeïnformeerde post.

* Voor een 128 bits hash moet je gemiddeld 2¹²⁷ mogelijke inputs afgaan. Met 10¹⁵ hashes per seconde duurt dat: 2¹²⁷ / 10¹⁵ / 60 / 60 / 24 / 365 ≈ 10¹⁶ jaar.

[Reactie gewijzigd door .oisyn op 24 juli 2024 22:04]

[z.jeroen]

Ik krijg sterk de indruk dat Marc nu de publiciteit zoekt om fondsen te werven voor zijn eigen onderzoek.

Scherp opgemerkt (niet dus). Natuurlijk doet hij dat. Net zoals iedereen aandacht zoekt voor zijn onderzoek. Waar het om gaat is of zijn argumenten kloppen.

Dat er cryptanalyse van wereldniveau nodig zou vraag ik me af.

In een publicatie van Tao Xie en Dengguo Feng genaamd "How To Find Weak Input Differences For MD5 Collision Attacks" vinden script kiddies met talent genoeg informatie om zelf MD5 collisions te kunnen berekenen.

Er is een groot verschil tussen een methode toepassen om een collision te vinden (wat een script kiddie vast prima kan), en een geheel nieuwe methode vinden om collisions te berekenen. Je voorbeeld zegt mij daarom niets.

[Verwijderd]

Er is een groot verschil tussen een methode toepassen om een collision te vinden (wat een script kiddie vast prima kan), en een geheel nieuwe methode vinden om collisions te berekenen. Je voorbeeld zegt mij daarom niets.

Zelf zeker onderzoeker die erkenning zoekt

[Phoib]

Alleen gebruiken ze een andere methode dan beschreven door Xie en Feng, die doorontwikkeld is door Stevens.

En ja, dan is er inderdaad cryptoanalyse van wereldniveau nodig om dat voor elkaar te krijgen.

[KirovAir]

Flame kán haast niet door particulieren gemaakt zijn. Wat ontzettend veel baanbrekende technologie in een enkel stuk malware zeg. Hoewel ik totaal geen voorstander ben van virussen, kan ik bij dit soort artikels niet meer dan lof geven aan de programmeurs van deze virussen. Hele knappe koppen die dit geschreven hebben. Totaal niet te vergelijken met een Melissa virus of een ander stukje spyware. Dat ze toevallig voor dit soort zaken zijn ingehuurd is een ander verhaal, maar de hackers die dit programmeren staan echt aan de top van de virtuele voedselketen.

[TDeK]

Hele knappe koppen die dit geschreven hebben. Totaal niet te vergelijken met een Melissa virus of een ander stukje spyware.

Er lopen wel meer knappe koppen rond hoor, maar die hebben
a) geen onbeperkt budget ter beschikking en dus
b) niet de tijd en/of middelen om hier een lange periode aan te werken en
c) een particulier had een dergelijke investering met fraude of verkoop aan de onderwereld nooit terug kunnen verdienen
Dus zeker props voor de programmeurs van deze collision, maar in mijn ogen zit het echte briljante in de manier van afleveren van de malware (Windows Update spoof) en het zeer klein houden van de doelregio + het zo lang uit handen blijven van de security analisten. Al zegt dat laatste waarschijnlijk meer over de kwaliteit en kunde van de securityindustrie.
Voor hen die de basiskennis voor deze collision analyse willen vergaren raad ik deze online cursus aan.

[segascope]

Best wel eng wat ze paar jaar geleden al konden doen, de 2012 virussen/malwares zullen nog gesofisticeerder zijn. Stuxnet en Flame werden beide een 6 tal jaren geleden ontwikkeld. Ik denk dat de bestrijding een paar jaar achterloopt op de ontwikkelingen van malwares.

[TDeK]

Dan ga je ervan uit dat ze al wat nieuws zijn gaan ontwikkelen terwijl de bestaande malware nog prima werkte. Defensie heeft veel geld, maar het hoeft niet op hè . Ik vermoed dus dat er nu een klein zwart gat is ontstaan in de spionage keten, hoewel we natuurlijk niet weten hoeveel malware we nog niet gevonden hebben (absence of evidence != evidence of absence).

[Verwijderd]

Nou, er schijnt nog genoeg in omloop te zijn. Ik vind deze tweet van SpiderLabs wel een eye-opener:

We (@SpiderLabs) investigated >300 breaches in 2011. 100% used malware. 0% detected by AV on targets. In lab top 25 AV engines detected 12%.

Lang leve AV programma's

edit: typo

[Reactie gewijzigd door Verwijderd op 24 juli 2024 22:04]

[segascope]

Technologie staat niet stil, dat de bestaande malware prima werkt wilt niet zeggen dat ze niet nog betere aan het ontwikkelen zijn. Of denk je dat de virus bouwers de laatste 6 jaar gewoon hebben gewacht tot deze malwares gevonden werden?

[TDeK]

Tegen custom malware kan niets je beschermen. Zelfs de heuristics (die gedrag van code detecteren) blijken in de praktijk niet te werken. En in het enkele geval dat het wel werkt en de malware wordt naar de virusvendor verstuurd, dan blijkt er aan die kant niets mee te gebeuren.
Dus je hebt gelijk: Mac users moeten niet áán de anti-virus, de Windows users moeten er juist vanaf. Of althans, je moet er niet blind op vertrouwen. Zo draai ik op mijn machines (ja, zelfs op mijn Mac) Clam AV (ClamXAV voor Mac) om zo af en toe een full-disk scan te draaien en om een monitor op bepaalde mappen te zetten (~/Downloads en ~/Desktop bij mij).

[mae-t.net]

Dat is dan 1 foute uitgang in je potjeslatijn en 1 inhoudelijke fout. En dat in zo'n kort zinnetje. Jammer.

Op http://www.clamxav.com/ valt meteen bovenaan het volgende te lezen:

ClamXav is a free virus scanner for Mac OS X. It uses the very popular ClamAV open source antivirus engine as a back end and has the ability to detect both Windows and Mac threats.

[Verwijderd]

Haha, uhm, lees nog even alle artikelen door, het is ook via jouw broekzak verspreid. (via iOS, ja ook via android maar daar word je vast niet warm of koud van)

Misschien dat je je nu beseft waarom je wel een virusscanner en firewall op iig je mac(s) & als het even kan op je iphone nodig hebt.

Wat ook nog een leuk punt is, is dat je denk op dit soort virussen een 'manuele check' te kunnen doen, echt niet dus, flame doet zoveel zieke trucs dat het merendeel van de virusscanners etc het niet eens kan vinden, laat staan dat de gebruiker (jij dus) er ook echt niets merkt.

Als dit inderdaad door een overheid is geschreven doelend op nucleaire programmas van arabische landen, dan is het niet meer dan logisch dat je het niet kan vinden, hoe dit dan zou werken (kijkend naar stuxworm en duqu) is dat het gewoon ergens op het internet losgelaten word, en in een jaar 'via via via via via via via' op de doelpc's terecht komt (of dat was iig het plan bij die 2) dan is het dus wel belangrijk dat er tijdens het 'zoeken' niemand merkt wat er gebeurd.

Mede daarom zal er dus ook de genoemde 'uinstall' zijn ingebouwd, als het doel is bereikt, kan het totaal geen kwaad om het virus van alle andere apparaten te verwijderen.

[Sebas1979]

Je redenatie is dus:

- er zijn niet zoveel virussen voor Mac ('wereldnieuws')
- met een virusscanner kun je alsnog besmet raken ('flame')
------------------------------------------------------------------
--> een virusscanner voor Mac is overbodig.


Ik heb niet zoveel verstand van Macs, maar je redenatie rammelt.

[Verwijderd]

Nee toch echt je redenatie, tuurlijk is het slecht dat antivirus die 2 niet heeft kunnen tegenhouden, maar denk je echt dat je met wat voor handmatige actie dan ook meer kan bereiken?

Lees jij alle privé hacker forums, bbs-en etc van de wereld? Denk ik niet? Dan kan je dus ook nooooit weten hoe of wat er op dit moment door het internet heen en weer rent, en jezelf nooit beschermen.

Ja het is zuur dat een virusscanner 'laat' kan zijn met iets ontdekken, maar 99% kans dat ie het dan alsnog eerder ziet dan jij zelf?

Ik zou gewoon lekker een antivirus pakketje voor de mac kopen, onder het mom van 'better safe then sorry', wat heb je te verliezen? die 49 euro die het moet kosten ofzo? nou lekker boeiend, ik koop met alle liefde een game of cd minder per jaar om in ieder geval een vorm van veiligheid te hebben.

[Verwijderd]

Natuurlijk lees ik niet alle hackers forums en dergelijke maar als er een virus op de Mac rondwaart dan weet ik dat momenteel even snel dan dat de anti virus software het weet.

Ze zijn zo zeldzaam dat eens het ontdekt is het op alle Mac sites staat en die lees ik dan weer wel. Hoe je het virus moet verwijderen via de terminal staat er ook direct bij. En eens het ontdekt is is het ofwel te laat of weet je hoe het te voorkomen.

Hadden de mensen die besmet waren door flashback wel anti-virus op hun Mac gehad dan waren ze nog steeds besmet geweest met het flashback virus.

Momenteel blijft anti-virus software op de Mac gewoon geldklopperij.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 22:04]

[mae-t.net]

Jouw redenatie rammelt volgens de meest fundamentele logica (eerstejaarsvakje bij informatica- en rechtenopeidingen). Ander voorbeeldje:

De meeste mensen hebben geen SOA's
Een condoom beschermt niet volledig tegen elke SOA
-> Zonder condoom heb je evenveel kans op een SOA als met.

Nouja, analogieen gaan altijd een beetje mank, maar je snapt het punt hopelijk. Zo niet dan is een inleidende cursus in de logica altijd nog een optie.

[Reactie gewijzigd door mae-t.net op 24 juli 2024 22:04]

[Verwijderd]

Anti-virus vergelijken met een condoom is wel het domste wat je kan doen! Een condoom is geen product dat je moet updaten. Moest een condoom werken zoals anti-virus software zou een condoom helemaal niet veilig zijn want de condoom zou je niet beschermen tegen SOA's die nog niet door de condoomfabrikant zijn ontdekt.

Ik snap dat voor een windows gebruiker mijn logica zal rammelen want moest ik windows gebruiken zou ik zeker en vast anti-virus gebruiken. Maar de belangrijkste les voor een Windows gebruiker als je dan toch met SOA's wil vergelijken is dat op anti-virus betrouwen juist net het zelfde als geen condoom dragen is. Door anti-virus te vergelijken met een condoom geef je mensen een vals gevoel van vertrouwen!

Als je mij verwijt van dom te zijn dan kan je evengoed elke windows gebruiker verwijten van dom te zijn. Want als jij Anti-virus wil vergelijken met een condoom kan ik evengoed de Mac vergelijken met een condoom want de kans dat je een SOA oploopt met een condoom is bijna nihil net zoals een virus oplopen met een Mac bijna nihil is.

Mac gebruikers aanraden van anti-virus te gebruiken is eerder te vergelijken met mensen aanraden van pilletjes tegen de varkensgriep te nemen

[Reactie gewijzigd door Verwijderd op 24 juli 2024 22:04]

[mae-t.net]

Ik vergelijk helemaal geen antivirus met een condoom (ik dacht dat het je op die manier misschien eerder zou aanspreken maar jij neemt het veel te letterlijk). Ik had voor mijn voorbeeldje van jouw denkfout ook een willekeurig ander sprekend voorbeeld kunnen nemen van een conclusie die niet volgt uit de aannames.

Want dat is het feitelijk. Uit die link ook een voorbeeld dat gelukkig niets met virussen en condooms te maken heeft:

Bij 25% van de dodelijke ongevallen had de bestuurder alcohol gedronken en bij 75% van de dodelijke ongevallen had de bestuurder koffie gedronken. Het is dus veiliger als de bestuurder alcohol drinkt in plaats van koffie.

[Reactie gewijzigd door mae-t.net op 24 juli 2024 22:04]

[SED]

Een condoom is geen product dat je moet updaten.

Misschien ben je er nog niet aan toe. maar een condoom update je na elke keer gebruik


Meer serieus, want je lijkt het te menen.

Elke goed beveiligde computer heeft ene firewall. Als er toch iets doorkomt dan is die firewall niet slecht maar moet je de instellingen aanpassen.
Dat wil niet zeggen dat die firewall al die tijd nutteloos was.
Denk daar eens even over na..

Ook OSX heeft inmiddels malware scanners aan boord, al zijn die erg beperkt. De noodzaak is ook daar bekend. Het is zelfs zeer goed mogelijk dat er reeds een flame variant op Apples OSX actief is. ( waarschijnlijk zelfs)
Die zul je echter niet vinden omdat die zich stil houdt en alleen data doorstuurt.

Dankzij de intense technische kennis die men met windows opgedaan heeft kan men flame nu traceren en bestrijden. Die stappen moeten bij OSX allemaal nog gezet worden.

[Reactie gewijzigd door SED op 24 juli 2024 22:04]

[IStealYourGun]

Met deze onthulling lijkt dit inderdaad zo te zijn, je hebt er niet alleen goede programmeurs voor nodig maar ook cryptografen.

[Verwijderd]

Klopt, en het wordt alleen maar geavanceerder, Criminaliteit op straat lijkt steeds verder terug te zakken, en het verleden leert dat criminelen evolueren, en nu dus steeds meer de digitale weg kiezen. Als je genoeg geld hebt kun je de beste hackers inhuren.

Overheden kunnen zelf ook als crimineel worden gezien, omdat ze voor eigen doeleinden principes opzij zetten en potentieel zelf regels overtreden.

[Underworld]

Lekker slim trouwens van CWI Centrum voor Werk en Inkomen (oprichting jr: 19/10/1993). Om je instituut dezelfde naam te geven als Centrum Wiskunde & Informatica oprichting (jr: 11/02/1946)...