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 , , 49 reacties

Franse beveiligingsonderzoekers hebben een methode ontwikkeld waarmee SecurID 800-tokens binnen vijftien minuten zijn te kraken. Ook een aantal andere cryptografische tokens die RSA-sleutels opslaan, zijn kwetsbaar gebleken.

Onder de kwetsbare tokens zijn de RSA SecurID 800-tokens de voornaamste. Ook een aantal andere tokens die gebruikmaken van hetzelfde protocol, is echter kwetsbaar. Daaronder zijn tokens van het Nederlandse bedrijf Gemalto, maar ook de nationale identiteitskaart van Estland.

De apparaten worden gebruikt voor het opslaan van geheime, cryptografische sleutels, die kunnen worden gebruikt om iemands identiteit te verifiëren. In de praktijk kan bijvoorbeeld een extra code worden getoond die wordt gegenereerd op basis van de sleutel en die bij het inloggen op een systeem moet worden ingevuld, naast gebruikersnaam en wachtwoord.

De Franse beveiligingsonderzoekers wisten een kwetsbaarheid in de cryptografische wrapper te misbruiken om de cryptografische sleutel te ontfutselen, blijkt uit hun onderzoeksrapport. Daarbij gebruikten ze een al sinds 1998 bekende methode, die tot nu toe werd beschouwd als in de praktijk niet bruikbaar, omdat het zeer lang kon duren voordat de sleutel werd achterhaald. Door de methode te tweaken wisten ze de tijd die nodig was om de tokens te kraken terug te brengen tot circa 13 minuten.

Vorig jaar wisten hackers in te breken op systemen van RSA, waarbij ze informatie over de werking van sleutelgenerators buitmaakten.

Update, woensdag 11:42: Volgens Marcel Snippe van RSA is de kwetsbaarheid al bekend, en wordt al langer aangeraden om over te stappen op een nieuwe, veiliger versie van de pkcs-standaard. Bovendien is de aanval weinig praktisch, stelt Snippe: zo moet een aanvaller toegang hebben tot iemands SecurID 800-token en de pincode van de gebruiker. In dat geval geeft iemand de aanvaller al volledige toegang, stelt Snippe.

Update, vrijdag 13:11: RSA benadrukt dat de hack het niet mogelijk maakt om op het apparaat opgeslagen sleutels te bemachtigen.

Moderatie-faq Wijzig weergave

Reacties (49)

Voor tokens die alleen gebruikt worden om tijdelijke authenticatie codes te genereren lijkt me dit niet een heel interessant verhaal. Immers: om de key te achterhalen, moet je het token in bezit hebben. Dan kan je hem net zo goed direct gebruiken om in te loggen. Bovendien zijn die tokens doorgaans de 2e factor, dus met alleen dat token ben je er niet. Enige voordeel is dat je iemands token kan stelen, kraken en daarna weer terug in z'n tas doen bijvoorbeeld, waardoor het slachtoffer niet weet dat zijn token gekraakt is. Maar als je daar een kwartier voor nodig hebt, dan is dat al niet heel eenvoudig.

Voor andere tokens wordt het sleutelmateriaal op het token echter ook gebruikt voor encryptie van data op het token, of voor encryptie van data die elders opgeslagen / verzonden wordt. En daar is het natuurlijk wel bijzonder interessant om het sleutelmateriaal te kunnen opvissen, aangezien je je dan direct toegang kan verschaffen tot versleutelde data op het token, versleutelde data die je op een laptop hebt aangetroffen of versleutelde data die je op een netwerk hebt onderschept.
Daarbij maakt het ook minder uit als de diefstal van het token wordt ontdekt, immers, je hebt de data en de sleutel tot die data al en daar kan niemand meer iets aan doen. Authenticatietokens kan je simpelweg blokkeren als misbruik wordt vermoedt.

[Reactie gewijzigd door Orion84 op 26 juni 2012 12:40]

En wat gebruiken de onderzoekers om die tokens te kraken? Een stevige consumentenpc of de supercomputer van een universiteit?
Als je het onderzoek leest misbruiken ze de wrapper om de key gewoon te tonen :
In a PKCS#11-based API, applications initiate a session with the cryptographic token, by
supplying a PIN. Once a session is initiated, the application may access the objects stored on the token, such as keys and certi cates.
Kortom er komt geen super zware machine aan te pas, maar alleen een ROM lezer en de exploit itself.
En wat gebruiken de onderzoekers om die tokens te kraken? Een stevige consumentenpc of de supercomputer van een universiteit?
En dat maakt uit, omdat...?

Tegenwoordig kan veel computercapaciteit gehuurd worden via 'the cloud'. Georganiseerde misdaad die gebruik maakt van deze zwakte is ook niet te beroerd om gebruik te maken van identiteitsdiefstal om de betreffende capaciteit te huren.

[edit]
Heb het artikel kort doorgenomen. Er wordt tot zover ik lees niet ingegaan op de gebruikte computercapaciteit, maar de hoeveelheid berichten die nodig zijn voor de aanval ('We have demonstrated a modi ed version of the Bleichenbacher RSA PKCS#1 v1.5 attack that allows the `million message attack' to be carried out in a few tens of thousands of messages in many cases.') suggereert dat relatief weinig capaciteit nodig is in het hedendaagse computerlandschap.

[Reactie gewijzigd door The Zep Man op 26 juni 2012 12:01]

Vrijwel al het rekenwerk wordt door de hardware key zelf gedaan. Je kan de aanval dus in principe met je smartphone uitvoeren. Uit het rapport:
in practice Bleichenbacher's attack requires only about 215 000 oracle calls on average against a 1024 bit modulus when the ciphertext under attack is known to be a valid PKCS#1 v1.5 block. This is however not efficient enough to be practical on low power devices such as smartcards which perform RSA operations rather slowly. We give a modi ed algorithm which results in an attack which is 4 times faster on average than the original, with a median attack time over 10 times faster.
De smartcard/hardware key is dus de beperkende factor in het aantal keys die je per seconde kan testen.
Je moet dus als hacker wel de token in handen hebben. Dat maakt het praktische nut ervan wat lastiger.

[Reactie gewijzigd door Dreamvoid op 26 juni 2012 11:43]

Als je weet hoeveel tokens er jaarlijks gestolen/verloren worden in combinatie met laptops, tablets of andere zaken die de eigenaar van het token "identificeren", dan is er een gerede kans aanwezig dat token X voldoende toegang geeft tot data die eigenlijk niet openbaar had moeten zijn.

Sterker nog, toegang tot Personeelshandboek.pdf door middel van een gestolen/verloren token is al onrechtmatig verkregen toegang, laat staan documenten die extra/gevoeliger informatie hebben.
Wat is dan precies nog het belang van het kraken? Als ik het token heb, dan kan ik dat toch gewoon gebruiken?

Hoogstens zou je een token kunnen "lenen", het kraken en dan weer terugleggen, zodat de rechtmatige eigenaar zijn account niet zal laten blokkeren. Maar de scenario's waarin een hacker deze mogelijkheid heeft, zijn gering.
Een token geeft z'n gegevens over het algemeen pas vrij na het intikken van een wachtwoord, combinatie van "what you have and what you know" dus, net als je pinpas.
RSAid pasje heeft elke 90 Seconden een nieuw numerieke sleutel. Als je de gebruikersnaam + Token Serienummer hebt kan je het wachtwoord kraken anders wordt het nog lastig lijkt mij.

Dit houd tevens ook in dat de banken die nu zo'n Token gebruiken (Rabobank, ABN enz) ook weer opzoek zullen moeten gaan in de nabije toekomst naar een nieuwe beveiligingen methode.

De tokens die ING uitgeeft vroeger de Postbank vind ik ook niet veilig.
De tokens die ING uitgeeft vroeger de Postbank vind ik ook niet veilig.
Dat zijn one-time pads. Veiliger kan niet:
In cryptography, the one-time pad (OTP) is a type of encryption which has been proven to be impossible to crack if used correctly.
.
Het via SMS versturen van de TAN is dan wel weer dubieus uit security oogpunt, maar in ieder geval via een 2e kanaal.
De zwakte zit daar inderdaad meer in de gebruiker die
- in goedgelovigheid alle TAN-codes van zijn lijst afgeeft aan criminelen die daar hun slag mee slaan
- zijn TAN-code-lijst onzorgvuldig bewaard, dus open en bloot rond laat slingeren, kwijt/zoek raakt of zelfs verliest.

- hetzelfde apparaat gebruikt om de TAN-sms te ontvangen en te bankieren al heb je dan nog de pincodes van het apparaat en de app of op de webpagina een username en password. Het kunnen versturen van beide via sms is wel de grootste flater die ING heeft geslagen.
offtopic:
Sinds Postbank met NMB en NN tot ING geworden is, is er veel verslechterd.
Ik wijt dat een het elitaire karakter van de NMB destijds en de woekerpolis/provisie-maximalisatie-cultuur bij NN. ING bevat immers het 'DNA' van alle drie de vorige organisaties, al zie ik van de Rijkspostspaarbank/Postbank-cultuur weinig meer terug en heeft volgens mij de NN-cultuur de overhand.

[Reactie gewijzigd door BeosBeing op 27 juni 2012 09:09]

Dat lijkt me wel degelijk uit te maken. Niet alleen beantwoord het de vraag hoeveel cloud resources je eventueel nodig zou hebben maar maakt het ook duidelijk of je zoiets in het geheim kan doen. De halve Amazon cloud afhuren om een stapel tokens te kraken gaat niet ongemerkt.
Dat lijkt me wel degelijk uit te maken. Niet alleen beantwoord het de vraag hoeveel cloud resources je eventueel nodig zou hebben maar maakt het ook duidelijk of je zoiets in het geheim kan doen. De halve Amazon cloud afhuren om een stapel tokens te kraken gaat niet ongemerkt.
Niet ongemerkt, maar wel pas achteraf. En via identiteitsdiefstal kan de dader ermee wegkomen.

Met dit soort zaken is het niet zozeer de vraag 'of', maar 'wanneer'. Kijk naar MD5 hashes die tot voor kort nog gebruikt werden in certificaten, terwijl al jarenlang bekend is dat deze onveilig zijn en niet meer gebruikt zouden moeten worden in dit soort situaties. Hetzelfde gaat op voor deze aanval.
of je gebruikt als hacker een botnet dat je tot je beschikking hebt. Het lijkt mij erg onwaarschijnlijk dat ze daar een legale cloud voor afhuren.
Ach uurtje Amazon Cloud of Microsoft Azure onder valse naam enz kan prima toch ^_^
Idd, maar buiten dat het dan zeker niet onopgemerkt zal blijven ga je op een gegeven moment ook het punt voorbij of het voor de crimineel rendabel is. Want als er idd een heel serverpark nodig is om zo snel te kunnen kraken dan zal het zeer wss wel een heel erg elite misdaad worden. Er zullen er weinig rondlopen die eerst tonnen tot miljoenen investeren voor hun criminele business, zeker niet als het op zo'n grote schaal moet dat je simpelweg niet kan verstoppen.
En het alternatief, in plaats van tonnen te investeren duizenden kwartieren wachten is natuurlijk geen optie. Duizend kwartier is immers al bijna anderhalve week.

Ik ben het helemaal met Zap de Man eens. Hoewel het uit tweakers-perspectief leuk is om te weten wat deze onderzoekers gebruikt hebben, maakt het voor de kwetsbaarheid van de beveiliging erg weinig uit of iets met één computer in één seconde of met duizend computers in duizend dagen is te kraken. Pas als het miljoenen computers in tientallen jaren is wordt het echt relevant.

[Reactie gewijzigd door 84hannes op 26 juni 2012 12:41]

ach een beetje crimineel heeft een botnet tot zijn beschikking, lekker anoniem, en veel bandbreedte.
Idd, maar buiten dat het dan zeker niet onopgemerkt zal blijven ga je op een gegeven moment ook het punt voorbij of het voor de crimineel rendabel is.
Klopt, maar het hangt er ook vanaf wiens account je wilt hacken. Dat van een willekeurige chnese e-bay -verkoper of van iemand die miljarden bezit en verhandeld zoals Steve Jobs, Bill Gates e.d..
WPA kan ook al binnen 15 minuuten gekraakt worden
Degene die dat deed gebruikte amazone's cloud computers (tesla gpgpu's).
Het koste hem bijna niks.

bron:
nieuws: Hacker ontwikkelt snelle brute force-aanval op wpa-psk

edit.
kleine aanpassingen

[Reactie gewijzigd door DCG909 op 26 juni 2012 11:41]

Dat zegt helemaal niks. Dat hangt volledig van de complexiteit van je wachtwoord af. Hoe ingewikelder hoe langer het duurt voordat juist dat wachtwoord voorbijkomt in de enorme lijst van pogingen. Brute-force is niks anders dan berekenend gokken.
Inderdaad, bij Amazon kun je wel even wat performance halen voor korte tijd.
denk dat een beetje hack group wel een klein bot netwerkje heeft waarmee je wel een aardig eind komt richting de kracht van die supercomputer.
Op zich wel slecht dat er methode, die al sinds 1998 bekend is nooit gefixed is, ook al dachten ze dat deze nooit gebruikt kon worden
Goede vraag inderdaad. Lijkt mij nogal een verschil.
Desalniettemin is dit wel de zoveelste 'beveiligings' methode die gekraakt is. Natuurlijk kan gesteld worden 'alles valt te kraken', en dat is in principe ook zo, maar dat een token die gebruikt wordt in verband met nationale identiteit gekraakt kan worden binnen 15 minuten met een methode die kennelijk al 14 jaar oud is, vind ik wel triest.
Een kwartiertje rekentijd zoals iedereen die kan huren bij Amazon waarschijnlijk.
En wat gebruiken de onderzoekers om die tokens te kraken? Een stevige consumentenpc of de supercomputer van een universiteit?
Dat lijkt me goeddeels irrelevant, als er genoeg geld te halen valt, zijn criminelen bereid te investeren in rekenkracht om te kraken...
Dat is idd een goede vraag.
Maar wat betekend dit in de praktijk :?

Ik heb zo'n SecurID om remote in te kunnen loggen op de servers van mijn werkgever. Kan een aanvaller met deze techniek nu inloggen? Ik ga er vanuit dat mijn gebruikersnaam en wachtwoord nog steeds benodigd zijn.

Tevens wijzigt die code op dat SecurID om de zoveel tijd(30 seconden of zo?). Heeft dat nog invloed?

Kortom: wat voor problemen hebben de geen die SecurID gebruiken nu echt?
Je gebruikersnaam is vrij eenvoudig te raden. Je wachtwoord wordt al wat lastiger, zeker als je sterke wachtwoorden gebruikt. Vervolgens heeft je SecurID token een uniek serienummer en moet men weten dat jij dat nummer hebt. Wordt al erg lastig. Ik weet 'van vroegah' dat mijn SecurID token van toen ook nog een pincode had die je voor de daadwerkelijke code moest invullen. De combinatie van alles maakt het alsnog heel erg lastig, maar feit blijft dat je als organisatie niet wil dat de methode ontrafelt is waarmee je codes gegenereerd worden.

De buitenste muren van het kasteel beginnen af te brokkelen, maar de binnenplaats is nog wel veilig, zeg maar.
Wat jij zegt inderdaad.. Volgens mij is het ook nog steeds moeilijk.

Ik heb zelf een Vasco token en dat token is gekoppeld aan mijn account en heeft ook nog eens een pincode beveiliging voordat je de challenge key op kan geven. Voordat ik de challenge code krijg moet ik me overigens eerst aanmelden met mijn gebruikersnaam en wachtwoord, maar dat lijkt me logisch.
Voordat ik de challenge code krijg moet ik me overigens eerst aanmelden met mijn gebruikersnaam en wachtwoord, maar dat lijkt me logisch.
. De RSA secur-id tokens doen dit door in het paswoord veld je paswoord in te laten typen EN de response op het secur-id token. De login is dus een combinatie van wat je weet en wat je hebt in 1 keer ipv. logon en dan pas challenge response.
Zoals hierboven gezegd hebben ze niet de code die op de 30 sec(bij mij is het 15 sec) wisselt gekraakt, maar de generator ervan. Dus men kan nu zelf die codes genereren.

En ja, je gebruikersnaam en wachtwoord zijn nog steeds nodig. Ik moet zelfs nog met een pin op mijn token inloggen. Maar er is wel weer een security laag weg.
In jouw geval dus twee... want je token werkt niet of beter gezegd is niet meer veilig, dus is ook de pin daarvan overbodig geworden, want dat is puur van die token en heeft verder niets van doen met de authenticatie voor de systemen Je bent dus in principe weer terug bij het oude... gebruikersnaam en wachtwoord.
Is natuurlijk wel mooi dat ze er zo snel geraken. Maar je bent er op dit moment nog niets mee.

Een SecureID maakt elke 20 seconden een nieuwe ID aan, en deze moeten in sync zijn met de server. Ook hebben de meeste een dubbele authenticatie. Eerst een PIN code die vast staat, en dan pas de RSA key. Bijgevolg moet je nog aan social engineering gaan doen om beide vast te hebben.

Tot op heden is dit nog steeds de veiligste manier om je netwerk te beschermen ( in samenwerking met een SSL VPN Appliance die enkel de resources die je nodig hebt doorgeeft. )
Klopt, een eigen username+pin code (+8 tekens)+RSA key. Vervolgens dien je je eigen pincode ook nog eens in de aantal maanden te wijzigen (verplicht). Oftewel een vrij sterke beveiliging.
voor mijn ProRail login heb ik 1 login voor het netwerk: username + 5 tekens + RSA
en daarna nog voor de applicaties een: domein/username en wachtwoord.

zelfs als je de RSA hebt kan je er nog weinig mee...

[Reactie gewijzigd door ArcticWolf op 26 juni 2012 12:36]

Mijn token is 15 seconden geldig en dan wisselt hij, dus dan is er nog niet een heel groot probleem nu.
Je token geeft elke 15 seconden een nieuwe key, maar je key is langer "geldig" dan die 15 seconden; het getal dat het token geeft is op basis van de huidige datum/tijd, en omdat klokken wel eens afwijken (klok in de token en klok van de verificatieserver) is er een grotere foutmarge. Schrijf maar eens zo'n getal op, wacht een paar minuten en gebruik het "oude" getal om in te loggen, je zult zien dat dat gewoon werkt.
Als een goede token niet goed qua tijd is gesynchroniseerd, zal deze al snel niet meer werken. De vosco token codes waar ik mee werk zijn al na een paar seconden niet meer geldig.
Je bedoelt waarschijnlijk Vasco ;)
Nee na een halve minuut ofzo komt het systeem met de melding dat ik een vorige key heb ingevoerd en wil een nieuwe key. Als ik langer wacht krijg ik gewoon een foutmelding. Maar als de keygenerator gekraakt is, is dit wel kwalijk ja.
Als ik het goed begrijp hebben ze de sleutel waarmee die tokens worden gegenereerd weten te achterhalen. Dan kun je dus een generator bouwen die exact dezelfde tokens als jou SecureID genereerd.
Of te wel, het nut van je secureID is tot 0 gegenereerd. Je username en password zijn dan nog alleen je enige vorm van beveiliging.
ik gebruik een secureID token in combinatie met een eigen code die ik erbij moet plaatsen.
in dit geval zouden ze dat ook moeten weten om hun eigen code generator te kunnen gebruik. het wordt op deze manier wel makkelijker voor hun om dit te brute forcen.
Mijn token is 15 seconden geldig en dan wisselt hij, dus dan is er nog niet een heel groot probleem nu.
Aannemende dat die keys daadwerkelijk maar 15 seconden geldig zijn(which i doubt, meeste mensen doen er langer dan 15 secs over om een nummer van 6 karakters te lezen en over te tikken, zie ook de tijd bij internetbankieren of je blizzard authenticator) de rekenkracht rechtevenredig stijgt met het aantal transistors, heb je dat over pakweg 5,68 jaar wel...why wait?
Goh, en je denkt niet van, 'laat die hackers nou eens een methode gevonden hebben om de volgende code te voorspellen'.
Een RSA SD800 token bestaat uit 2 delen. nl. het SecurID deel en de smartcard deel welke ook via USB aanwezig is. In dit rapport hebben ze het over het smartcard gedeelte (wat bijna niemand gebruikt) en dus niet over over de one time tokens (OTP).
Wat dat betreft wordt in je via dit artikel weer helemaal op het verkeerde been gezet en is er eigenlijk niets aan de hand.
Gemalto een nederlands bedrijf noemen is hetzelfde als U2 een nederlandse band noemen :)

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