Hoofdcategorieën
Device Settings

Wachtwoorden kraken door ritme toetsaanslagen

Door Hielko van der Hoorn, donderdag 23 augustus 2001 17:00
Bron: vnunet.com, views: 3.780

VNUNET.com schrijft dat een groep onderzoekers van de Berkeley universiteit in California een nieuwe zwakte hebben ontdekt van SSH (Secure Shell). Laatst was al ontdekt dat wachtwoorden van twee tekens lang geen beveiliging bieden, en nu blijkt dat wachtwoorden afgeluisterd kunnen worden.

SSH stuurt elk teken wat de gebruiker intikt meteen door naar een andere machine. Door deze packets af te luisteren en wat geavanceerde statistische technieken los te laten op het patroon waarmee dat gebeurt wisten de onderzoekers succesvol wachtwoorden te raden. Als je (veel) meer wilt weten over deze methode kan je hier terecht voor een 16 pagina’s tellende whitepaper :

SSH was designed as a secure channel between two machines, based on strong encryption and authentication. But by observing the rhythm of keystrokes, and using advanced statistical techniques on timing information collected, attackers can pick up significant details.

Each keystroke from a user is immediately sent to the target machine as a separate IP packet. By performing a statistical study on a user's typing patterns, and applying a key sequence prediction algorithm, the researchers managed to successfully predict key sequences from inter-keystroke timings.

A password cracker program, dubbed Herbivore, was developed on the back of the research. Herbivore is capable of learning a user's password by monitoring SSH sessions.

Met dank aan Theswitch voor de tip!

Volgende 18:28 "Code Red is creatie van Amerikaanse overheid"
Vorige 16:31 Excite@Home Australië zoekt illegale downloads
Advertentie

Reacties

«  1  2  3  4  »

Laatst was al ontdenkt dat wachtwoorden van twee tekens lang geen beveiliging bieden
LOL :) Dat kan iedereen zo kraken ;)

(26+10)^2 is toch nog altijd 1296 mogelijkheden :)
(26 letters, 10 cijfers)

Hoeveel tekens heeft ASCII ook al weer? :+

Vraag me af hoe snel ze dus een pure cijfercombinatie kraken op deze manier...

Ik gebruik bijvoorbeeld weleens een 10-cijferige combinatie die ik inmiddels in minder dan 3 seconden in kan tikken ...
Maar dan echt alleen op het keypad en als ik mijn WW inmoet voeren ...

Ga dat dan maareens vergelijken met mijn normale typgedrag, wat veel en veel trager is omdat ik ..
A: niet met 10 vingers kan tikken
B: een zeer onregelmatige typsnelheid heb
C: niet echt blind kan typen

ze luisteren dus niet naar de echte aanslagen die worden gemaakt, maar naar de pakkets die naar de pc worden gestuurd, deze kunnen ze afluisteren, het is dus niet dat je door sneller of langzamer te typen je ww kan maskeren hiervoor

Je kunt dus juist wel door sneller of langzamer te typen je wachtwoord maskeren (voor als je echt erg paranoide bent dat is).

De afluisteraar ziet pakketjes voorbijkomen, waarbij elk pakketje een toetsaanslag voorstelt. Zoals trouwens ook in het artikel staat kun je dus door te kijken naar het ritme van voorbijkomende pakketjes redelijk gokken welke toetsen zijn ingetikt. Zo typ ik bijvoorbeeld de i en de j altijd erg snel achter elkaar en de c en de r veel langzamer.

Typ ik nu maar 1 letter per seconde, dan kun je onmogelijk achterhalen welke letters dat waren.

En dan nog:
and applying a key sequence prediction algorithm
Oftewel zorg ervoor dat je ww geen sequentie bevat, geen woorden dus maar losse letters, cijfers en andere tekens. Ik wil namelijk wel eens weten hoe ze het verschil kunnen ontdekken tussen ´wachtw´ en ´esvjye´. Hoewel je over de laatste weer een keyschifting kunt laten lopen die er weer netjes wachtw van maakt (toets naast de originele gebruikt)

O fuck ascii heeft zijn ezelsbruggetje verraden.....

Och mijn wachtwoord is ook $$$$ maar daar kun je toch niks mee want ik vertel ze niet in de goede volgorde :P :+

Binnen Unix zijn wachtwoorden hoofd- en kleine letter gevoelig, dus kun je (2x26+10)^2 als formule hanteren. En eventueel kun je uiteraard met andere ASCII codes werken. Alt-255 is een heel mooi en goed voorbeeld. Met een brute force progje ben je echter zo door al deze combinaties heen. Neem maar eens een voorbeeld aan de RC5-64 codekraker. Die doet zo een paar miljoen wachtwoorden per seconde...

Verder kun je in het artikel lezen dat het raden van het wachtwoord 50x versneld werd. Dus mocht je een wachtwoord hebben, dat (theoretisch) met de huidige computers binnen 50 jaar te kraken is, duurt het nou nog steeds 10 jaar.

btw Ik heb dit nieuwtje ook al gesubmit, was ik soms later dan Theswitch?

Binnen Unix zijn wachtwoorden hoofd- en kleine letter gevoelig
Wachtwoorden zijn altijd hoofdlettergevoelig, bij NT bij Novell (alleen de inlognamen niet altijd, denk maar aan het inloggen van een Win9x machine op NT).

Volgens mij staat SSH echt niet toe dat jij een paar miljoen keer per seconde probeert in te loggen. Zelfs lokaal lijkt me dat niet mogelijk.

Reactie op Gumkop: zowel het wachtwoord als de useraccount op netware is niet hoofdlettergevoelig. Op NT daarintegen is het wachtwoord wel hoofdlettergevoelig.

En eventueel kun je uiteraard met andere ASCII codes werken. Alt-255 is een heel mooi en goed voorbeeld.
Alt-zoveel werkt in unices niet, en bovendien zijn veel special chars niet toegestaan in je password.
Met een brute force progje ben je echter zo door al deze combinaties heen. Neem maar eens een voorbeeld aan de RC5-64 codekraker. Die doet zo een paar miljoen wachtwoorden per seconde...
Als je een 3DES encrypted wachtwoord wilt kraken, doet een tbird-1.4ghz ongeveer 2000 pogingen per seconde. Op een lokaal password.

Als je wilt inloggen (dus via brute-force proberen binnen te komen) gaat het VEEL trager, omdat ssh na een fout password 3 seconden wacht voor je opnieuw mag proberen. Dan kun je wel meerdere ssh sessies tegelijk openen en zo proberen, maar je kunt maar een beperkt aantal ssh-sessies tegelijk starten; op mijn computer ongeveer 400 (hierboven raakt de target bak door zijn file descriptors heen). 400/3=133 pogingen per seconde, onder ideale omstandigheden.
Verder valt dit erg sterk op natuurlijk (100+ sshds in de program listing.. goh)
Verder kun je in het artikel lezen dat het raden van het wachtwoord 50x versneld werd. Dus mocht je een wachtwoord hebben, dat (theoretisch) met de huidige computers binnen 50 jaar te kraken is, duurt het nou nog steeds 10 jaar.
50 / 50 = 1 jaar bedoel je. Bovendien heb je hier geen last van met de OpenSSH client (deze stuurt zijn password niet char voor char door). Ook als je een RSA of DSA key gebruikt, heb je hier geen last van.

WW's van 1 teken zijn ook vast niet zo lastig :Y)

edit: dit is dus een reactie op Robin van Rootseler.

Die bug met die tweeleterige wachtwoorden had geen bal te maken met het SSH protocol, maar met een programma. Of is codered soms ook een HTTP bug?

Dat wilde ik ff rechtzetten :)

Het probleem zat hem er meer in, dat er geen wachtwoord was, als er een wachtwoord van 2 getallen in de password file stond.

Oftewel, je kon op _veel_ verschillende (belangrijke systeem users, die normaal '!!' (geen wachtwoord dus eigenlijk) in de passwd file hebben, wel inloggen.
Zonder een password (of een willekeurige) in te voeren.

en inderdaad, het had niks met SSH 'ansich' te maken, maar met de implementatie (versie 3.0) van ssh.fi

overbodig

Als er eentje overbodig gemod wordt, laat het dan niet de bovenstaande zijn, want dat is nou juist de enige die het bij het goed eind heeft en de enige zinnige reactie is op de oorspronkelijke post van RvR.

/overbodig

Overigens - offtopic - passwords zijn bij NT niet hoofdlettergevoelig, zo lang je over het LanMAN password praat, zie l0ghtcrack (sp?) en de daarbij behorende docs voor meer info. Alleen de NT-passwordhash is caps-gevoelig.

interessant, ik dacht dat ze luisterden naar een toetsenbord als iemand zijn ww intypte.
Daar leek de titel wel op :)


via telnet wist ik het al, dat je zo packets op kon vangen
ssh en telnet is nogal een verschil, bij telnet hoef je alleen maar in het pakket te kijken wat erin zit en je hebt de toets. Bij deze attack moeten ze dagenlang het ritme van je toetsaanslagen loggen, en dan kunnen ze dat ritme vergelijken met het ritme waarmee de pakketjes voorbij komen als je je password intikt, en die vergelijking levert dan op dat ze het aantal mogelijkheden van je password terugbrengen waardoor ze een brute force attack kunnen gaan uitvoeren (die dan een paar dagen duurt i.p.v. een paart weken). Dus nogal een verschil met telnet, en zoals ze zelf al zeggen is het vrijwel alleen theoretisch mogelijk, in praktijk zitten er teveel haken en ogen aan (bijvoorbeeld: bijna iedereen heeft compressie aanstaan bij z'n ssh sessies, en dan werkt het al niet goed meer)

Logisch.. alles kan worden afgeluisterd. of je het kan begrijpen is een tweede.

Dus is dus puur op statisme gebouw het zwakste punt van elke beveiliging.

Lijkt me niet. Als ze het wachtwoord in zijn gehaal in plaats van per pakketje zouden versturen, kun je weinig meer met statistiek. Hetzelfde geldt voor de gecodeerde data.

statistical study = statISTische technieken

maar dat leek me duidelijk

iemand die met 1 vinger typt heeft toch geen herkenbaar patroon in zijn typritme zitten ?

iemand die met 1 vinger typt heeft toch geen herkenbaar patroon in zijn typritme zitten ?
ahhum.....
Tik eens met één vinger op de tafel....... :)

Ik denk dat dat net zo duidelijk af te lezen is als bij 10-vingertiepers. Omdat het er vooral om gaat dat je voor het indrukken van bepaalde toetsen combinaties ritmes gaat ontwikkelen. Al doe je dat met 1 vinger het ritme ontstaat meestal vanzelf.
Daarbij komt ook nog eens dat de meeste mensen waarvan het ook maar een beetje interessant is om hun ssh-inlogcode te weten waarschijnlijk niet met 1 vinger typen!

* 786562 milos

<edit>toevoeging</edit>

natuurlijk heeft die een bepaald typeritme.

Bij "nieuwe" keyboardkloppers duurt het langer om toetsen die je weinig gebruikt te vinden dan bijvoorbeeld de 'e' en de 'n'.

Bij de al iets ervarener, nog steeds met 1 vinger typende, keyboardklopper zal het langer duren om van de 'p' naar de 'z' te gaan dan om van de 't' naar de 'r' te gaan.

Dat *alles* langer duurt, dat maakt niet veel uit voor de statistische analyse : je kijkt over een langere periode naar de aanslagen.

Vanuit de diepere herrineringen van statistieklessen komen zaken als 'standaard deviatie' en 'gemiddelde' en 'mediaan' weer naar boven. -> het maakt niet zoveel uit hoe snel je tikt, het gaat om het relatieve tijdsverschil tussen twee toetsaanslagen.

Ik vraag me af hoe makkelijk dit gaat, ik heb er zo mijn twijfels bij. Er wordt zoveel ruis geintroduceerd bij het intypen.

Want:
1. Sommige mensen tikken met 2 vingers
2. Sommige missen een vinger
3. Hoe kan een computer nou zien of ik na een d en e of een r tik etc. Want dat duurt ongetwijfeld even lang
4. de lag tussen de twee computers!!!! die is vrij variabel en kan zo een kwart seconde worden. ik tik ongeveer 7 tekens per seconde dus dat valt gewoon binnen de foutmarge.

Ik denk dat ze het werkend hebben gekregen op dat onderzoeksinstituut, doordat ze de software hebben "getraind" op het tikgedrag van EEN bepaald persoon. Ja, dan is het vrij makkelijk om het te achterhalen. Maar normaal is het ipverkeer een veel grotere chaos.
En het waren twee computers die heel dicht bij elkaar stonden, dus GEEN lag, wat je in real world wel hebt.
edit:
lagverhaal uitgelegd

Ik wist al wel dat dit gebruikt werd als extra beveiliging. Dan werd het ritme waarmee je het password intikte vergeleken met wat je normaal doet. Iemand die jouw password geraden heeft zal het ongetwijfeld in een ander ritme intikken. Ik kan me wel voorstellen dat dit ook andersom kan. Niet feiloos misschien, maar wel voldoende om het aantal mogelijkheden sterk te beperken.

Het gaat dan niet om de exate aanslagen maar om dingen als: Tussen een q en een M zit veel tijd en tussen een q en een W niet

Dune: Walk without Rythem, SSH: Type without rythem.

Sommige mensen tikken met 2 vingers 2. Sommige missen een vinger
ze moeten niet voor niks een paar dagen al jouw toetsaanslagen loggen! :Z

want waarschijnlijk hebben ze de software "getraind" op het tikgedrag van een bepaald persoon.
Ze hebben idd de software getrained het tikgedrag te bepalen:
Herbivore is capable of learning a user's password by monitoring SSH sessions.
En dat is nou juist het mooie van dat Herbivore tooltje. Die kan voor de meeste gebruikers wachtwoorden achterhalen, door lang genoeg te monitoren en statistieken te bewaren voorspellen waar een er een e of d staat.
edit:
chraammaadiekaa lasdich sein

By performing a statistical study on a user's typing patterns, and applying a key sequence prediction algorithm,...
Lezen dus :)

zie bovenstaande reacties:

maar dan nog, het scheelt al onwijs veel als je een klein idee hebt van uit hoeveel letters het ww bestaat.... of welke mogelijke lettercombinaties erin zouden kunnen zitten.

gaat altijd nog sneller als bruteforce hacking. Dit is een zwaar stoer idee als je het mij vraagt.

Dit zal tot op zekere hoogte wellicht werken, maar als je een 10 tekens lang password hebt met hoofdletters, kleine letters, rare tekens en cijfers wordt dat niet in 1 keer geraden door op de "inter keystroke timing" te letten hoor... Misschien wordt het aantal mogelijkheden een stuk beperkter waardoor de brute force tijd kleiner wordt..

Trouwens: je moet daarvoor dus "een statistical study on a user's typing patterns" houden.. Niet zomaar op elk SSH accountje toe te passen dus :)

Dat betekent dus dat je je pw in een ander venster moet tikken, en dan kopieren.. Dan hebben ze je ritme in elk geval niet.

Niet vergeten vervolgens iets anders te kopieren, anders zit je password nog in de buffer! |:(

Heel simpele oplossing hiervoor: gewoon in een abnormaal ritme typen! Als iedereen die SSH gebruikt dit nou doet hebben we nergens last meer van!

als ik ff een seconde nadenk op de helft van mijn wachtwoord is het direct al veel moeilijker. waarom wordt een wachtwoord btw. per teken doorgestuurd? is dat veiliger dan het hele wachtwoord in 1 packet versturen ofzo?

waarom wordt een wachtwoord btw. per teken doorgestuurd? is dat veiliger dan het hele wachtwoord in 1 packet versturen ofzo?
dan moet een packetsniffer al elk pakketje hebben, en dan nog de decryptie eroverheen terwijl je niet eens weet of die pakketjes samen het wachtwoord vormen of niet etc. etc. Dus het is inderdaad veel moeilijker

Sorry hoor, maar ik zie niet in waarom het veiliger is. Obscurity is no security. En in dit geval lijkt het me dus duidelijk onveiliger.

Helaas -

het wachtwoord wordt teken voor teken in een packet verstuurd omdat SSH niet weet dat je een wachtwoord aan het tikken bent. Je stuurt 'data' naar de server; die wordt versleuteld en direct op de lijn gezet.

Log maar eens in op een server met ssh. Tik maar eens iets, elke letter wordt ge-echoed naar je ssh-client. Dus voor elke letter die je tikt stuur je een pakket naar de server en stuurt de server een pakket terug.

(NB: de server stuurt niet altijd een pakket terug, en soms ook meer, bijvoorbeeld als je op een unix prompt "ls -l<ENTER>" tikt en je krijgt een hele hoop data binnen : multiple packets. Ook kan local echo uitgezet worden, in dat geval krijg je geen response van de server. Tik maar eens (op diezelfde unix prompt) "su<ENTER>" en je krijgt niet meer je tekens teruggeechoed)

Trouwens, dat verhaal van een packetsniffer die moeite zou hebben om elk pakket te vangen is ook onzin. TCP verbindingen (gebruikt door SSH) zijn 'sessies', elk pakket is te identificeren als behorende bij een bepaalde sessie. Dus zodra je 1 pakket van een bepaalde sessie hebt ge-identificeerd, kun je de rest er bij vinden. Er zijn netwerksniffers die op deze manier een hele TCP-stream kunnen tracken en dus de hele communicatie van de client met de server kunnen laten zien.


Tot slot : SSH stuurt het wachtwoord pas weg als de gebruiker op 'ENTER' drukt. Maar je moet 'm wel intikken, en zolang je dat niet op je lokale PC doet, gaat dat dus weer wel per letter over het netwerk.

Dit programmaatje kan misschien je normale typgebruik analyseren enzo, maar je wachtwoord is heel iets anders dan een normaal woord, ik typ mijn wachtwoord bijvoorbeel 2x zo snel. Hierdoor loopt dat programma, dat heeft geleerd aan de hand van mijn normale typgedrag, helemaal achter de feiten aan. En er zijn ook mensen die hun wachtwoord bijna vergeten, en het daardoor heel langzaam tikken. Dus ik ben er niet echt bang van.

Maar MOCHT dit echt problemen gaan opleveren (wat ik niet verwacht) kan je altijd nog een zeer simpel progsel maken dat jouw tekens na een random tijd pas doorstuurt, zodat een eventuele afluisteraar wordt gefooled.

Problem solved!!!! :+
«  1  2  3  4  »

Op dit item kan niet meer gereageerd worden.

Volgende 18:28 "Code Red is creatie van Amerikaanse overheid"
Vorige 16:31 Excite@Home Australië zoekt illegale downloads
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011