Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 175, views: 69.933 •

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)

Reactiefilter:-11750168+1147+221+30
Hoe hebben ze het dan voor elkaar gekregen om het gebruik van TAN-codes te omzeilen?

Edit: ij > ei

[Reactie gewijzigd door SaphuA op 26 juni 2012 14:19]

mensen gaan naar een valse site en blijven tan codes invoeren todat ze kunnen inloggen :+ (20 tan codes later: weg geld)
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.
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 26 juni 2012 13:03]

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 Magalaan op 26 juni 2012 13:39]

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!
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.
Volgens mij is het OS onafhankelijk. Herinneren jullie die special nog van Tweakers.net?
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.
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.
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.
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.
Geen aanname, beide genoemde trojans, SpyEye en Zeus, zijn Windows only.
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.
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
@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.
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.
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. :D
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..
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.
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.
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.
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.
Virtueel machientje of Knoppix CD o.i.d. en daarmee bankieren is de meest veilige manier voor internetbankieren
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.
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 26 juni 2012 16:20]

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 26 juni 2012 16:34]

TAN codes komen toch altijd "out-of-band"?
Is het niet via SMS dan is het via de post.
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...
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.
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
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 :?
Ja das dom + dat bij tancodes t bedrag staat wat overgemaakt wordt bij de transactie.
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,-
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...
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 26 juni 2012 18:54]

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.
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.
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 26 juni 2012 13:15]

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.
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 26 juni 2012 13:41]

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
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.
Off--topic: het bedrag wordt niet afgerond, je moet het bedrag voor de komma intoetsen.
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?
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.
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
"Nederlandse bankklanten slachtoffer van miljoenenhack"

Zijn hier de slachtoffers de bank of de klanten? lijkt mij dat de ING dit vergoed.
Lijkt me alleen als het je als klant opvalt, en dan contact opneemt met de ING...
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.
Is dit een grapje of een serieus voorstel?
He wat dom van mij!

Nee het ging er gewoon om dat degene die getroffen zijn op de hoogte worden gebracht.
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 Nozem1959 op 26 juni 2012 17:50]

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."
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
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.
En die vergoeding wordt weer bij de klanten verhaald.
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.
Duh, er is altijd een afweging tussen de kosten van security (en dan niet alleen financieel) en van eventueel risico.
En waar denk je dat potje van gevuld wordt?
..door bij iedereen een tientje van de rekening te halen?
..door bij iedereen een tientje van de rekening te halen?
Weleens van verzekeringen gehoord? Banken zijn ook verzekerd.
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...
Lezen lijkt me, de bank vergoed staat er.
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.
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.
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 26 juni 2012 18:55]

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.
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.
Dus iemand hackt de hacker en ziet de log bestanden?
Ik vind het vooral schitterend dat de "hackers" door gebrek aan beveiliging op hun eigen systeem ontmaskerd werden!
Ik vind het vooral schitterend dat de "hackers" door gebrek aan beveiliging op hun eigen systeem ontmaskerd werden!
Wie zegt dat het hun eigen systemen zijn? Het artikel noemt alleen 'extern opgeslagen mappen' en 'een server (...) in de Verenigde Staten'. De eigenaar van de server wordt niet genoemd.

Toegegeven, het is een grote fout die ze gemaakt hebben. Echter is het natuurlijk mogelijk om als crimineel nog een vangnet te hebben: hack niet vanaf systemen die uiteindelijk terug getraceerd naar jou kunnen worden. Een gehackte server van iemand anders gebruiken (bijvoorbeeld via uiteindelijk een gehackt/open access point) is zeker geen overbodige luxe en zeker niet bij bedragen van 35 miljoen euro. Met zo'n hoog bedrag zal getracht worden om de onderste steen boven te krijgen.

[Reactie gewijzigd door The Zep Man op 26 juni 2012 12:52]

Volgens mij gaat het om een bedrag van 35 miljoen als alle aanvallen geslaagd zouden zijn.

In Nederland probeerden de aanvallers in totaal 35 miljoen euro van circa vijfduizend vooral zakelijke bankrekeningen te halen.
Ontmaskerd is een groot woord. Men weet waar de server stond, welke is gebruikt. Maar hoeveel informatie daar uit valt te halen? De daders lopen nog vrij rond en het geld is weg. Gezien het feit dat de server in de VS stond, zal die wel in beslag zijn genomen. Maar wellicht dat de hackers in staat zijn geweest de server nog tijdig te wissen, dan wel delen volledig te versleutelen.

Ik vraag me af waar dat geld heen gegaan is. Of dat dat dan wordt overgeboekt op een rekening in de VS (die op een valse naam staat) of rechtstreeks naar één of andere bananenrepubliek. Voor hackers is de uit pas binnen als ze het geld cash in handen hebben
Ik kwam er achter dat een vriend van mij het Zeus virus had. Het is echt goed gemaakt. Mensen (gebruikers) moeten echt beter gaan opletten want je bent echt zo de pineut.
Dit noemen ze nu: Een open deur intrappen...
Al vanaf het moment dat de eerste virussen bestaan is dit altijd al een probleem geweest!
Het probleem blijft echter dat, hoe goed je ook oplet, je altijd een potentieel slachtoffer blijft.
Als iemand een zero-day exploit heeft gevonden en een nieuwe variant maakt van Zeus en/of SpyEye zal geen geen enkele virusscanner die herkennen.
De standaard dingen als meuk uit nieuwsgroepen downloaden verhogen het risico! Niet doen dus... Maar wat als je op een legitieme site komt (T-net?) en die blijkt geïnfecteerd te zijn?
Dan ben je alsnog het haasje!
Kan je veel doen om te voorkomen? JA
Kan je het 100% voorkomen? Hééél moeilijk!
Ik kwam er achter dat een vriend van mij het Zeus virus had. Het is echt goed gemaakt. Mensen (gebruikers) moeten echt beter gaan opletten want je bent echt zo de pineut.
Zeus is geen virus, maar een trojaans paard. Uit zichzelf verspreid het zich niet: gebruikersinteractie of een externe drager (zoals een virus) zijn nodig om het geinstalleerd te krijgen.
[...]
Zeus is geen virus, maar een trojaans paard.
Tja... Zo kunnen we nog wel bezig blijven.
We hebben Appels en Peren... Het is beide fruit!
In de volksmond zijn het allemaal virussen... in één woord: ongewenst!
Ik kwam er achter dat een vriend van mij het Zeus virus had. Het is echt goed gemaakt. Mensen (gebruikers) moeten echt beter gaan opletten want je bent echt zo de pineut.
en hoe kwam je daar achter?
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)?
Klopt, in ieder geval is dat zo bij de Rbank.
Wel opvallend dat dat sinds deze week ook bij kleinere bedragen vereist is... :Y)
Die wijziging dat het ook bij kleine bedragen nodig is is ingevoerd eind mei/begin juni :)
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.
Dat van het bedrag was keurig vooraf aangekondigd bij de mededelingen.
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.
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 :P
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
35 miljoen over 5k rekeningen? dat is meer dan 2500 per rekening hoor
Er staat gemiddeld 2500
Hoe kan het gemiddelde van 35 miljoen / 5k = 7000, dan 2500 zijn? Succes.
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.
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 26 juni 2012 14:10]

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..
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.
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."
Echter. Bij die onderhoudspagina ontbreekt de "s" bij "https:\\"
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.
Het is mij bij dit soort berichten altijd volstrekt onduidelijk hoe die two-factor authentication omzeilt wordt. Tuurlijk, je kan de website vervalsen op het moment dat mensen hun tan code gaan invullen, zodat die naar de aanvaller gestuurd wordt en niet naar de Bank, maar daar is in dit geval geen sprake van. Iemand enig idee hoe bij dit soort fraudes de two factor authentication ontweken wordt?
Iemand enig idee hoe bij dit soort fraudes de two factor authentication ontweken wordt?
Lees mijn eerdere reactie voor een voorbeeld. Hetzelfde principe kan ook gebruikt worden met TAN codes en SMS verificatie.

Een alternatief kan natuurlijk ook zijn om via een browserplugin de gebruiker zijn normale zaken te laten doen en alleen op de achtergrond de rekeningnummers van alle gemaakte transacties te wijzigen. Zakelijke gebruikers hebben vaak een lange betaaltermijn. Tegen de tijd dat zij erachter komen (herinneringen over rekeningen die al betaald zouden moeten zijn) is het al te laat. De buit is dan de waarde van alle gemaakte transacties.
[...]
Lees mijn eerdere reactie voor een voorbeeld. Hetzelfde principe kan ook gebruikt worden met TAN codes en SMS verificatie.
Als mensen niet lezen maakt het niet uit wat voor verhaal je ophangt. Er staat druk op S en dus drukken ze op S.
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.
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 26 juni 2012 13:01]

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....
Hoezo? Of je nou tekst of een afbeelding moet manipuleren als "man-in-the-browser", de vector (trojan) blijft hetzelfde.
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 26 juni 2012 14:25]

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.
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 26 juni 2012 15:34]

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.
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.
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 26 juni 2012 13:06]

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...
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è ;)
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.
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.
Kortom ze hebben 2x een betaling gedaan :) wie zet er nou een (gemiddelde)oen achter een rekening van een miljoen.
de eerste two-factor authentication is voor de daadwerkelijke inlog, de 2de is voor de betaling. Dus er heeft 1 betaling plaatsgevonden
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
Plus dat je tegenwoordig het afgeronde bedrag er ook nog eens bij moet aangeven als je betaald (S).
Dit zat afgelopen week in mij spam box:
--------

Om de veiligheid te waarborgen van onze online klanten database vragen wij uw login informatie te valideren.

U bent verplicht om onze online validatie formulier in te vullen door te klikken op de volgende link.

Klik hier om het online formulier te openen (dit was de hyperlink)
Opmerking: Deze beveiligingsmaatregel is bedoeld om uw persoonlijke informatie te beschermen tegen onrechtmatig gebruik door anderen.

Gelieve alle gegevens correct in te vullen om blokkering van uw rekening te voorkomen.

Hartelijk dank voor uw medewerking

Hendrik Borsboom
IT Security Assistant
ING

------------------
ook van western union NL was er een identieke versie.
Dat is gewoon een phishing mail en dat is weer iets anders. Een bank vraagt nooit om je gegevens. Dus daarin trappen is stom.
En ik kreeg daarnet 3x het volgende binnen (ook al ben ik belg)
Geachte klant,
Wij hebben een aanvraag gekregen om 500 euro van Uw Rabobank rekening afteschrijven om de levering van de documenten te betalen.
Het afschrijven van het geld en het sturen van de documenten zal in 48 uren gebeuren.

Om het detail van de bestelling te zien klikt a.t.b. *hier* .
Om de bestelling terug te trekken, klikt a.t.b. *hier*.

Het detail van de bestelling:
Datum van verstuur: 26.06.2012
Afzender: Belastingsdienst
Type: expres

Met besten groeten,
Het dienst van klanten support van ABN AMRO^
Natuurlijk, als iemand op zo een link klikt, god weet waar ie uitkomt.
Heb ik vanmorgen ook in mijn lokale spambak ontvangen, 4x een afschrijving voor ABN-Amro, 3x voor Rabobank, z.g. afkomstig van noanswer_* at Rabobank.nl en in de voet een bericht van Marktplaats over veilig handelen. Natuurlijk voorzien van diverse "klik" links.

Edit: blijven steeds maar binnenkomen waarbij het nummer achter noanswer_ steeds anders is. Nu maar even handmatig een regel in Mailwasher aan gaan maken zodat ik ze helemaal niet meer te zien zal krijgen. het zijn er vandaag ondertussen een stuk of 10 tot nu toe.

[Reactie gewijzigd door hardware-lover op 26 juni 2012 19:45]

Idem, een stuk of 20 keer hier binnengekomen inmiddels. Allen (zogenaamd) van noanswer_***@rabobank.nl

Maar dat soort mailtjes zijn te makkelijk, het taalgebruik is dermate triest dat daar werkelijk niemand in trapt mag ik hopen.
Da's al een flinke vooruitgang, bij mij zijn de phishingmails in dergelijk slecht Nederlands dat je echt het intellect van een kanarie met issues moet hebben om er in te trappen.

Zo te zien was er hier overigens niet sprake van phishing, maar een trojan die het vuile werk deed.

Er was trouwens net een soortgelijk bericht over 12000 van onze zuiderburen, zou het gerelateerd zijn?

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBTablets

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

Beste nieuwssite en prijsvergelijker van het jaar 2013