Wachtwoorden kraken door ritme toetsaanslagen

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!

Reacties (88)

[Mark_V]

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

[xipetotec]

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

[LinuxMan]

Sommige mensen tikken met 2 vingers 2. Sommige missen een vinger

ze moeten niet voor niks een paar dagen al jouw toetsaanslagen loggen!

[Ortep]

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

[Anoniem: 8176]

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

[Burat]

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

Lezen dus

[demonite]

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.

[RobT]

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.

[iceblink]

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

[humi]

Mjah...als ik het goed begrepen heb leert het programaatje hoe jij tikt. Daar zullen vast wel patronen inzitten. Na verloop van tijd kan hij dan een aantal gokken geven voor je password.
Wat al genoeg helpt is in ieder geval je password door SecureCRT te laten onthouden ...(dit werkt natuurlijk alleen op je eigen PC, maar jah) ..dan vult securecrt je password in, en ze kunnen niks meer met zo'n statistisch progje..
verder werkt securecrt voor SSH sessies ook met een invulboxje..die submit het password volgens mij pas zodra je op ok drukt..

Voor andere SSH clients weet ik het niet

[weird]

Sowieso is het bij het inloggen op een machine met SSH immer zo dat je wachtwoord wordt gecached op de machine vanwaaraf je inlogt. Het SSH protocol neemt jouw gehele wachtwoord en zend dit versleuteld naar de overkant en wordt daar geverifieerd.

Het probleem zit hem er juist in dat je je wachtwoord intikt terwijl je via SSH ingelogd zit op een machine waarvan de netwerkverbinding tussen jou en de server is af te luisteren door derden.

Inloggen kan ook met een RSA of een DSA key, dan hoef je heel je wachtwoord niet in te tikken en kan het dus ook niet gesnift worden. Maar zodra je op je server bent ingelogd (als user) en je wilt iets doen met root-privileges en je tikt 'su' dan moet je een wachtwoord intikken. )IT* is dus te sniffen. Doordat je verbinding al langere tijd in de gaten wordt gehouden kan mbv statistische analyse geschat worden wat je tikt. En zoals altijd met statistiek : hoe meer data, hoe betrouwbaarder je schatting.

Met deze data en een dictionary attack aangepast voor de waarschijnlijke toetsaanslagen kun je dus behoorlijk wat te weten komen ZONDER de public/private keys te kennen.

[markvt]

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

[Burat]

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

[Anoniem: 4106]

Laatst was al ontdenkt dat wachtwoorden van twee tekens lang geen beveiliging bieden

LOL Dat kan iedereen zo kraken

[0rbit]

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

[musiman]

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?

[gumkop]

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).

[Olaf van der Spek]

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.

[Scraper]

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

[deadinspace]

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.

[Jive]

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

[Anoniem: 20535]

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

[Nikel]

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.

[Anoniem: 7477]

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.....

[xipetotec]

Hoeveel tekens heeft ASCII ook al weer?

[Fairy]

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

[RG]

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

[ACM]

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

[Anoniem: 25816]

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.

[Eelke Spaak]

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

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

[LinuxMan]

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)

[Anoniem: 5067]

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.

[Olaf van der Spek]

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.

[HanH]

Is het niet zo dat de meeste mensen hun wachtwoord(en) veel sneller typen (en dus in een ander ritme) dan een willekeurige andere tekst? Ik weet van mezelf dat ik dat wel zo doe. Ik zet bijvoorbeeld bij sommige wachtwoorden mijn handen anders neer, omdat het dan sneller te typen is...(bijvoorbeeld 1tje met veel cijfers/ tekens onder de cijfers erin) Wordt het zo dan niet veel moeilijker, zo niet onmogelijk om iemands wachtwoord af te tappen en aan het ritme te ontcijferen?

[Anoniem: 1788]

Als ik het goed begrepen heb is het juist makkelijker als je wachtwoorden goed en snel kunt typen. De toevallige intervallen zijn dan stukken kleiner.

Het hele verhaal is trouwens wel erg sterk Ik zoek altijd een wachtwoord uit dat erg lang is en dat ik snel kan intypen. Meestal zo'n 15 tot 20 tekens. Na een tijdje oefenen en een goed gekozen wachtwoord, kun je die binnen de seconde intypen.

Het lijkt me een storm in een heel klein glas water. Mijn wachtwoorden mogen ze iig wel monitoren. Ik ga er geen rekening mee houden met typen.

mmm,,.. Ik bedenk me dat ik m'n wachtwoord dus intyp met zo'n 50 ms tussen elk teken. Daarop een analyse houden, betekent dat je onderscheid moet kunnen maken tot op waarschijnlijk de milliseconde.

De pingtijden zijn echter vele milliseconde (meestal zo rond de 100). De onzekerheidsfactor is dus nogal groot.

ze mogen van mij proberen m'n user en root passwords te raden. En dan brute force aanvallen?. /var/log/auth.log zal flink groeien. Kon nog wel eens erg opvallen

[Anoniem: 2391]

Users die denken dat ze veilig zijn, zijn vaak het eerste gehacked

[0siris]

stel dat je passwd "fiets2001!" is (wat op zich al lastig te raden is vanwege combo letters+cijfers+ander karakter)

Dan typ je gewon je passwd als volgt in:
"fie<del><del>iet<del>ts200<del>01!"

Gooi maar weg die 16 kantjes whitepaper...

[mullah]

grappig.. zodra ik een <del> of een <backspace> probeer bij het intiepen van mijn wachtwoord gaat het gerarandeerd fout..

[FreeRider]

Het schijnt zelfs al mogelijk te zijn om alle toetsaanslag af te luisteren via de straling die je PC af geeft. Uit de patronen in de radiostraling valt letterlijk direct af te lezen welke toets er precies wordt ingedrukt.

[Anoniem: 32081]

Klinkt als een broodje aap verhaal. Natuurlijk zal een toestaanslag een vaste serie enen en nullen over de keyboard kabel sturen, maar hoe wil je dit van buiten af syncen? Je hebt immers geen lijntje waarmee je de datastroom kan synchroniseren, en die heeft het keyboard wel.
Bovendien is de straling die de keyboardkabel produceerd wel erg klein (paar volt), dus het magneetveld is superklein. Bovendien zijn de meeste kabels afgeschermd dus weg magneetveld.
Straling van een beeldscherm is wel af te lezen (hoewel het tegenwoordig met beeldschermen die aan de bekende stralingsmormen voldoen weer een stuk moeilijker is) maar dan heb je het wel over straling geproduceerd door een paar kV van de electronenbuis.

[Anoniem: 16213]

`En passworden afluisteren via monitorstraling kan NIET!!

sinds waneer zie je je password terwijl je tiept?
niet dus
je ziet sterren
of niets (bij Linux Getty)

[mullah]

Is ook alweer een oplossing voor gevonden.. je modificeert de output van de videokaart zo dat de output hetzelfde lijkt als de kleur die je nodig hebt, maar binnen een vlak samengesteld wordt door verschillende combinaties van rgb en helderheid, een soort dithering dus.

[HanH]

hoe dichtbij moet je daarvoor zijn?

[humi]

Das is beeldschermstraling, en daar kan je een kopie van je beeldscherm mee maken...kan al minstens een jaar, bereik van 10 meter geloof ik..

[blaatenator]

das gewoon electro magnetische straling, en is niet beperkt tot beeldschermen, alhoewel die tot voor kort wel de meeste straling afgaven. Bij ons hebben we zelfs regels mbt het leggen kabels waarover gevoelige info gaat. Is eigenlijk heel simpel: Niet! Alles waarover een electro magnetisch signaal gaat is af te luisteren. Vandaar dat glasvezel (tot nu toe) als DE oplossing wordt gepromoveerd