'Nederlandse bankklanten slachtoffer van miljoenenhack' - update

Internetcriminelen hebben ruim 35 miljoen euro proberen te stelen van Nederlandse bankrekeningen. Daarbij werden vooral zakelijke gebruikers getroffen. Hoeveel geld de aanvallers precies hebben buitgemaakt, is onduidelijk.

De aanval, die ook gebruikers in andere Europese landen, de Verenigde Staten en Latijns-Amerika trof, was gebaseerd op verschillende versies van de bekende Zeus- en SpyEye-trojans. Dat blijkt uit onderzoek van McAfee en Guardian Analytics. In Nederland probeerden de aanvallers in totaal 35 miljoen euro van circa vijfduizend vooral zakelijke bankrekeningen te halen.

Zakelijke gebruikers waren het doelwit omdat die doorgaans meer geld op hun rekening hebben staan en transacties met grote bedragen minder snel tot argwaan leiden, zo redeneren de onderzoekers. Gemiddeld werd per bankrekening geprobeerd om 2500 euro te plunderen. Het is echter onduidelijk hoeveel geld de aanvallers daadwerkelijk hebben buitgemaakt. Uit het rapport blijkt dat in Nederland klanten van twee banken zouden zijn getroffen, maar welke dat zijn, blijft onvermeld.

Woordvoerder Daan Heijbroek van ING, de grootste bank van Nederland, herkent het geschetste scenario niet. "We herkennen SpyEye en Zeus wel", zegt Heibroek, "maar deze aanval en de genoemde bedragen niet." Als klanten bij ING toch slachtoffer zijn, wordt de schade in ieder geval vergoed, ook als het zakelijke gebruikers zijn. "We zullen alle zaken op individuele basis onderzoeken", aldus Heijbroek. "Als een klant te goeder trouw is, zullen we de schade vergoeden."

Bart van Leeuwen van de Nederlandse Vereniging van Banken benadrukt dat het gaat om 'pogingen, niet om daadwerkelijke aanvallen'. "De banken monitoren steeds beter en vangen daardoor veel fraude af, dankzij goede preventieve maatregelen", zegt hij. "Het onderzoek verbaast ons niet, het gebruik van malware is een bekend onderdeel van bankfraude."

De aanval werkt via malware die wordt geïnstalleerd op computers van gebruikers. De malware zorgt ervoor dat het proces van internetbankieren wordt onderschept. Daarbij valt in dit geval op in hoeverre het proces volledig geautomatiseerd is, schrijven McAfee en Guardian Analytics: er komen bijna geen handelingen van de aanvallers aan te pas.

Volgens de onderzoekers werden 426 varianten op ZeuS en SpyEye gebruikt. In tegenstelling tot de gebruikelijke implementatie van de Zeus- en SpyEye-malware, gebruikten de aanvallers eigen servers die uit naam van de klant frauduleuze transacties uitvoeren. Normaliter wordt die frauduleuze transactie op de computer van de gebruiker zelf uitgevoerd. Volgens McAfee reduceert de implementatie van deze aanvallers de kans dat de aanval wordt ontdekt.

Bij de aanval op Nederlanders werden gebruikers na het inloggen omgeleid naar een pagina waarop gebruikers werd verteld dat er bijvoorbeeld server-onderhoud was, waardoor ze een paar uur of zelfs dagen niet bij internetbankieren konden komen. In die tijd werd op de server van de aanvallers geheel automatisch een frauduleuze transactie gestart waarbij geld werd overgemaakt naar de aanvallers. Daarbij slaagden ze erin om de two-factor authentication van banken te omzeilen. Voorbeelden van two-factor authentication zijn de random reader bij de Rabobank en het systeem met tan-codes bij ING.

De aanval werd ontdekt doordat de criminelen een grote fout maakten: extern opgeslagen mappen met logs over slachtoffers en transacties waren niet goed genoeg beveiligd. Daardoor konden onder meer slachtoffers worden geïdentificeerd. Het is onduidelijk waar de aanvallers vandaan komen, al is wel bekend dat de server die werd gebruikt om Nederlanders aan te vallen in de Verenigde Staten stond. Of er al aanhoudingen zijn verricht, is nog niet bekend.

Update, 14:01: Reactie Nederlandse Vereniging van Banken toegevoegd.

Reacties (175)

[WhiteDog]

In België moet je een betaling bij de meeste banken bevestigen met zo'n kaartlezer waar je jouw pinpas moet instoppen. Je geeft dan een code in die op je scherm verschijnt op het toestel en krijgt een andere code in de plaats die je online moet ingeven. Vaak moet je ook nog eens het bedrag zelf ingeven op de kaartlezer.

Dit gaat ongeveer zo:
1. Stop pinpas in het toestel
2. Geef pincode in
3. Kies M2
4. Geef code in die op het scherm staat, bv. 1234 5678. Druk OK.
5. Geef bedrag in, bv 321. druk OK.
6. Geef nu de code die op het toestel verschijnt online in.

Gezien je enkel het bedrag moet ingeven bij betalingen zou er bij de gebruiker toch een lichtje moeten gaan branden als hij bovenstaande procedure ergens anders aan het uitvoeren is. Tenzij je natuurlijk denkt een echte betaling te doen (in een fake omgeving) en men op de achtergrond een ander rekeningnummer gebruikt

[mashell]

Aan de andere kant. Mijn bank de Rabobank verandert met enige regelmaat de procedure. Dan worden de codes langer, dan moet er opeens een 3e getal worden ingevoerd. Ik kan me voorstellen dat er klanten zijn die er niet vreemd van opkijken als op een dag de S methode ook gebruikt wordt voor inloggen, "met al die extra codes moet dat immers wel veiliger zijn".

[ThomasG]

Klopt niet helemaal wat je zegt. Ze hebben de procedure laatst een keer aangepast zodat het tweede getal (het bedrag) geld voor alle bedragen. Het derde getal is alleen het geval bij grote bedragen. Van de Rabobank website:

Bij betaalopdrachten boven een bepaald totaalbedrag moet u als extra beveiliging een tweede of derde controlegetal ingeven.

Wat betreft het inloggen met S. In het boekje dat je bij je randomreader krijgt staat duidelijk uitgelegd dat de I voor inloggen is, en de S voor betalen/overboeken. Natuurlijk is een deel van de beveiliging voor de rekening van de bank, maar als mensen daar in trappen is het gewoon hun eigen schuld.

@albatross: Dat is toch precies wat ik zeg..

[Reactie gewijzigd door ThomasG op 23 juli 2024 03:26]

[albatross]

Klopt niet helemaal wat je zegt. Ik bestelde laatst online een pizza, en moest ook al een tweede code invoeren (2 cijfers).

[dr86]

In nederland ook, bij de ing gaat het met een tan code op je telefoon, bij rabo en abn met een kaartlezer

[Triple_D]

Het virus dat de hackers gebruiken manipuleert de website die de gebruikers krijgen te zien. Zodra de gebruiker inlogt manipuleert het virus de website en laat de gebruiker 2 maal de two-factor authentication uitvoeren. De 'gemiddelde' gebruiker heeft niet in de gaten wat er precies gebeurd, de website en het slotje zien er hetzelfde uit, de gebuiker zal hoogstens denken dat de beveiliging is uitgebreid (dit soort 'informatie bericht' kan het virus ook laten zien door het wijzigen van de website).

door de 2de keer de two-factor authenticatie in te voeren, wordt er geld overgemaakt en klaar is kees.

meer info: http://www.mcafee.com/us/...operation-high-roller.pdf
zie ook: http://www.trendmicro.com..._online_banking_fraud.pdf

[Reactie gewijzigd door Triple_D op 23 juli 2024 03:26]

[servies]

Het probleem is alleen dat voor het inloggen de 'I' wordt gebruikt en voor het overboeken de 'S'. Als je voor het inloggen de 'S' moet gebruiken, dan weet je gewoon dat je fout zit...
Het zou mij ook niets verbazen als dit achteraf een enorm opgeblazen verhaal blijkt te zijn om maar media aandacht te krijgen voor hun eigen producten...

[pegagus]

Ik heb dus wel eens bij de Rabo (paar jaar geleden) opnieuw moeten inloggen, voordat ik kon betalen. De Rabo gebeld met het verhaal, maar er was volgens hun niets aan de hand (wat ook zo was). Maar de truuk die nu wordt uitgehaald, is exact het zelfde.

Op het moment dat de betaling verricht moet gaan worden, wordt je omgeleid. Door opnieuw in te loggen geef je je I-code af en omdat je direct weer de betaling op je scherm hebt, zie je dus niet dat er wat mis. is. Je voert de betaling uit met de S-code, en die heeft de hacker dus ook in handen. De hacker heeft dan de I-code en de S-code en kan precies het bedrag overmaken, wat jij wilde betalen. Maar dan wel naar zijn eigen rekening.

[Zoidberg_AvG]

De S-code is afhankelijk van de rekening waar het bedrag heen gaat. Daarnaast moet ook nog het bedrag afgerond in euro's worden ingevoerd.

[Triple_D]

Bij ABN AMRO met de oude identifier is er geen verschil tussen 2FA voor het inloggen en 2FA voor betalingen.

Ze kunnen natuurlijk ook boven de 2de 2FA zetten dat dit een extra beveiliging is door een combinatie van I en S te gebruiken.

Zwakste schakel van beveiliging is de mens hè

[hoeschrijfjedit]

Kortom ze hebben 2x een betaling gedaan wie zet er nou een (gemiddelde)oen achter een rekening van een miljoen.

[Triple_D]

de eerste two-factor authentication is voor de daadwerkelijke inlog, de 2de is voor de betaling. Dus er heeft 1 betaling plaatsgevonden

[hoeschrijfjedit]

Bij de Rabobank is i inloggen en s is betalen.
Dus log je niet in met de i , kan er een betaling plaatsvinden.

Telebankieren voor dummy's

[Illegal_Alien]

Plus dat je tegenwoordig het afgeronde bedrag er ook nog eens bij moet aangeven als je betaald (S).

[Just smile]

Het betreft hier inderdaad de ING Bank en de Rabobank. Wij hebben ook frauduleuze transacties ontvangen met onze webshops. Meerdere per dag zelfs, waarvan 90% via de Rabobank. De gemiddelde orde waarde klopt inderdaad wel. Alleen werd het geld niet naar de rekening van de fraudeurs / hackers gestort, zij bestelden producten die zij direct per e-mail ontvangen om dit daarna weer te verkopen.

Gisteravond merkte ik dat de transacties nu door één of andere reden tegen word gehouden, een bezoeker was ruim een uur online en trachtte telkens via iDeal te betalen.

De bestellingen kwamen van Nederlandse IP adressen dus het zal ongetwijfeld zijn dat de hacker/fraudeur de bestelling zelfs via de computer / netwerk van de gedupeerde heeft geplaatst.

Wat kan je als webshop er tegen doen? Na het constateren dat het een frauduleuze bestelling betreft de IP adressen en e-mail accounts blokkeren. Alleen is het geld al bijgeschreven en de producten worden automatisch verstuurd.

Het controleren of de persoon ook daadwerkelijk iDeal gemachtigd is kan niet, aangezien de bank verder geen controle gegevens geeft aan de webshop. Dus elke transactie zou ook een normale kunnen zijn..

[polleke67]

Ik heb zelf onderstaande meegemaakt 3 maanden geleden. Het was via de ABN/AMRO-site. Continue een https verbinding. Je logt in optie 1, maakt een betaling, met TAN-code (optie2). Dan verschijnt er een pop-up, dat de synchronisatie verloren is gegaan en dat de verbinding opnieuw opgezet moet worden en je opnieuw moet inloggen (normaal optie1), maar nu wordt dit gedaan met optie2. Er vindt nu een betaling in de achtergrond plaats. Dus MITM attack.

In mijn geval 2500 naar een Oostblokland. Gelijk fraude afdeling gebeld van ABN/AMRO en deze konden de betaling zelf niet meer terugdraaien, maar de locale bank in het Oostblokland wel. Echter deze locale bank bracht wel administratie kosten a 25 euro in rekening. Dit is uiteindelijk allemaal door ABN terugbetaald inclusief kosten van spoedbetaling.

Ik heb mijn laptop voor onderzoek aangeboden aan ABN, omdat geen anti4us, malware, spyware programma reageerde, maar dit was niet nodig.

[Verwijderd]

Bij het inloggen op de ASN Bank omgeving, wordt er al een tijdje gewaarschuwd voor een virus;

Momenteel is er een virus in omloop dat van invloed kan zijn op ASN Online Bankieren. Controleren of uw computer besmet is doet u middels onderstaand stappenplan.

Te volgen stappenplan:
Voer uw toegangsnaam en wachtwoord in en klik op inloggen.
Als uw rekeningoverzicht getoond wordt, is er niets aan de hand.
Als u onderstaande virustekst ziet,

Om te zorgen voor een hoog veiligheidsniveau, introduceert ASN nieuwe instrumenten voor de beveiliging van internetbankieren. Om dit moment wordt uw system gescand om een uniek digitaal profiel te bouwen waarmee uw toekomstige verrichtingen worden getekend. Na deze scan kunt u weer gebruik maken van internetbankieren.

Om het digitale profiel van uw computer met succes op te bouwen verzoeken wij u:
* Niet op 'Terug ' te drukken
* Niet op 'Home ' of 'Hernieuwen ' in uw browser te drukken.
* Geen nieuw adres in te voeren in de adresbalk van uw browser.
* De browser niet af te sluiten.

De ASN zorgt altijd voor een veilige omgeving!

is uw computer besmet. Zet dan onmiddellijk uw computer uit en neem contact op met de ASN Klantenservice: 0800 0380 (gratis) op werkdagen van 08.00 uur tot en met 17.30 uur. Stuur een e-mail buiten openingstijden via een andere computer naar [e-mail] met als onderwerp "Virus", vermeld daarbij uw contactgegevens en wij helpen u de eerstvolgende werkdag graag verder.

Zou ASN tot 1 van de benadeelden behoren? Inloggen geschied dmv een wachtwoord, maar geld overboeken via een challenge-response code.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 03:26]

[SaphuA]

Hoe hebben ze het dan voor elkaar gekregen om het gebruik van TAN-codes te omzeilen?

Edit: ij > ei

[Reactie gewijzigd door SaphuA op 23 juli 2024 03:26]

[basvd]

http://www.mcafee.com/us/...operation-high-roller.pdf

The malware discovered within Operation High Roller is the first to work around the “smartcard/physical reader + PIN” combination. Normally, the victim inserts a smartcard into its reader device and enters a PIN into the device. The bank’s system generates a digital token based on the data contained on the physical smartcard, authorizing a transaction. The malware defeats this authentication by generating an authentic simulation of this process during login to capture the token. To allay suspicion, the script collects the token as the user logs in, rather than during the transfer authorization process. It then uses the digital token to validate the transaction later in the online banking session while the user is stalled with a “Please Wait” message.

Edit: Pagina 11 staat het proces beschreven

If during the automated attack, the financial institution requests a transaction authorization number (TAN), the fraudsters’ client-side web injection displays a fake TAN page to the victim and the malware proceeds as follows:
– The malware collects the TAN from the victim’s screen and presents the authentic TAN to the financial institution to enable the fraudulent transaction, while delaying the victim from accessing their account.
– The malware uses the intercepted credentials to initiate a silent, separate transaction to a mule account (either individual or business) or in one case, a prepaid debit card.
– The malware looks up a valid mule account from a separate database, automating a traditionally manual step in the process. The transaction is performed in a hidden iFrame, a parallel instance of the online banking session on the client that operates in the background. The code navigates to the transaction page and initiates an automated form submission that adds the mule information.

[Reactie gewijzigd door basvd op 23 juli 2024 03:26]

[cyberstalker]

Het is me nog steeds onduidelijk. De codes die worden gegenereerd voor het inloggen en het authorizeren van transacties zijn toch volkomen verschillend?

Hoe zou de malware dan transacties kunnen uitvoeren zonder dat ik specifiek daarvoor een code aanmaak? Bovendien moet je (tenminste bij de Triodos Bank) ook altijd het totaalbedrag intoetsen op je e-dentifier om een transactiecode te krijgen. Als dit bedrag afwijkt dan valt dat toch op?

Het enige wat ik me zou kunnen bedenken is dat malware transacties inboekt met exact dezelfde bedragen, zodat het niet opvalt, maar ik lees daar nergens iets over terug.

[YopY]

Bovendien moet je (tenminste bij de Triodos Bank) ook altijd het totaalbedrag intoetsen op je e-dentifier om een transactiecode te krijgen.

idd, de Rabobank doet dat tegenwoordig ook voor alle bedragen - dat was eerst alleen bij hogere bedragen. Dit is - met bovenstaand verhaal in het achterhoofd - een goeie oplossing, aangezien de code die je invult niet meer geldig is als het bedrag niet overeenkomt met wat je ingevuld hebt. Moet je natuurlijk wel doorhebben dat het 2e getal altijd het bedrag is; als er een 8-cijferig bedrag overgeheveld wordt heb je alsnog een probleem.

Toekomstige e-dentifiers / random readers zouden ook expliciet moeten vragen om de hoeveelheid geld dat de transactie betreft, ipv een generieke '2e/3e invoer' zoals nu (en al 10 jaar)

[Reactie gewijzigd door YopY op 23 juli 2024 03:26]

[Zoidberg_AvG]

Er staat volgens mij bij de rabobank gewoon bij dat het 2e bedrag het afgeronde bedrag in euro's is. Op de randomreader staat het idd wel gewoon als 2e en 3e verificatie code

[PBX_g33k]

Bij de rabobank wordt er inderdaad aangegeven dat de tweede code het bedrag afgerond in hele euro's is. Dat wordt ook niet in kleine letters aangegeven, dus het moet opvallen.

[Herko_ter_Horst]

Off--topic: het bedrag wordt niet afgerond, je moet het bedrag voor de komma intoetsen.

[mjtdevries]

Met die uitleg word ik weinig wijzer.
Hoe kan je de token tijdens login gebruiken als token voor de tranfer authentication?
Hoe omzeil je daarmee de pin code en reader of TAN code?

[majoh]

Een voorbeeld die ze geven is dat op het moment dat je inlogt op de achtergrond een transactie wordt ingeschoten. En dan meteen een popup gegeven wordt met een vraag om je code in te voeren i.v.m. onderhoud of een ander geloofwaardig bericht. Met die code wordt dan de onderwater ingevoerde transactie afgeschoten.

Hier zouden denk ik veel mensen intrappen aangezien je in je vertrouwde omgeving zit, URL klopt en groene balkje wordt getoond. Plus als het een beetje goed gestyled wordt, ook nog geloofwaardig overkomt.

[Verwijderd]

Hoe hebben ze het dan voor elkaar gekregen om het gebruik van TAN-codes te omzeilen?

Edit: ij > ei

Eerst maakte SPYEYE screen shots, en moest men meekijken.
Zie video hier op Tweakers.
video: Demonstratie: hoe gaan cybercriminelen te werk?
Nu gaat dat automatisch.
Ik las dit verhaal net op webswereld.

Het High Roller-systeem vraagt echter meteen als de klant inlogt nogmaals om een inlog- of autorisatiecode, bijvoorbeeld met de smoes van 'verbeterde veiligheid'. Vervolgens krijgt de klant een 'Even geduld a.u.b.' melding te zien, die soms uren kan duren. In die tijd worden de laatst ontfutselde codes gebruikt om de frauduleuze transactie te kunnen voltooien.

http://webwereld.nl/nieuw...ing--en-rabo-klanten.html

[stewie]

mensen gaan naar een valse site en blijven tan codes invoeren todat ze kunnen inloggen (20 tan codes later: weg geld)

[Verwijderd]

Dat is niet wat ik lees in het artikel hoor:

gebruikers werd verteld dat er bijvoorbeeld server-onderhoud was, waardoor ze een paar uur of zelfs dagen niet bij internetbankieren konden komen

Daarbij slaagden ze erin om de two-factor authentication van banken te omzeilen.

Het is dus niet dat de gebruikers zelf de codes in hadden gevoerd bij het inloggen (bij de ING moet je überhaupt niet met tan-codes, die heb je pas nodig bij het uitvoeren van een transactie). De hackers hebben het dus weten te omzeilen, terwijl dat juist de verdediging is tegen fraude. Ik ben ook wel heel erg benieuwd hoe ze dit zomaar hebben kunnen doen.

[Lupo1989]

In Spanje is dit al lange tijd ooit eens omzelen. Ze hacken de mobiel en pc. Hierdoor konden ze op de achtergrond inloggen, transactie doen en sms ontvangen. Hierdoor is het dus mogelijk om volledige transactie te doen op de achtergrond. Je hebt er veel voor nodig maar het is degelijk mogelijk.

Kaspersky: Dissecting the Banking Malware Problem

[Verwijderd]

Eindelijk iemand die goed leest. Zij hebben die laatste beveiliging omzeild volgens het artikel en ik ben ook benieuwd hoe, want dit laat zien dat het systeem dus absoluut niet waterdicht is. Hoe wil men trouwens aantonen, of men "te goeder trouw" is- als je geen enkele controle hebt, over wat er gebeurt en de TAN-security omzeild kan worden, without any notice? Ik denk dat de ING er beter a priori vanuit kan gaan, dat alle bedragen naar de bekende dubieuze nummers gewoon fraude zijn, dit bespaart de klanten weer een hoop ergernis inzake hun onschuld te bewijzen. Tijd voor nieuwe Staats-steun, met deze beroving

[biglia]

Ik ken het systeem van tan codes niet. In België wordt er voor het inloggen al een andere code gegenereerd dan om bijvoorbeeld een overschrijving te doen. Dat lijkt me toch iets veiliger.

[mjtdevries]

Het TAN code systeem is een vorm van "one time pad"
Cryptografisch gezien is dat het veiligste wat er bestaat. Je moet alleen wel zorvuldig met de TAN codes omgaan.
http://nl.wikipedia.org/wiki/One-time_pad

Daar zit het risico. als je iemand zover krijgt dat ie TAN codes afgeeft terwijl er geen betaling is, dan kan je die code eenmalig misbruiken.

Maar daar lijkt hier geen sprake van te zijn.

[Reactie gewijzigd door mjtdevries op 23 juli 2024 03:26]

[Manu_]

Heb je die pagina zelf doorgelezen? Dit heeft echt helemaal niets met one-time pad te maken. Bij OTP gebruik je een key van dezelfde lengte als de plaintext en krijg je de cyphertext door bitwise XOR op de plaintext en key toe te passen.

De TAN codes zoals ING ze gebruikt is een voorbeeld van het gebruik van een out of band channel voor authenticatie.

[mjtdevries]

De cruciale aspecten van een one-time-pad zijn niet de lengte van de key, maar het feit dat de sleutel werkelijk willekeurige tekens moten zijn, dat ie maar één keer gebruik mag worden en dat er maar twee kopiën mogen zijn.
TAN codes voldoen volledig aan die drie eisen.

Je hebt niet perse een key nodig die net zo lang is als je tekst om een super veilige encryptie te bereiken.
In 1881 was dat wel de gebruikte methode, maar toen hadden we ook nog wat minder computers....

TAN codes zijn zeker niet per definitie een out-of-band channel. Je kunt ze namelijk zonder SMS gebruiken, gewoon het simpele papiertje. En dan is er dus geen out-of-band channel.

Een TAN code via SMS zou je een one-time-password kunnen noemen. Wat overigens ook met OTP word afgekort om het lekker verwarrend te maken

[Reactie gewijzigd door mjtdevries op 23 juli 2024 03:26]

[Manu_]

TAN codes zijn inderdaad niet per definitie OOB, maar TAN codes via SMS zijn wel een voorbeeld van een out-of-band channel, ze worden zelfs als voorbeeld genoemd.

Bij one-time-pad is het wel degelijk belangrijk dat de key even lang is als de plaintext. Alleen dan kan het information-theoretically secure zijn. Als je key minder lang is moet je hem gaan hergebruiken, en dan kun je je sleutel eruit 'XORen'.

Each bit or character from the plaintext is encrypted by a modular addition with a bit or character from a secret random key (or pad) of the same length as the plaintext, resulting in a ciphertext

(wiki)

TAN codes kun je gewoon echt geen one-time pad noemen.

[Reactie gewijzigd door Manu_ op 23 juli 2024 03:26]

[Jaco69]

TAN codes komen toch altijd "out-of-band"?
Is het niet via SMS dan is het via de post.

[Verwijderd]

Is dat ook bestand tegen man in the middel attack?

En als het systeem van de gebruiker is geinfecteerd kan je dan nog veilig zijn?

Daarom vind ik dat in dit soort berichten ook best het OS genoemd mag worden van de slachtoffers, zodat we weten welke systemen het kwetsbaarst zijn.

Waren het Linux gebruikers?
Waren het OSX gebruikers?
Waren het Windowsgebruikers en zo ja welke versie?

[Reactie gewijzigd door Verwijderd op 23 juli 2024 03:26]

[mrdemc]

In het geval van een MITM-attack heeft het OS van de gebruiker weinig relevantie. Dit kan ook vanuit de router bijv. ingesteld worden en op elk willekeurig OS, etc.
zoals ik het hier zie is het een vorm van MITM doordat de virus een code implementeerd in de echte bankwebsite client-side en zo ook waardes kan vervangen door andere waardes.
Het verschil met tan-codes en de edentifier (zo noemt de abn het, is een apparaat dat de code genereerd) is zover ik weet flink qua beveiliging. Zo zijn de gegenereerde codes afhankelijk van de hoogte van het bedrag. Danwel, bij gebruik van de tan-code ontvangt de gebruiker een sms met daarin de hoogte van het over te maken bedrag (verschil zou dus zichtbaar moeten zijn) en bij de ABN zie je dit niet als de site onderschept wordt en wordt aangepast aan wat de gebruiker verwacht te zien. Ik dacht dat bij de rabo op het apparaat zelf ook een bedrag zichtbaar werd, weet het niet zeker. Weet ook niet hoe het zit met de edentifier2 van de ABN.

[? ?]

Een MITM kan eenvoudig gebroken worden door punt 2: meerdere systemen. Dan moeten ze al voor 2 verschillende systemen een MITM doen = heel moeilijk.

Hun redenering is echter als volgt: de onkosten van hacking < kosten voor ombouwen systemen en kosten voor de ingewikkeldere procedures.

Want dan moeten ze meer personeel in dienst nemen om het telkens aan iedereen uit te leggen. Het is dus hun eigen dikke schuld. Trouwens, als ik even Computer Security (Dieter Gollmann) mag gebruiken.

1. Hoe gaan we spoofing attacks tegen: door het aantal foutieve login pogingen te tonen.
Doen banken dat? Neen. Zouden ze het kunnen? Tuurlijk: elke keer er iets verdacht gebeurt een SMS of mail of dergelijke. Mijn bank gebruikt zelfs de knoppen M1 en M2 op de cardreader door elkaar. Terwijl sommige banken M2 exclusief gebruiken om zich aan te melden (zoals het hoort , of is het nu omgekeerd)

2. Multiple authentication channels: het breken van een systeem dat op verschillende kanalen werkt is minstens dubbel zo moeilijk. Na elke overschrijving een bevestiging vragen of de kans geven om te annuleren via een ander kanaal. Bijvoorbeeld via SMS. Het feit dat SMS redelijk makkelijk uit de lucht te halen is een negatief punt, maar er is toch een netto meerwaarde. De aanvaller moet namelijk al in de buurt zijn en nog eens SMS kraken ook. Maar dat kan ook via een smartphone met beveiligde applicatie gebeuren. Het gaat erom dat er twee verschillende kanalen zijn. Als het ene gehackt wordt (bv. computer) en het andere niet, is er nog steeds een veiligheid.

Al die technici weten dat en deze principes zijn al bekend sinds de jaren 1960... Het management zal wellicht gewoon de extra kosten niet willen maken of de 'ongebruiksvriendelijkheid' niet willen.

Maar als klant mij verantwoordelijk stellen? No way.
Trouwens hoe moet ik (als ITer) weten hoe lang hun sessie loopt? Als ik me authenticeer via M1 en de website zegt dat mijn response foutief is, kan die in principe gebruikt zijn in een authenticatie van de hacker. Hoe lang moet ik wachten om nog een authenticatie te doen? Deze informatie staat nergens, dus kan je het mij niet kwalijk nemen als ik na een foutieve poging het nog eens probeer.

En ja in dit voorbeeld kan er gerust een groen slotje staan naar de bankwebsite.
Conclussie: de banken hebben er als enige schuld aan en het kan hen niks schelen

[Bonez0r]

@Fastman, punt 2:
Voorbeeld van een ING klant. Gebruiker logt door phishing of een virus in op een nep-banksite --> dief heeft nu dus username en wachtwoord. Klant vermoedt nog niks en gaat een betaling doen. Dief krijgt de opdracht van de klant binnen en geeft deze door aan de echte bank, alleen het doel rekeningnummer verandert hij. Bank stuurt een sms met tan code die de klant ontvangt en netjes invoert op de nepsite. Dief gebruikt deze weer om zijn eigen transactie te bevestigen.

Ik heb net even in mijn eigen smsjes gekeken, er staat wel een bedrag in, maar geen rekeningnummer of naam van de begunstigde. Zolang de dief de bedragen niet verandert zou het dus onopvallend kunnen gebeuren.

[? ?]

Dat is een voorbeeld van hoe het niet moet, ze kunnen ten minste een rekeningnummer meesturen. Nog beter zou zijn om via SMS een code te sturen, gewoon 4 cijfers.
En de gebruiker dient deze dan terug te SMSen om te bevestigen. Lekker ingewikkeld allemaal, maar het is een keuze met consequenties.

Dan zou een aanvaller al de telefoonnummer van de klant moeten weten, de sms moeten kunnen onderscheppen (kan als hij in de buurt is) en een valse sms sturen (makkelijk). Vooral de nabijheid vormt dan een probleem. Maar dan moeten ze je adres nog weten en juist op die moment dat jij een bankzaak doet kamperen in de buurt.

100% veilig bestaat niet, maar zoals ik al zei: wat is een paar miljoen euro voor een bank? Waarschijnlijk hebben ze meer kosten aan stelende werknemers dan aan hackers.

[BeosBeing]

Als men het algoritme van de randomreader, e.dentifier of ander dergelijk apparaat kunt achterhalen, dan heb je als bank en als gebruiker een probleem. Vervang maar eens op korte termijn al deze apparaten bij de gebruikers.

Bij een systeem zoals TAN heeft ING in ieder geval zowel het code-genereren als het verifiëren in eigen hand. Mocht dat gekraakt worden, dan is het systeem wel in korte tijd aan te passen. Uiteraard heeft ook dat systeem zijn zwakheden.

[L-VIS]

Het zal ongetwijfeld Windows zijn, niet omdat het onveilig is, maar omdat het een grote gebruikersgroep heeft. Denk maar na, als maar 1% van de aanvallen slaagt heb je het liefst een zo groot mogelijke groep!

[jqv]

Waarom Windows?
Dat is een aanname die jij niet kunt staven met de grootte van de groep.

Dat Windows een kwetsbaarder systeem is dan andere apparaten als Android, iOS, Linux en MACos, maar dat nog geen zeker verhaal.
Het gaat hier namelijk om de gebruiker en niet om het apparaat.

Ik kan ook een aanname doen dat het vooral Linux en MAC OSx gebruikers zijn, omdat deze namelijk geen benul hebben van beveiliging. Hun systeem is namelijk zelden slachtoffer van aanvallen. Dat maakt deze groep juist kwetsbaarder.

En ook die theorie rammmelt van alle kanten.

[mtsr]

Geen aanname, beide genoemde trojans, SpyEye en Zeus, zijn Windows only.

[BeosBeing]

Er worden in het artikel 2 trojans genoemd: ZeuS en SpyEye.
De OSsen waarop deze trojans werken staan niet in het artikel maar in artikelen zoals deze op security.nl wordt wel verwezen naar Microsoft.

De kans dat één specifieke trojan versies heeft voor totaal verschillende besturingssystemen is erg klein.

[Verwijderd]

Waarom Windows?
Dat is een aanname die jij niet kunt staven met de grootte van de groep.

Waarom zou ik op linux mikken? Als je meer marktaandeel hebt ben je ook een beter doelwit.

Dat zegt L-VIS ook, het is niet voor niets dat je bijvoorbeeld nu malware voor android ziet komen. Je wilt voor je malware immers een zo groot mogelijke doelgroep hebben zodat als 1 % van de gebruikers aan je truc ten prooi valt je nog steeds een mooi aantal te pakken hebt.

[jqv]

Het gaat er niet om wat je kiest, maar wat er gesuggereerd wordt door L-Vis.

Hij geeft iets weer als zijnde een feit zonder deze te onderbouwen met bewezen argumenten.

"Het zal ongetwijfeld Windows zijn, niet omdat het onveilig is, maar omdat het een grote gebruikersgroep heeft."

Dat er een grote kans is dat het gros van de slachtoffers een Windows-apparaat hebben gebruikt, betekend nog niet dat iedere slachtoffer het slachtoffer is geworden door een windows PC.

[Cybergamer]

Volgens mij is het OS onafhankelijk. Herinneren jullie die special nog van Tweakers.net?

[mad_max234]

Windows 7 is beter beveilig dan osx hoor, althans volgens de kenners, zins vista doet windows niks onder voor linux. Win ligt alleen dag en nacht onder vuur door duizenden hackers, daar zijn de pijlen op gericht. osx krijgt er nu langzaam ook last van, maar is nog lang niet het hoofddoelwit van virusschrijvers.

En zeus is een win only virus, dat doet het niet op osx of linux, dus grote kans dat het win gebruikers zijn. Komt omdat er veel kennis is vergaard is van Windows systemen en dat die kennis steeds word doorgegeven 7. Virussen worden doorgegeven en aangepast, vaak is er niet genoeg kennis om zelf virus op te zetten, zijn meestal niet de beste programmeurs. Maar stukje bij beetje verbeteren ze anders mans werk en krijgen ze het voor elkaar om virus te maken die veel kwaad kan doen. Hackers zijn erg goede na-apers en vaak maar slechte of middelmatige programmeur. Zit er dan eentje bij die de basis heeft gelegd en daar maken veel hackers gebruik van die het anders niet voor elkaar hadden gekregen.

[latka]

Windows 7 is beter beveilig dan osx hoor, althans volgens de kenners, zins vista doet windows niks onder voor linux.

Ik zou graag referenties hiervan zien, zover ik weet is dit niet correct.

[mad_max234]

Is dat ook bestand tegen man in the middel attack?

En als het systeem van de gebruiker is geinfecteerd kan je dan nog veilig zijn?

Nee natuurlijk niet, artikel niet gelezen? Zeus gebruikt nu juist man in the middle attack, laat je inloggen op een andere pagina waarmee de aanvaller(in het middel, tussen gebruiker en bank) toegang krijgen tot de echte site. Tan doet daar niks tegen, die zie gewoon dat er gebruiker is ingelogd met geldig tan code. Tan doet sowieso niks tegen dit soort aanvallen, hoe lastig de code zelf te kraken is is hier helemaal niet van toepassing want word gewoon met geldig code ingelogd en word niks met de code gedaan, ze doen nog niet eens een poging om tan te kraken want is niet nodig.

[Standeman]

Tan doet heel veel tegen dat soort aanvallen. Bij elke code staat ook het bedrag genoemd zodat je het kan controleren.

De enige manier waarop dit niet werkt is wanneer je met tan-lijsten werkt.. Dus vast staande codes..

[SiC123]

maar die worden semi-random gevraagd, niet op volgorde. Je hebt dus wel een lijst met 100 codes, maar de phising site weet niet welke er nodig is. Is wel een heel kleine kans dat de juiste code gegeven wordt.

[.oisyn]

Ze worden dus wél op volgorde gevraagd. Bij elke tancode staat een volgnummer (of je het nou per SMS doet of via het papiertje), die is gewoon oplopend.

[BeosBeing]

De laatste keer dat ik het met zo'n lijst geprobeerd heb, vroeg hij de code in een willekeurige rij en kolom, dus niet op volgorde.

Wat mad_max234 aangeeft klopt wel, een site die inloggegevens de inloggegevens en de TAN ontvangt kan zelf de rekeningnummers aanpassen. De TAN-sms geeft alleen het totaalbedrag. Zou je daar meer gegevens bij willen zetten, bv rekeningnummers, dan moet je echter per overschrijving een sms sturen (onhandig) of je moet meerdere rekeningnummers in één sms zetten waarbij je het risico loopt dat de sms meer dan 150 tekens wordt.

Echter men kan alleen bedragen wegsluizen die de de gebruiker zelf opgeeft en men moet de opgegeven overschrijvingen terugmelden in plaats van de gemanipuleerde die de originele site weer zal geven, ook als de gebruiker nogmaals inlogt. Logt die in vanaf een ander systeem dan wordt de manipulatie ook gemerkt.

Met de inloggegevens kan men echter ook eenvoudig het mobiele nummer aanpassen waarnaar de TAN-sms gestuurd wordt dus op het moment dat de site is gefaked staat de rekening open.

Wordt echter het algoritme van randomreader of e.dentifier gekraakt dan ben je veel verder van huis, want dan liggen alle rekeningen bij een bank open en die kan er niets tegen doen. Gezien die apparaatjes werken op een klein batterijtje kan dat algoritme niet al te moeilijk zijn, en omdat de e.dentifier versie 2bij het inloggen niet meer vraagt voor het invoeren van een code die de website opgeeft, kan er in de response geen pin-code ingevoerd zijn Parameters zijn dus enkel bank- en pas-nummer (beide vast) en de tijd. Dat algoritme moet dus een stuk makkelijker te kraken zijn als dat van de eerste e.dentifier.

[Countess]

Is dat ook bestand tegen man in the middel attack?

En als het systeem van de gebruiker is geinfecteerd kan je dan nog veilig zijn?

je krijg enkel een tan code toegestuurd (via SMS) als je een transactie start, en bij de tan code staat het totaal bedrag van de transacties em het volg nummer.

als daar dus ineens 1000 staat ipv 15,95 dan is er iets mis.

[Verwijderd]

Virtueel machientje of Knoppix CD o.i.d. en daarmee bankieren is de meest veilige manier voor internetbankieren

[Rey Nemaattori]

Ik ken het systeem van tan codes niet. In België wordt er voor het inloggen al een andere code gegenereerd dan om bijvoorbeeld een overschrijving te doen. Dat lijkt me toch iets veiliger.

Alleen de ING gebruikt tan codes in nl, alle andere banken hebben gewoon 't random reader systeem...

[SuperDre]

de betalingssite wordt onderschept, en compleet nagebootst (inclusief het ophalen en tonen van de tan), alleen ipv jouw bedrag door te geven, geven ze dus hun bedrag door.

[Fireshade]

de betalingssite wordt onderschept

En dit is de basis die dit hele gebeuren mogelijk maakt.
Zoiets is een hele knappe prestatie. Jammer dat het zomaar kan.
Ik neem aan dat het niet gedaan wordt door een domme tikfout in de URL. Je zou zeggen dat op z'n minst in de servers van de banken gehacked is om de onderschepping mogelijk te maken.

[Verwijderd]

Ja das dom + dat bij tancodes t bedrag staat wat overgemaakt wordt bij de transactie.

[basvd]

Zoals vermeld in 2e alinea, het gaat om zakelijke gebruikers. Een bedrag van 550 euro valt waarschijnlijk minder snel op bij bijvoorbeeld een (totaal)transactie van €18.432,-

[mrdemc]

Dan nog zou je het verschil moeten zien. Als het goed is heb je namelijk zelf nog een overzicht van het totale bedrag en zul je ook dan controleren of je niet teveel overmaakt. Of je nu een bedrijf of particulier bent, in beide gevallen zul je het liefst zoveel mogelijk geld zelf willen houden en als je dan bij elke transactie bijv. een euro te veel overmaakt omdat je het niet controlleerd en je hebt zo'n 10.000 transacties per maand, is dat toch een inkomstenderving van 120.000 euro per jaar...

[cire]

Tja, vorig jaar was er ook een aanval op ING gebruikers. Zelfs als er 90% van het bedrag van hun betaalrekening werd afgeschreven hadden mensen het niet in de gaten, terwijl het bedrag gewoon in de SMS staat. Het systeem is zo sterk als de zwakste schakel en dat willen nogal eens de gebruikers zijn

[Reactie gewijzigd door cire op 23 juli 2024 03:26]

[Rey Nemaattori]

Ik zou zweren dat nu ze zowel pasnummer controleren alsmede het over te maken bedrag meenemen de random reader berekening, dit soort praktijken niet langer mogelijk was?

Je kan nooit 2500 euro overschrijven met een RR code van een andere transactie(nooit gekund overigens, vanaf 1000 euro oid zat het bedrag sowieso in de berekening van de key)?

[The Zep Man]

Je kan nooit 2500 euro overschrijven met een RR code van een andere transactie(nooit gekund overigens, vanaf 1000 euro oid zat het bedrag sowieso in de berekening van de key)?

Een voorbeeld over hoe gewerkt kan worden.

Gebruiker denkt net ingelogd te zijn via de normale inlogprocedure bij de Rabobank en krijgt vlak na het inloggen het volgende bericht:

"Welkom bij Rabobank. Door onze nieuw geintroduceerde beveiligingsmaatregelen controleren wij nu nog strenger. Deze extra signeerstap voeren wij eens per week uit. Voer de volgende stappen uit met uw Random Reader om in te loggen:

1. Voer uw bankpas in.
2. Druk op S (Signeren).
3. Voer de volgende cijfers in: xxxx xxxx
4. Druk op OK.
5. Voer de volgende cijfers in: 2476
6. Druk op OK en nogmaals op OK.
7. Geef de waarde op die op uw Random Reader verschijnt: ____________
8. Klik op Inloggen om door te gaan."

Na het volgen van deze procedure wordt op de achtergrond 2476,68 euro overgemaakt naar een rekening waar Rabobank geen controle over heeft. De gebruiker wordt doorgestuurd naar een onderhoudspagina of naar een gesimuleerde omgeving waarin de eerdere transactie niet te zien is.

Met andere woorden: alle benodigde variabelen zijn bekend bij de aanvaller. Dit zijn het bankrekeningnummer, nummer van de pas en Random Reader identificatie welke eerder verkregen zijn bij het inloggen van de gebruiker via een omleiding naar een eigen pagina, en de handshake voor de transactie (inclusief het extra controlegetal wat het hele bedrag is in gehele euro's, naar beneden afgerond).

[Reactie gewijzigd door The Zep Man op 23 juli 2024 03:26]

[nIghtorius]

Maar een goed oplettende gebruiker (helaas zijn dit niet allemaal).. ziet het feit dat men het "S"(Sign)/Onderteken toets moet gebruiken om in te loggen.. Dit is sowieso niet goed. Het moet altijd de "I"(Inloggen) zijn.

Maar dit grapje vind ik wel dat het beter naar de klant gecommuniceerd moet worden. Veel mensen begrijpen het verschil tussen I en S niet. Die doen maar wat.

Sowieso als er een "extra" controle komt na het inloggen gaat er bij mij de paranoia modus actief..

[majoh]

Sowieso als er een "extra" controle komt na het inloggen gaat er bij mij de paranoia modus actief..

Ik denk dat veel mensen, hier in zullen trappen. Aangezien je in je vertrouwde omgeving zit. URL in je browser klopt. Groene balkje van goed certificaat aanwezig is. Wat is hier niet aan te vertrouwen? Zeker als de site je niet verder laat gaan voordat je deze handeling gedaan hebt.

Natuurlijk zullen heel wat mensen dit niet vertrouwen en bellen. Maar ik denk dat de gros van de gebruikers denkt: "Hé ik zit op de bank website, dus het zal wel."

[Verwijderd]

Echter. Bij die onderhoudspagina ontbreekt de "s" bij "https:\\"

[The Zep Man]

Maar een goed oplettende gebruiker (helaas zijn dit niet allemaal).. ziet het feit dat men het "S"(Sign)/Onderteken toets moet gebruiken om in te loggen.. Dit is sowieso niet goed. Het moet altijd de "I"(Inloggen) zijn.

De massa weet dit niet en 'letten niet goed op', en dat is nou net de doelgroep.

Maar dit grapje vind ik wel dat het beter naar de klant gecommuniceerd moet worden. Veel mensen begrijpen het verschil tussen I en S niet. Die doen maar wat.

En als de klant niet wilt luisteren?

Sowieso als er een "extra" controle komt na het inloggen gaat er bij mij de paranoia modus actief..

Waarmee jij aangeeft dat jij (een individu) geen onderdeel bent van de doelgroep. Goed om te weten, nutteloos voor de probleemstelling.

[albatross]

En dus had Rey gewoon gelijk: zonder (grove) denk/lees fout van de gebruiker is het bij de Rabobank niet mogelijk om met je S code in te loggen.

[Mr_gadget]

Dat vraag ik me ook af idd. Maar het virus kan natuurlijk achter de schermen gewoon een transactie van 2500 euro aanvragen terwijl jij op je scherm te zien krijgt dat je 25 euro overmaakt.

[martijnnos]

Daarom typ je dat ook juist in je RR er zal wel een andere code uitkomen als je een ander bedrag in typt mag ik hopen

[elTigro]

ja.
de tweede code die je in de RR intypt is altijd het bedrag. Als je dus 25 euro ziet staan, en op de achtergrond 2500 moet worden overgemaakt is je 2e code dus 2500. (staat ook op de pagina die je ziet als je dit moet gaan intypen)
als je dat gaat intypten terwijl je maar 25 euro wilt overmaken zou je moeten weten dat het niet in orde is.

Zou. Maar niet iedereen is zo kundig in deze zaken. Ouderen of mensen die al niet handig zijn met computers zullen dus sneller het slachtoffer worden dan mensen die niets of niemand vertrouwen en alles altijd al zelf uitzoeken.

Maareh?
35 miljoen over 5k rekeningen? dat is meer dan 2500 per rekening hoor

[stresstak]

35 miljoen over 5k rekeningen? dat is meer dan 2500 per rekening hoor

Er staat gemiddeld 2500

[Sentienel]

Hoe kan het gemiddelde van 35 miljoen / 5k = 7000, dan 2500 zijn? Succes.

[Toettoetdaan]

Klopt, in ieder geval is dat zo bij de Rbank.
Wel opvallend dat dat sinds deze week ook bij kleinere bedragen vereist is...

[airell]

Het zal niets verbazen als de rabo de 'blackouts' van de afgelopen keren zelf hebben veroorzaakt om zo snel veiligheidspatches door te voeren. Zoals je zegt, er was 'ineens' het vereiste van extra handeling met de RR (het bedrag invoeren namelijk) toegevoegd.

[SCS2]

Dat van het bedrag was keurig vooraf aangekondigd bij de mededelingen.

[Poekie McPurrr]

Die wijziging dat het ook bij kleine bedragen nodig is is ingevoerd eind mei/begin juni

[Stoffel]

Dat snap ik dus ook niet. Zeker dit:

"The malware defeats this authentication by generating an authentic simulation of this process during login to capture the token. To allay suspicion, the script collects the token as the user logs in, rather than during the transfer authorization process. It then uses the digital token to validate the transaction later in the online banking session while the user is stalled with a “Please Wait” message."

is gewoon niet mogelijk bij in ieder geval de Rabobank, want de code om in te loggen kan helemaal niet gebruikt worden om transacties goed te keuren. Ik neem aan dat het bij andere banken vergelijkbaar werkt.

[T i M]

Het lijkt mij onmogelijk dat de beveiliging met bijvoorbeeld de random reader is omzeilt. Dat zou betekenen dat de implementatie bij de bank zelf niet in orde is en dat lijkt me erg onwaarschijnlijk. Kan me voorstellen dat de hackers de gebruikers hebben gevraagd om bijvoorbeeld een TAN code.

[Moartn]

Onderschat dit soort trojans niet: ze kunnen bijvoorbeeld je browser manipuleren. Wat ze bijvoorbeeld kunnen doen is dat jij gewoon een normale overboeking doet, en zodra je die verstuurt even snel het door jouw ingevulde rekeningnummer vervangen door hun eigen nummer, ook in het bevestigscherm wat daarna volgt. Dan hoef je helemaal geen enkele beveiliging te omzeilen. Een trojan op de PC van de gebruiker krijgen is voldoende.

[edit]
Hetzelfde kunnen ze natuurlijk doen met het bedrag. Je boekt een bedrag van 10 euro over naar rekening 123, maar omdat je browser gekraakt is verstuur je stiekem een bedrag van 10000 over naar rekening 321, zonder dat je het ziet. Het probleem zit niet aan de kant van de bank, het zit op de PC van de gebruiker.

[Reactie gewijzigd door Moartn op 23 juli 2024 03:26]

[NovapaX]

Ik denk dat over een tijdje de banken meer moeten werken met server-side gegenereerde afbeeldingen. Het wordt dan opeens een stuk minder triviaal om een pagina te manipuleren....

[Keypunchie]

Hoezo? Of je nou tekst of een afbeelding moet manipuleren als "man-in-the-browser", de vector (trojan) blijft hetzelfde.

[NovapaX]

Ik zeg ook alleen dat het een stuk minder triviaal wordt om ongemerkt de pagina te manipuleren.
Nu is er bij wijze van spreken niet meer dan een beetje Javascript nodig... dan moet je aan de gang met (onbetrouwbare) OCR libraries en image-manipulation om de getallen in de afbeelding te wijzigen.

Het kan natuurlijk wel, maar daarmee wordt het gewoon wat minder makkelijk...

Ik denk alleen persoonlijk dat er op den duur een move gemaakt wordt naar native apps die via de verschillende betrouwbare App-stores & repo's (van windows en mac en linux) te downloaden zijn. En dat de web-based variant van internetbankieren standaard afgesloten zal worden.

Eerst je computer koppelen (met certificaat o.i.d) aan je bankrekening.
Ook kun je dan DNS overslaan.... en het checken van het server-certificaat door de app laten doen en niet op de gebruiker hoeven vertrouwen dat deze wel even de groene balk controleert.

Mensen zijn nu toch onderhand wel gewend dat ze ergens even een app voor installeren...

[Reactie gewijzigd door NovapaX op 23 juli 2024 03:26]

[Vircos]

Dan zou de bank (bijvoorbeeld Rabobank) als 3e code het rekeningnummer van de begunstigde mee moeten nemen tijdens het signeren. Op die manier kan het rekeningnummer wel gemanipuleerd worden binnen de browser, maar zal de gegenereerde signeercode niet meer overeen komen met de gemanipuleerde transactie gegevens om de transactie te kunnen verifiëren.

Edit: typo

[Reactie gewijzigd door Vircos op 23 juli 2024 03:26]

[Sjaaky]

Dat doen ze ook, maar vanaf een bepaalde grens. Ben deze een keer tegengekomen, maar weet niet meer waar de grens precies ligt. Bij meerdere betalingen in 1x wordt dan de begunstigde gepakt waarnaar je het hoogste bedrag overmaakt.
Als je meer dan 1 betaling signeert, zou een trojan wel de rekeningnummers van de kleinere bedragen aan kunnen passen.

[YDh]

Veel banken vragen voor een bedrag dat hoger is dan 1000 euro een extra bevestiging. Als je even 10 euro wou overschrijven en iemand veranderde dat naar 10000 euro, dan zie je dat dus en zal het niet werken.

Ook zit er tussen de initiatie van de betaling en de effectieve betaling meestal meer dan 1 scherm. De bank heeft dus al het rekeningnummer naar waar je wilt overschrijven en stuurt dat ook nog eens terug. Natuurlijk kan goeie malware dat wel onderscheppen en aanpassen.

Daarnaast is er natuurlijk nog de certificaatcontrole van je browser. Ik weet niet of er al malware is die die omzeilt. Persoonlijk let ik er toch op dat het certificaat correct is als ik naar de site van mijn bank ga, maar ik geef grif toe dat de gemiddelde gebruiker dat wellicht niet doet.

Misschien ben ik paranoia maar als er iets mis loopt tijdens mijn transactie (bijvoorbeeld mijn response code is incorrect) dan log ik altijd uit en sluit mijn browser. Daarna probeer ik het opnieuw in een nieuwe browserinstantie.

[ViperNL]

Dat lijkt me dan juist weer niet. Een tancode is niet om in te loggen, alleen om te betalen. In je sms staat dan ook een bedrag.
Het zou misschien wel kunnen als ze de gehele site nagemaakt hebben en dan alle overschrijvingen naar een andere rekening sturen.

[Verwijderd]

"Nederlandse bankklanten slachtoffer van miljoenenhack"

Zijn hier de slachtoffers de bank of de klanten? lijkt mij dat de ING dit vergoed.

[Verwijderd]

Er staat nergens in het artikel dat het om ING gaat.

uit het artikel:

Woordvoerder Daan Heijbroek van ING, de grootste bank van Nederland, kan niet bevestigen of ING-klanten slachtoffer zijn geworden. Als ze dat zijn, wordt de schade in ieder geval vergoed, ook als het zakelijke gebruikers zijn. "We zullen alle zaken op individuele basis onderzoeken", aldus Heijbroek. "Als een klant te goeder trouw is, zullen we de schade vergoeden."

[Verwijderd]

Er staat nergens in het artikel dat het om ING gaat.

Hier wel

Doelwit: ING en Rabo

Vorige week sloeg een ander beveiligingsbedrijf, Trend Micro, al alarm over dezelfde bende en ZeuS-mutant. Trend Micro-onderzoeker Loucif Kharouni bevestigt tegenover Webwereld dat er specifieke code voor ING bank en de Rabobank is aangetroffen. Daarnaast zijn ook banken in Italië, Duitsland en Engeland de klos. McAfee wil geen banken bij naam noemen.

http://webwereld.nl/nieuw...dert-ing--en-rabo-klanten

[schaafkaas]

Het is niet de bank die gehackt is, maar de computers van de gebruikers. De trojan op de computer van de gebruiker toont een namaak internet bankier site, waar de gebruiker zijn codes invoert. De hackers misbruiken vervolgens deze codes op de echte site.

De bank heeft hier dus niks verkeerd gedaan.

[miw]

Erm, de bank voert dan op zijn minst transacties uit die behoorlijk verdacht zouden moeten zijn. Verder kiest de bank het beveiligingssysteem uit om electronisch bankieren te implementeren. Als klant kan je niet voor een andere beveiliging kiezen en ook is het niet mogelijk voor een eindgebruiker om te verifieren of de interactie rechtstreeks met de bank is of via een tussenpersoon (the man in the middle) verloopt. Het enkele feit dat er mogelijk een malware infectie op een PC heeft plaatsgevonden ontslaat de bank niet van zijn plicht om alleen transacties uit te voeren die de eigenaar van de rekening zelf heeft goedgekeurd.

[Herko_ter_Horst]

Zonder de mogelijkheid om gedachten te lezen, weet de bank nooit of de eigenaar van de rekening de transactie heeft goedgekeurd. De bank kan de wil van de gebruiker alleen afleiden uit "circumstantial evidence", namelijk het feit dat de juiste inlog- en transactieverificatiegegevens zijn gebruikt.

Aangezien deze malware gebruik maakt van precies die gegevens (door de gebruiker te verleiden tot het invoeren hiervan), zijn deze voor de bank niet te onderscheiden van "echte" gegevens, want het zijn echte gegevens.

[Reactie gewijzigd door Herko_ter_Horst op 23 juli 2024 03:26]

[BeosBeing]

Men kan wel detecteren of er geld overgemaakt wordt naar dubieuze rekening-nummers.
Als een gebruiker meld dat hij slachtoffer is geworden van phishing, dan kan de bank de rekeningnummers waarnaar zijn geld is doorgesluisd ook voor andere rekeninghouders blokkeren.

Uit jouw woorden leid ik af dat de bank die rekeningnummers niet kan onderscheiden van goede maar ik vind het onwaarschijnlijk dat hierop niet gecontroleerd wordt. Uiteraard loopt men net als bij malwarescanners op pc's altijd achter de feiten aan.
Dat is ook de enige geldige reden dat banken tegenwoordig om legitimatie moeten vragen als je een rekeningnummer opent.

Onze overheid is echter veel meer geïnteresseerd om all rekeningen van van alle belastingplichtigen te kunnen traceren, banken hangen liever de vuile was niet buiten en de politie moet vooral snelheidsboetes binnenhalen om de staatskas te spekken en moet verder voor ieder wissewasje stapels rapporten schrijven zodat effectief onderzoek naar echte criminelen onmogelijk wordt. Omdat het voor de staat veel oplevert is er echter behalve verkeersboetes ook steeds meer aandacht voor uitkeringsfraudeurs*.

offtopic:
*Veelal zijn dat echter mensen die na het vinden van een baan niet hebben gemeld dat ze aan het werk zijn om het simpele feit dat ze eerder beginnen en later klaar zijn als de kantooruren waarbinnen ze dat kunnen melden en dat inkomende mobiele gesprekken door die instanties geblokkeerd worden.

[cire]

Wat zou je laatste zin in de praktijk dan moeten betekenen?

Je zou ook kunnen beweren dat een auto fabrikant alleen auto's mag maken die nooit een ongeluk krijgen... uiteindelijk schiet je daar niet veel mee op.

[mrc4nl]

Degene de een rekening hebben bij de bank natuurlijk,Het is hun rekening, dus zij zijn slachttoffer.Dat het bedrag vergoed wordt maakt het er niet minder op.De bank is er de dupe van, want die moet vergoeden.

[Verwijderd]

En die vergoeding wordt weer bij de klanten verhaald.

[mashell]

Natuurlijk niet. De bank heeft daar een potje voor. Ze maken de kille rekensom tussen investeren in betere beveiliging en schadevergoedingen betalen. Hebben ze ook gedaan met de magneetstrip, banken hebben de invoering van pinnen met de chip bewust jaren uitgesteld.

[Tijger]

Duh, er is altijd een afweging tussen de kosten van security (en dan niet alleen financieel) en van eventueel risico.

[Verwijderd]

En waar denk je dat potje van gevuld wordt?

[Verwijderd]

..door bij iedereen een tientje van de rekening te halen?

[Verwijderd]

..door bij iedereen een tientje van de rekening te halen?

Weleens van verzekeringen gehoord? Banken zijn ook verzekerd.

[cire]

Verzekerd of niet, uiteindelijk betalen de "gewone" klanten voor dit soort vormen van fraude. Echter extra beveiliging bouwen kost ook geld, dus ergens houdt dat ook op natuurlijk...

[vinkjb]

Lezen lijkt me, de bank vergoed staat er.

[ATS]

Lijkt me alleen als het je als klant opvalt, en dan contact opneemt met de ING...

[Verwijderd]

Als er zo'n lijst is, wat ik me af vraag, kunnen ze beter die personen individueel benaderen. Lijkt me, zeker gelet op de privacy van de klanten, onzin om zo'n lijst voor iedereen beschikbaar te maken.
Het is voor een bank ook een nadeel, want dan weet iedereen gelijk om hoeveel rekeningen het gaat, dit kan ook voor veel publiciteitsschade leiden.

[Verwijderd]

Is dit een grapje of een serieus voorstel?

[willempipi]

He wat dom van mij!

Nee het ging er gewoon om dat degene die getroffen zijn op de hoogte worden gebracht.

[Verwijderd]

He wat dom van mij!

Nee het ging er gewoon om dat degene die getroffen zijn op de hoogte worden gebracht.

Onnozel zou ik je opmerking willen noemen.
En je bent bekend met het bestaan van de telefoon enzo
De bank licht nooit iemand in. Je merkt het vanzelf en je moet dan de bank waarschuwen.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 03:26]

[NovapaX]

Zomaar een idee:
Zou het helpen om internetbankieren standaard af te sluiten en over te stappen op native apps voor Windows, Mac en Linux, net als nu al voor smartphones gebeurt?

Er blijven natuurlijk genoeg zwakke plekken bestaan, maar het simpelweg omleiden naar een fake website gaat dan niet meer zomaar werken.

Zeker niet als er nog een certificaat gebaseerde authenticatie toegevoegd gaat worden:
(SSL client certificaat wordt op USB stick meegestuurd met de pincode mee.... je moet het certificaat inladen in de software op die pc voordat je de eerste keer in kan loggen)

Wordt misschien wel wat vervelender, maar bij smartphones moet je nu eerst ook je telefoon 'koppelen' voordat je in kan loggen met je code.
Dus geef het een makkelijke naam, en laat de gebruiker het in drie stappen doen, dan moet het goed gaan: "Koppel eerst deze computer aan je bankrekening met de USB-sleutel die u bij uw bankpas hebt ontvangen"

Ik weet niet genoeg van NFC, maar misschien kunnen we daar wel een extra veiligheidslaag uithalen ipv die certificaten op usb stick.

[majoh]

Er wordt hier niet omgeleid naar een fake website, maar je echte website wordt door het virus aangepast.

Dit kan natuurlijk ook gewoon met native apps, zoalgn het virus kans krijgt om geinstalleerd te worden.

[NovapaX]

Ja, dat zou kunnen...

Maar het verschil is dat browsers ontworpen zijn om die mogelijkheden te bieden... zie bijvoorbeeld de vele extensies die pagina's een andere opmaak geven en ad-blockers.

Eigenlijk is zo'n trojan in dit geval niet veel anders dan een browser-extensie.... zie hier de grens tussen handig en gevaarlijk....

Maar ik vermoed dat diverse beveiligingsmaatregelen in de besturingssystemen en in de app zelf (sandboxing) het een stuk moeilijker maken om in te haken in een native app.

Bovendien zal dan een trojan specifiek gericht moeten worden op een bepaalde app/bank.

[Giesber]

Vroeger bij KBC (Belgische grootbank) kregen we een sleutelbestand dat op een diskette stond (en ook op de harde schijf gezet kon worden). Als dat bestand gewijzigd was, of niet toegankelijk was dan kon je niet inloggen. Dit was een beveiliging naast het wachtwoord van de gebruiker.

Dit is jaren geleden vervangen door een systeem met de bakjes om de bankkaart in te steken.

Ten eerste is het "nieuwe" systeem (het oude wordt al meer dan 5 jaar niet meer gebruikt) een stuk mobieler: het werkt op de meeste PC's die internettoegang hebben, en je hebt gewoon een bakje (mag zelfs van iemand anders of van andere banken zijn) nodig.

Ten tweede is dit volgens mij veiliger: als er virussen zouden zijn die de online banking site zouden manipuleren op de PC van de gebruiker, zou alles mogelijk zijn (in de veronderstelling dat dat virus dan ook wel het wachtwoord kon loggen). Op het moment dat de gebruiker ingelogd was, was het sleutelbestand toegankelijk en kan een virus dus overschrijvingen doen zonder enige verdere input van de gebruiker. Dat het in een native app ipv een website zou gebeuren zou het een pak moeilijker maken voor de hackers, maar ook zeker niet onmogelijk. Eenmaal het programma gekraakt zou alles weer mogelijk zijn.

Nu is er blijkbaar ook misbruik mogelijk, maar het blijft vooralsnog relatief kleinschalig: 35 miljoen, dat is de winst die de Nederlandse banken samen op enkele dagen kunnen maken gok ik? Het potentiële misbruik (als er totaal geen beveiliging was) loopt ongetwijfeld in de tientallen miljarden. Toch een teken dat de huidige beveiligingen redelijk goed werken denk ik. Perfectie is een mooi streefdoel, maar is nagenoeg niet haalbaar.

[arniejj]

Zolang de trojan als administrator aan het werk kan, zal je applicatie niet waterdicht zijn. Dat geldt ook voor mobiele apparaten, waar je op Android bijvoorbeeld als root user kunt inloggen, wanneer je toestel geroot is. Het is dan nog maar kinderspel om transacties te onderscheppen en evt. toetsaanslagen te registreren. Je zou zomaar met de ING app een macro kunnen opnemen om de mobiele pincode te onderscheppen. Concreet zou dat zijn de posities registreren waar de gebruiker het scherm aanraakt nadat de ING app gestart is. Dan kan de hacker zelfs een aanval uitvoeren als het toestel een bepaalde tijd niet gebruikt wordt (bijv. toestel zit in broekzak of het scherm staat uit, maar de applicatie wordt wel geactiveerd).

Sowieso lijkt het mij een minder goed idee om een bank applicatie op een gejailbreakte/geroote telefoon te installeren.