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. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 78, views: 24.555 •

Meer dan de helft van 43 onderzochte Nederlandse bankensites is kwetsbaar voor de zogenoemde Beast-aanval, waarmee tls 1.0-verbindingen kunnen worden gekraakt. Onder meer de sites van ING, Rabobank en ABN Amro zijn kwetsbaar.

https sslDe 17-jarige beveiligingsonderzoeker Daniël Heesen, die eerder beveiligingsproblemen bij webwinkels aan het licht bracht, nam 43 bankensites onder de loep, onder meer om te kijken of deze kwetsbaar waren voor de Beast-aanval.

Bij ruim de helft, 22 sites, blijkt dat het geval te zijn. Daaronder zijn grote banken als ING, Rabobank en ABN Amro, vertelt hij tegen Tweakers.net. "Internetbankieren blijkt toch minder veilig dan iedereen altijd dacht", zegt hij.

Het beveiligingsprobleem is al enkele jaren bekend, maar pas afgelopen september kwam er een exploit uit. Met de deels in javascript geschreven Beast-aanval kunnen tls 1.0-verbindingen worden gekraakt, waardoor ssl-cookies kunnen worden gestolen. Heesen heeft de kwetsbaarheden in de praktijk niet getest.

Om de methode te kunnen toepassen is het wel noodzakelijk dat een aanvaller een man in the middle-positie heeft en dus netwerkverkeer kan onderscheppen, of dat er op een andere manier javascript kan worden geïnjecteerd. Ook moet het netwerkverkeer kunnen worden afgeluisterd. De meningen over de toepasbaarheid van de aanvalsmethode verschillen: volgens sommige experts is deze onpraktisch. Het is volgens de onderzoekers die Beast ontwikkelden echter wel de eerste bekende aanval waarbij https-verkeer daadwerkelijk wordt ontsleuteld.

Het probleem wordt veroorzaakt doordat in tls 1.0 voor het versleutelen van plaintext-blocks de data van een voorgaand blok wordt gebruikt. Dat proces kan worden gemanipuleerd. Veel banken ondersteunen alleen nog maar tls 1.0. Het probleem is dat veel serverside-software tls 1.1 en 1.2 nog niet ondersteunt en hetzelfde geldt voor browsers: Chrome heeft nog geen ondersteuning voor de nieuwere tls-verbindingen en in Firefox is tls 1.0 standaard ondersteund.

Heesen zocht contact met alle banken, maar slechts één bank nam de moeite om tegenover hem inhoudelijk te reageren. Die bank, Freo, is niet kwetsbaar voor de Beast-aanval. Andere banken gaven enkel aan de melding te hebben ontvangen of reageerden geen behoefte te hebben aan ondersteuning.

Woordvoerder Daan Heijbroek van ING reageert: "Wij nemen veiligheid zeer serieus en bevestigen de bevindingen van Heesen." Heijbroek zegt dat de bank zal onderzoeken welke maatregelen het kan nemen. Hij tekent echter wel aan: "Het is natuurlijk een beperkt onderzoek, omdat slechts enkele componenten van de beveiliging worden behandeld." De Rabobank zei eerder met een reactie te zullen komen, maar slaagde daar niet in. De Nederlandse Vereniging van Banken zegt het 'goed' te vinden dat er onderzoek wordt gedaan, maar denkt niet dat de beveiliging van internetbankierders in de praktijk in gevaar is.

Heesen ontdekte ook andere beveiligingsproblemen. Dertien banken hadden andere problemen met hun ssl-certificaat, zoals zwakke versleuteling. Ook vond hij kwetsbaarheden die een man in the middle of denial of service mogelijk maken en constateerde hij op plekken ondersteuning van zwakke versleuteling. Bij drie banken kon hij cross site scripting uitvoeren, wat een potentieel beveiligingsprobleem is.

Kwaadwillenden kunnen dan bijvoorbeeld eigen javascriptcode injecteren om cookies te stelen, hoewel een slachtoffer er dan wel toe moet worden verleid om op een link te klikken. Bovendien betroffen de aangetroffen kwetsbaarheden enkel het niet-beveiligde deel van de websites, waardoor de impact beperkt is. Onder andere Finbox, dat het digitale equivalent van de acceptgiro moet worden, was kwetsbaar voor xss. Cross site scripting kan worden gebruikt voor de Beast-aanval, maar in dit geval was dat niet mogelijk.

Reacties (78)

Reactiefilter:-178077+161+214+30
En opnieuw nieuws over exploits...ze worden steeds handiger met omwegen vinden :)
En wat een nieuws:
Om de methode te kunnen toepassen is het wel noodzakelijk dat een aanvaller een man in the middle-positie heeft en dus netwerkverkeer kan onderscheppen
Tja weet je dan is alles onveilig als het netwerkverkeer kan worden onderschept.
De theorie van cryptografie gaat uit van Alice, Bob en eavesdropper (afluisteraar) Eve. Goede cryptografie methoden zijn veilig, onafhankelijk van de acties van Eve. Een one-time-pad bijvoorbeeld is bewijsbaar veilig tegen elke mogelijke aanval van Eve. Dat is dus perfect.

Een iets minder goed (maar praktischer) algoritme kan data niet oneindig lang beschermen, maar bijvoorbeeld tegen 1 miljard CPU-jaren aan decryptie. Dat is genoeg voor thuisbankieren; het maakt onderschepping economisch zinloos.

In dit geval is het nieuws, omdat de beveiliging gekraakt kan worden tegen prijzen die veel lager zijn dan de gemiddelde banksaldi.
XSS exploits zijn misschien nog wel interessanter dan de man-in-the-middle methode... Ben benieuwd in hoeverre dit in de praktijk ook haalbaar (lees praktisch is).

Uiteraard is het goed dat deze student de grote banken op beveiligingen checkt, maar of dit nou in een keer heel storm gaat lopen door de exploits is dus nog maar de vraag :)
A man-in-the-middle attack can succeed only when the attacker can impersonate each endpoint to the satisfaction of the other—it is an attack on (or lack of) mutual authentication. Most cryptographic protocols include some form of endpoint authentication specifically to prevent MITM attacks. For example, SSL can authenticate one or both parties using a mutually trusted certification authority.

[Reactie gewijzigd door BtM909 op 14 maart 2012 12:25]

Als je kwaad wil is het volgens mij makkelijker dan je denkt om een man-in-the-middle positie te bereiken. Ik zal niet over open WiFi-hotspots danwel open thuisnetwerken beginnen want je hebt sowieso een bord voor je kop als je over een dergelijk netwerk bankzaken gaat regelen.

Erger zijn bijvoorbeeld de SpeedTouch modem's die in "iedere" Nederlandse straat wel in minimaal een of twee huishoudens te vinden zijn. Er zijn voldoende sites die aan de hand van het SSID de netwerksleutel (instant) kunnen achterhalen, die in 99% van de gevallen niet anders zal zijn dan de factory-default. Op die manier positioneer je jezelf eenvoudig als man-in-the-middle en kan je al het verkeer over jouw laptop (of zelfs een andere proxy) laten lopen.

Het vervolgens kapen van een sessie-cookie via een beast aanval lijkt dan kinderspel.

Kortom, het is misschien nog niet gebeurd danwel niet bekend, maar in theorie is het echt té makkelijk om binnen korte tijd veel schade toe te brengen. Teleurstellend dat de banken zo schaars of nonchalant reageren.
Ehm, toegang tot een router lijkt me niet genoeg om "eenvoudig" een man in the middle attack uit te voeren op een TLS verbinding. Kun je uitleggen hoe je dat wilt doen?

Wikipedia zegt het volgende:
A man-in-the-middle attack can succeed only when the attacker can impersonate each endpoint to the satisfaction of the other—it is an attack on (or lack of) mutual authentication. Most cryptographic protocols include some form of endpoint authentication specifically to prevent MITM attacks. For example, SSL can authenticate one or both parties using a mutually trusted certification authority.

[Reactie gewijzigd door (id)init op 14 maart 2012 14:04]

Méér dan genoeg, je maakt verbinding met het netwerk, broadcast een ARP-spoof en je kunt direct met een MITM-attack al het verkeer afluisteren danwel manipuleren.

http://openmaniak.com/ettercap_arp.php
Ehm, met een TLS verbinding gaat je dat zo echt niet lukken.

TLS is er juist voor om informatie over onbetrouwbare verbindingen te beveiligen en staat los van de beveiliging van de eventuele router. Alle informatie die over de TLS verbinding gaat is versleuteld met bijv het AES algoritme, het is onmogelijk om de onversleutelde informatie te achterhalen of te manipuleren.
het is onmogelijk om de onversleutelde informatie te achterhalen of te manipuleren.
Kleine correctie: Praktisch onhaalbaar binnen fatsoenlijke/bruikbare tijd.
Dit artikel laat nu net zien dat het dus wél kan. Je hebt gelijk - en dat stelt het artikel ook - dat het behoorlijk lastig is, maar als je eenmaail toegang hebt tot de wifi is het dus mogelijk de header met decryptie key te ontsleutelen.

En dan heb je dus toegang tot de TLS verbinding zelf.
desalniettemin zal de gebruiker een waarschuwing van z'n browser krijgen dat het certificaat waarmee de 'server' (man in the middle) zich authenticeert niet authentiek is, of niet past bij het 'rabobank.nl' domein. Dit is ook wat het Wikipedia artikel bedoelt: een man in the middle zal *ook* de authenticatie van de betrokken partijen moeten faken. In de web wereld dus de browser.
SSL is toch veiliger, waarom word dat niet gebruikt?
SSL is oud, TLS is nieuwer, alleen wordt er vaak over SSL gesproken, maar bedoelt met TLS
SSL is toch veiliger, waarom word dat niet gebruikt?
Maar ook hier waar er zeker over TLS wordt gesproken gaat het erom dat TLS1.0 kwetsbaar is. TLS1.1 en TLS 1.2 niet meer. Maar dan moet je die features wel hebben in je server en browser. Of op zijn minst de probleem ontwijkende configuratie/installatie hanteren. Dan kan je het nog even uitzingen.

[Reactie gewijzigd door VisionMaster op 14 maart 2012 13:00]

Kosten baten verhaal.
Zolang de exploit niet op grote schaal word toegepast doen ze er niks aan.
Als de economische schade voor de bank niet boven de investeringskosten van een nieuw systeem uitkomt vinden ze het wel best.
Of het moet al via dit soort berichten gaan zodat ze door de negatieve berichtgeving alsnog economische schade lijden door klanten die weggaan.
Het beveiligingsprobleem is al enkele jaren bekend
Dit geeft al aan hoezeer de banken met veiligheid omspringen. Zelfs nu er een exploit is (een bekende, wie zegt dat er niks anders eerder was) word er blijkbaar nog niks aan gedaan.

[Reactie gewijzigd door arbraxas op 14 maart 2012 12:29]

[quote]Dit geeft al aan hoezeer de banken met veiligheid omspringen. Zelfs nu er een exploit is (een bekende, wie zegt dat er niks anders eerder was) word er blijkbaar nog niks aan gedaan.[/quote[

Banken redeneren niet vanuit de techniek, maar vanuit een financieel oogpunt. Zolang de kosten voor een oplossing hoger zijn, dan de kosten die voortvloeien uit het probleem, zal een bank geen actie ondernemen.
idd want ik las hier dacht ik deze week nog een artikel over man in the middle via openbare wifi toegangspunten.

Genoeg mensen die steeds meer via wifi werken en dus ook misschien betalingen doen en zie daar je man in the middle is er al in de praktijk
Mensen die een onbeveiligde draadloze router gebruiken - en dat zijn er nog steeds nogal wat - zijn dus kwetsbaar. Lijkt me niet zo ongevaarlijk als de banken doen uitschijnen.
er zijn ook veel thompson netwerken waar je zonder veel moeite op kunt komen
Ik meen gehoord te hebben dat dat komt doordat de Thompson routers voorzien zijn van een password hash die uit de SSID van de Thompson gehaald kan worden. Er werd mij ook toentertijd aangeraden een andere pass in te stellen.

Op welke manier is mij ook niet geheel duidelijk maar het schijnt (of scheen toen) mogelijk te zijn (geweest). Geen idee of dat nog steeds zo is en of hoe het gedaan werd.
De Thompson routers in kwestie waren (op zich een goed idee) standaard voorzien van wpa encriptie, met een per router unieke ssid en password.
Het probleem was dat van de ssid zonder al te veel moeite het password uitgerekend kan worden, doordat het genereren van beide nogal simpel in elkaar zit.
SpeedTouch idem.
Waarom is het een probleem van de banken als er mensen zijn die een onbeveiligde draadloze router gebruiken? Die router is toch de verantwoordelijkheid van de consument?
Wel grappig om te zien dat nieuwsberichten je vaak op het verkeerde been zetten en of paniek veroorzaken. Voor ons als techneuten is dit interessante informatie, maar voor de consument / huist-tuin-keuken gebruiker is dit best wel paniek zaaien :D

Er staat immers dat het vrij lastig is uit te voeren en de afhankelijkheden niet zomaar voor het oprapen liggen. De vraag is of de consument hier direct hinder van kan hebben of zich zorgen moet maken.

Zo ook met het RDP verhaal, al mijn collega's hebben het er over en zijn met contacten aan het bellen om bij voorkeur nog binnen nu en een uur dit geïnstalleerd te hebben. Super goed, maar als je goed leest, zijn er nog geen hacks beschikbaar.

[Reactie gewijzigd door Workaholic op 14 maart 2012 12:30]

Ook grappig: deze keer is Internet Explorer de betere & veiligere browser die wel TLS 1.2 ondersteunt, en niet Firefox of Chrome.
De internetbankier sites zijn dan misschien niet helemaal veilig en kunnen door kwaadwillenden "bekeken" worden. Maar ze kunnen toch geen overdrachten maken zonder verificatie van de eigenaar? Bij ING ontvang ik eerst een SMS voordat ik een overschrijving kan maken. Mochten ze dan het nummer waarnaar geSMS´t wordt aan willen passen, krijg ik eerst een brief thuis, waarna ik als nog in eigen persoon moet verschijnen bij een ING bank. Ik zie dit als een redelijk waterdicht model, of zijn hier juist wegen omheen?
En als dat gebeurt zo'n opdracht die je zelf niet gedaan hebt hoef je dus alleen je wachtwoord te veranderen en de hackers kunnen weer opnieuw beginnen.
In de sms van de ING wordt niet vermeld naar welke rekening het bedrag wordt overgemaakt, enkel om hoeveel geld het gaat.
Een hacker zou op het moment dat jij geld wilt overboeken dit kunnen sturen naar een andere rekening, indien het bedrag niet wordt aangepast hoef jij hier niets van te merken.
En in alle eerlijkheid moet ik toegeven dat ik bijna nooit de moeite neem het bedrag te controleren, laat staan het rekeningnummer mochten ze dat in de toekomst gaan toevoegen...

[Reactie gewijzigd door Stevie-P op 14 maart 2012 12:45]

Onzin:
Totaalbedrag overboekingen E 380,79. Hoogste overschrijving E 380,79 naar rekening *302 Volgnummer 347; TAN-code 345890
Zeker geen onzin, zo zien mijn TAN smsjes eruit:
Let op: geef nooit uw TAN-code af! Aantal opdrachten: 1.
Totaalbedrag overboekingen E**,**.. Volgnummer ***; TAN-code ******
Nergens een rekeningnummer te vinden. Hoe kan het dat jouw sms een andere inhoud heeft? Mijn laatste is van 12-03, is het sindsdien aangepast?

Reactie van ING zelf:
Bij zeer hoge bedragen kan een afwijkende layout (hoogste overschrijving en bijbehorend rekeningnummer voorkomen). Bij bedragen boven de 1.000 euro wordt bovendien om een tweede TAN-code gevraagd. Het sms-bericht zoals u dat beschrijft voldoet aan de inhoud zoals wij die versturen.
De hoogste overschrijving waar ik nog een sms van heb liggen, was voor 200 euro. Hier werd geen rekeningnummer bij vermeld.

[Reactie gewijzigd door Stevie-P op 14 maart 2012 16:29]

Postbank vs ING?
[qoute] De hoogste overschrijving waar ik nog een sms van heb liggen, was voor 200 euro. Hier werd geen rekeningnummer bij vermeld. [/qoute]

Dat kan kloppen, althans in de tijd dat ik tellen en rekenen heb geleerd (al heel wat jaren terug) was ¤ 200,= nog 1/5e van ¤ 1000,=
en je haalt zelf uit een reactie van de ING aan:

[qoute} Bij zeer hoge bedragen kan een afwijkende layout (hoogste overschrijving en bijbehorend rekeningnummer voorkomen). [/qoute]

Aangezien ze bij ¤ 1000,= een extra tan vragen zal "zeer hoge bedragen" wel rond de ¤500,= en ¤750,= liggen.
Het wordt pas echt eng als het verkeer niet alleen bekeken kan worden, maar ook aangepast kan worden. Wie zegt dan dat wat jij op het scherm ziet bij het invullen van je SMS-code ook daadwerkelijk is wat de bank straks binnen gaat krijgen als opdracht? Bij de rabobank moet je voor bedragen boven de 500 euro nog een extra controlegetal invullen op je randomreader, en boven de paar duizend euro een van de rekeningnummers, maar tot 500 euro hebben hackers dan gewoon vrij spel als jij een klein bedrag overmaakt.
Er zijn wegen omheen: de provider van het telefoonnummer kan het telefoonnummer op een andere simkaart zetten. Natuurlijk gaat dat niet ook niet zomaar, tenzij je daar werkt of toegang hebt tot de systemen daar...
Bij verschillende phishing sites en virussen voor ABN, Rabobank, ING e.d. wordt er vaak de methode gebruikt dat hij bijna op het einde van je bankzaken (als je de batch eruitgooit zeg maar), de phisher even een betaling extra erin gooit of een popup genereert met een verborgen "post" van hun betaling. Let je even niet op en ga je vervolgens verder naar het intikken van de SMS of challenge/response code, en is het kwaad geschied.

Nu weet ik dat bij de SMS van ING en bij de E-Dentifier van ABN AMRO (als je deze niet aan de computer hebt gekoppeld) geen bedrag meegeven in de SMS/challenge code, dus het gaat best makkelijk.
Hier is het nóg gevaarlijker. Ik heb het in het voorbeeld even over ABN AMRO.
  • Jij hebt een enkele betalingsopdracht gedaan, en geeft aan dat je de opdrachten wilt verzenden.
  • De MITM schiet buiten jouw browser om een extra betalingsopdracht in.
  • In het overzicht van de betalingen die je gaat verzenden zie je enkel de betalingen die je zelf hebt ingeschoten, want de MITM kan de HTML aanpassen zodat zijn eigen betaling er niet in voorkomt.
  • De betaling wordt gewoon gedaan.
  • De MITM kan zelfs tot je uitlogt er voor zorgen dat zijn extra betaling onzichtbaar blijft.
  • Met een beetje pech valt je dit of niet op, of pas heel veel later. Zie dan nog maar eens te bewijzen dat je dat zelf niet was.
Oh, en tijdens dit alles staat vrolijk het groene slotje in de adresbalk, dus je waant je wel veilig.
ik vraag me af of het in theorie mogelijk is om met behulp van hacken echt bij het geld te komen. of zijn deze site gewoon ondanks de kleine lekken toch onmogelijk volledig te kraken?

Daarnaast heb je bij transacties nog altijd een verificatie code nodig.

[Reactie gewijzigd door sygys op 14 maart 2012 12:34]

Met een man in the middle aanval kun je al het netwerk verkeer monitoren en veranderen. Een https verbinding zou dat moeten voorkomen maar de beast-aanval kan die beveiliging omzeilen zegt dit artikel.
Je zou dus bank verkeer kunnen onderscheppen en op het moment dat iemand een overboeking doet een andere rekening kunnen gebruiken. Het slachtoffer zal dan de benodigde security codes geven.

[Reactie gewijzigd door henk-jan op 14 maart 2012 13:08]

Om die man-in-the-middle situatie te vermijden zouden ze zich misschien eens bezig moeten gaan bezig houden met DNSSEC. Een methode om DNS records te controleren op authenticiteit.
Niet helemaal: heel het certificatensysteem komt ook meer en meer onder vuur te liggen. Dit wordt tenslotte gebruikt om de DNS records te authenticeren. (zie ook het stukje hierover op tweakers eerder deze week).
Met DNSSEC los je deze problemen niet op.
Zou wel graag willen weten welke banken het allemaal zijn en wie er aan de goede en slechte kant staat...
Precies wat ik me ook af vroeg. Ik zou wel eens willen weten welke banken er juist goed uit de test komen. Dat ING, Rabo en ABN beveiligingsproblemen hebben dat wisten we eigenlijk al, ik ben meer benieuwd hoe de 'kleintjes' zoals ASN, SNS, Triodos, Friesland bank en dergelijke het doen.

Op dit item kan niet meer gereageerd worden.



Populair: Tablets Websites en communities Smartphones Beheer en beveiliging Google Laptops Sony Games Consoles Politiek en recht

© 1998 - 2014 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013