Veiligheid internetbankieren, onmogelijk veilig ???

[Twazerty]

Meestal als er weer iets bekend is over een aanval op een bank dan is dat heel vaak ING, ik zit zelf bij de rabobank en daar hoor je een stuk minder over. Nu ben ik zelf developer en kan wel wat zaken bedenken waar potentiële problemen zitten en hoe je een en ander kunt manipuleren.

Ik kwam op een idee hoe je betalingen zou kunnen "onderscheppen". Het idee ontstond vanuit Firebug, daarmee kun je de html bewerken in de browser. Als firebug dat kan dan kan een virus/malware dat ook. Dus stel je gaat een geldbedrag overboeken, hierbij moet je het rekeningnummer invoeren. Hierna volgt een POST actie naar de rabobank. Een virus zou het indrukken van de verzend knop kunnen onderscheppen (javascript ofzo) en het banknummer aan kunnen passen naar iets anders. Hierna wordt het gewijzigde banknummer gepost. Op de andere overzichtsschermen die je te zien krijgt naar welk banknummer je geld overmaakt zou ook gemanipuleerd kunnen worden in de browser zodat je nog steeds denkt naar het juiste banknummer geld over te maken. Alle andere validaties zoals pincode, bankpas en geldbedragen blijven intact, je hebt niets in de gaten. Ook SSL zal nog steeds actief zijn, deze voorkomt alleen maar het onderscheppen van jouw pc naar de server van de bank en dus niet de wijzigingen die je doet in je browser. Er wordt feitelijk niets gekraakt of omzeild, uitsluitend de ingevoerde en getoonde data wordt gemanipuleerd in de browser.

Als een malwarebouwer dit virus enkele minuten kan activeren op het drukste betaalmoment van de dag... middels een botnet moet dat wel te doen zijn.

Mis ik iets in mijn idee? of zal alles net op tijd weggesluisd worden zodat de bank te laat is?

De oplossing die ik hiervoor heb bedacht is het volgende: bij het verzenden van een opdracht alle huidige beveiligingen toe blijven passen, dus bankpas + pincode + randomreader. Echter nu toegevoegd door een SMS met een overzicht van banknummers met bedragen. Op deze manier kan het banknummer niet gemanipuleerd worden. De SMS manipuleren lijkt mij bijna onmogelijk, maar wellicht dat er slimme koppen rondlopen die (bv middels social engineering) de SMS buiten spel kunnen zetten.

Alles wat zich afspeelt op het scherm van de gebruiker kan gemanipuleerd worden, inclusief de afbeeldingen die rabobank toont in plaats van tekst. Ook eventuele remote desktop sessies zouden gemanipuleerd kunnen worden zonder dat de gebruiker het ziet (wel aanzienlijk moeilijker)

Ofwel: is internetbankieren überhaupt wel veilig te krijgen? of moeten we uitsluitend gebruik maken van de computers van je bank?

Edit: iedere developer met een beetje gezond verstand zou dit moeten kunnen bedenken lijkt mij zo?

[Herko_ter_Horst]

Je hebt uiteraard gelijk: het is niet 100% veilig te krijgen. Maar dat is een open deur: geen enkel systeem dat ook nog (voor mensen) bruikbaar moet zijn is 100% veilig.

Gelukkig krijg je die malware van je niet zomaar geïnstalleerd, daar heb je een lek of de medewerking van de gebruiker voor nodig. De gebruiker zal dus maatregelen moeten nemen om te voorkomen dat die malware geïnstalleerd wordt. Een up-to-date OS, een virusscanner en niet overal blind "Install"/"Ok" klikken. Maar dan nog kan het gebeuren dat er malware binnenkomt.

Blijft over de aloude afweging tussen gemak, veiligheid, risico en schade: is de veiligheid van Internetbankieren t.o.v. het gemak "goed genoeg" als je het afzet tegen het risico op en de hoogte van de potentiële schade?

Het geklooi dat je er als individu mee kan krijgen, maakt dat sommige klanten een hogere mate van veiligheid willen dan de bank nodig vindt. Maar voor de meerderheid van de klanten geldt dit mijns inziens niet: die vinden het gemak het belangrijkst en/of zijn te weinig op de hoogte van de potentiële risico's.

De bank rekent intussen heel klinisch: levert het feit dat mensen hun zaken via Internet regelen i.p.v. aan de balie ons meer op dan het kost om schade te vergoeden?

[ Voor 49% gewijzigd door Herko_ter_Horst op 14-08-2012 21:30 ]

[BastiaanCM]

Kijk, als het zo simpel was dan had je hele post niet gehoeven.

Het idee ontstond vanuit Firebug, daarmee kun je de html bewerken in de browser.

Volgens mij heb je nog niet gehoord van banken trojans ? Die laten gewoon een andere website zien, zoals je omschrijft. Alleen moet je naast de gewone dingen, opeens nog een aantal vlakken invullen. De andere geschetste situaties bestaan ook al. Jaren. (Verborgen stortingen e.d.)
nieuws: Nieuwe trojans halen bankrekening leeg (2006)

is internetbankieren überhaupt wel veilig te krijgen?

In mijn ogen ligt de veiligheid van internetbankieren voornamelijk, doch niet volledig bij de gebruiker zelf. In veel gevallen van malware ligt de schuld toch wel bij de gebruiker. Maar ! Niet altijd. Met behulp van 0-days en exploits bij computers die niet worden ge-update kunnen zonder enige tussenkomst van gebruikers de computers overgenomen worden. (@Hekko_ter_Horst, die malware krijg je dus soms wel zomaar geinstalleerd).

Als een malwarebouwer dit virus enkele minuten kan activeren op het drukste betaalmoment van de dag... middels een botnet moet dat wel te doen zijn.

Dit is in mijn ogen wel een realistische situatie. Maar op zo`n moment is er natuurlijk al wat mis. Dat botnet zou niet onopgemerkt moeten gaan (vooral voor anti-virus).

Zoals ik al zei, ik vind dat de verantwoordelijkheid voornamelijk ligt bij de gebruiker omdat de meeste malware volgens mij toch wel gewoon door de gebruikers gedownload word. Gelukkig word het meeste wel snel opgepakt door de antivirus pakketten op computers indien aanwezig.. Kijk als je die niet hebt (vooral op Windows) dan is dat gewoon niet handig

Wat ik zelf nog wel zou willen zien is een meer actief blokkade platform met adressen richting C&C servers bijvoorbeeld. (Denk voor Windows aan een door Microsoft live beheerd hosts file waarbij dit spul geblokkeerd word.) Sowieso word in mijn ogen elk OS wel veiliger naarmate het ouder word, omdat ontwikkelaars er aan blijven werken. Of gewoon mijn DNS servers die dat blokkeren. Volgens mij levert bijv OpenDNS al zo`n soort service.

De oplossing die ik hiervoor heb bedacht is het volgende: (...)

Hier komt het uit bij een discussie over Computer Security waar hele boeken over geschreven worden. Kwestie van bereikbaarheid betrouwbaarheid e.d. (Confidentiality, Integrity, Avaibility, Authenticity, Accountability.) Je gaat het mensen wel heel moeilijk maken om geld over te maken met een gebruikersnaam, wachtwoord, identifier en SMS..

[Gomez12]

Ik heb geen idee hoe het exact zit, maar in principe is jouw methode simpel te ondervangen door het getal wat je aan de random reader moet voeren af te laten hangen van alle ingevoerde gegevens (dus ook rekening nr etc)

1 verandering zorgt er dan al voor dat de random reader niet meer het juiste getal teruggeeft omdat de input fout was.

Zoals ik al zeg, ik heb geen verstand van hoe het exact zit. Maar de bank heeft met een random reader en een van te voren in te geven nummer alle controle in handen voor het onderscheppen van MITM attacks.
En zelfs al zou het systeem van de bank (voor de uitgifte van de nrs) gehackt worden dan is er nog geen man overboord, ze kunnen gewoon een nieuw systeem introduceren zolang het maar compatible blijft met de random reader.

In wezen is de communicatie veilig (/te herstellen) zolang de bank geen security through obscurity in hun random readers heeft gebouwd. In wezen is het veilig zolang de random reader niet gehackt wordt.

Zolang de random reader geen flaws vertoont (en dus via een cryptografisch veilig algoritme werkt) kan de bank alles aanpassen aan de beveiliging aan hun kant.

Er zullen vast genoeg tijdelijke flaws zijn geweest aan de serverkant, maar zolang de bank daarop monitort en actief actie op onderneemt gaat het om een miniem aantal frauduleuze transacties die zo weer terug te draaien zijn.

Het mooie aan banken is dat ze vanwege traagheid / nachtelijke verwerking / niet echt gegarandeerde verwerkingstijd allerlei tijd hebben om extra controles uit te voeren. Als jouw methode al zou slagen, en je krijgt 10.000 computers geinfecteerd om naar jouw rekening geld over te maken dan staan er opeens in de nachtelijke queue 10.000 opdrachten naar een prive-rekening (onregelmatig patroon), die kan je dus even blokkeren en de eerstvolgende werkdag uit laten zoeken door een bankemployee of het wel klopt.
Zoja, dan wordt het de volgende batchverwerking meegenomen en duurde het 2 dagen voordat jij het op je rekening had. Zonee, dan krijg jij niets en wordt het waarschijnlijk gelijk bij de verzenders teruggestort.

Ik dacht dat er interbancair binnen 30 dagen geld terug gestort kon worden in geval van interbancaire fraude (dus niet bij Marktplaats oid dat is van een heel andere orde)

Wil je een random reader beveiliging kraken dan moet je :
- Het volgende getal van de bank kunnen voorspellen
- De pincode van de desbetreffende klant weten (zodat je de random reader na kan bootsen)
- Je transacties binnen het normale spendeer gedeelte van de klant houden zodat er geen alarmbellen ergens gaan rinkelen.

Stap 1 kan nog wel, maar die kan elk moment veranderen
Stap 2 kan nog wel, maar vereist veelal al inside kennis.
Stap 3 zorgt er dan nog voor dat het veelal niet de moeite waard is om stap 1 of 2 te proberen.

Daarom is spam ook vele malen effectiever dan brute-force hacking. Spam zorgt ervoor dat je per dag 10.000 binnenhaalt en onder de radar van 3 blijft zodat je in een maand redelijk wat kan binnenhalen. Brute force hacking is erg veel moeite voor 1 en 2 en valt op bij 3.

[Herko_ter_Horst]

Gomez12 schreef op dinsdag 14 augustus 2012 @ 22:14:
Ik heb geen idee hoe het exact zit, maar in principe is jouw methode simpel te ondervangen door het getal wat je aan de random reader moet voeren af te laten hangen van alle ingevoerde gegevens (dus ook rekening nr etc)

1 verandering zorgt er dan al voor dat de random reader niet meer het juiste getal teruggeeft omdat de input fout was.

Zoals ik al zeg, ik heb geen verstand van hoe het exact zit. Maar de bank heeft met een random reader en een van te voren in te geven nummer alle controle in handen voor het onderscheppen van MITM attacks.
En zelfs al zou het systeem van de bank (voor de uitgifte van de nrs) gehackt worden dan is er nog geen man overboord, ze kunnen gewoon een nieuw systeem introduceren zolang het maar compatible blijft met de random reader.

Je snapt het idee niet. Het is geen MITM aanval, het is een aanval op de client. De gebruiker (en uitsluitend de gebruiker) ziet iets anders dan dat er verstuurd wordt: vlak voordat de informatie de browser verlaat/inkomt, wordt deze door de "Firebug"-malware (in feite een browserplugin) veranderd. De bank ziet hier niets van, de random reader weet überhaupt niks van de transactie en al wist ie dat wel: het lijkt gewoon een legale transactie. Alleen de gebruiker ziet iets anders.

[sh4d0wman]

Wat jij bedoelt is een MITB aanval zie wikipedia: Wikipedia: Man-in-the-browser
Dit is inderdaad hoe een deel van de banking trojans werken. On-the-fly worden elementen in een webpagina aangepast zoals bijvoorbeeld het rekeningnummer. Als eindgebruiker zie je dus niks vreemds. Wellicht zou je het kunnen zien in je betalingsoverzicht maar ook dat kan aangepast worden. Een andere truuk die men toepast is om na de succesvolle transactie de banking website onbereikbaar te maken voor de eindgebruiker. Een nog extremere methode is de pc onklaar te maken.

Beveiliging hier tegen is lastig. Dan zou je eigenlijk de gebruiker naast de random reader ook gebruik moeten laten maken van sms. Dus authenticeren van de opdracht via de random reader en een bevestiging van bedrag en rekeningnummer per sms sturen. Dan ziet de gebruiker in ieder geval dat er iets mis is. (mits zijn smartphone niet voorzien is van malware welke de sms onderschept)

[hellknight]

Hoe zou een MITB aanval dan kunnen werken bij systemen als die van de Rabo? HIerbij moet niet alleen bij inloggen gebruik gemaakt worden van de random-reader, maar ook bij het versturen van de transacties.
HIerbij worden, zower ik weet, de doel-bankrekening(en) gebruikt voor het bepalen van de 1e code welke op de random reader ingevuld moet worden, en vervolgens moet het totale eindbedrag in hele euro's als 2e code ingevoerd worden. Dit samen wordt dan gebruikt om de code te genereren welke ingevoerd moet worden om de transacties te bevestigen. Als doelrekening en/of totaalbedrag aangepast wordt, is de code niet meer geldig, en zal het versturen van de transacties mislukken.

[Rukapul]

hellknight schreef op donderdag 16 augustus 2012 @ 16:37:
HIerbij worden, zower ik weet, de doel-bankrekening(en) gebruikt voor het bepalen van de 1e code welke op de random reader ingevuld moet worden, en vervolgens moet het totale eindbedrag in hele euro's als 2e code ingevoerd worden.

Het dikgedrukte geeft perfect de beperkte veiligheid van de methode. Het probleem is dat de getallen die in een randomreader in beginsel geen betekenis hebben. Sterker nog, de betekenis is er later bijgekomen, niet consequent (bij grote transacties is het anders dan kleine), niet uniform tussen banken, etc. Hiermee is de methode meteen waardeloos geworden.

Veilig internetbankieren kan op zich wel, maar dan is een vertrouwde client nodig. De PC (in combinatie met gebruikers die allerlei menselijke beperkingen hebben) is dat al lang niet meer. Minimaal kom je dan op een soort van random-reader++ uit welke zorgdraagt voor alle interactie met de gebruiker en welke in staat is om op veilige wijze met de bank te communiceren. Op zich niet moeilijk, maar relatief (vergeleken met een random reader) wel duur.

[Herko_ter_Horst]

hellknight schreef op donderdag 16 augustus 2012 @ 16:37:
Hoe zou een MITB aanval dan kunnen werken bij systemen als die van de Rabo? HIerbij moet niet alleen bij inloggen gebruik gemaakt worden van de random-reader, maar ook bij het versturen van de transacties.
HIerbij worden, zower ik weet, de doel-bankrekening(en) gebruikt voor het bepalen van de 1e code welke op de random reader ingevuld moet worden, en vervolgens moet het totale eindbedrag in hele euro's als 2e code ingevoerd worden. Dit samen wordt dan gebruikt om de code te genereren welke ingevoerd moet worden om de transacties te bevestigen. Als doelrekening en/of totaalbedrag aangepast wordt, is de code niet meer geldig, en zal het versturen van de transacties mislukken.

De grap van de voorgestelde methode is - nogmaals - dat de invoer van de gebruiker wordt omgebouwd voordat deze naar de bank wordt gestuurd en dat vervolgens op de resultaatpagina de boel weer wordt omgebouwd voordat de pagina aan de gebruiker getoond wordt. De nummers die de bank binnen krijgt zullen dus altijd kloppen. De gebruiker ziet ook geen gekke dingen. De gebruiker wordt alleen maar gevraagd om de random-reader te gebruiken en kan daaraan niet zien welke bankrekeningnummers gebruikt zijn.

Als er al een relatie is van de random reader code met de bedoelde bankrekeningnummers, is die voor de gebruiker compleet onzichtbaar/niet te achterhalen (die relatie is er volgens mij overigens niet, anders zou het voorspellen van de nummers makkelijker worden).

[Gomez12]

Rukapul schreef op donderdag 16 augustus 2012 @ 16:50:
[...]
Minimaal kom je dan op een soort van random-reader++ uit welke zorgdraagt voor alle interactie met de gebruiker en welke in staat is om op veilige wijze met de bank te communiceren. Op zich niet moeilijk, maar relatief (vergeleken met een random reader) wel duur.

In potentie hoeft dat helemaal niet duur te zijn, het enige wat je nodig hebt is aan het einde 1 veilige communicatie methode om een bericht van de bank bij jou te krijgen. Zodat daarin de gegevens gestuurd kunnen worden die de klant moet bevestigen.

In wezen volstaat daarvoor een goedkope gestripte telefoon met wat extra software checks en daarin een sim-kaart die zeg 500 sms'jes per jaar kan ontvangen van enkel 1 nummer. En tja, als AH / Aldi zo af en toe met die dingen kunnen stunten voor een tientje dan zie ik de kosten niet echt...

Het is enkel een groot gebruikersongemak.

Ik bedoel je kan zo'n dumbphone met beperkte sim-kaart vast wel weer rooten / custom roms erop zetten en dan weer gevaar lopen. Maar dat is dan van een heel andere orde als dat een hacker uit verweggistan via inet je kan hacken.

[Rukapul]

Gomez12 schreef op donderdag 16 augustus 2012 @ 20:01:
[...]

In potentie hoeft dat helemaal niet duur te zijn, het enige wat je nodig hebt is aan het einde 1 veilige communicatie methode om een bericht van de bank bij jou te krijgen. Zodat daarin de gegevens gestuurd kunnen worden die de klant moet bevestigen.

In wezen volstaat daarvoor een goedkope gestripte telefoon met wat extra software checks en daarin een sim-kaart die zeg 500 sms'jes per jaar kan ontvangen van enkel 1 nummer. En tja, als AH / Aldi zo af en toe met die dingen kunnen stunten voor een tientje dan zie ik de kosten niet echt...

Het is enkel een groot gebruikersongemak.

Het is zelfs nog iets erger dan gebruikersongemak. Het is een gegeven dat mensen slecht zijn in het uitvoeren van routinematige controle*. De menselijke aard werkt daar tegen. Gevolg is dus dat op den duur men 'blind' bevestigt (voorbeeld: sinds op m'n nieuwe telefoon TAN-codes al zichtbaar zijn in de notificatiebalk open ik de SMS soms niet eens).

Een oplossing moet erop gebaseerd zijn dat (ook) de gebruikersinvoer van een vertrouwd apparaat van een geauthenticeerde gebruiker afkomt. Op die manier ervaart de gebruiker het als een geintegreerd geheel. De gebruiker zal ook opletten omdat de invoer onderdeel is van het doel wat hij nastreeft* namelijk het betalen.

Voor de rest ben ik het met je eens dat het een single-purpose gestripte telefoon zou kunnen zijn In vergelijking met bestaande oplossingen is die oplossing echter veel en veel duurder.

* inzichten uit recente usable security literatuur