Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 58 reacties

IsraŽlische onderzoekers van de Universiteit van Haifa zijn er in geslaagd het algoritme van de pseudo-random number generator van Windows 2000 te reconstrueren en zijn zo op een aanvalsmethode gestuit.

De kwetsbaarheid die de onderzoekers hebben gevonden met betrekking tot de pseudo-random number generator stelt een aanvaller in staat informatie te achterhalen die verzonden is voor de hack van het systeem heeft plaatsgevonden. De prng van Windows is cruciaal voor de beveiliging van bijna alle applicaties die draaien op het besturingssysteem. Het algoritme van de generator is nooit gepubliceerd.

Random karaktersDoor de binaire code van Windows 2000 te analyseren is het IsraŽlische onderzoeksteam er echter in geslaagd het algoritme te reconstrueren en de beveiliging ervan op de proef te stellen. Het team kwam tot een succesvolle aanval: als de staat van de generator bekend is aan de aanvaller, bijvoorbeeld door een bufferoverflow, blijkt het mogelijk de voorgaande staat af te leiden. De manier waarop Windows gebruikmaakt van de generator blijkt bovendien het effect van de aanvalsmethode te versterken.

Zo bleek de staat van de generator pas ververst te worden nadat 128KB aan gegevens doorgestuurd zijn naar het proces dat de generator aangeroepen heeft. Bovendien draait elk proces een andere kopie van de prng. Gevolg is dat een aanval waarbij de staat van de generator bekend is 128Kbyte aan data kan onthullen van voor of na die staat, zoals ssl-sleutels.

Volgens de onderzoekers is hun aanval ernstiger en efficiŽnter dan reeds bekende aanvalsmethoden waarbij een aanvaller alleen achter ssl-sleutels kan komen als deze controle heeft over het systeem op het moment dat de sleutels gebruikt wordt. Het lijkt er echter wel op dat de applicatie die de prng aangeroepen heeft vatbaar moet zijn voor een aanval of dat de aanvaller administrator-rechten op het systeem moet zien te bemachtigen om het lek te misbruiken.

Het team heeft alleen Windows 2000 onderzocht, maar neemt aan dat Windows XP en Vista dezelfde generator gebruiken en dus ook kwetsbaar zijn.

Moderatie-faq Wijzig weergave

Reacties (58)

Van wat ik tijdens DevDays 2007 heb gehoord, is de hele cryptografische library in Vista op de schop genomen: Best een aanwezige kans dus dat het in Vista anders zit.
Ik neem aan dat het om de random generator in de Visual C/C++ runtime library gaat en niet de random generator in de Cryptography API. Het klopt overigens dat Vista en Windows 2008 Server een vernieuwde Cryptography API ondersteunen.
Het gaat om de CryptGenRandom functie uit de Cryptography API, niet om de rand() functie uit stdlib.h; dat zou ook vrij nutteloos zijn omdat die sowieso niet bedoelt is voor cryptografische doeleinden.
Het kan aan mij liggen maar ik vind het allemaal redelijk normaal klinken en zeker niet spannend. Een random getal van een generator is toch altijd gebaseerd op de staat van de generator en dus ook op de vorige output/systeemklok etc.

Lijkt me vrij logisch dat als je via reverse engineering tot assemblycode/broncode komt dat je dan kan voorspellen wat er is gebeurt/gebeuren gaat.

Verder wordt er ff verondersteld dat men achter de staat komt via een bufferoverflow...

kortom als de code gewoon goed geprogrammeerd is/aangepast wordt zodat bufferoverflow niet mogelijk is dan is de hele methode waardeloos.

verder zal geen enkel programma keys uitleveren die 100% deze random waarde bevat en dus moet je nog altijd ook ff over de broncode/werking daarvan beschikken.

ps. het nabouwen/reverse engineren van iets is niet hetzelfde als het "kraken" van iets tenzij dit direct leidt tot een key.

[Reactie gewijzigd door Thundy op 13 november 2007 16:30]

kortom als de code gewoon goed geprogrammeerd is/aangepast wordt zodat bufferoverflow niet mogelijk is dan is de hele methode waardeloos.
Doe jij dat even? Bufferoverflows kunnen in elke software zitten, en daar kun je maar beter rekening mee houden. Er zijn genoeg gebruikers met ongepatchte software.
ps. het nabouwen/reverse engineren van iets is niet hetzelfde als het "kraken" van iets.
Dat word ook niet beweert, men heeft 'm gekraakt na het reverse engineeren... Als je zegt dat je algoritme pseudo-random nummers produceert, en als er dan aangetoond is dat dit niet het geval is, dan kun je zeggen dat het algoritme, en daarmee de PRNG, 'gekraakt' is.

[Reactie gewijzigd door JanDM op 13 november 2007 16:54]

waar lees jij dat dit niet het geval is?

het enige wat ze aangetoond hebben is dat ALS ze de state weten, ze het vorige getal kunnen berekenen en pas NA het achterhalen van de broncode.

iets wat mij vrij logisch en ongevaarlijk klinkt aangezien je toch echt al dik binnen in het systeem moet zijn (via een hack) voordat je uberhaubt toegang hebt tot het geheugen van PRNG (via nog een hack)...
Bijna goed: lineaire congruentie methodes klopt dit voor, maar een beetje random generator voor crypto doeleinden voert continue randomness toe aan de generator (interupt ratio, muisbewegingen, disk activiteiten) om zo te voorkomen dat je kunt voorspellen. Ook dit is niet waterdicht (als je het aantal netwerk pakketjes per seconde mee gaat nemen kun je het extern beinvloeden...) maar zeker niet te hacken op de door jou voorgestelde wijze.
Een zeer originele manier om een aanval uit te voeren dat wel.
Het lijkt er echter wel op dat de applicatie die de prng aangeroepen heeft vatbaar moet zijn voor een aanval of dat de aanvaller administrator-rechten op het systeem moet zien te bemachtigen om het lek te misbruiken.
Gelukkig valt de ernst van de situatie nogal mee. Als je adminrechten op een pc kan krijgen is een bestaand ssl wachtwoord niet echt je grootste zorg.
"Klik hier om de nieuwste emoticons te downloaden"

Maar wat de mensen niet weten, is dat het hier eigenlijk niet gaat om emoticons, maar -heel slim- om een verborgen app die de prng aanroept. :Y)
Dat gaat dus niet werken:
Bovendien draait elk proces een andere kopie van de prng.
Aan de ene kant wel goed dat ze het doen, liever een paar onderzoekers dan een groep russische krakers :) Maar aan de andere kant, dit is onderzoek wat iemand anders niet zou doen omdat het teveel tijd kost. Nu is windows dus kwetsbaar terwijl het in oude situatie het niet zo was...Maar MS zal het nu wel moeten patchen (voor zover mogelijk).
Vind dat ze hun tijd beter kunnen besten aan nieuwe beveiligingstechnieken ipv dit. MS kan het met de source in handen veel sneller.

[Reactie gewijzigd door Mr_gadget op 13 november 2007 16:00]

Als MS daadwerkelijk de intentie hadden om de prng te onderzoeken, dan is het waarschijnlijker dat ze die hele prng direct goed ontworpen hadden.
Blijkbaar vonden ze bij MS de prng een goede oplossing en is er een onderzoek van onafhankelijke mensen voor nodig om dat te weerleggen.

edit: tiepvaud

[Reactie gewijzigd door sobani op 13 november 2007 16:39]

Ik vraag me af of programma's die draaien onder Windows ook gebruik maken van deze generator. Als dat zo is, dan zijn die ook gevoelig hiervoor, toch? Ik kan me voorstellen dat bijvoorbeeld Java een eigen random nummer generator heeft (virtuele machine e.d.), maar is dat ook zo bij C / C++ e.d. programma's?
Dat is dan een behoorlijke blunder van de Microsoft programmeurs. Pseudo-random number generators 101: zorg dat je uit de toestand van de PRNG op moment t de toestand op moment t - 1 niet kan afleiden. Zie ook http://en.wikipedia.org/wiki/PRNG.
Is het niet zo dat ze juist de andere kant opgaan, naar t+1?
Dus de toekomst in, waardoor de randomness verdwijnt.
enig idee hoe oud deze opzet is? van pakweg 1998 ongeveer dus bijna 10 jaar geleden. Kom jij aan met een brandnieuw artikel waarin recente ideeen verwerkt zijn en dat vergelijk je met oude software. Dan kom je tot de wereldschokkende conclusie dat het niet meer bij de tijd is.
Dat is een behoorlijke blunder van confusion lijkt me ;)
Verbaast me dat ze hier na zoveel tijd op zijn gekomen door
de binaire code van Windows 2000 te analyseren
Een paar jaar terug was de win2k source van het internet te plukken.... had ze heel wat moeite kunnen besparen :/
Ik denk dat ze dan een groot probleem hadden gehad, als MS erachter was gekomen hoe ze het onderzoek uitgevoerd hebben. Een beetje onderzoekend bedrijf publiceert uiteraard de onderzoeksrapporten.
Nee hoor, alleen maar gedeeltes van de source.
De code hebben is 1 ding, em goed lezen en de betreffende stukken eruit halen (en doorkrijgen hoe ze werken) is 2. Een mooi Java-filetje kun je snel doorlopen, try that met binair ;) Overigens vraag ik me inderdaad af hoe ze door de EULA heen gekomen zijn, waarin doodleuk staat dat het reverse engineren van software niet toegestaan is.
Omdat je een 64-bit processor hebt? :+

Maar ontopic: Weer een veiligheids gat gevonden, maar het is alleen voor Windows 2000 zeker. Ik ga ervanuit dat het in XP nog wel zou kunnen, maar Vista hebben zo nogal omgegooid. Wel NT natuurlijk, maar de kernel is ook omgegooid. Dit is en blijft natuurlijk wel een veiligheidslek, XP of niet. Het feit dat je in XP standaard admin rechten hebt, en in Vista mensen toch UAC uitzetten of veel te makkelijk op 'Oke, toestaan' klikken, maakt het lek er niet minder op.

Als ik het goed begrijp is dat prnm dus nodig voor technieken in Windows dat geloof ik Data Execution Prevention heet? In dat geval is het wel zorgelijk, aangezien het inschakelen hiervan wel een grote positieve impact (qua beveiliging) op je systeem schijnt te hebben.

Toch is het geen echt veiligheidslek lijkt me, want alles kan je reverse-engeneeren. Dit zou immers met Linux net zo goed kunnen als met Windows, slecht voorbeeld van Linux is open source, maar alles kan je reverse engeneeren lijkt me, en dan kan je van alles een veiligheidslek maken?

[Reactie gewijzigd door Sebazzz op 13 november 2007 15:57]

Toch is het geen echt veiligheidslek lijkt me, want alles kan je reverse-engeneeren. Dit zou immers met Linux net zo goed kunnen als met Windows, slecht voorbeeld van Linux is open source, maar alles kan je reverse engeneeren lijkt me, en dan kan je van alles een veiligheidslek maken?
Nee, het probleem is niet dat ze de prng gereverse-engineerd hebben. Het probleem word in het bronartikel als volgt omschreven:
We analyzed the security of the algorithm and found a non-trivial attack: given the internal state of the generator, the previous state can be computed in $O(2^{23})$ work (this is an attack on the forward-security of the generator, an $O(1)$ attack on backward security is trivial). The attack on forward-security demonstrates that the design of the generator is flawed, since it is well known how to prevent such attacks.
Dus het open zijn van de generator maakt niets uit, als die maar goed in elkaar zit. Omdat dit zo'n belangrijk onderdeel is kun je er denk ik wel vanuit gaan dat dit bij Linux iig door tientallen beveiligingexperts onderzocht is :)
Het team heeft alleen Windows 2000 onderzocht, maar neemt aan dat Windows XP en Vista dezelfde generator gebruiken en dus ook kwetsbaar zijn.
* TRRoads mompelt iets over assumption en mother

Het team neemt aan dat XP en Vista hetzelfde algoritme gebruiken, maar we zijn inmiddels flink wat verder dus het is goed mogelijk dat er een compleet ander algoritme gebruikt wordt.

Het is dus niet al te verstandig van ze om dat zomaar aan te nemen, zeker aangezien dat op zich eenvoudig te achterhalen moet zijn nu ze weten waar te kijken.

[Reactie gewijzigd door TRRoads op 13 november 2007 22:01]

Toch schat ik de kans op exploits die hiervan gebruik maken erg klein in door de complexiteit van het hele verhaal. Ik vermoed dat deze 'weakness' alleen gebruikt zullen worden voor high-level hacks/spionage aangezien het, as far as I can tell, niet echt toepasbaar is op thuis gebruikers. Met name overheden en grotere multinationals zullen dit aangrijpen om (naar ik hoop) te zorgen dat er geen systemen draaien die hiervoor gevoelig zijn.
Waarom is het niet toepasbaar op thuisgebruikers?
De hack maakt toch geen onderscheid tussen 2000, XP of Vista?

De kans dat iemand een thuisgebruiker gaat hacken is wel erg klein omdat daar over het algemeen minder te halen valt dan bij een bedrijf.
De hack maakt toch geen onderscheid tussen 2000, XP of Vista?
Dat is dus eignelijk niet bekend.
Zeker bij vista zijn grote stukken van de cryptografie herschreven en hoeft dite helemaal niet hetzelfde te werken. Het is echter niet uitgesloten dat dat wel zo is.
Ik vermoed hetzelfde. Dit probleem vind ik vergelijkbaar met dat P4 HT cache "exploit", wat ook een behoorlijke storm in een glas water was.

Je moet Administrator rechten hebben om ook maar iets te kunnen doen, als je dat al hebt kan je ook op genoeg andere (makkelijkere) manieren aan keys en dergelijke komen.

[Reactie gewijzigd door Radiant op 13 november 2007 18:54]

Bijvoorbeeld het Storm botnet wordt zeker niet bestuurd door een scriptkiddie, maar door mensen met diepgaande kennis van computerbeveiliging, die complexe software schrijven. Kennis van encryptie en prng's zal ongetwijfeld tot hun arsenaal behoren.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True