Veel bankensites kwetsbaar voor aanval op beveiligde verbinding

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.

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

[IIsnickerII]

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?

[_JGC_]

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.

[Stevie-P]

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 23 juli 2024 11:18]

[Spider.007]

Onzin:

Totaalbedrag overboekingen E 380,79. Hoogste overschrijving E 380,79 naar rekening *302 Volgnummer 347; TAN-code 345890

[Stevie-P]

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 23 juli 2024 11:18]

[Verwijderd]

Postbank vs ING?

[Joop Visstick]

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

[jeffreytigch]

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.

[Korben]

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.

[Soldaatje]

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.

[terual]

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

[Verwijderd]

Voor iemand die de resultaten wil zien. http://heesen.posterous.com/conclusie-bankenonderzoek

[tweaker2010]

Interessant, maar waar zijn die scorecijfers op gebaseerd? Een beetje veilig bestaat toch niet? Daarnaast vraag ik me af welke site je voor dit onderzoek gebruikt hebt.

[Verwijderd]

De scorecijfers zijn op de volgende punten berekend:
- HTTPS beveiligd.
- Inlogmogelijkheid
- Kwetsbaar voor aanval.
- Maakt de bank melding van mogelijke phishing.
- Doet de bank een oproep tot controle URL bank.
- Doet de bank een oproep tot controle ‘slotje’.
- Analyseren externe partijen (Google analytics) op inlogpagina.

[tweaker2010]

Oke, misschien kun je dit even uitleggen, want deze scores kloppen niet:

Westland Utrecht
Niet kwetsbaar.
Score: 5

ABN AMRO
Kwetsbaar voor SSL aanval.
Score: 7

[ThomasXCI]

Maar dit is toch nauwelijks een onderzoek te noemen Hij toont in zijn onderzoek niet eens aan hoe hij aan zijn bevindingen komt en waarop deze gebaseerd zijn.

[Verwijderd]

Dit zijn de conclusies. De argumentatie staat in het rapport.

[ThomasXCI]

Maar hoe kunnen we je conclusie begrijpen als we het voorwerk niet kennen. Zoals je probleemstelling en onderzoekmethode.

En het is nogal vreemd in mijn ogen dat je het opvallend vindt dat er geen 10 gescoord is. Wanneer is iets volgens jou 100% veilig dan?

[Verwijderd]

- HTTPS beveiligd.
- Inloggen met een reader of token.
- Niet kwetsbaar voor een aanval.
- De bank melding dat mogelijke phishingmails niet afkomstig zijn van de bank.
- De bank doet een oproep tot controle URL bank.
- De bank doet een oproep tot controle ‘slotje’.
- Externe partijen analyseren niet (Google analytics) op inlogpagina.

Nogmaals het is een schema die je opstelt om iets te peilen. Maar het garandeerd niet een volledig veilige omgeving.

[Verwijderd]

Nee dank je wel, succes verder met de advertentie verkoop

[Verwijderd]

Hmm, over die TLSv1.0 zwakheid bij banken blog/tweet/tweak ik al maanden. Goed om te horen dan ze hier eindelijk wakker zijn geworden.

Het heeft ermee te maken dat de servers van deze banken nog verouderde webserver software en crypto-libs gebruiken en dit zal zeker niet snel veranderen.

Ik had in December 2011 al een aantal banken hierover geinformeerd en het enige wat ik te horen kreeg was dat deze aanval alleen in bijzondere gevallen zal voorkomen en dat het er niet direct voor zorgde dat kwaadwillende geld van de rekening konden halen.

Alleen een mogelijke inzage op een bankrekening was voor hun geen redenen om de servers te upgraden. En nu het op tweakers verschijnt gaan ze opeens een onderzoek starten


Zelf als die banken hun servers zouden updaten met support voor TLSv1.2, dan kunnen de Firefox, Chrome browsers en oudere browsers zoals IE7 er nog niet mee overweg. Deze ondersteunen namelijk alleen maar TLSv1.0.

Check hier je browser op de TLS ondersteuning (zoek naar Client Version):
https://mikestoolbox.org/

Daarnaast hebben onze servers wel TLSv1.2 ondersteuning
https://www.fortresslinux.org

Onder Linux kan je dat testen d.m.v het volgende command:
gnutls-cli www.fortresslinux.org


edit: typo's and extra info

[Reactie gewijzigd door Verwijderd op 23 juli 2024 11:18]

[Spider.007]

En nu het op tweakers verschijnt gaan ze opeens een onderzoek starten

Nou, ik zou er niet teveel van verwachten. Zoals in het artikel al staat reageren banken slechts sporadische op dit soort meldingen; en zoveel geloofwaardigheid heeft een '17-jarige beveiligingsonderzoeker' natuurlijk ook niet, terwijl een 'onderzoek' als dit tegelijkertijd extreem eenvoudig uit te voeren is.

[Verwijderd]

Om eerlijk te zijn spider,

Ik heb voor een aantal van deze banken gewerkt en ik heb 17 jaar ervaring in de ICT-beveiliging. Naar mij word er ook niet geluisterd.

Het is maar goed dat er een meldingplicht voor lekken aankomt hier in Nederland. Zolang het niet in de media verschijnt, zal er niets gebeuren in dit soort situaties.

In noem dit het "Het breekijzer effect" (n.a.v het programma van Pieter Storms).

[Verwijderd]

Volgens je profiel ben je geboren in 1980 en dan op 32 jarige leeftijd al 17 jaar ervaring in de ICT-beveiliging... lijkt me stug dat dat de waarheid is.

[aikebah]

Er zijn volgens mij genoeg 15-jarigen die (vaak voor de hobby) aan het hacken zijn. De kennis die ze dan opdoen kunnen ze mijns inziens rustig scharen in de categorie 'ervaring in de ICT-beveiliging'. Helemaal niet zo ongeloofwaardig dus.

[elvries]

Blijkbaar heeft in ieder geval chrome al een tijdje geleden een patch http://www.theregister.co...e_chrome_patch_for_beast/ gehad, waardoor ook TLSv1.0 waarschijnlijk (?) veilig is.

[Verwijderd]

Is het niet mogelijk om fraude te plegen als je alleen iemand zijn rekening in kan zien?

Ik weet niet 100% zeker of het volgende correct is, aangezien ik het niet in de praktijk getest heb. Hierbij ga ik ervan uit dat de kwaadwillende toegang heeft tot een rekening overzicht van een ING klant na een BEAST aanval.

* Je maakt een nieuw paypal account aan.
* Je geeft het betreffende rekening nummer op alsof het jouw rekening is.
* Na een paar dagen zie een paar eurocent op die rekening verschijnen en deze voer je in voor de Paypal rekening verificatie.
* Je kiest voor de optie dat Paypal automatische incasso's van je rekening kan doen.
* Je misbruikt de gegevens van de bankrekening voor het incasso formulier en je verzend deze per digitale fax (ps. ik heb geen idee wat er in dit formulier exact gevraagd wordt).
* Als dit gedaan is, doe je een ergens een betaling op het internet via dit paypal account en het wordt automatisch van die rekening afgeschreven. Je kan trouwens ook bitcoins kopen met een paypal account.

Zoals ik al eerder zei, ik weet niet zeker of dit in de praktijk ook zo gaat werken, maar het is een van de mogelijkheden.

Wel weet ik dat automatische incasso machtigingen slecht gecontroleerd worden door de tussenpersonen en de banken.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:23]

[SCS2]

Dat is toch ook wat er een jaar gelden ofzo, gebeurd is bij klanten van de ING waar de inloggegevens van bekend waren geworden?

[heggico]

De 17-jarige beveiligingsonderzoeker Daniël Heesen,
Ben ik de enigste die hiervan opkijkt? 17 jaar en al beveiligingsonderzoeker?

[Verwijderd]

Hij heeft waarschijnlijk de urls van enkele banken getest op volgende site:
https://www.ssllabs.com/ssldb/index.html

deze geeft ook aan of je kwetsbaar bent voor de BEAST attack.

Zo kan iedereen zich beveiligingsonderzoeker noemen natuurlijk :-)

[wvd_vegt]

Inderdaad opmerkelijk (hopelijk doet ie meer dan downloaden en starten van reeds beschikbare scripts).

Nog spot goedkoop ook (20 euro per audit)

bron: http://www.sitedeals.nl/w...website-hacker-proof.html

[Reactie gewijzigd door wvd_vegt op 23 juli 2024 11:18]

[BtM909]

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 23 juli 2024 11:18]

[Zoefff]

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.

[Verwijderd]

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 Verwijderd op 23 juli 2024 11:18]

[PhoeniX1992]

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

[Verwijderd]

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.

[Armin]

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.

[Verwijderd]

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.

[Spockz]

het is onmogelijk om de onversleutelde informatie te achterhalen of te manipuleren.

Kleine correctie: Praktisch onhaalbaar binnen fatsoenlijke/bruikbare tijd.

[sygys]

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 23 juli 2024 11:18]

[henk-jan]

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 23 juli 2024 11:18]

[jaspergeerts]

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.

[redfox314]

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

[VisionMaster]

Met DNSSEC los je deze problemen niet op.

[InflatableMouse]

Was laatst nog een programma op TV, dit soort exploits worden gewoon al lang gebruikt en het kost de banken miljoenen per jaar omdat ze garant moeten staan voor de veiligheid en dus misbruik/diefstal in bijna alle gevallen vergoeden.

Een via malware/spyware geinstalleerde software op een pctje waarmee het mogelijk is het internet verkeer te monitoren en via injecties een tweede transactie te maken direct nadat de gebruiker zelf z'n eigen transactie heeft bevestigd. Het schijnt niet eens heel erg ingewikkeld te zijn.

Maar wat me nog het meeste verbaasd is hoe stom die medewerkers/woordvoerders van die banken ouwehoeren ... ontkennen, goed praten, probleem is niet zo groot en de kans zo klein bla bla bla maar als ze geconfronteerd worden met echte cijfers van gevallen en wat het kost, weten ze dat zogenaamd niet, horen ze het voor het eerst. Fix toch gewoon dat probleem dat is veel belangrijker dan die jaarcijfers, die zijn toch al te hoog.

Edit: Oh ja, een van die medewerkers (ING als ik me niet vergis) legde de schuld voor dit soort hacks bij de eind gebruiker, die zou zijn beveiliging niet op orde hebben. En bedankt!

[Reactie gewijzigd door InflatableMouse op 23 juli 2024 11:18]

[R4gnax]

Een via malware/spyware geinstalleerde software op een pctje waarmee het mogelijk is het internet verkeer te monitoren en via injecties een tweede transactie te maken direct nadat de gebruiker zelf z'n eigen transactie heeft bevestigd. Het schijnt niet eens heel erg ingewikkeld te zijn.

En daarom bevatten zinnige implementaties van internet bankieren ook een systeem om een nonce in te brengen via een externe factor die niet in directe verbinding staat met de client PC. Bijvoorbeeld TAN lijsten of apparaatjes zoals de random reader van de Rabobank. In het geval van die laatste is de nonce gebaseerd op de bankpas, begunstigde en over te maken bedrag. Dat maakt replay aanvallen en man-in-the-middle aanvallen op transacties een stuk gecompliceerder (zo niet praktisch onmogelijk dan wel niet meer interessant).

[Anoriel]

Moet je toch even corrigeren InflatableMouse. Bij een online overboeking wordt met dergelijke malware/spyware (trojan/keylogger) niet een tweede transactie gedaan maar al reeds voordat iemand een overboeking doet, gevraagd om een overboekingscode in te vullen ivm. veiligheidsmaatregelen, bevestiging van identiteit gebruiker, etc.

Code wordt ingevuld in een handig pop-up schermpje (onderdeel van de malware) et voila, de code wordt vervolgens gebruikt om geld af te boeken. Deze afboeking wordt overigens via de normale route gedaan maar door een derde (kwaadwillende) partij.

Dit is dus geen veiligheidslek bij de banken maar inderdaad bij de eindgebruiker zelf.

De dag dat banken te maken krijgen met de situatie die jij omschrijft, is de dag dat de hel losbreekt

[cire]

@InflatableMouse.... Als het allemaal niet zo erg ingewikkeld is, kun je waarschijnlijk ook wel uitleggen hoe die 2e transactie werkt!?

[Verwijderd]

En opnieuw nieuws over exploits...ze worden steeds handiger met omwegen vinden

[PolarBear]

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.

[MSalters]

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.