Om het gebruiksgemak te vergroten, de website te kunnen analyseren en om advertenties te kunnen beheren maakt Security.NL gebruik van cookies. Door gebruik te blijven maken van deze website, of door op de akkoord button te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer weten over cookies? Bekijk dan ons cookieoverzicht.
Nieuws Achtergrond Community
Inloggen | Registreren
Nieuws
image

'Nieuwe' aanval internetbankieren sinds 2009 bekend

zondag 25 mei 2014, 12:30 door Redactie, 19 reacties

Het programma om de 'nieuwe' aanval op internetbankieren uit te voeren die gisteren in het televisieprogramma Kassa werd gedemonstreerd bestaat al sinds 2009. Daarnaast is de aanval alleen mogelijk als onoplettende eindgebruikers uit zichzelf meewerken.

Dat laat Ronald Kingma, CEO van SecureLabs, tegenover Security.NL weten. Zijn bedrijf bouwde het uit 2009 stammende sslstrip verder uit zodat ook het internetbankieren van Nederlandse banken werd ondersteund en er automatisch transacties van bankgebruikers naar andere rekeningen konden worden overgemaakt. De aanval werkte echter alleen als eindgebruikers niet opletten en hun gegevens zelf op een onbeveiligde pagina invullen.

Om de aanval uit te voeren moet een aanvaller zich tussen de bank en de eindgebruiker plaatsen, bijvoorbeeld via een kwaadaardig wifi-hotspot of een aangepaste router of modem. De hotspot, de onderzoekers gebruikten de bekende Pineapple, zorgt ervoor dat als gebruikers naar hun banksite gaan die met HTTPS begint, ze naar een onversleutelde HTTP-versie worden doorgestuurd.

De gebruiker kan dit in de browser zien, bijvoorbeeld door het ontbreken van HTTPS in de adresbalk, het slotjes-icoon of een gekleurde adresbalk. Zodra de gebruiker op deze onbeveiligde pagina zijn gegevens invult zorgt de aangepaste sslstrip-versie ervoor dat de gegevens vervolgens automatisch naar de bank worden gestuurd, alleen met aangepaste rekeninggegevens.

Javascript

Kingma merkt op dat veel eindgebruikers niet zullen opmerken als ze opeens op een HTTP-versie van de banksite uitkomen in plaats van HTTPS. Om de aanval verder te verfijnen stuurt de hotspot JavaScript naar de browser van de eindgebruiker. Deze JavaScript zorgt ervoor dat de gebruiker de oorspronkelijke transactie te zien krijgt die hij dacht gedaan te hebben in plaats van de aangepaste transactie van de hotspot. Aangezien deze JavaScript in de browser actief blijft, zal een gebruiker de frauduleuze transactie pas opmerken als hij op een andere computer gaat internetbankieren of zijn browsercache leegt.

Per toeval

Het probleem werd per toeval ontdekt toen de onderzoekers met de Pineapple aan het spelen waren. Vooral het uitbouwen van sslstrip en ervoor zorgen dat transacties van eindgebruikers automatisch werden aangepast vergde het nodige werk. Kingma merkt op dat deze vorm van het aanvallen van HTTPS al inderdaad sinds 2009 bestaat. Hij wilde met het onderzoek ook de maatschappelijke kant van het probleem aantonen. "Door de bankregels van januari is de bewijslast meer richting de eindgebruiker opgeschoven."

Toen de aanval eenmaal was uitgewerkt werd die aan het Nationaal Cyber Security Center en de banken gedemonstreerd. Kingma merkt op dat de banken het probleem zeer serieus namen, mede omdat ze de frauduleuze transacties zelf niet in hun systemen opmerkten. Ook bleek uit eigen onderzoek van SecureLabs, waarbij er een hotspot zonder de aanvalscode werd opgezet, dat eindgebruikers niet door hadden dat ze naar een onbeveiligde pagina werden doorgestuurd.

HSTS

Om het probleem aan te pakken hebben de meeste banken nu HTTP Strict Transport Security (HSTS) geïmplementeerd, iets wat al sinds maart 2011 door Firefox wordt ondersteund. HSTS moet ervoor zorgen dat er automatisch een beveiligde verbinding wordt gemaakt, wat "man in the middle" aanvallen moet voorkomen. In november 2012 werd besloten om van HSTS een webstandaard te maken. Toch ondersteunt Internet Explorer, ondanks herhaaldelijke oproepen, nog altijd geen HSTS, hoewel wordt aangenomen dat dit bij de volgende versie wel het geval zal zijn.

Details over de aanval wil Kingma pas later vrijgeven, aangezien nog niet alle banken HSTS geïmplementeerd hebben. Gebruikers die zich willen beschermen krijgen dan ook het advies om altijd naar de aanwezigheid van HTTPS in de adresbalk te kijken en te controleren of de banksite over een geldig SSL-certificaat beschikt.

Banken: niet internetbankieren via open wifi-netwerk
VS overweegt om Chinese hackers op conferenties te weren
Reacties (19)
25-05-2014, 12:47 door Anoniem
"Door de bankregels van januari is de bewijslast meer richting de eindgebruiker opgeschoven."
Onzin, er is in januari geen wetswijziging geweest die iets veranderd aan de bewijslast. Dat banken dit graag zouden willen, dat is een ander verhaal, maar is ook een zeer eenzijdig verhaal.

Dus mocht jouw bank niet willen meewerken aan het vergoeden van de schade, stap naar de rechtbank en eis jouw geld terug. Het is de verantwoording van de bank om op jouw geld te passen, dat is nu net het hele idee van een bank...

Of moeten we ons geld maar weer bewaren in een oude sok of onder het matras?
25-05-2014, 12:57 door GeminiAlpha
Heeft ING's gepromote hulpprogramma Trusteer enig nut bij deze kwestie? Voegt EMET veiligheid toe?
Wie kan deze 2 middelen nog eens kort op leken-nivo uitleggen?

Ik gebruik Trusteer (toch al) niet omdat het merkbare traagheid op mijn systeem veroorzaakt. Heb EMET wel aktief.
Hoofdzaak zal wel (weer) zijn, dat je eigen gedrag en oplettendheid de grootste invloed heeft.
25-05-2014, 14:02 door Anoniem
Ik ben niet bekend met Trusteer, dus daar kan ik geen uitspraken over doen.

In EMET kun je SSL certificaten aan bepaalde domeinen/websites hangen. Indien het SSL certificaat van je bank opeens afwijkt (wat een aanduiding kan zijn op een Man-In-The-Middle (MITM) aanval) krijg je hiervan een melding van EMET.
De aanval die nu weer in het nieuws is gekomen, werkt via een MITM aanval. Bij deze aanval wordt de gebruiker naar een HTTP versie van de website omgeleid (bijv. via sslstripper), waarbij kwaadaardige JavaScript wordt geïnjecteerd (zie notitie 1). Om dit te voorkomen kun je in je browser de addon HTTPS-everywhere (https://www.eff.org/https-everywhere) installeren. Hierin moet je als regel instellen dat je bank altijd via HTTPS moet lopen.

Meer informatie over MITM: https://en.wikipedia.org/wiki/Man-in-the-middle_attack
Notitie 1: Deze kwaadaardige JavaScript code bevindt zich niet op de website van de bank zelf, maar wordt door de aanvaller via het netwerk mee verzonden en ingelezen door je browser. Via HTTPS is dit niet mogelijk (tenzij je het certificaat van de aanvaller hebt geaccepteerd), omdat Mixed Content (HTTP + HTTPS) door browsers wordt tegengehouden.
25-05-2014, 15:37 door Anoniem
Zoals anoniem 14:02 al zegt dacht ik zelf ook al direct aan HTTPS-everywhere om zo'n aanval tegen te gaan. Waarschijnlijk moet je wel zelf een regel toevoegen zodat de add-on ook werkt op de site van jouw bank.

Met EMET heb ik geen ervaring, ik gebruik echter wel Hitman Pro Alert, een speciale browser scanner die ook specifiek MITM aanvallen zou moeten detecteren.

Ben ik met de combi HTTPS-everywhere en Hitman Pro Alert voldoende beschermt of loont het de moeite hier ook nog EMET aan toe te voegen? En dan bedoel ik niet alleen tegen dit soort aanvallen maar ook andere.
25-05-2014, 17:10 door Anoniem
Door Anoniem:
"Door de bankregels van januari is de bewijslast meer richting de eindgebruiker opgeschoven."
Onzin, er is in januari geen wetswijziging geweest die iets veranderd aan de bewijslast. Dat banken dit graag zouden willen, dat is een ander verhaal, maar is ook een zeer eenzijdig verhaal.

Dus mocht jouw bank niet willen meewerken aan het vergoeden van de schade, stap naar de rechtbank en eis jouw geld terug. Het is de verantwoording van de bank om op jouw geld te passen, dat is nu net het hele idee van een bank...

Of moeten we ons geld maar weer bewaren in een oude sok of onder het matras?
Sure... Als jij je geld weggeeft aan een crimineel dan is de bank verantwoordelijk. Dat is pas krom.
25-05-2014, 17:11 door [Account Verwijderd] - Bijgewerkt: 25-05-2014, 17:12
[Verwijderd]
25-05-2014, 17:17 door Erik van Straten
Door Anoniem: ... omdat Mixed Content (HTTP + HTTPS) door browsers wordt tegengehouden.
Dat valt tegen, zie http://blog.ivanristic.com/2014/03/https-mixed-content-still-the-easiest-way-to-break-ssl.html.
26-05-2014, 08:11 door Anoniem
Waarom wordt het rekening nummer niet in de verificatie code meegenomen?
Als dat onder water zou vervanderen klopt je signeercode niet meer. (rabo random reader heeft nu al wel als 2e stap het totaalbedrag dus die 3e stap zou er zo bij kunnen)
26-05-2014, 08:17 door Anoniem
Door Anoniem: Zoals anoniem 14:02 al zegt dacht ik zelf ook al direct aan HTTPS-everywhere om zo'n aanval tegen te gaan. Waarschijnlijk moet je wel zelf een regel toevoegen zodat de add-on ook werkt op de site van jouw bank.

Met EMET heb ik geen ervaring, ik gebruik echter wel Hitman Pro Alert, een speciale browser scanner die ook specifiek MITM aanvallen zou moeten detecteren.

Ben ik met de combi HTTPS-everywhere en Hitman Pro Alert voldoende beschermt of loont het de moeite hier ook nog EMET aan toe te voegen? En dan bedoel ik niet alleen tegen dit soort aanvallen maar ook andere.
HitmanPro Alert detecteert geen MitM aanvallen maar MitB aanvallen, dus banking trojans die in jouw browser gaan zitten een gegevens aanpassen(zoals rekeningnummer ontvanger en bedrag).
Als je Internet Explorer gebruikt kan je met EMET het certificaat van je bank aan de site koppelen, en als EMET dan een ander certificaat ziet geeft het een waarschuwing. Dit kan dus wel helpen tegen MitM aanvallen.
Verder beschermd EMET tegen alle soorten malwar/virussen die via exploits op je PC willen binnendringen.
26-05-2014, 08:26 door Anoniem
Toch een tweetal vragen:
1. Stel iemand gaat met zijn ananasroutertje tussen mijn laptop en mijn wireless router zitten. Is dit dan voor mij zichtbaar doordat de naam van mijn netwerk niet meer dezelfde is?
2. Is het bij internetbankieren op enig moment mogelijk om te zien dat de verbinding niet beveiligd is als iemand met z'n ananasroutertje tussen mijn laptop en de bank zit? Ik heb uit de Kassa-uitzending begrepen dat men dan een slotje kan laten zien maar dat dit toch niet hetzelfde is als bij een normale verbinding.
26-05-2014, 08:43 door Anoniem
Details over de aanval wil Kingma pas later vrijgeven, aangezien nog niet alle banken HSTS geïmplementeerd hebben.

Waarom krijgen de banken die HTTP Strict Transport Security nog niet hebben ingevoerd geen boete. Het is één van de meest basic verdedigingen voor websites!! Ongeloofelijk dat dit onbestraft blijft, complete faal van de SOC'ers die dit niet waren opgevallen...
26-05-2014, 08:56 door GeminiAlpha
Door Anoniem: Zoals anoniem 14:02 al zegt dacht ik zelf ook al direct aan HTTPS-everywhere om zo'n aanval tegen te gaan. Waarschijnlijk moet je wel zelf een regel toevoegen zodat de add-on ook werkt op de site van jouw bank.
En hoe moet die regel er dan uitzien? Beetje hulp bij de implementatie kan geen kwaad.
26-05-2014, 09:33 door Whacko
Door Anoniem:
Door Anoniem:
"Door de bankregels van januari is de bewijslast meer richting de eindgebruiker opgeschoven."
Onzin, er is in januari geen wetswijziging geweest die iets veranderd aan de bewijslast. Dat banken dit graag zouden willen, dat is een ander verhaal, maar is ook een zeer eenzijdig verhaal.

Dus mocht jouw bank niet willen meewerken aan het vergoeden van de schade, stap naar de rechtbank en eis jouw geld terug. Het is de verantwoording van de bank om op jouw geld te passen, dat is nu net het hele idee van een bank...

Of moeten we ons geld maar weer bewaren in een oude sok of onder het matras?
Sure... Als jij je geld weggeeft aan een crimineel dan is de bank verantwoordelijk. Dat is pas krom.

Wat is het verschil met skimmen? Daar weet je al gebruiker ook niet dat je geld gestolen wordt. Net zoals met skimmen, valt het niet altijd direct op dat er een MITM attack plaatsvindt.
26-05-2014, 10:28 door Anoniem
Op anoniem 08:26

1) Nee, de naam van je router is hetzelfde (ze doen zich voor als jouw router). Technisch gezien zou het mogelijk kunnen zijn om zo'n aanval te detecteren door het MAC adres te verifiëren (wat uiteraard ook te vervalsen is) of door het aantal hops bij bijv. het pingen van google te bekijken. Voor iemand met een wat mindere technische achtergrond is helaas het antwoord nee.
2) Ja: namelijk in deze aanvallen wordt het verkeerd naar http:// adressen omgeleid ipv https://. Helaas is de laatste jaren steeds meer de trend geworden op de gebruiker zo min mogelijk 'lastig te vallen' met URL's, waardoor het begin van de url onzichtbaar wordt gemaakt (http(s):// gedeelte). In plaats daarvan worden ook kleuren gebruikt (zoals groen) in de URLbalk om aan te geven dat een verbinding beveiligd is. Waar het op neer komt, altijd https:// bij je bankzaken.

Dit soort MITM aanvallen in een notendop: een aanvaller A wil het verkeer van slachtoffer S onderscheppen. Daarvoor doet A zich voor als een wifi station, door de naam van het wifi station O waarmee S wilt verbinden over te nemen. Echter wanneer verbind S met A in plaats van O? Door: 1) dichter bij S te staan dan O (dus beter bereik), 2) door O te DDOSsen, waardoor alleen A beschikbaar is. In de meeste gevallen wordt het verkeer doorgestuurd van A naar O, met als verschil dat A manipulaties op ongeencrypt verkeer kan uitvoeren. Indien S naar de website van bank B gaat, zegt A (via O) dat B een http versie (ipv https) moet sturen. B stuurt http terug naar A, die de website manipuleert en stuurt dit door naar S. Naast dat A JavaScript code injecteert in de website, wordt tevens het icoontje van de website aangepast met een slotje. Aan de hand van de browser van S wordt het website icoontje ergens bij de URL getoond. In de voorbeelden was dat voor de URL, waardoor de website van B veilig leek. De rest is bekend.

Hoe kun je je hier tegen beveiligen? 1) vermijd open wifi stations, 2) indien dat niet mogelijk is, gebruik een VPN verbinding, 3) gebruik een add-on als HTTPS-everywhere, 4) gebruik EMET (zie bovenstaande reacties).

Ben je hiermee helemaal in te dekken? Alleen met VPN heb je goede zekerheid, in de andere opties zijn aanvallen (theoretisch) nog mogelijk.

@anoniem 08:11. Ik ben het helemaal met je eens, ik verbaas mij nog elke dag hierover dat banken als ABN Amro dit nog steeds niet hebben geïmplementeerd.

@GeminiAlpha: Uit een snelle check zie ik dat Rabobank en ABN Amro al standaard erin staan. ING is helaas standaard uitgeschakeld vanwege 'Mixed content' (zie hierboven). Voor het toevoegen van rules zie: https://www.eff.org/https-everywhere/rulesets. Voor minder technische mensen gebruik de FireFox addon HTTPSfinder.
26-05-2014, 10:53 door User2048
Door Anoniem: Toch een tweetal vragen:
1. Stel iemand gaat met zijn ananasroutertje tussen mijn laptop en mijn wireless router zitten. Is dit dan voor mij zichtbaar doordat de naam van mijn netwerk niet meer dezelfde is?
2. Is het bij internetbankieren op enig moment mogelijk om te zien dat de verbinding niet beveiligd is als iemand met z'n ananasroutertje tussen mijn laptop en de bank zit? Ik heb uit de Kassa-uitzending begrepen dat men dan een slotje kan laten zien maar dat dit toch niet hetzelfde is als bij een normale verbinding.
1: De aanval zal niet waarschijnlijk zijn op jouw thuisnetwerk. De aanvaller zou dan op zijn ananasroutertje dezelfde netwerknaam moeten kiezen als die van jouw netwerk en dan moeten proberen om jouw eigen netwerk te "overstemmen", zodat je laptop met de ananas verbindt in plaats van met je eigen router. Waarschijnlijker is dat dit soort aanvallen op openbare netwerken plaats zal vinden. De aanvaller noemt zijn netwerk bijvoorbeeld "Cafe Jansen Wifi" en 10-tegen-1 dat er mensen mee verbinden.
2: Ik heb begrepen dat ze in plaats van het icoon van de website een slotje laten zien. In de adresbalk ziet het er anders uit dan bij een beveiligde verbinding, bijvoorbeeld een rode achtergrond in IE, en geen groen slotje in Chrome.
26-05-2014, 21:28 door Anoniem
Gewoon de internetbankieren App gebruiken, dan is er niets aan de hand. Thuis gewoon bedraad
27-05-2014, 11:20 door Anoniem
Voor meer uitleg kijk ook eens hier:
https://blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
27-05-2014, 15:21 door Anoniem
Door Anoniem: Toch een tweetal vragen:
1. Stel iemand gaat met zijn ananasroutertje tussen mijn laptop en mijn wireless router zitten. Is dit dan voor mij zichtbaar doordat de naam van mijn netwerk niet meer dezelfde is?
2. Is het bij internetbankieren op enig moment mogelijk om te zien dat de verbinding niet beveiligd is als iemand met z'n ananasroutertje tussen mijn laptop en de bank zit? Ik heb uit de Kassa-uitzending begrepen dat men dan een slotje kan laten zien maar dat dit toch niet hetzelfde is als bij een normale verbinding.

Kleine aanvulling op User2048:

1.Als jij met een openbaar netwerk ooit verbonden bent geweest onthoud je laptop of mobile device dit. Als jij in de buurt van de ananas komt, zend jouw telefoon al je netwerken uit met het verzoek om te verbinden. De ananas pakt dit gelijk op en doet zich voor als het openbare netwerk waar je device naar verbinden wou. Gelijkertijd gaat die alle andere (WPA/WPA2) netwerken als een open netwerk aanbieden die jouw device heeft gepubliceerd. Soms geeft een OS dit aan dat dit netwerk nu opeens een open netwerk is ipv een gesloten en komt met een melding. Mac OS X doet dit bijvoorbeeld.
De software die dit kan doen op de ananas ik Karma.
2. Er komt inderdaad een grijs slotje in je browser. Dit is een optie van sslstrip.
27-05-2014, 23:13 door Anoniem
Even checken of ik het allemaal gesnopen heb…

1. Stel ik bezoek een openbare gelegenheid met een free hotspot waar ik al eerder gebruik van heb gemaakt. Iemand wurmt zich met een ananaskassie tussen mijn laptop en deze hotspot en mijn laptop maakt dat tien tegen een verbinding met deze router met alle gevolgen van dien.
2. Er verschijnt in de browser weliswaar een slotje maar dat is niet geheel hetzelfde als een echt slotje maar wijkt o.m. af qua kleur.

De moraal van dit verhaal:
Vermijd in een openbare gelegenheid internetactiviteiten waarbij je gebruikersnaam, wachtwoord of e-mailadres o.i.d. moet invoeren om onderschepping en misbruik ervan te voorkomen. Bezoek gerust de site van het reisbureau maar boek je reis thuis. Internetbankieren moet je sowieso niet doen in een openbare gelegenheid. Gewoon thuis en dan bij voorkeur via een netwerkkabel. Better safe then sorry.

Veel dank overigens voor alle antwoorden.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.

Zoeken
search
Vacature
Image

Senior Security Consultant

Als security consultant bij Cegeka speel je een uitermate belangrijke rol in het veilig houden van de bedrijven in Nederland en de Nederlandse maatschappij. Vandaar ook dat Cegeka dit hoog op de agenda heeft staan. Wij doen dit door, in close cooperation, onze klanten advies te geven op strategisch, tactisch en operationeel niveau.

Lees meer

Wat baart jou momenteel meer zorgen, traditionele criminaliteit of cybercrime?

12 reacties
Aantal stemmen: 1010
Image
BYOD
04-03-2021 door Anoniem

Wanneer mensen een eigen device (BYOD) mee nemen naar werk: hoe bescherm jullie je daartegen? (Ben zelf tegen het gebruik van ...

19 reacties
Lees meer
Is een laptop die via de werkkostenregeling wordt vergoed een privélaptop?
03-03-2021 door Arnoud Engelfriet

Juridische vraag: Bij ons bedrijf is gekozen voor bring-your-own-device, waarbij mensen zelf privé een laptop mogen kopen en ...

19 reacties
Lees meer
De verkiezingsprogramma's doorgelicht: Deel 4 digitalisering
20-02-2021 door Redactie

Een digitaal paspoort, recht op betaalbaar en snel internet, 'digitale inburgering' of digitaal stemmen, het zijn slechts een ...

8 reacties
Lees meer
Certified Secure LIVE Online training
Nieuwe Huisregels en Privacy Policy

Op 5 december 2017 hebben we een nieuwe versie van onze huisregels en privacy policy ingevoerd. Om verder te kunnen gaan dien je eenmalig akkoord te gaan met de nieuwe huisregels van Security.NL.

Op 24 mei 2018 hebben we, in het kader van de AVG, onze privacy policy bijgewerkt. Om verder te kunnen gaan dien je eenmalig akkoord te gaan met de bijgewerkte privacy policy. Heb je vragen neem dan contact op met info@security.nl.

Verzenden
Privacy Policy

Op 24 mei 2018 hebben we, in het kader van de AVG, onze privacy policy bijgewerkt. Om verder te kunnen gaan dien je eenmalig akkoord te gaan met de bijgewerkte privacy policy. Heb je vragen neem dan contact op met info@security.nl.

Verzenden
Inloggen

Bedankt! Je kunt nu inloggen op je account.

Wachtwoord vergeten?
Nieuwe code captcha
Inloggen

Wachtwoord Vergeten

Wanneer je hieronder het e-mailadres van je account opgeeft wordt er een nieuwe activatielink naar je gestuurd. Deze link kun je gebruiken om een nieuw wachtwoord in te stellen.

Nieuwe code captcha
Stuur link

Password Reset

Wanneer je het juiste e-mailadres hebt opgegeven ontvang je automatisch een nieuwe activatielink. Deze link kan je gebruiken om een nieuw wachtwoord in te stellen.

Sluiten
Registreren bij Security.NL

Geef je e-mailadres op en kies een alias van maximaal 30 karakters.

Nieuwe code captcha
Verzenden

Registreren

Je hebt je succesvol aangemeld. Voordat je je account kunt gebruiken moet deze eerst geactiveerd worden. Dit kan je zelf doen middels de activatielink die naar het opgegeven e-mailadres is verstuurd.

Sluiten
Over Security.NL
Huisregels
Privacy Policy
Adverteren
© 2001-2021 Security.nl - The Security Council
RSS Twitter