Virus ontfutselt geld aan klanten ABN Amro - update

Klanten van ABN Amro zijn mogelijk het slachtoffer geworden van een gerichte virusaanval waarbij ongemerkt geld overgeheveld wordt naar criminelen. Inmiddels zouden maatregelen genomen zijn om de fraude te voorkomen.

Volgens onze bronnen zou de beslissing geen persbericht uit te zenden, ingegeven zijn door het feit dat het niet om een gewone keylogger gaat die logingegevens probeert te downloaden, maar om een trojan die uniek is in zijn soort.

Roel Schouwenberg van Kaspersky wist ons te vertellen dat de methode van verspreiding nog niet is achterhaald, maar dat besmette systemen blijken bij te houden welke websites bezocht worden, om dit vervolgens door te geven aan een gecorrumpeerde webserver. Als een https-site wordt bezocht, wordt opdracht gegeven om een tweede trojan te downloaden, die als 'traffic logger' functioneert. Deze houdt al het https-verkeer bij, om dat vervolgens ook weer naar de webserver te sturen. Als de webserver melding krijgt van een bezoek aan de ABN Amro-website, wordt een derde stukje malware gedownload dat specifiek voor deze site ontworpen is.

De ABN Amro maakt voor zijn online-bankapplicatie gebruik van een zogenaamde two factor authentication, maar tussen de codes om in te loggen en die om een transactie te bevestigen, zit geen verschil. Hiervan wordt door de criminelen misbruik gemaakt. Met de derde trojan wordt bij het inloggen op de site namelijk de melding weergegeven dat het inloggen mislukt is, terwijl achter de schermen een transactie klaargezet wordt. Door nogmaals een inlogpoging te doen, wordt deze transactie heimelijk bevestigd.

Een woordvoerder van de bank wilde geen commentaar geven. Anonieme bronnen bevestigen aan Tweakers.net dat er daadwerkelijk klanten slachtoffer zijn geworden van de nieuwe aanval. Om hoeveel mensen het gaat is niet bekend. Een oplossing is bij Kaspersky te downloaden.

Update 17.35u: Inmiddels heeft de bank het nieuws bevestigd. Een woordvoerster van de bank liet ons weten dat inmiddels maatregelen genomen zijn om de fraude te verhinderen. Hoe dat gebeurd is, kon in het kader van de veiligheid echter niet meegedeeld worden. Slechts een 'handvol' klanten zou getroffen zijn, aldus de woordvoerster.

Reacties (176)

[Left]

Aan de reacties te lezen heersen er een paar misverstanden:

Ten eerste is dit niet een echte 'man in the middle attack'. Bij een man in the middle attack probeer je contact te leggen met je bank, maar in werkelijkheid wordt je eerst langs een andere computer geleid. Deze kan dan jouw inlogcodes bewaren/ opdrachten veranderen etc.
Een echte man in the middle attack kan voorkomen worden door het ip-adres te checken bij elk contact met de bank. Maar dat kan hier dus niet, want de trojan bevindt zich op de pc van de gebruiker.

Ten tweede: Fraude door een virus als dit is zo goed als niet door de bank te voorkomen. Het enige wat de ABN nog had kunnen doen is een verschillende code types hanteren voor transactiebevestigingen en inloggen. Maar daarmee had het de trojan alleen maar wat lastiger gemaakt, dit systeem was nog steeds te kraken geweest; de trojan had zich gewoon stil kunnen houden tijdens het inloggen en kunnen wachten tot de gebruiker zelf een transactie wou uitvoeren, om dan de transactiecode te gebruiken voor een eigen transactie.

Tenslotte: Op de internetbanksite van de ABN staat al een hele tijd een waarschuwing voor dit virus, samen met een link om te checken of je pc veilig is.
Dit is IMO ook echt alles wat de ABN hieraan kan doen.

[Il Duce]

Wat ze zouden kunnen doen is de tweede challenge ( die je krijgt bij het overschrijven) random maken. Nu is die statisch, en gebaseerd op het rekeningnummer van de ontvangende partij. Dus als dat rekeningnummer 123456 is dan is de challenge altijd 2345. Dat is de enige reden waarom deze trojan werkt, aangezien hij nu bij de eerste log in 2345 als challenge kan geven en de response kan bewaren tot de gebruiker is ingelogd.

Als ze gewoon het ontvangende rekeningnummer zouden gebruiken als seed voor een keyed-hash functie, en de uitkomst daarvan zouden gebruiken als challenge dan zou de challenge dus onvoorspelbaar zijn, en zou deze aanval onmogelijk zijn.

Edit: Aan de andere kant, als de challenge onvoorspelbaar zou zijn, dan kan de gebruiker nooit controleren of er geen transacties meegesneakt worden door een trojan.

[Reactie gewijzigd door Il Duce op 23 juli 2024 21:41]

[comecme]

Weet jij zeker dat de challenge op zo'n manier statisch is? Dat zou dan wel héél erg slecht gemaakt zijn namelijk.

Bovendien, is het echt zo dat je bij ABN AMRO per overschrijving een code moet intikken? Bij Postbank en Rabobank is dat namelijk één code zodra je je transacties gaat versturen. Als je drie transacties in één keer verstuurt heb je dus maar één code.
Ik neem aan dat ABN AMRO ook zo werkt. En dan kun je dus nooit de challenge-code berekenen a.d.h.v. het rekeningnummer. Er is immers sprake van meerdere rekeningnummers.

[Il Duce]

Het was statisch. Ik wou net even een screenshotje maken om het te laten zien, maar ze hebben het veranderd. (of ik ben gek)

Dat met die meerdere transacties maakt niet uit want dat ding kan gewoon zijn eigen transactie posten met de response zodra je ingelogd bent, dan hoeft ie dus niet te piggybacken via het normale overmaak scherm.

[miw]

Het is een misvatting dat de bank elke geauthoriseerde transactie automatisch uitvoert, zelf als de transactie een overboeking naar de buitenlandse rekening van maffiamaatje inhoudt. Die transactie kan met eenvoudig ophouden en even persoonlijk contact opnemen met de geachte klant. Net zoals ISP's omgaan met slecht geconfigureerde of met malware besmette PC's. De integriteit van een PC bewaren is zelfs moeilijk voor goede ICT experts zoals hacks op vele gerenommeerde websites aantonen. Jammer dat banken daar zo geheimzinnig over doen.

[Edgarz]

Even kort mijn idee over de trojans: De trojan verzorgt een fake beeld bij de gebruiker ('respons foutief") en vraagt om herhaling, terwijl de trojan achter het fake schermbeeld een boeking heeft aangemaakt. De nietsvermoedende klant genereert een nieuwe respons welke gebaseerd is op de verificatie van de overboeking (welke achter het fake beeld door de trojan als input wordt genomen). Nieuwe respons accordeert de overboeking en de trojan neemt je weer mee terug naar het algemene scherm.

Echter, veel overboekingen zijn direct te zien in het mutatie-overzicht. Of deze wordt geagendeerd (pas later zichtbaar/uitgevoerd) ofwel men gokt erop dat de overboeking niet opvalt door het een veelvoorkomende naam/omschrijving mee te geven (huur, Nuon). Maar ben wel benieuwd hoe men dat heeft afgedekt.

Elk systeem is te kraken. Postbank, Fortis, ABN, Rabo.

Met drie- of vierdubbele trojans (en/of desnoods een fake server) is geen enkel controlesysteem waterdicht. Of je moet er dagelijks nieuwe handelingen voor over hebben.

[localhost]

Als ik het goed begrijp:

1. Het login-schem is echt van de Bank, gebruiker kan het SSL certificaat controlleren.
2. De Submit wordt geredirect naar een andere https webserver van de hacker.
3. De webserver van de hacker geeft een reply (jscript popup?) dat het fout is gegaan.

[Edgarz]

1. Het initiele inlogscherm wel. Pas vanaf "versturen opdracht" komt de trojan om de hoek kijken. Denk niet dat ssl te controleren is, hoeft nl. geen echt bankscherm te zijn maar een gegenereerde pagina. Overigens controleert de gemiddelde klant SSL niet en wanneer wel dan alleen bij eerste inloggen en niet meer tussendoor.
2. Ja, en dat volgt uit 1
3. Nee geen popup. Foutmelding wordt op html pagina weergegeven. Dit zou ondersteunen dat er naar een ander https adres wordt doorverwezen door de trojan. Een andere manier waarop de trojan een scherm kan genereren zal wel bestaan maar dat impliceert een zeer complex stukje software wat meer doet dan alleen naar andere webservers verwijzen c.q codes doorzenden.

[SPee]

Nee

1. Het login scherm is echt
2. De submit gaat naar de webserver van de bank en er wordt ook daadwerkelijk ingelogd (gebruiker denkt nog te wachten op resultaat)
3 a. De trojan maakt een transactie
3 b. De trojan gaat die transactie bevestigen
3 c. De trojan krijgt een response code
4. De trojan toont een fout pagina met de 3c. response code. Nu pas krijgt de gebruiker het resultaat van 2 en denkt dat de login fout is gegaan.
5. De gebruiker vult de response in (denkt opnieuw te moeten inloggen
6. De trojan gebruikt de response om de transactie te accorderen
7. De gebruiker krijgt de normale beginpagina te zien

8 a. De gebruiker vraagt het overzichtscherm met transacties
8 b. De trojan filtert zijn gemaakte transactie eruit en toont het resultaat.

[OddesE]

Als je toch een trojan schrijft kun je ook wel even jouw transacties er tussenuit filteren voordat je het 'Geagendeerd' scherm toont...

[Il Duce]

Dat hele scherm hoeft niet getoond te worden, aangezien de trojan alle informatie toch al heeft.

[Nekje64]

Het is al half genoemd in in verschillende berichtjes zonder verwijzing:
ABN heeft een duidelijke maatregel genomen op 14 Augustus. Als je nu naar https://www.abnamro.nl/nl/logon/identification.html gaat krijg je de tekst:
Momenteel is er een gevaarlijk virus in omloop.
Controleer uw pc op dit gevaarlijke virus.
Doe nu de check! Controleer of uw pc is geïnfecteerd.
Ze linken naar een eigen pagina met extra uitleg, deze linkt een speciale ABN pagina van Kasperski met een tool welke opspoort en evt. verwijderd. Kasperski meldt dat het niet om het virus van maart gaat.

[SchizoDuckie]

Tsja... PRUTSERS bij de ABN.

Ik heb volgens mij 3 jaar geleden op tv al een voorbeeld gezien van exact deze methode van man-in-the-middle attacks op de abn site. Volgens mij was het bij radar ofzoiets Dat die methode nog steeds niet veranderd is laat maar weer eens zien dat het misschien nog niet zo'n slecht idee is dat ze overgenomen worden door fortis

Op mijn rabobank kastje zit netjes een I en een S knop, I voor het inloggen en S voor het bevestigen van transacties. Knappe jongen die daar nog tussendoor komt.

[Reactie gewijzigd door SchizoDuckie op 23 juli 2024 21:41]

[Niemand_Anders]

Heb je het artikel wel gelezen? Ze hoeven maar 2 schermen te vervangen. De aangepaste website (proxy) toont aan jouw de code welke je moet invoeren op je calculator (deze komt 1-op-1 van de echte rabo site). De proxy doet totdat jij je transacties wilt doorvoeren helemaal niets. De andere schermen worden door de proxy 1-op-1 doorgegeven zonder aanpassingen. Je kunt via de proxy dus gewoon je transactie journaal terug lezen. Een gebruiker heeft verder niets in de gaten. Alleen valt het op een gegeven moment wel op dat elke keer de eerste bevestiging van een transactie onjuist is.

Op het moment dat jij je transacties wilt bevestigingen krijg je een aangepaste pagina voor je neus met daarop de code voor je calculator. Jij voert deze code netjes in op je calculator en drukt zelf op de 's' knop. Het resultaat voer jij vervolgens weer in op de aangeoaste webpagina. De proxy voert via deze verificatie code hun transactie uit en zegt tegen jouw dat jouw code fout was en toont daarna opnieuw een verificatie scherm. Alleen deze is niet aangepast en daarnee kun jij dan je eigen transacties uitvoeren.

Deze hack gaat dus veeel verder dan alleen het achterhalen van username/password.In deze hack is veel tijd en zorg gestoken. En net zoals bij de meeste virussen wordt eerst de grootste massa bestookt. Aangezien de Rabobank de tweebank van Nederland is welke gebruik maakt van de two factor authenticatie zal het niet lang duren voordat ook daar enkele slachtoffers zullen vallen.

Verder blijft abn-amro (en zijn website) na de overname gewoon bestaan. Alleen is feitelijk de directie vervangen.

[Anoniem: 132488]

De postbank is anders ook aan het prutsen, al vind ik het systeem met de TAN-Codes wel een veilig principe. je hebt een lijst met 100 codes thuis op papier, voor elke transactie heb je zon code nodig. al heb je de inlognaam+pin, zonder die lijst kun je niks

[Kalief]

Het TAN-code systeem van de Postbank is op dezelfde manier onveilig als dit ABNAmro probleem. Je hebt namelijk alleen je mijn.postbank.nl login nodig om het telefoonnummer te wijzigen waar die TANcodes naar toe worden gestuurd.

---

Onderstaande reacties kloppen. Het wijzigen gaat niet zomaar. Er is slechts een login nodig als voor de eerste keer wordt gekozen voor TAN-per-mobiel ipv schriftelijk. Er is dan uiteraard geen oud telefoonnummer waar een bevestiging kan worden gevraagd. Ik weet niet of zo'n eerste-keer-bevestiging dan schriftelijk wordt afgehandeld.

[Reactie gewijzigd door Kalief op 23 juli 2024 21:41]

[xerix]

Nee dit is niet hetzelfde. Je kan namelijk niet zomaar het telefoonnummer veranderen. Daarvoor wordt er namelijk een code naar je oude nummer gestuurd die je moet invoeren alvorens je het nummer kan wijzigen.

[Ilmar]

Dat is dus onzin, je moet nog steeds originele mobiel hebben, of post onderscheppen.

06 wijzigen: u beschikt nog over bovenstaand 06-nummer?
Om veiligheidredenen vragen wij u de wijziging van uw 06-nummer te bevestigen met een TAN-code. Deze TAN-code ontvangt u op bovenstaand 06-nummer. Klik op Wijzigen om uw 06-nummer te wijzigen. U wordt gevraagd uw nieuwe 06-nummer op te geven en deze wijziging te bevestigen met een TAN-code. Het nieuwe nummer is direct actief.

06 wijzigen : u beschikt niet meer over bovenstaand 06-nummer?
Klik op Blokkeren. Door het blokkeren van de betaalfunctie is overschrijven niet meer mogelijk. U ontvangt binnen 5 werkdagen per post een activeringscode om de betaalfunctie opnieuw in gebruik te nemen. Uw nieuwe 06-nummer kunt u bij het activeren opgeven. (Let op: vervang tijdens het activeren uw oude nummer door uw nieuwe 06- nummer)

[Olaf van der Spek]

zonder die lijst kun je niks

Jij snapt duidelijk deze attack niet. De Postbank lijkt op precies dezelfde manier kwetsbaar te zijn.
Alleen een systeem waarbij een bevestigingscode naar een telefoonnummer wordt gestuurd, lijkt me veiliger.

[martdj]

Ik denk dat jij hier de mist ingaat. Waar het hier bij deze aanval om gaat is dat de code om in te loggen (die je van je ABN calculator afhaalt) dezelfde is als om een transactie goed te keuren. Daardoor kan de Trojan mensen laten denken dat ze inloggen en stiekum daarmee een transactie goedkeuren. Bij de postbank zijn de TAN codes alleen voor het goedkeuren van een transactie, waardoor dit veel moelijker is. Of die TAN codes nu via de telefoon of een papieren vel gaan, maakt in deze niets uit.
Natuurlijk zou er best een systeem te bedenken zijn waarbij je mensen laat denken dat ze transacties doen en als ze die willen verzenden dat je dan die transacties vervangt door jouw transactie, maar dat kan bij alle bank software via het Internet. Het enige wat dan veilig is, is als er een soort hash code gegenereerd wordt op basis van jouw transacties en je die hash code naar de bank moet sturen (of in een calculator in moet voeren) om de code om de transactie te bevestigen te verkrijgen, maar dat doet tot nu toe nog geen enkele bank bij mijn weten.

[MadEgg]

Dit is toch precies wat er bij de Rabo gebeurd? Je zet je transacties klaar en krijgt een hash-code die je vervolgens op je Random Reader invult, samen met je pincode. Vervolgens krijg je nu de bevestigingscode.

Het probleem wat je hiermee houdt is dat je zelf de hash-code niet kunt controleren(ik niet in ieder geval). Om dat nog weer veilig te stellen zou de Random Reader eigenlijk het totaal over te maken bedrag nog even moeten laten zien ter controle.

[Olaf van der Spek]

Om dat nog weer veilig te stellen zou de Random Reader eigenlijk het totaal over te maken bedrag nog even moeten laten zien ter controle.

Dat is ook niet veilig, de trojan kan dan nog steeds het rekeningnummer veranderen.

[localhost]

Bij Rabobank: Bij bedragen groter dan x.xxx euro (ik dacht 2.500) moet je zelfs in plaats van 2 hash getallen, 3 getallen intikken op je calculator, waarbij het laatste getal het bedrag is dat je gaat overmaken.

[Anoniem: 201824]

Bij de rabo krijg je een overzicht van de te betalen opdrachten te zien voordat je werkelijk de code hebt ingevoerd. Daar staan de bedragen en begunstigden. Totaal misschien niet(weet ik even niet uit me hoofd) maar een beetje rekenaar kan meteen het totaal inschatten. Al weet ik nog niet hoe je dan de hash code wilt berekenen. Dan moet je nog altijd de algoritme voor de hashcodes van je random reader weten.

Verder maakt de grootte van het totaalbedrag of een unieke overboeking niet uit. Die wijzigen de dieven niet omdat dan de door jouw teruggegeven codes mogelijk niet meer juist zijn voor de Rabo server en ze niet zal verwerken.

[Olaf van der Spek]

Natuurlijk zou er best een systeem te bedenken zijn waarbij je mensen laat denken dat ze transacties doen en als ze die willen verzenden dat je dan die transacties vervangt door jouw transactie, maar dat kan bij alle bank software via het Internet.

Dat vind ik geen significant verschil in veiligheid vergeleken met ABN AMRO dus.

[Luuk1983]

Ik ontvang mij TAN codes ook op mijn telefoon op het moment dat ik een transactie doe. Ik vind die TAN codes op papier juist weer onveilig. Als ik nu geld over ga schrijven, ontvang ik op moment van versturen van de transactie een SMS bericht met de TAN code. Daarin staat een volgnummer en het transactiebedrag + de code. Zonder deze TAN code kan de overboeking niet plaats vinden. Voor elke transactie is een nieuwe (andere) TAN code nodig. Het lijkt me dus niet logisch dat de postbank op dezelfde manier kwetsbaar is.

[Dreamvoid]

Die TAN code via SMS is idd de veiligste methode van NL op het moment (ook omdat bij de bevestingings sms zowel het bedrag als de laatste cijfers van de tegenrekening staan), maar er zit wel 1 risico aan vast: jat iemand je mobieltje en je login/pass, dan kan hij via mobiel internet gewoon transacties doen.

[26779]

@dreamvoid

Die TAN code via SMS is idd de veiligste methode van NL op het moment

en hoe gaan SMS berichten ook al weer door de lucht? jawel... plain text....

[Dreamvoid]

SMS gaat niet plain text, het is GSM, dus inclusief A5 encryptie. Maar idd, als iemand je SIM kaart gekloond heeft, of een man-in-the-middle fysieke GSM zendmast geplaatst heeft, of de SMS server van de provider heeft gekraakt kan dit natuurlijk ook. Dat vergt alleen wel heel erg veel voorbereiding en coordinatie: de hacker moet dan zowel de verbinding met internet als het lokale GSM netwerk gekraakt hebben, wat uiteraard wel wat lastiger is dan alleen een simpele trojan installeren (zoals nodig bij Fortis/ABN/Rabo/etc).

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 21:41]

[Soldaatje]

Je moet je wachtwoord ook regelmatig wijzigen bij de Postbank, moest ik toevallig net nog doen. Niet dat je je wachtwoord zomaar ergens laat liggen maar toch tegen bruteforce en dictonary attack is het wel weer veiligER.

Ik heb voor de zekerheid maar even een extra toetsblokkeringscode geactiveerd op mijn mobiel zodat als ik hem kwijtraak niemand toegang kan krijgen zonder de toegangscodes.

[Reactie gewijzigd door Soldaatje op 23 juli 2024 21:41]

[Anoniem: 201824]

@Soldaatje.
Dit is niet echt gerelateerd aan dit nieuws item, want de beveiliging van banken is heel goed, maar:
Een wachtwoord wijzigen betekent niet dat het direct veiliger is voor bruteforce of dictionary attacks. Bruteforce gaat 'snel genoeg' tegenwoordig op de wat oudere beveiligingsmethoden. En dictionary, die zal waarschijnlijk net zo snel gevonden zijn als je vorige code, of je moet je vorige wachtwoord zoiets als zomer2007 hebben gehad en nu SDw29Dj6xX3e ofzo hebben, maar dat zal wel niet.

[bsander]

Hetzelfde geldt natuurlijk voor die TAN codes op papier of zo'n random reader van de Rabobank. Na een tijdje is het gewoon niet meer te beveiligen met een geautomatiseerde procedure..

[Neko Koneko]

maar er zit wel 1 risico aan vast: jat iemand je mobieltje en je login/pass, dan kan hij via mobiel internet gewoon transacties doen.

Maar hoe groot is die kans? misschien als ze je handtas jatten (gaat voornamelijk voor vrouwen op ) maar dan nog moet je je pin code nooit bij je bankpas bewaren... Als je je pincode op afstand (of liever, in je hoofd) houdt, hebben ze je pas, je telefoon maar missen ze die derde, namelijk de pincode en kunnen ze nog niks (er vanuit gaande dat ze de pincode niet kunnen uitlezen uit de pas voordat je hem kunt blokkeren - als de pincode überhaupt op de pas staat maar volgens mij is dat ook niet zo).

[Reactie gewijzigd door Neko Koneko op 23 juli 2024 21:41]

[TD-er]

MijnPostbank.nl heeft al tijden een SMS-dienst.
Hier staat ook het bedrag bij, als je je TAN-code ontvangt. Dat is nog weer een stukje veiliger dan die oude papieren TAN-lijst, voor het geval van de trojan.
Nadeel is natuurlijk dat je wel een probleem hebt als ze je inlognaam en wachtwoord weten en je GSM jatten.
Je login-naam kun je op je PC bewaren, dus als ze naast je GSM ook je laptop jatten zijn ze al een heel eind.

[Anoniem: 201824]

Je tel.nr laat je dan natuurlijk zo snel mogelijk blokkeren zodra je er achter komt... Je bent verder voor de rest gewoon zelf verantwoordelijk voor het verlies van je belangrijke gebruikersnaam+wachtwoord combi en je gsm.

[TD-er]

Ja zo ken ik er nog wel een... Je bent ook verantwoordelijk voor dat je geen virus op je PC hebt en dat je de pin-machine controleert wanneer je bij de Praxis gaat pinnen en dat je de certificaten van een website waar je met credit-card gaat betalen eerst grondig analyseert.
Kortom, waar ligt de grens van je eigen verantwoording?
Als mijn laptop en GSM gewoon thuis liggen omdat ik op vakantie ben, wanneer moet ik dan de boel laten blokkeren?

Maar goed, daar gaat het niet zozeer om, ik wilde gewoon aangeven waar de zwakke punten liggen. Wie de verantwoording moet dragen is een andere discussie.

[EIo]

De postbank is anders ook aan het prutsen

Lekker onderbouwd. Dat het (heel) soms plat ligt bedoel je? vind ik nog niet zo kwalijk.
Die fishing aanvallen, tsja, daar kunnen ze in principe niet echt op worden afgerekend daar ze er niets aan kunnen doen...
Voor de rest heb ik niet het idee dat ze aan het prutsen zijn.

Trouwens, ik krijg gewoon m'n TAN code naar m'n GSM gestuurd. Dat kan wellicht wel sneller gehacked worden natuurlijk, maar voor m'n gevoel is de combinatie echt wel veilig. En ik heb niet zo'n los kastje nodig.

[Anoniem: 221159]

Uitgaand van het zelfde triple-trojan verhaal:

Op het allerlaatste moment, vlak voordat jij je bevestiging code in moet voeren, wordt er nog snel een extra overschrijving tussen gepropt die je dan al niet meer ziet.

Jij zag/ziet alleen jou legitieme transacties keurig op een rijtje staan en voert vol vertrouwen je code in.

Het is in dit geval niet te doen om een man-in-the-middle attack te voorkomen. Een beetje slimme trojan past namelijk altijd zo de pagina('s) aan dat zijn transactie nooit te zien is.

[Reactie gewijzigd door Anoniem: 221159 op 23 juli 2024 21:41]

[Niemand_Anders]

Nee, er worden echt gewoon twee transacties uitgevoerd. Daarom moet je ook tweemaal een verificatie code opgeven. De eerste is voor hun transactie (deze schermen zie je niet). Bij de tweede code bevestig je je eigen opdrachten.

Ze hebben een speciaal aangepast http proxy geschreven welke slechts enkele schermen aanpast. Je ziet ook gewoon de echte ABN-amro website, dus geen phissing website. Omdat je via hun 'proxy; inlogt hebben ze ook de sessie cookie waarmee zij hun eigen transcatie kunnen voorbereiden. Op het moment dat je op de bevestifing/opdrachten uitvoeren link klikt komt de proxy eigenlijk pas echt in aktie. Op dat moment tonen zij jouw transacties en 'onderscheppen' vervolgens jouw form post. Die form post bevat juist de bevestigings code waarmee zij hun transactie kunnen uitvoeren. Vervolgens geven zij aan dat de code onjuist is en tonen daarna weer het oorsponkelijke bevestigings scherm welke zij dan ongewijzigd weer 1-op-1 doorsturen naar de abn-amro website.

[Anoniem: 201824]

Dat gaat dus niet werken in geval wanneer je dat bij de rabo doet (@kees en @sobani)
De code wordt mede gevormd door het bedrag wat de server nu heeft staan voordat je een code teruggeeft. Die codes zijn aan elkaar verbonden, en de bedragen dus ook aan de codes. Flauwekul dus wat jullie suggereren. Anders was Internetbankieren allang geflopt en gestopt.

[still_the_same]

Ehm, wat dacht je van, sorry, het signen is niet gelukt, probeer het nog 1 keer..... TADA ;-)

[TheLunatic]

Er zitten verschillende systemen achter de I en de S. Bij de I moet je je pincode invoeren en krijg je een inlogcode, bij de S moet je je pincode+verificatiecode invoeren en krijg je een bevestigingscode. Dat verschil zou een normale gebruiker wel moeten merken zou het door een trojan gefaked worden.

[Reactie gewijzigd door TheLunatic op 23 juli 2024 21:41]

[still_the_same]

Je logt in, dat gaat mis... Je doet het nog een keer.... Het gaat goed... poeh poeh, das lastig... Je zit nu op een fakesite die gegenereerd is uit jouw data. Je zet een opdracht klaar, je signed hem en het gaat mis... grmbl.... Je doet het nog een keer.. het gaat goed... Jeej denk jij... Jeej denkt dan man in the middle ;-)

[TWeaKLeGeND]

1. Je logt in bij SNS met je I knop

Trojan bouwt nu on the fly een man in the middle pagina op ofwel gebaseert op de gegevens van je echte account ofwel het IS je echte account maar dan worden enkel bepaalde gegevens vervangen door de trojan (en dat hoeft echt geen zware rekenkracht of merkbare delay te kosten) waarbij jij rustig je transactie doet terwijl de trojan stiekem een echte transactie klaarzet. Jij wil je transactie finaliseren maar de trojan zorgt ervoor dat jij de code te zien krijgt van hun eigen aangemaakte transactie.

2. Jij gebruikt in vol vertrouwen de S knop op je zojuist aangemaakte transactie te finaliseren.

De neppe transactie staat keurig netjes als afgehandeld in je browser en de echte transactie gaat zo de zak van the man at the end in.

Oplossing: De verificatiecode moet naar het normale systeem gewoon 4/6/8 getallen groot zijn PLUS nog 2 getallen zijnde de eerste en de laatste getallen van de rekening waar men naar probeert over te boeken, PLUS nog 2-4 getallen die het te overboeken bedrag enigzins moeten representeren. Uiteraard is de laatste toevoeging vrij zwak omdat je gewoon dat exacte bedrag kan laten overboeken of dat bedrag met een nulletje erachter etc, maar die 2 rekeninggetallen maakt de drempel om dergelijke aanvallen te organiseren bij betreffende bank veel en veel hoger (Maar het is zeker niet waterdicht en ook niet bepaald klantvriendelijk)

[Reactie gewijzigd door TWeaKLeGeND op 23 juli 2024 21:41]

[Shin_Alu]

Die oplossing zal ook niet helpen, aangezien gebruikers die getallen niet gaan controleren en de site door het virus zo aangepast zou kunnen worden dat deze het ook niet weergeeft / controleerd.

Zolang de daadwerkelijke controle niet volledig bij de gebruiker ligt kan je op de manier van dit virus oplossen, het enige dat wisselt is hoe moeilijk het uit te voeren is en of er een (legitieme) transactie nodig is om de verborgen transactie uit te voeren

Aan het smsje of de code voor de cardreader zal een gemiddelde gebruiker het niet zien

[Anoniem: 80466]

Een two way response system vereist echter dat een man in the middle attker de complete site moet kunnen simuleren omdat gebruikers ook hun rekening gegeven kunnen gaan bekijken of anders zaken binnen de internetbankieren site.
Dat is veel complexer dan een one response systeem waarbij je de gebruiker kan laten denken dat hij uitlogt omdat je toch al zijn code hebt.
Het is een groot verschil of je alleen een login pagina simuleer of een complete internetbakieren site.

[Parasietje]

Je denkt teveel in een richting. Een phishing site is niet noodzakelijk een nagebouwde pagina met eigen code. Het kan ook een soort proxy-server zijn die bepaalde requests herschrijft. Een proxy-server die bijvoorbeeld alles doorlaat, behalve als een overschrijving gebeurt. Dan herschrijft hij in de request naar de bank-server het rekeningnummer en het bedrag. In het antwoord van de server zet hij de originele data weer terug.

[gfgw]

4/6/8 getallen plus 2 plus nog 2-4: dat zijn dus 8-14 getallen? Dat wordt omslachtig. Uit hoeveel cijfers moet elk getal dan bestaan? Een typefout is dan zo gemaakt.

[beantherio]

Je kunt er niet zoveel mee want voor iedere betaalopdracht moet toch weer een aparte code gegenereerd worden door de site, ingevoerd worden in het rabo-machientje waarna je een code terugkrijgt die je weer moet invoeren. En als er in die code ook maar enigzins iets versleuteld zit van de betaalopdracht dan heb je daar als hacker niets aan.

[Anoniem: 201824]

Even een aanvulling:
Je kan meerdere unieke overboekingen (verwerkt als een verzameling opdrachten) met 1,2 of meer(afhankelijk van grootte van het bedrag) codes in een keer versturen. Dus er is niet perse voor elke unieke overboeking die je wilt doen een nieuwe code nodig. Wel is die code bij de Rabo iig. afhankelijk van de grootte van het bedrag, iig. geldt dit per unieke overboeking, weet niet of er ook met kleine unieke overboekingen per opdracht ook naar de totaalsom wordt gekeken... Maar al is het maar 1 code, het is dan nog moeilijk om de juiste code te genereren, die zou dan van de echte Rabo server moeten onderschept worden, tussen client en server, met de man in het midden.

[borft]

dat werkt niet, want de 2e code die je moet geven is afhankelijk van een code die je eerst van de rabobank zelf krijgt en is alleen geldig voor die transactie.

[Olaf van der Spek]

bij de S moet je je pincode+verificatiecode invoeren en krijg je een bevestigingscode.

Krijg je die via de mobiele telefoon dan?
Anders lijkt het me redelijk simpel om alsnog eerst de foute transactie en daarna de goede transactie te laten signen met een smoes.

[Bravo]

Nee, deze krijg je niet per mobiel, maar is wel afhankelijk van het bedrag wat overgemaakt moet worden. Als er dus een afwijkend bedrag wordt bevestigd doordat er extra opdrachten worden uitgevoerd, zal de code niet kloppen en kan de transactie niet worden uitgevoerd.
Volgens mij is dit redelijk waterdicht, ook een van de redenen dat ik zelf bij Rabo zit

[.oisyn]

Hoe weet jij dat er een afwijkend bedrag is dan? Of staat het bedrag duidelijk zichtbaar in de code? Want waarom zou een trojan niet gewoon een nep-pagina kunnen genereren met jouw betaalopdracht en een verificatiecode, terwijl ze er stiekem op de achtergrond nog een transactie aan toe hebben gevoegd (en daar dus van de verificatiecode geven)? Jij hebt er geen idee van dat die verificatiecode eigenlijk helemaal niet bij dat totaalbedrag hoort.

[ronny]

jij weet niet dat de verificatie code niet bij de opdracht hoort maar de rabobank wel.
Ik neem te minste aan dat de verificatie code wordt verwerkt in de laatste code om het te bevestigen.
Hierdoor kan de rabo de een controle doen, door de code met de transactie's te vergelijken. klopt dat dan is code geaccepteerd en anders is deze verworden.

[wizzkizz]

maar het kan wel zo zijn dat er een extra opdracht bij je andere opdrachten is gevoegd en door de trojan uit het overzicht gefilterd. Jij vult je code in, Rabobank accepteert mooi. In het daaropvolgende 'in behandeling' menu wordt ook de extra opdracht niet getoond, evenmin in je rekeningoverzicht (want dat filtert de trojan eruit).

Je merkt het dus pas op het moment dat je op een andere, niet besmette, computer inlogt of als je een papieren afschrift krijgt.

Het kan wel, maar dat kun je never nooit niet voorkomen als de client machine onbetrouwbaar is. Als je via een sms ook het bedrag krijgt, kun je dat wel voorkomen.

[Reactie gewijzigd door wizzkizz op 23 juli 2024 21:41]

[flowerp]

Hoe weet jij dat er een afwijkend bedrag is dan? Of staat het bedrag duidelijk zichtbaar in de code?

Bij bedragen boven een bepaald maximum (dacht 800,- ofzo?) vraagt de bank je om een 2de S code in te vullen. In die code staat direct het bedrag.

Ik vraag me alleen af waarom ze dit pas boven een bepaald bedrag doen. 800,- ben ik toch liever ook niet zomaar kwijt.

[jpbvo!]

Dit is pas vanaf 10.000 euro! Daaronder hoef je slechts 1 keer de S code in te vullen.

Edit n.a.v. hieronder: Dan is de grens blijkbaar aangepast. Goeie zaak, extra beveiligingsstap maakt de kans op fraude minder.

[Reactie gewijzigd door jpbvo! op 23 juli 2024 21:41]

[SunnieNL]

Nee.. heb het ook al eens gehad toen ik 900 moest overmaken.. dus is zeker minder dan 10.000

[flowerp]

Ik heb hem ook een paar keer gehad en ik zou willen dat ik een paar keer meer dan 10.000 had over mogen maken

[Sr_Ogel]

pas auto betaald via internetbankieren was 2250 eurotjes maar de 2e S werd niet gevraagd.

[AVee]

Bij mij was het laatst voor 2500,- euro wel nodig, maar ik vermoed gewoon dat het per bank verschilt...

[ajvdvegt]

Als je de code verkeert intikt, krijg je de melding die iets zegt als 'het bedrag is onjuist'.

[Kees]

heel gemakkelijk, ware het niet dat ik te lui ben om een poc te schrijven

Op exact dezelfde manier als nu gedaan wordt met de abn amro kan ik ook bijhouden wanneer jij bij de rabo inlogt, en vervolgens een extra transactie neerzetten en die uit de geretourneerde html code halen zodat hij voor jou niet zichtbaar is.

Als jij vervolgens een transactie instuurt dan wordt mijn transactie ook uitgevoerd.

Ik geef meteen toe dat het iets minder erg is dan wat er in dit bericht staat want daar wordt de transactie al meteen gedaan op het moment dat jij 'inlogt', bij 'mijn' poc zou je eerst zelf een transactie moeten doen.

Het enige systeem dat veilig zou zijn is een telefonische en/of schriftelijke bevestiging van elke transactie, zolang je alleen maar een computer gebruikt is er een stuk malware voor te bedenken.

[TD-er]

laat maar weer eens zien dat het misschien nog niet zo'n slecht idee is dat ze overgenomen worden door fortis

... Zodat in het vervolg ook de Fortis klanten gepakt kunnen worden?

In elke telebankier-software of -methode zal wel fouten in het ontwerp zitten.
Het is alleen een kwestie van zoeken voor de criminelen en dat is pas interessant als het een relatief grote bank betreft. Door de overname zal het mogelijk alleen maar interessanter worden, ook al heb ik begrepen dat na de overname beide banken onder hun eigen naam verder zullen gaan.

[gielius]

laat maar weer eens zien dat het misschien nog niet zo'n slecht idee is dat ze overgenomen worden door fortis

Die vlieger gaat niet op
Fortis gebruikt precies dezelfde methode met precies hetzelfde verificatieprincipe dus je kunt eerder zeggen dat ze inderdaad goed bij elkaar passen

[Seraphin]

Alleen jammer dat I-bankieren bij de Fortis op precies dezelfde manier werkt.

[Anoniem: 180516]

Ben ik de enige die het schandalig vindt dat ze geen persbericht uitgeven?
De mensen waarschuwen dat het virus er is en dat ze moeten oppassen wanneer ze een fout bij het inloggen krijgen is toch wel het minste dat ze kunnen doen.

[TD-er]

Het bestaansrecht van de banken ligt in het feit dat er een vertrouwen is van de klant in de bank.
De banken willen graag van de dure loketten en papieren transacties af, dus die willen niet dat mensen bang worden om digitaal hun bankzaken te regelen.
Zolang het bericht dus niet op het 20h journaal verschijnt, zal het grootste deel van de klanten er niets van meekrijgen en bij misbruik vergoed de bank het geld toch wel.
Zo kort na de pinpas-fraude kunnen ze niet nog meer van dergelijke berichten erbij hebben, dus ik snap het wel dat ze -zolang er nog niet precies bekend is hoe het misbruikt wordt- het verhaal nog niet aan de grote klok zullen hangen.
Het nadeel hiervan is natuurlijk dat dit het uitgelezen moment is voor de crimineel om toe te slaan, ook bij andere banken.

[FereiDON]

Als je inlogt bij ABN dan is er wel zo'n melding dat er een virus rondzwerft en dat je dus op moet passen. Ook zit er een link bij van Kaspersky waar je je pc kunt controleren op dat virus.
Mijn pc had gelukkig niks

[PilatuS]

Volgens mij is die melding nog van een ander ouder virus. Die melding staat er namelijk al een tijdje.

[Nekje64]

Ook heeft ABN onlangs een hele complete manual bij het inloggen hoe je zo safe mogelijk werkt. Een oplossing voor deze staat er nog niet bij.

Zoiets als: controleer je code voor verder gaan, bij een foutmelding stoppen met werken en Kasperski bellen.

[Captain Pervert]

Alle PR-mensen zijn overspannen naar huis wegens het Barclays/consortiumgedoe wat zich al een half jaar voortsleept Men heeft er de handen vol aan om te zorgen dat niet iedereen wegloopt.

[erikdeperik]

ik snap het toch niet.
je hebt een edentifier nodig icm je pin en pas,
als je inlogged moet je een respons geven op een getal wat zij aangeven.
die respons krijg je door je pas in te voeren in je edentifier , je pin invoeren en het getal in te voeren.
de uitkomst is de respons.
dus het getal wat je als respons geeft is nooit 2 keer hetzelfde
bij het inloggen en het uitloggen.

[djmulder]

daar zit nou de grap,

wat er gebeurt in leektaal:

- Je komt op abn-amro site, login scherm;
- Gebruiker logt in met login, password (pin en pas# dus) en security key;
- Spyware gooit foutmelding op, maar laat de site toch doordraaien op de achtergrond en doet een transactie;
- Transactie vraagt natuurlijk ook om een key, deze key wordt aan de gebruiker gevraagd met een nieuwe (door spyware gegenereerd) loginscherm;
- Gebruiker krijgt "normale" site voor zich, spyware gaat verder met transactie.

Simpel in theorie, ik en een oud collega hebben hier al een keer over doorgekoffiet ... maarja wat doe je er aan? er is weinig te doen aan dit, misschien captcha beveiliging, maar kom je ook niet heel ver mee (tja plaatje is ook door te linken).

"de" oplossing zou zijn om gewoon te kappen met online bankieren en weer met de post.. zo lang de gebruiker in gevaar is voor invloeden van buitenaf zitten er zat tussen die hier instinken.

Wat ook wel zou werken is de link van de transactie site dynamisch te maken, dan ben je er volgens mij ook wel, iets als:

[code]
<a href='GUID.aspx'><img src='een of andere imagelink met dynamischenaam maar natuurlijk ervoor zorgen dat het niet het enige plaatje is nog op dezelfde plaats staat steeds.jpg'></a>
[/code]

[Reactie gewijzigd door djmulder op 23 juli 2024 21:41]

[koenie]

De toekomst om dit soort problemen te voorkomen ligt in virtualisatie. Bij elke keer dat de bankapplicatie wordt opgestart wordt er op de host een viruele machine (guest)gestart. (met hashes gecontroleeerd op juiste versie door de bank zelf). In deze viruele machine kan men alleen een internet connectie maken met de bank.
- Transacties uitvoeren.
- Applicatie (viruele machine) afsluiten

Aangezien de virtuele machine in deze moderne tijden middels de hypervisor vrijwel direct praat met de hardware wordt het al een stuk lastiger om vanuit de host (als trojan) het verkeer af te luisteren en te manipuleren.

[Edgarz]

Ik denk zelf dat transacties in sandboxen, al dan niet middels virtualisatie, dit soort threats kunnen beperken. Alhoewel ook daar wel wat op te vinden al zijn.

[djmulder]

ook dit is af te tappen natuurlijk, kom je weer op het verhaal: "spelen met geheugen adressen"

[Het.Draakje]

Die russische beveilingsexpert had toch al aangetoond dat zij de hypervisor ook kon bedonderen ?

Echt 100 procent veilig krijgen we het nooit. Maar dat krijgen we ook niet met 'echt geld'.

[Edgarz]

Precies mijn idee. Hier valt weinig tegen te beginnen, de PC van de gebruiker is een belangrijke speler in de communicatie met de bank. Of je zou verplicht een online trojan/virusscan moeten starten voordat je kunt bankieren via internet. Maar ja, om nu een uur te gaan zitten wachten voor het overmaken van je Christine Le Duc acceptje... (kun je ook veel leuke dingen in doen, in dat uurtje)

[miw]

De beveiliging zit hem dan ook niet primair in de front end, waar de bank ervan uit moet gaan dat de klant ook een degelijke systeembeheerder is en dat het gebruikte OS en de applicaties veilig zijn tegen malware. Deze aannames zijn ieder op zich al idioot en dus is veel van de authenticatie niets anders dan beveiligingstoneel. In het backoffice gebeuren kan veel meer opgespoord worden. Waarschijnlijk heeft een dergelijk systeem ook de informatie aangeleverd om een besmette PC te laten onderzoeken door externe virus experts.
Verder is het natuurlijk zot dat banken nog steeds niet risicodrager zijn bij dergelijk misbruik waardoor er geen enkele stimulans is voor banken om te (blijven) investeren in veiliger electronisch bankieren.

[Left]

De response is idd niet hetzelfde.

Ik vond het ook wat onduidelijk, maar wat het artikel bedoelt is dat de response op dezelfde manier gegenereerd wordt. De Trojan kan jou dus nog een keer vragen om een inlogcode, terwijl het in werkelijkheid om een bevestigingscode voor de malafide transactie gaat.

[jqv]

Weet niet of ze het in de gaten hebben hier bij tweakers:

De ABN Amro maakt voor zijn online-bankapplicatie gebruik van een zogenaamde two factor authentication, maar tussen de codes om in te loggen en die om een transactie te bevestigen, zit geen verschil.

Ik heb internetbankieren bij ABN AMRO.
Maar de code om in te loggen en om opdrachten te bevestigen zijn beide verschillend.

ze worden gemaakt aan de hand van een apparaattje waar je je pas indoet, pincode ingeeft en de opgegeven code van de bank.

Daarna krijg je een nieuwe code die je op de site ingeeft om in te loggen.

voor het bevestigen doe je dezelfde procedure, alleen krijg je dan van de bank een andere code. en geeft het apparaat een andere code om op de site in te voeren.

[Reactie gewijzigd door jqv op 23 juli 2024 21:41]

[corani]

Het probleem is niet dat de codes gelijk zijn, maar dat de procedures gelijk zijn. Zo weet je niet of de challenge/response voor het inloggen is, of voor het bevestigen van een transactie.

Overigens, het staat wel degelijk op de site van de ABN-AMRO (met een link direct na het inloggen): https://www.abnamro.nl/nl...nternetcriminaliteit.html

[Reactie gewijzigd door corani op 23 juli 2024 21:41]

[Anoniem: 2090]

methode voor het genereren is hetzelfde. De trojan zorgt ervoor dat je bij inloggen een melding krijgt van dat je code fout is en in het achtergrond wordt er wel een overboeking gedaan. En vraagt vervolgens om een bevestigingscode in je tweede loginpoging.

[Shin_Alu]

Wat ze bedoelen is dat de generatie hetzelfde is, niet de specifieke getallen.

[Anoniem: 229769]

Is dit niet heel eenvoudig te voorkomen door alle transacties te blokkeren zodra er twee of meer gelijktijdige verbindingen zijn met de bank? Want waarom zou een gewone gebruiker twee maal inloggen en op beide sessies transacties uitvoeren? Een van beide sessie kan dan als verdacht beschouwd worden.
In dat geval een gewoon 10-15 minuten alle verbindingen van deze rekeninghouder verbieden.

[daft_dutch]

Meerdere verbindingen is lastig te zien. Meerdere tabs bij firefox is nog steeds de zelfde verbinding. en gewoon 10-15 min verbieden is ook poep natuurlijk

de sms-tan code van de postbank is geweldig maar die heeft weer het Je moet weer je wachtwoord wijzigen. Iets wat ik compleet onveilig vind. (geresulteerd in opschrijven en/of volgnummers)

e.dentifier + sms bevestiging lijkt mij de uitkomst.
Waar de sms tan de bevestiging is.

MAAR KOM TOCH OP. Gebruik een veilig besturing systeem. Of neem een vmware player met firefox. heb je dit gedoe veel veel veel heel veel minder.

[Jokuh]

Boh die ABN toch, eerst steunen ze de wapenindustrie, en nu dit!
Gelukkig heb ik SNS

OT: Zoiets mag gewoon niet gebeuren, maarja, alles wat te beveilen is, is ook te kraken.

[Reactie gewijzigd door Jokuh op 23 juli 2024 21:41]

[Anoniem: 198808]

Nou heb ik een tijdje een SNS rekening gehad maar volgensmij is hun inlog procedure net zo "onveilig" als die van de ABN AMRO. Zover ik me kan herinneren is bij de SNS de procedure voor de inlog code en de code om een transactie te versturen ook het zelfde.

Daarnaast heb je bij de SNS niet eens je bankpas nodig om het apparaat te kunnen gebruiken, dat heeft voordelen qua gebruiksgemak maar ook nadelen qua veiligheid.

Maar goed, ik vind dit nou niet echt een reden om aan te nemen dat internetbankieren van ABN AMRO (of de SNS) echt onveilig is. We hebben het hier een hele tijd geleden ook al over gehad en geen enkele vorm van internetbankieren is echt 100% veilig.

Internetbankieren van de Rabobank zou op een vergelijkbare manier omzeilt kunnen worden.

[Reactie gewijzigd door Anoniem: 198808 op 23 juli 2024 21:41]

[Anoniem: 53425]

Internetbankieren van de Rabobank zou op een vergelijkbare manier omzeilt kunnen worden.

Dat kan niet want in tegenstelling tot de ABN AMro maakt de Rabobank gebruik van twee verschillende manieren van om in te loggen en om transacties te versturen.

De inlog codes onderscheppen heeft geen zin voor het versturen, en als er grotere bedragen verstuurd moet worden dan moet naast het getal dat ingetikt met worden ook nog het totaal bedrag ingevoerd worden.

[Anoniem: 68905]

Tuurlijk kan dit ook bij de Rabobank.

Laat de gebruiker gewoon telebankieren, zodra hij een transactie doet, voeg er 1 aantoe, filter de pagina die de gebruiker te zien krijgt zodat hij alleen denkt dat hij zijn eigen transactie doet en voila...

[Gaming247]

Het kan inderdaad, maar het kan niet op dezelfde manier zoals bij de ABN.

[Niemand_Anders]

Deze methode kan bij elke bank (muv postbank) worden gebruikt. Als je het artikel had gelezen, dan had je geweten dat de bezoeker tweemaal een (verschillende) code moet invoeren. Bij de eerste invoer (welke gewoon correct is), geeft de aangepaste website aan dat de authenticatie onjuist was en vraagt om een nieuwe code. Met de eerste code wordt de geheime transactie uitgevoerd (bevestiging opdracht), met de twee code je eigen opdrachten.

Bij de postbank is deze hack in principe iets lastiger, maar aangezien de meeste bezoekers alle waarschuwingen negeren zal het ook daar kunnen werken. De Postbank verstuurt namelijk per SMS een TAN code, waarbij eveneens ook de oorsponkelijk ticket en bedrag wordt meegestuurd. Als een bezoeker deze SMS goed doorleest en controleert zal deze merken dat hetgeen wat op het scherm staat en wat in de SMS verschillend is en de transactie afbreken.

ABN Amro is momenteel de grootste bank van Nederland welke gebruik maakt van de two factor authenticatie. Aangezien de SNS bank een stuk kleiner is dan Rabobank zullen zij hier minder snel slachtoffer van worden. Bij deze hack gaat het duidelijk verder dan alleen eenzelfde look & feel. vervangen complete (werkende) schermen.

Nogmaals het betreft hier geen hack op de inlog, maar op de bevestiging van een transactie! Jij logt via de criminele proxy namelijk gewoon in op de echte ABN Amro website. In dit soort gevallen is het nou eenmaal beter om bij een kleinere (online) bank te zitten. Vanwege de voorbereidingen en werk van deze criminele moeten verzetten zullen zij zich voornamelijk op grote groepen richten.

Deze criminelen voeren daarnaast juist kleine transacties uit. Bijvoorbeeld 25 euro per transactie. Als dat beperkt blijft tot 1 tot 2 maal per maand zullen deze bedragen zelfs 'verdwijnen' tussen je normale pin betalingen. Zelfs bij een handvol computer praat je dan toch weer over 250 euro per maand. Pak in elke land in west europa 1 bank en dat bedrag per maand loopt toch flink op. Gelukkig voor ons zijn de meeste criminele niet geduldig en zullen als snel grotere transacties uitvoeren.

De Praxis skimmers hebben zo lang hun gang kunnen gaan omdat ze met de gekopieerde passen kleine transacties deden. Een waarschijnlijk hebben/hadden deze criminele niet alleen bij de praxis een skimmer staan.

[peterveldman]

bij de rabobank gaat dit niet of gebruikers moeten echt niet goed opletten, bij het inloggen hoef je namelijk alleen je pincode in het apperaatje in te voeren en bij het versturen van geld moet je nog een tweede code invoeren, ook zitten er twee knoppen op het apperaatje, 1 voor inloggen en 1 voor het versturen van de opdracht.

[Innsewerants]

er wordt 'onzichtbaar' een extra transactie toegevoegd, jij bevestigd die zelf onwetend met het doen van je codes.. zij hoeven geen codes te kennen dus. hoe veilig je apparaatje of wat het aantal codes is heeft er dus verder niet veel mee te maken in dit geval.

[Anoniem: 184837]

Bij de SNS moet je bij iedere vorm van geld overmaken en het inloggen, een code intoetsen en omzetten met een digipas. Het opvragen van gegevens of het downloaden van transacties is echter vrij toegankelijk na het inloggen. Zou men een soortgelijke virus-methode toepassen bij de SNS dan krijgt het virus dus alleen maar rekeninginformatie te zien.

[Gwaihir]

Rabobank en ING gebruiken voor authorisatie van betalingen een andere knop op de code-generator, die naar ik mag aannemen een andere, niet uitwisselbare code oplevert. Fortis gebruikt wel een apparaatje met 'één knop' wat nauwelijks van die van ABN AMRO te onderscheiden.

[DeTeraarist]

Werkt niet, toevallig een paar weken terug geprobeerd met een collega. Een ABN-Pas in een Fortis-Reader.