'Nieuwe' aanval internetbankieren sinds 2009 bekend
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.
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?
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.
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.
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.
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?
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)
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.
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.
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.
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...
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?
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.
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.
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.
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.
https://blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
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.
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.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Cybersecurity Trainer / Full Stack Developer
Ben je toe aan een nieuwe job waarmee je het verschil maakt? Wil jij je security kennis graag delen en hands-on laten zien hoe cybersecurity in de praktijk echt werkt? Werk je net als wij graag samen met enthousiaste en gedreven collega's? Bij ons geen bureaucratie maar open communicatie en een werkomgeving gericht op samenwerking.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?