Het nieuwe brute-forcen

Door HaX0r op donderdag 4 augustus 2011 13:37 - Reacties (27)
Categorie: Diepere Shit, Views: 4.169

Laats las ik een artikel over een duitse hacker genaamd Thomas Roth die een GPU Cluster had gemaakt van een amazon Cloud. Hij kon hiermee binnen 49 minuten 14 verschillende hashes van 95 karakters bestaande 6 cijferige codes kraken. Het ging hier om de SHA-1 hash. Mijn intresse was gewekt en ik begon na te denken over de toekomst van brute-force aanvallen.

Nu is de SHA-1 hash niet bedoelt om wachtwoorden in op te slaan maar om data te verifiŽren. Dealnietsmin is dit een enorme prestatie. Het laat zien dat je op een hele goedkope manier GPU's kan parallelliseren om een enorme rekenkracht te verkrijgen. Voor maar 2 dollar en 10 cent per uur! Dat betekent dat bijvoorbeeld creditcard wachtwoorden enorm snel verkregen kunnen worden. Het gevaar zit hem in de lage kosten, iedereen kan hier gebruik van maken.

Nog even voor de leken onder ons. Brute forcen betekent simpelweg alle mogelijke combinaties proberen die mogelijk zijn. Als we in de toekomst Clouds beter kunnen aansturen is het misschien mogelijk om deze speciaal te gebruiken voor brute-force aanvallen. Ik denk hier aan aan een systeem om verschillende startpunten te gebruiken. Even heel simpel uitgelegd.

Je hebt een password, je weet dat hij niet meer als 5 cijfers lang is en bestaat uit de nummers 0-9. Dit is even om het makkelijk te maken. Je bruteforce begint in dit geval bij 0 en gaat dan de cijfers af tot 9. Vervolgens begint hij bij 00 en gaat vervolgens deze cijfers weer af in dit geval gaat dat dus met 10, 20, 30 enz en dan 11, 12, 13 en zo gaat hij alle mogelijke combinaties af.

Als je nou eens verschillende clusters zou kunnen aansturen om op een verschillende punten te beginnen met de brute-force. Bijvoorbeeld: 0, 00, 000, 000, 0000 en 00000 dan zou de snelheid waarmee je de juiste code raad een stuk hoger liggen dan dat je braaf van 0 begint. Zou je geen snelheid verliezen door met verschillende startpunten te beginnen dan zou je de tijd die nodig is om de juiste combinatie te raden heel erg inkorten.

Persoonlijk zou ik niet weten hoe dit echt in zijn werk zou gaan maar ik vond het een interessante gedachte. De strijd tussen encrypters en decrypters staat in ieder geval al lang genoeg aan de kant van de encrypters. Tijd voor verandering!

Voor de mensen die zich hierin willen verdiepen heb ik een lijstje gemaakt.

Leesvoer:
http://en.wikipedia.org/wiki/Brute-force_attack
http://en.wikipedia.org/wiki/Hash_function
http://en.wikipedia.org/wiki/SHA1
http://en.wikipedia.org/wiki/Collision_attack
http://en.wikipedia.org/wiki/Hash_table#Collision_resolution
http://en.wikipedia.org/wiki/Rainbow_tables
http://en.wikipedia.org/wiki/Salt_%28cryptography%29

Met jullie hulp kan deze lijst vast uitgebreid worden!
Dank aan: Llanorant

Volgende: Het nieuwe brute-forcen 2 08-'11 Het nieuwe brute-forcen 2
Volgende: Ding-dong 07-'11 Ding-dong

Reacties


Door Tweakers user Wortelsoep, donderdag 4 augustus 2011 13:47

De strijd tussen encrypters en decrypters staat in ieder geval al lang genoeg aan de kant van de encrypters.
Eh, waarom? Is het een wedstrijd? Is het een goede zaak als bruteforcen gemakkelijker wordt?
Ik heb verder ook geen verstand van deze materie, maar er zijn toch algoritmen die met de huidige technieken honderden of duizenden jaren zullen duren om te kraken. Natuurlijk kan een cloud dat versnellen, maar hoeveel? En is het niet een kwestie van een algoritme "vergroten" (ik ken van distributed.net RC5 64 en 72, waarbij 72 exponentieel zwaarder was)?

Door Tweakers user dcm360, donderdag 4 augustus 2011 13:52

Apart dat je het in de conclusie van dit stukje het ineens over encryptie gaat, terwijl het hele stuk erboven over hashing gaat.

Door Tweakers user Stouten, donderdag 4 augustus 2011 13:53

Eerder 0, 10000, 20000, 30000, 40000?

Door Tweakers user TWeaKLeGeND, donderdag 4 augustus 2011 13:55

Stel nou dat het 7 characters was dan zou het 95x zo lang duren gemiddeld. Stel nou dat het 8 characters was, dan was hij al 300 dagen bezig. Wat nou als het 9 characters waren?

Heb je enig idee hoeveel geld aan stroom alleen al je zou moeten besteden om bijvoorbeeld een winrar password te kraken van een relatief laag aantal characters van 16? Ongeacht dat het met zelfs de gehele amazon cluster of bijvoorbeeld het nog veel grotere bitcoin netwerk (vele tienduizenden GPU's) jaren (levens) zou duren.

Zo een zielig wachtwoord van 6 characters heb ik amazon niet voor nodig hoor, dat doe ik makkelijk thuis.

[Reactie gewijzigd op donderdag 4 augustus 2011 13:58]


Door Tweakers user HaX0r, donderdag 4 augustus 2011 13:58

Wilko schreef op donderdag 04 augustus 2011 @ 13:47:
[...]


Eh, waarom? Is het een wedstrijd? Is het een goede zaak als bruteforcen gemakkelijker wordt?
Ik heb verder ook geen verstand van deze materie, maar er zijn toch algoritmen die met de huidige technieken honderden of duizenden jaren zullen duren om te kraken. Natuurlijk kan een cloud dat versnellen, maar hoeveel? En is het niet een kwestie van een algoritme "vergroten" (ik ken van distributed.net RC5 64 en 72, waarbij 72 exponentieel zwaarder was)?
Ik denk niet dat het echt een wedstrijd is maar zo kan je het wel zien. In heel veel gevallen niet maar in sommige wel. De politie kan nu bijvoorbeeld geen inzage krijgen in bestanden van criminele als deze met een 128bit encryptie beveiligt zijn. Aan de andere kant wil je niet dat iemand makkelijk jou wachtwoorden kan kraken of je pincode.

Maar als brute-forcen makkelijker wordt moet er weer betere encryptie komen. Ze helpen elkaar evolueren. :)

Dat klopt, vandaar dat ik zeg dat de strijd al lang genoeg staat aan de encrypters. Er valt niet eens meer wat te decrypten. Slechts brute-forcen.

Klopt ook, maar we weten niet hoe snel we kunnen brute-forcen. De full potentie is in ieder geval nog lang niet bereikt.

Door Tweakers user RobIII, donderdag 4 augustus 2011 14:00

Brute-forcen is leuk voor offline attacks; de gemiddelde (fatsoenlijke) website/webapp of SSH/FTP/Mail-server of whatever gaat na een x-aantal pogingen (zeg 3, 5 of 10) gewoon "op slot" (al dan niet voor bepaalde tijd) voor een bepaalde user/ip/whatever. Daar gaat je brute-force. (Los van 't feit dat als je alle pogingen parallel aan elkaar op een online iets zou loslaten 't binnen de korste keren onder deze omstandigheden door de knieŽn zou gaan of er wordt ingegegrepen door "anti DDOS" maatregelen.)

Verder is het al sinds dag 1 van het bestaan van hashes bekend dat ze te bruteforcen zijn (het is niets nieuws, het is inherent aan het algoritme) en daarbij dat er collisions mogelijk zijn (er zijn meerdere "antwoorden" die naar dezelfde hash leiden). De clue is waar 't break-even punt ligt: is het de moeite waard om iets te brute-forcen en de tijd die je er in steekt en... Het enige verschil is dat 't steeds sneller gaat en er dus steeds makkelijker een offline brute-force is uit te voeren.

En verder haal je hashing en encryptie door elkaar (zie dcm360)

[Reactie gewijzigd op donderdag 4 augustus 2011 14:02]


Door Tweakers user HaX0r, donderdag 4 augustus 2011 14:01

dcm360 schreef op donderdag 04 augustus 2011 @ 13:52:
Apart dat je het in de conclusie van dit stukje het ineens over encryptie gaat, terwijl het hele stuk erboven over hashing gaat.
Bedankt, er is inderdaad helemaal geen sprake meer van echte decryptie. Ik vond het echter zo wel goed klinken.

Door Tweakers user HaX0r, donderdag 4 augustus 2011 14:06

RobIII schreef op donderdag 04 augustus 2011 @ 14:00:
Brute-forcen is leuk voor offline attacks; de gemiddelde (fatsoenlijke) website/webapp of SSH/FTP/Mail-server of whatever gaat na een x-aantal pogingen (zeg 3, 5 of 10) gewoon "op slot" (al dan niet voor bepaalde tijd) voor een bepaalde user/ip/whatever. Daar gaat je brute-force. (Los van 't feit dat als je alle pogingen parallel aan elkaar op een online iets zou loslaten 't binnen de korste keren onder deze omstandigheden door de knieŽn zou gaan of er wordt ingegegrepen door "anti DDOS" maatregelen.)

Verder is het al sinds dag 1 van het bestaan van hashes bekend dat ze te bruteforcen zijn (het is niets nieuws, het is inherent aan het algoritme) en daarbij dat er collisions mogelijk zijn (er zijn meerdere "antwoorden" die naar dezelfde hash leiden). De clue is waar 't break-even punt ligt: is het de moeite waard om iets te brute-forcen en de tijd die je er in steekt en... Het enige verschil is dat 't steeds sneller gaat en er dus steeds makkelijker een offline brute-force is uit te voeren.

En verder haal je hashing en encryptie door elkaar (zie dcm360)
Klopt ja, niet elke site heeft echter een anti DDOS systeem. De meeste hebben een simpel IDS systeem. Die houd niks tegen en report alleen maar. Tevens kan je ook verschillende ip's gebruiken etc. Het gaat hier inderdaad op een vooruitgang op file brute forcen. :)

Door Tweakers user CodeCaster, donderdag 4 augustus 2011 15:13

Dat betekend dat bijvoorbeeld creditcard wachtwoorden enorm snel verkregen kunnen worden.
Ik snap deze conclusie niet en weet ook niet wat creditcardwachtwoorden zijn. Enlighten me?

@Hashing/encryptie-minidiscussie: hashing wordt ook wel one-time encryption genoemd, tenminste, als ik Google moet geloven. Of is dat een layman's term die formeel niet bestaat?

[Reactie gewijzigd op donderdag 4 augustus 2011 15:20]


Door Tweakers user HaX0r, donderdag 4 augustus 2011 15:23

CodeCaster schreef op donderdag 04 augustus 2011 @ 15:13:
[...]

Ik snap deze conclusie niet en weet ook niet wat creditcardwachtwoorden zijn. Enlighten me?
Het gaat dan om je beveiligings code, CVV2 genoemd. Deze wordt ergens gewoon gebrute-forced tot hij werkt. Vervolgens word er misbruik van gemaakt.

Door Tweakers user ameesters, donderdag 4 augustus 2011 15:39

dcm360 schreef op donderdag 04 augustus 2011 @ 13:52:
Apart dat je het in de conclusie van dit stukje het ineens over encryptie gaat, terwijl het hele stuk erboven over hashing gaat.
hashing is een vorm van encryptie ;)

Door Tweakers user HaX0r, donderdag 4 augustus 2011 15:42

ameesters schreef op donderdag 04 augustus 2011 @ 15:39:
[...]


hashing is een vorm van encryptie ;)
Klopt ook, maar brute force is geen decryptie methode. Ik dacht dat hij daar op doelde. :P
Dank.

Door Tweakers user Rafe, donderdag 4 augustus 2011 15:49

HaX0r schreef op donderdag 04 augustus 2011 @ 15:23:
[...]


Het gaat dan om je beveiligings code, CVV2 genoemd. Deze wordt ergens gewoon gebrute-forced tot hij werkt. Vervolgens word er misbruik van gemaakt.
Een CVV2 hoort bij een bepaalde creditcard. Ook al probeer je verschillende authenticatiepogingen vanuit verschillende pc's/cloudhosters, gaan er bij Visa of MasterCard echt wel alarmbellen af en wordt de betreffende CC tijdelijk geblokkeerd als je zoiets probeert. Ik ben zelf eens gebeld voor iets veel simpeler was: of het klopte dat ik midden in de nacht een laptop had besteld via internet, voordat ze de transactie door lieten gaan.

CodeCaster: one-way encryption ;) De output van een hashfunctie is tenslotte niet terug te rekenen naar de input.

H4X0r: in je stuk staat "goedkope manier GPU's kan paralyseren", ik neem aan dat je niet verlammen maar parallelliseren bedoeld :)

Door Tweakers user Sgreehder, donderdag 4 augustus 2011 15:58

SHA-1 is al een tijdje geleden bevonden als 'kwetsbaar' (zie: http://eprint.iacr.org/2008/469.pdf). Overigens is een hash geen vorm van encryptie, het is immers niet de bedoeling de oorspronkelijke data te 'verbergen'. Een cryptografische functie is een betere term.

En het heeft ook weinig van doen met brute-forcen, aangezien het vinden van een collision te maken heeft met een zwakte in het algoritme zelf, nog buiten het feit dat hier gewoon bekend is welke input in de hash wordt gestopt.

Geen nieuws dus. Kortom, MD5 is kut, SHA-1 is kut, aan een opvolger van SHA-2 wordt gewerkt 'just-in-case'.

[Reactie gewijzigd op donderdag 4 augustus 2011 15:59]


Door Tweakers user HaX0r, donderdag 4 augustus 2011 16:23

Rafe schreef op donderdag 04 augustus 2011 @ 15:49:
[...]

Een CVV2 hoort bij een bepaalde creditcard. Ook al probeer je verschillende authenticatiepogingen vanuit verschillende pc's/cloudhosters, gaan er bij Visa of MasterCard echt wel alarmbellen af en wordt de betreffende CC tijdelijk geblokkeerd als je zoiets probeert. Ik ben zelf eens gebeld voor iets veel simpeler was: of het klopte dat ik midden in de nacht een laptop had besteld via internet, voordat ze de transactie door lieten gaan.

CodeCaster: one-way encryption ;) De output van een hashfunctie is tenslotte niet terug te rekenen naar de input.

H4X0r: in je stuk staat "goedkope manier GPU's kan paralyseren", ik neem aan dat je niet verlammen maar parallelliseren bedoeld :)
Danku, heb het aangepast. :)

@Sgreehder

Het gaat hier ook niet om de daadwerkelijke prestatie maar om de uitwerking ervan. GPU Clusters hiervoor inzetten en de snelheid waarmee dat gaat is nieuws.

[Reactie gewijzigd op donderdag 4 augustus 2011 16:25]


Door Tweakers user CodeCaster, donderdag 4 augustus 2011 16:59

Rafe schreef op donderdag 04 augustus 2011 @ 15:49:
CodeCaster: one-way encryption ;) De output van een hashfunctie is tenslotte niet terug te rekenen naar de input.
Oeps, thanks.

Door Tweakers user Stroopwafels, donderdag 4 augustus 2011 17:37

En dus vraag ik me af of het ook slim is om 2 salts te gebruiken, eentje in de database en eentje in het script zelf en dan die te combineren.

Laten we ervan uitgaan dat alleen SQL injectie mogelijk is.
Dan kan er zeker gebruik gemaakt worden van een of andere read_file functie in SQL?

Maarja dan heb je natuurlijk de kans dat de brute-forcer gewoon de hash gaat "cracken" ook al zit er een salt in.

[Reactie gewijzigd op donderdag 4 augustus 2011 17:38]


Door Tweakers user Damic, donderdag 4 augustus 2011 18:46

Wilko schreef op donderdag 04 augustus 2011 @ 13:47:
[...]
...En is het niet een kwestie van een algoritme "vergroten" (ik ken van distributed.net RC5 64 en 72, waarbij 72 exponentieel zwaarder was)?
Was??? Het is gewoon "zwaarder" (langer) maar nu ze eindelijk in gang geschoten zijn met de gpu's (vooral Stream is UBER) gaat het verdomd goed vooruit.

Door Tweakers user Staatslot, donderdag 4 augustus 2011 20:22

Het is compleet offtopic, maar ik moet het toch even melden..
2x het betekent met een d schrijven?? En het is bedoeld met een t?

Hoe leuk ik je stuk ook vind, serieus, ik haak echt af na 3 van dit soort fouten op het eerste oog. Sorry...

Door Tweakers user HaX0r, donderdag 4 augustus 2011 20:38

Staatslot schreef op donderdag 04 augustus 2011 @ 20:22:
Het is compleet offtopic, maar ik moet het toch even melden..
2x het betekent met een d schrijven?? En het is bedoeld met een t?

Hoe leuk ik je stuk ook vind, serieus, ik haak echt af na 3 van dit soort fouten op het eerste oog. Sorry...
Thx aangepast. Zou je voortaan dit in DM kunnen sturen?
Gelukkig stond het er maar 2x in. :)

[Reactie gewijzigd op donderdag 4 augustus 2011 20:39]


Door Tweakers user mtak, donderdag 4 augustus 2011 23:25

Als je brute force leuk vind, vind je http://en.wikipedia.org/wiki/Rainbow_tables vast ook wel leuk.


Door Tweakers user sfranken, vrijdag 5 augustus 2011 00:19

Wilko schreef op donderdag 04 augustus 2011 @ 13:47:
[...]


Eh, waarom? Is het een wedstrijd? Is het een goede zaak als bruteforcen gemakkelijker wordt?
Ik heb verder ook geen verstand van deze materie, maar er zijn toch algoritmen die met de huidige technieken honderden of duizenden jaren zullen duren om te kraken. Natuurlijk kan een cloud dat versnellen, maar hoeveel? En is het niet een kwestie van een algoritme "vergroten" (ik ken van distributed.net RC5 64 en 72, waarbij 72 exponentieel zwaarder was)?
Ja, want als het gekraakt word wordt er wat beters verzonnen

Door Tweakers user Gomez12, vrijdag 5 augustus 2011 01:11

Simpelste oplossing is gewoon je minimale wachtwoord lengte verlengen en max wachtwoord lengte groot maken.

7 karakter wachtwoord duurt al veel langer dan die 14 minuten, 8 karakters nog veel en veel langer.

6 karakter wachtwoord verlengen zonder dat de gebruiker het merkt is simpel te doen door een salt toe te voegen. Salt is weer simpel op te bouwen door het onder te verdelen in 2 stukken ( 1 bekend bij de server, 1 door de gebruiker aangegeven )

Door de gebruiker aangegeven salt-gedeelte is weer relatief simpel te doen door een klein stukje security by obscurity ( bijv geef aan de geheime vraag een id-nr voor welk userveld te gebruiken in de salt (vraag 1 = userid, vraag 2 = username, vraag 3 = woonplaats) etc. etc.

Op deze manier zit je zo vanuit een door de gebruiker ingevoerd wachtwoord van 6 karakters op een dbase-wachtwoord van 50 karakters of meer.

En op een hash van een ww van 50 karakters mag je van mij part het hele amazon cluster gooien diie ga je niet vinden binnen 14 minuten.

Dat is de kracht van een goed algoritme, de enige zwakte zit in de invoerlengte en die is kunstmatig zo opgerekt...

Door Tweakers user RobIII, vrijdag 5 augustus 2011 02:26

Gomez12 schreef op vrijdag 05 augustus 2011 @ 01:11:
En op een hash van een ww van 50 karakters mag je van mij part het hele amazon cluster gooien diie ga je niet vinden binnen 14 minuten.
Wake-up-call: Die 50 karakters hoef je helemaal niet te vinden; je moet gewoon een string vinden die dezelfde hash oplevert (lees: collision).

Door Tweakers user Korben, vrijdag 5 augustus 2011 08:26

RobIII schreef op vrijdag 05 augustus 2011 @ 02:26:
[...]

Wake-up-call: Die 50 karakters hoef je helemaal niet te vinden; je moet gewoon een string vinden die dezelfde hash oplevert (lees: collision).
Aangezien de hele hash bij SHA-1 maar 20 bytes is, is het volgens mij onwaarschijnlijk dat je bij wachtwoorden van minder dan 20 tekens een collision vindt. En een wachtwoord van 20 tekens brute-forcen duurt, ook met een Amazon EC2 GPU-cluster, ondoenlijk lang.

Als mijn berekening klopt dat het 3 minuten per wachtwoord kost, dan kost een wachtwoord van 7 tekens 9 minuten, 8 tekens 81 minuten, en als we uitgaan van een salt van 4 tekens kost een wachtwoord van 8 tekens dus 3.433.683.820.292.512.484.657.849.089.281 minuten.

Oh, en SHA-1 is 'onveilig', maar alleen omdat er in theorie een gevaar op collision bestaat...

[Reactie gewijzigd op vrijdag 5 augustus 2011 08:26]


Door Tweakers user martijnve, vrijdag 5 augustus 2011 16:11

Een salt heeft natuurlijk geen effect op de tijd die het kost om tot een collision te komen. Het is alleen om er voor te zorgen dat iemand niet even met een rainbowtable alle wachtoorden oplepelt na het verkijgen van de database.

[Reactie gewijzigd op vrijdag 5 augustus 2011 16:11]


Reageren is niet meer mogelijk