'Beveiligingslek maakt manipuleren transacties internetbankieren mogelijk'

Beveiligingsonderzoekers hebben een methode gevonden om transacties bij internetbankieren zo te manipuleren dat geld naar een verkeerde rekening wordt overgemaakt. De methode werkt door het uitschakelen van de versleutelde verbinding. Vooral Internet Explorer is vatbaar.

Het onderzoek werd uitgevoerd door SecureLabs in samenwerking met NU.nl, zo meldt laatstgenoemde. Door een wifi-hotspot op te zetten waarop malware werd geïnstalleerd slaagden de onderzoekers erin om transacties te onderscheppen. Zij schakelden de versleutelde verbinding van de bank naar de gebruiker uit, terwijl andersom de versleuteling bleef bestaan. Vervolgens werd in de adresbalk van de browser, waarmee de gebruiker poogde te internetbankieren, een slotje getoond wat de valse illusie van een beveiligde verbinding moest geven. Tenslotte slaagden de onderzoekers erin om de bankrekening waarnaar geld wordt overgemaakt aan te passen, waardoor kwaadwillenden geld naar hun eigen rekening kunnen overmaken.

Omdat de gebruiker het originele bankrekeningnummer krijgt te zien in de transactie valt het misbruik niet op. Daardoor kan er bij een nieuwe transactie opnieuw ongemerkt geld worden overgemaakt naar de rekening van de hackers. De door de beveiligingsonderzoekers opgezette methode werkte bij de geteste banken, waarbij geen namen werden genoemd, maar ook bij webwinkels en boekingssites.

De door de onderzoekers toegepaste hackmethode werkt alleen als er geen gebruik wordt gemaakt van http sts, een protocol dat vereist dat alle communicatie tussen server en gebruiker via https verloopt. Alhoewel de meeste browsers en banken dit inmiddels ondersteunen geldt dit voor Internet Explorer nog niet. Wel heeft Microsoft bevestigd dat het http sts gaat ondersteunen in Internet Explorer 12.

De Betaalvereniging Nederland, waarvan de meeste banken lid zijn, geeft in een reactie aan dat gebruikers openbare, onbekende wifi-hotspots beter kunnen vermijden als het gaat om internetbankieren en online aankopen. Volgens de onderzoekers is het in theorie echter ook mogelijk om de methode toe te passen op een met malware besmette router. Er zouden echter nog geen gevallen van misbruik zijn ontdekt. Ook het Nationaal Cyber Security Center kwam met een waarschuwing naar aanleiding van het aangetoonde beveiligingslek.

Volgens NU.nl komt het probleem alleen voor bij internetbankiersessies in de webbrowser. Mobiele apps die banken voor internetbankieren hebben uitgebracht zouden niet vatbaar zijn.

Door RoD

Forum Admin Mobile & FP PowerMod

25-05-2014 • 02:08

165

Reacties (165)

165
156
95
17
3
36
Wijzig sortering
Bij deze aanvalstactiek wordt gebruik gemaakt van het veranderen van de favicon in een slotje. Een relatief bekende methode voor hackers die inspeelt op deceptie. En je kan dus wel degelijk zien wanneer er iets niet pluis is!

Goed in de gaten houden hoe je ssl verbinging eruit ziet - in alle populaire browsers is er naast een slotje tevens een groene kleur te zien bij een beveiligde verbinding met de bank. Dit slotje staat nooit op dezelfde plek als een favicon. Zijn deze ssl kenmerken aanwezig, dan is er geen reden tot zorgen met betrekking tot de aanvalsmethode uit dit artikel.

Edit: zoals hieronder wordt aangegeven is de balk ook groen bij IE. Dit heb ik ff aangepast in de tekst.

[Reactie gewijzigd door Miks op 23 juli 2024 08:25]

Anoniem: 63628 @Miks25 mei 2014 03:12
In IE is de adresbalk ook gewoon groen bij SSL hoor. En dat favicoontje staat aan de andere kant van het SSL slotje, net als bij die andere browserts.

Echter onderschat jij het gebrek aan intelligentie van vele gebruikers aanzienlijk. De meesten snappen echt niet waar dat kleurtje in de adresbalk voor is hoor en ook niet waar dat icoontje wel of niet hoort te staan.
Heeft niets met "intelligentie" te maken maar met (obscure computer)kennis. Informatie die er niet uitziet alsof de gebruiker actie moet ondernemen en die niet toegelicht wordt in de browser zelf is informatie die de gebruiker niet geacht moet worden te kennen.

"Oh, je staat in panne met je wagen? Eigen schuld! Je had het maar moeten zien aankomen! Welke onintelligente bestuurder snapt nu niet dat als je je wagen zijwaarts op een helling naar links parkeert met de automaat in N dat de versnellingsvloeistof niet meer tot bij de pomp geraakt! DUH! NOOB!"
EV certificaten maken in elke browser de balk groen. Zo'n beetje alle banken hebben een EV... Zou ook raar zijn als ze 't niet hebben.
In het Kassa programma werd gesteld dat dit probleem is opgelost door de banken, echter is dit voor de volgende banken niet het geval:
- SNS Bank, geen ssl op hoofdpagina en geen hsts op bankieren gedeelte
- Triodos, geen ssl op hoofdpagina en geen hsts op bankieren gedeelte
- ASN Bank, geen ssl op hoofdpagina en geen hsts op bankieren gedeelte
- Deutsche Bank, wel ssl maar geen hsts op hoofdpagina, geen hsts op bankieren gedeelte, tevens zeer onduidelijke en onlogische domeinen/webadres, dus eenvoudig te manipuleren.
- Friesland Bank, geen ssl op hoofdpagina, ssl op bankieren gedeelte niet in orde, wel hsts op bankieren gedeelte
- BNP Paribas Fortis, wel ssl maar geen hsts op zowel hoofdsite als bankieren gedeelte
- DigiID, geen hsts, zijn de specialisten van overheid hier niet van op de hoogte gesteld?

Mensen die via de homepage op inloggen of internetbankieren klikken lopen nog steeds dezelfde risico's zoals in dit artikel wordt beschreven.

Op de homepage van deze banken is SSL niet actief, of geen EV certificaat. De knop/link om naar internetbankieren te gaan is dus domweg alsnog door een hacker aan te passen naar een onbeveiligde site/link. Als die link iets anders is, maar er wel logisch uit ziet, dan waar hsts header voor opgegeven is wordt hsts dus omzeilt. De banken/website moeten dus ook op hun hoofdsite ssl en hsts instellen, niet alleen op het internetbankieren gedeelte.

Ik heb gecontroleerd of de andere banken hsts op hun homepage wel heeft ingesteld, of alleen op hun internetbankieren subdomeinen. De banken die het wel op orde hebben: ABN Amro, Rabobank en ING. Hier staat hsts ingesteld op minimaal 100 dagen. Andere banken heb ik niet bekeken.

In het artikel wordt Ideal niet expliciet genoemd, het is hiervoor echter wel van toepassing. Vrijwel alle webwinkels gebruiken tot aan de betaling/inloggen geen ssl. Via man in the middle kunnen webadressen voor het uitvoeren van betalingen eenvoudig worden gemanipuleerd, zodat er bijvoorbeeld geldt wordt overgeboekt naar een andere webshop dan bedoeld (die van de hackers). De conclusie is volgens mij dat zolang de gehele sessie voorafgaand aan betalen via ssl met hsts loopt dit probleem vermeden wordt, echter zijn er heel veel manieren waarbij voorafgaand aan betalen geen ssl en hsts gebruikt word.

[Reactie gewijzigd door barbarbar op 23 juli 2024 08:25]

als dit zo is, hoe kunnen we hier dan als tweakers gelijk MS en IE de grond opnieuw inboren, terwijl de banken zelf de verbinding niet op orde hebben?
Dat IE hsts momenteel niet ondersteund is wat onhandig van Microsoft, de standaard is beschikbaar sinds oktober 2012.
Dat banken hun zaken niet op order hebben betreffende dit probleem is ook ongelukkig, maar niet het voornaamste probleem.

Het voornaamste probleem is in mijn ogen de eenvoud waarmee de duidelijkheid van een beveiligde verbinding in browsers is verminderd. Als je de presentatie bekijkt waarop sslstrip is gebaseerd zie je dat het heel lastig is om uberhaupt te zien of een verbinding beveiligd is. Het probleem is dus meer een algemeen browser en websitedesign probleem.

Tevens is hsts niet zaligmakend. Zoals ik aangeef met ideal betalingen bij webshops, werkt hsts alleen als je die webshop eerder hebt bezocht. Tevens is de kans groot dat de aanval wordt gedaan op terrassen en in restaurants, waarbij je waarschijnlijk je mobiel of tablet gebruikt. Hiermee is de kans groter dat je de beveiliging over het hoofd ziet, en hsts is minder effectief omdat je een webshop wellicht thuis op je laptop hebt bekeken, en via je telefoon tijdens de lunch die nieuwe schoenen besteld. Je mobiel kent die site dus niet, dus de hacker stript domweg hsts eruit.

Zoals in andere posts aangegeven is het gewoon niet slim via openbare hotspots belangrijke zaken te regelen, zoals o.a. betalingen en belastingen.

Tevens is de opmerking van Brenno de Winter over het gebruik van een vaste netwerk kabel ook niet zaligmakend. Het is voor een hacker bij veel bedrijven ook eenvoudig om het bedrade netwerk te infiltreren met eenzelfde kasje, welke heel erg lang onopgemerkt kan blijven, zoals in scholen bijvoorbeeld.

De opmerking van Brenno de Winter om met de mobiele app de betaling te controleren is wel nuttig, echter is het kwaad dan al geschied.

[Reactie gewijzigd door barbarbar op 23 juli 2024 08:25]

Het is nog geen standaard. Ach je bent zeker niet de eerste die deze fout maakt...
Als je de presentatie bekijkt waarop sslstrip is gebaseerd zie je dat het heel lastig is om uberhaupt te zien of een verbinding beveiligd is. Het probleem is dus meer een algemeen browser en websitedesign probleem.
Dat is ook de reden dat Firefox en Chrome beide geen 'favicon' (website icoon) meer ondersteunen since ergens in 2012 of eerder. Dus daar is dat al opgelost.
De hele MitM aanval met een wifi pineapple met Jasager firmware kan al enkele jaren uitgevoerd worden. O.a. het 'stelen' van wachtwoorden is uitermate makkelijk. Ik geef hier zelf regelmatig presentaties over binnen een overheidsinstantie. Overigens heb je die hele wifi pineapple niet nodig, er zijn diverse scripts te vinden die hetzelfde doen. Alleen met een pineapple is het wel heel erg makkelijk.

Ik heb bij Brenno en Securelabs geprobeerd los te krijgen wat zij qua extra infusions op de pineapple hebben gebruikt (er wordt in de reportage gesproken over eigen gemaakte software om het bankrekening nummer te beïnvloeden), maar hier krijg ik geen antwoord op. Securelabs reageert helemaal niet. Het zou ze juist sieren als ze de attack vector beschrijven in een whitepaper.

Mijn vermoeden is dat zowel Kassa en met name Nu.nl graag toehappen om het volgende grote 'lek' in Nederland als eerste te brengen. Sowieso zal het percentage gebruikers wat op een open wifi netwerk bankiert via een browser meevallen. Het meeste wordt een app gebruikt, waar vaak al tweezijdig SSL wordt gebruikt.

Daarnaast zouden banken kunnen stoppen met het aanbieden van hun sites over http en alleen https gebruiken.

Het komt bij mij een beetje over als willen scoren met een 'groot' lek. Had ik niet van Brenno verwacht. Wel van Ronald Kingma.
Het zou ze juist sieren als ze de attack vector beschrijven in een whitepaper.

Waarom zouden ze een andere manier om mensen te bestelen vrijgeven aan mensen die het niet aangaat?
Dat is vragen om problemen geef het aan de banken en makers van wifi hardware die het probleem hebben.
Niet alle wifi hardware kan immers zomaar aangepast worden en die hardware is dan ook gewoon veilig. Het gaat alleen om bepaalde types.
Zo is mijn tp-link waarschijnlijk extra vatbaar omdater opensource firmware op kan draaien.
Maar dan nog moeten ze wel eerst op mijn netwerk komen om de firmware te flashen.
Omdat zoiets als security through obscurity niet bestaat. Vroeg of laat zal er iemand achter komen en het gebruiken. Dan zijn partijen niet aangespoord om noodzakelijke patches aan te brengen. Je ziet nu al dat niet alle banken HSTS gebruiken.

Daarnaast vind ik dat er nu iets geroepen wordt wat niet geverifieerd kan worden. In wetenschappelijke termen is iets pas bewezen als dezelfde test nogmaals uitgevoerd kan worden en het zelfde resultaat wordt behaald.
Vroeg of laat is nog altijd beter dan gister en de banken geen tijd geven om het op te lossen..

Dat is net als het slot van je voordeur vervangen en criminelen de sleutel geven voordat het slot in je deur zit.

Geef de banken desnoods een ultimatum. 3 maanden en dan geven we het vrij.
Dat geeft tijd zat om het op te lossen.
De banken hebben ruimschoots de tijd gehad. Er is afgesproken pas op 24 mei, vlak voor de Kassa uitzending het 'nieuws' naar buiten te brengen. Daarvoor is al overleg met het NSCS geweest.
Dit is een klassieke Man-In-The-Middle aanval met sslstrip om te zorgen dat je niet beveiligd verbind met de bank. Dit is al jaren bekend en niks nieuws.

NU.nl wil de eerste zijn die over een nieuwe heartbleed rapporteerd. Dus SecureLabs mixt het met hotspot spoofing en doen alsof ze een heel nieuw lek hebben gevonden.

[Reactie gewijzigd door Armada651 op 23 juli 2024 08:25]

Dit is voornamelijk een marketing stunt van SecureLabs. Deze hack (man-in-the-middle / SSL intercept-rewrite) is gewoon bijna kinderspel. En, het is bij mij al lang bekend.

Het is goed dat ze nu weer even de publiciteit opzoeken om "jan modaal" hier van op de hoogte te brengen maar nieuws is dit dus niet. Meer reclame voor SecureLabs.
Het is sowieso geen goed idee om data van enige betekenis te verzenden via publieke wifi. Ook je eigen router is niet veilig, als men kans ziet deze te overstemmen met een fake accespoint.
Bankzaken doe ik daarom alleen vanaf een vaste, bedraade, verbinding.
Een fake accesspoint die dan dus ook nog toevallig dezelfde wachtwoord gebruikt. Jouw situatie lijkt me alleen relevant als je geen beveiliging op je draadloze verbinding hebt of als je een heel simpel wachtwoord gebruikt wat zomaar te raden is.

[Reactie gewijzigd door MadEgg op 23 juli 2024 08:25]

Een fake hotspot kan je ook zo inrichten dat alle wachtwoorden worden geaccepteerd. Op die manier kan je ook makkelijk achterhalen wat de wachtwoorden zijn van andermans netwerken. De hotspot ziet dat jij SSID 'blabla' zoekt, zegt dat hij dat is en accepteert vervolgens elk wachtwoord.
Zie ook: https://hakshop.myshopify.com/products/wifi-pineapple
En: http://null-byte.wonderho...t-eavesdrop-data-0147919/
Die links die jij geeft gaan over WEP, dat wordt al geruime tijd afgeraden en alle nieuwe routers van de afgelopen jaren gebruiken standaard WPA2.

Ik moet zeggen dat ik geen diepgaande kennis van draadloze beveiliging heb, maar als mijzelf een voorstelling maak van hoe dat zou gaan zou ik vermoeden dat de passphrase die je instelt om verbinding te maken gebruikt wordt om je data de encrypten alvorens het naar de access point te versturen. Als de access point dezelfde encryptiesleutel heeft kan hij het ontcijferen en kan de verbinding tot stand gebracht worden, maar als de access point zelf niet dat wachtwoord heeft dan kan hij er niets mee. Op die manier zou je dus nooit elk wachtwoord kunnen accepteren omdat je dan simpelweg de communicatie niet kunt ontcijferen.

Correct me if I'm wrong, maar als dit op een andere manier is geïmplementeerd dan mijn overdreven basale voorstelling vraag ik me af wat de ontwerpers van die encryptiemethoden ophadden toen ze het ontworpen... 8)7
Gaat ook om WPA2;
http://null-byte.wonderho...sing-aircrack-ng-0148366/
http://null-byte.wonderho...ds-with-cowpatty-0148423/
http://null-byte.wonderho...cracking-wps-pin-0132542/
https://code.google.com/p/reaver-wps/

En om MITM uit te voeren heb je niet altijd authenticatie nodig op wifi.

"vraag ik me af wat de ontwerpers van die encryptiemethoden ophadden toen ze het ontworpen.."

Tja, dat is toch bij vrijwel alles zo? PIN is vaak ook kinderlijk eenvoudig te omzeilen. Zie bv; https://www.youtube.com/watch?v=szgwaYajKHA (Pin and Chip is broken)

Achteraf lijkt het vaak eenvoudiger en dankzij door ontwikkeling wordt het ook eenvoudiger om toe te passen. Maar er ligt veel kennis en inzicht aan ter grondslag.
klopt. Vermijd open wifi hotspots

[Reactie gewijzigd door Miks op 23 juli 2024 08:25]

Bankzaken doe ik daarom alleen vanaf een vaste, bedraade, verbinding.
Misschien gaan we ooit wel weer terug naar de situatie dat je bankzaken en echte belangrijke dingen alleen bij een loket van een echte bank doet?

Een terugkeer en heropening van de loketten cultuur? Wie weet...
Dit is gewoon een klassieke man-in-the-middle attack. Snap niet waarom ze dit een "beveiligingslek" noemen.
HSTS is ook geen waterdichte oplossing voor deze aanval. Je bent namelijk afhankelijk van een lijst met websites die wordt gepreload in je browser.

Het is en blijft gewoon belangrijk dat je zelf controleert of het certificaat van de website waar je op zit, wel een geldig certificaat is. En je kunt je natuurlijk afvragen of het wel slim is om op een openbaar (meestal unencrypted) wifi netwerk, belangrijke bankzaken te regelen.
Het is en blijft gewoon belangrijk dat je zelf controleert of het certificaat van de website waar je op zit, wel een geldig certificaat is. En je kunt je natuurlijk afvragen of het wel slim is om op een openbaar (meestal unencrypted) wifi netwerk, belangrijke bankzaken te regelen.
Zolang de end-to-end verbinding encrypted is maakt het niet uit of het netwerk vertrouwd is, dus het hotspot argument is niet zo relevant. Met een vaste verbinding zijn alle hops naar de bankserver ook niet vertrouwd, dus 1 onvertrouwde hop erbij kan dan ook nog wel.
Het 'preloaden' kan je thuis hebben gedaan of op een andere goede verbinding. Dan zit je browser goed voor de komende tijd vast getimmerd op HTTPS.
Quote:
"HTTP Strict Transport Security (HSTS) is a web security policy mechanism whereby a web server declares that complying user agents (such as a web browser) are to interact with it using only secure HTTPS connections. It is communicated by the server to the user agent via a HTTP response header field named 'Strict-Transport-Security'."

Nog een quote, nu uit het artikel:
"De Betaalvereniging Nederland, waarvan de meeste banken lid zijn, geeft in een reactie aan dat gebruikers openbare, onbekende wifi-hotspots beter kunnen vermijden als het gaat om internetbankieren en online aankopen. Volgens de onderzoekers is het in theorie echter ook mogelijk om de methode toe te passen op een met malware besmette router"
Maken ze daar nog fysieke producten dan? :P
Ik dacht dat alle routers uit china kwamen :)
goede zaak dat dit aangetoond is. zelf zou ik niet internetbankieren op een (voor mij) onbekende hotspot maar dat ben ik natuurlijk.

al vereist deze methode zo te lezen vrij veel uitzoek en voor-werk om te verrichten kan het veel schade opleveren
Helaas denkt iedereen dat het te moeilijk is om de methode toe te passen maar een hotspot heb je binnen enkele minuten opgezet binnen linux (kali) hierna een kwestie van https (poort 443) laten vewijzen naar 80, dus je tikt https in en je komt op de http site, hierna is het een kwestie van zelf even een x aantal pakketjes versturen en alles monitoren, zo weet je dus hoe het pakketje eruit ziet en zo kun je dus ook het pakketje manipuleren wanneer het verstuurd wordt. Ook in de browser een certificaat kan gemanipuleerd worden..

Mijn uitleg is misschiens wat te simpel maar het is duidelijk dat je hier geen raketgeleerde voor hoeft te zijn..

Kwalijke zaak..
dus je tikt https in en je komt op de http site
Waarna de bank dus ziet dat je geen https gebruikt terwijl dat wel zou moeten omdat het immers daarvoor net een https sts header heeft verstuurd. Die header zou de hacker er dus ook eerst uit moeten halen. Dat is een bekende kwetsbaarheid van hsts.
Die header zou de hacker er dus ook eerst uit moeten halen. Dat is een bekende kwetsbaarheid van hsts.
Hiervoor is de lijst met preloaded HSTS websites uitgevonden. Deze zitten ingebakken in Chrome, Firefox en andere browsers die STS ondersteunen. Door deze lijst hoeft de website zelf geen sts header meer te sturen en kan een man-in-the-middle dit ook niet meer verwijderen.

De volledige lijst voor Googe Chrome staat hier. Wat mij verbaast is dat daar geen enkele Nederlandse bank op te vinden is. Google geeft zelf aan dat je contact kan opnemen met agl@chromium.org als je op de lijst terecht wilt komen. De lijst wordt gedeeld met Firefox, dus je hoeft dit maar 1 keer te doen.

Lieve ING, Rabo, ABN AMRO en andere banken (er zijn vast tweakers die daar werken en dit lezen), zouden jullie dat deze week AUB willen doen?

[Reactie gewijzigd door janderk op 23 juli 2024 08:25]

Wat een vreselijke oplossing, lijstjes met domeinnamen hard coded in een webbrowser...

Lieve ING, Rabo, ABN AMRO en andere banken, doe a.u.b. niet aan deze onzin mee. In plaats daarvan, draag bij aan een echte oplossing voor man-in -the-middle attacks. Ook het http sts protocol is geen waterdichte oplossing, blijkt wel weer...
Ik ben het helemaal met je eens. Maar beter iets dan niets zou ik zeggen. Voor de korte termijn is dit in elk geval een doekje voor het bloeden.

Dat geeft dan vervolgens tijd voor een echte oplossing. Wat ongetwijfeld een hoop tijd gaat kosten om te vinden en te implementeren.
Eens.

Overigens is dit 'onderzoek' van NU.nl totale kul. Men doet alsof men een nieuw iets gevonden heeft, wat echter al jaren bekend is. En het is ook geen lek zoals de titel stelt. Er is namelijk niets lek, maar het is gewoon een klassieke DNS-spoof met een phishing website.

De implementatie details worden niet helemaal duidelijk, maar zoals Tweakers het formuleert (andere websites zijn echter nog vager) lijkt het erop dat men deze phising site nu zo instelt dat het ecffectief een MITM aanval uitvoert. Men spreekt over 'uitschakelen' van SSL, maar er wordt dus eigenlijk niets uitgeschakelt. Het blijft dus in de kern social engineering, en geen lek in enige protocol.

Er zijn op Tweakers ook al talloze varianten voorbij gekomen. Denk aan de WiFi hotspots van Ziggo discussie waar de WiFi hotspot geen certifciaat heeft. In die zin inderdaad tijd voor een betere oplossing.

De STS aanvulling op HTTPS (HSTS) is een mooie aanvulling, maar niet meer dan dat. Immers het vereist een opt-in van de server. Plus het werkt enkel bij HTTP, maar niet bij email, chat, voip, etc.

Microsoft ondersteunt vreemd genoeg nog geen STS, maar in Windows Phone heeft bijvoorbeeld wel een andere beveiliging tegen dit soort trucs. Windows Phone gebruikt namelijk niet de DNS van de WiFi, maar indien beschikbaar, altijd die van je provider. Dat kost je een klein beetje data, maar voorkomt DNS spoofing via vage WiFi hotspots. Ook werkt dit bij alle protocollen en niet enkel HTTP en vereist ook geen server opt-in. Nadeel is dat bij geheel geen data verbinding deze optie wegvalt.

Ook dit is dus niet perfect, maar het geeft aan dat er meer oplossingen mogelijk zijn, en waarschijnlijk een combinatie van oplossingen nodig zijn.

Tot die tijd zijn er 3 simple tips die dit 100% voorkomen

1) ga niet op vage WiFi hotspots telebankieren
2) kijk of er een slotje is. Een echt slotje en geen icoon.
3) type explciet https:// voor een URL en pas je bank-bookmarks aan.
Microsoft ondersteunt vreemd genoeg nog geen STS, maar in Windows Phone heeft bijvoorbeeld wel een andere beveiliging tegen dit soort trucs. Windows Phone gebruikt namelijk niet de DNS van de WiFi, maar indien beschikbaar, altijd die van je provider. Dat kost je een klein beetje data, maar voorkomt DNS spoofing via vage WiFi hotspots. Ook werkt dit bij alle protocollen en niet enkel HTTP en vereist ook geen server opt-in. Nadeel is dat bij geheel geen data verbinding deze optie wegvalt.
Dat lost ook niets op. Als een aanvaller het Wifi netwerk onder beheer heeft kan hij naast DNS ook net zo gemakkelijk de routing tabellen aanpassen.

Behalve de tips die je geeft kun je natuurlijk ook een veilige VPN verbinding of SSH tunnel opzetten naar een systeem wat je wel kunt vertrouwen.
Klopt, maar routingtabellen vereist meestal een complexe routering. Banken zijn meestal verschillende domeinen. Alleen al de login- en executing server zijn twee verschillende. Plus dat sommige banken aan caching servers doen, en dus de IP per regio/per DNS server verschillend is. Dan routeer je er eentje weg, en blijkt de gebruiker opeens een andere IP te gebruiken.

Ik voorspel dus dat ze gewoon DNS spoofing gebruiken als eerste stap, al laat ik me graag corrigeren. Maar de informatie zoals gegeven is redelijk arm, zelfs als ik naar NU.nl zelf ga.

Maar je hebt gelijk feiloos is bijna niets als een hacker écht wil. Vandaar dat een VPN altijd aan te raden is als je perse op een potentieel onveilig netwerk wil telebankieren.

Overigens is https:// typen voor www.rabobank.nl ook genoeg in dit geval. Voor mijn niet-techneuten in de familie, heb ik dat altijd in alle bookmarks aangepast. 'Lui' klikken wordt dan beloond :)
Complexere routing ? Als het om een Wifi hotspot/AP gaat ?

Meestal is het gewoon default route aanpassen naar ander IP-adres, klaar.

Complexiteit is daarbij niet van toepassing.
Meestal is het gewoon default route aanpassen naar ander IP-adres, klaar.

Ales je alles wilt omrouten wel, maar het valt wel erg snel op, als www.google.nl intypen opeens op de rabobank uit komt.

En ga je selectief routen kom je er snel achter dat dat niet eenvoudig is om de redenen zoals gegeven.
Ik vraag me sowieso af waar ze dat nepslotje dan plaatsen. Ik heb ofwel een wereldbolletje, ofwel een slotje, in Firefox. Maar wacht, ik meen me nu te herinneren dat Firefox een tijd geleden geswitcht is, zodat er nu geen website-icoon op die plaats kan staan, wat vroeger wel kon. Als dat inderdaad kon/kan is dat wel heel dom en slecht van een browser...! Dan zou het slotje geen enkele zin hebben.

http://i.imgur.com/z4eFDq9.png
http://i.imgur.com/iSyWC76.png
Ja hoor, net gechecked.

IE plaatst nog steeds vrolijk een website icoon voor de website URL.
En op dezelfde plaats nog wel als waar het slotje verschijnt? Echt dom, reden genoeg om geen IE te gebruiken...
IE plaatst nog steeds vrolijk een website icoon voor de website URL.

Klopt, maar het slotje staat er sinds IE10 achter, dus echt verwarrend lijkt me dat niet ... O-)

[Reactie gewijzigd door Armin op 23 juli 2024 08:25]

Zet een ssl-stripping proof of concept op en kom er zelf achter dat ssl-striping niet meer werkt bij deze banken. Dat zal vast meespelen waarom ze STS nog niet geïmplementeerd hebben, bedoel als ze alles willen implementeren waarmee browsers mee komen wordt het ook onbegonnen werk.
Het hoeft maar 1x goed te hebben gewerkt. Bijvoorbeeld thuis of op je werk. Als je browser eenmaal weet wat te doen met die site boeit het niet meer. De risk is het initiele laden van HSTS, doe dat thuis of op een ander plekje en je zit goed voor de komende 3 tot 6 maanden.
Maar waarom zou je nog hotspots gebruiken als je een smartphone hebt met een 50 mbit 4g verbinding en 6gb data.... als mijn abo straks afloopt en ik haal een 4g toestel dan overweeg ik om wifi helemaal uit te zetten. Ook thuis. Het vreet stroom ook als je het niet gebruikt en is daarnaast met al die hotspots en toestanden toch niet meer veilig.

Ik vraag me af of mobiele apps ook vatbaat zijn voor deze onderschepping?
'Volgens NU.nl komt het probleem alleen voor bij internetbankiersessies in de webbrowser. Mobiele apps die banken voor internetbankieren hebben uitgebracht zouden niet vatbaar zijn.'
Ik zou de apps ook niet veel meer vertrouwen.

In de VS is gebleken dat de meeste financiele apps certificaat controles slecht of niet deed. En als ik dan zeg financiele apps, dank bedoel ik banken, paypal, etc.
Dat lost sslstrip op. Is trouwens oude techniek ( ~2009);

http://www.thoughtcrime.org/software/sslstrip/

Verbaasde mij dan ook over dit 'nieuws' want dit kan al jaren.
Side note: je kan ieder besturingssysteem naar wens gebruiken om dit te doen. Het heb zelf meer succes gehad met Debian, omdat Kali netwerk drivers patched en dat hostapd het dan niet even goed meer doet. Het draaien van een hotspot en routing is iets dat in Windows net zo goed kan. Het manipuleren van de data kan natuurlijk net zo goed met de juiste tools. Dus verkijk je niet op het punt dat het met Pineapple gedaan is, Linux, BSD, OSX, Windows of welk ander OS. Het gaat om het principe.
Goed om te weten, ik gebruikte voorheen BT maar sinds enkele weken Kali vanwege de verouderde software op BT.. Maar dit kan natuurlijk ook met elk ander OS! het voordeel wat ik bij Kali heb is dat er al een hoop programma's ingebakken zitten dus dvd in laptop en klaar, waar je bij andere OS'en nog een hoop bij elkaar moet schrapen.

Maar des niet te min, als nog een slechte zaak en ik ben van mening dat alles wat de mens in elkaar heeft gezet, ook weer onderdeel voor onderdeel uit elkaar gehaald kan worden en aangepast kan worden dus veilig zijn wel nooit in dat opzicht

[Reactie gewijzigd door hendymen op 23 juli 2024 08:25]

dus je tikt https in en je komt op de http site
Dat "kleine" detail kan niet. Om een redirect (301) te kunnen versturen naar de client over https, moet je een valid SSL certificaat hebben.

Dus, in andere woorden, als een gebruiker bijvoorbeeld een link van Google naar de site van z'n bank opent, of een suggestie uit z'n adresbalk aanklikt, dan werkt dit niet. Het werkt alleen als de gebruiker zelf de url intypt zonder "https".

Daarnaast is dit deels gebaseerd op social engineering (het "SSL-icoontje" als favicon), maar het kan effectiever.
Als je eenmaal toegang hebt tot een router of eigenaar bent van een openbare hotspot, kun je natuurlijk veel meer. Je zou mensen kunnen overtuigen om malware te downloaden om op facebook te kunnen - wat denk ik veel effectiever is aangezien mensen eerder facebook checken dan dat ze geld overmaken.

[Reactie gewijzigd door Huismus op 23 juli 2024 08:25]

Via extern beheerde wifi hotspots ben je dus kwetsbaar voor een man-in-the middle attack.
Goed te weten als consument, dat de verbinding van de bank hier niet op is uitgesloten.
Maar eerlijk gezegd ging ik daar al een beetje vanuit.

Als je dus internet bankierd, via een computer, met een bepaalde browsers, op een router die in beheer staat van een kwaadwillende dan kan de informatie gemanipuleerd, en half ontsleuteld worden. Het is een situatie waarin ik mezelf niet vaak zie zitten. En die waarschijnlijk ook weinig voorkomt. Veel mensen die nog IE gebruiken, zijn conservatief, en misschien is dat ook de groep die hun bankzaken liever thuis doet, dan onderweg.
Niet alleen de bank... Al het https verkeer, dus ook je mail etc. Is op die manier te ondervangen.
En nieuws is het niet, dit is al jaren zo
Wat te denken van Ziggo hotspots? Makkelijk na te bootsen, ik gebruik het geregeld (reduceert mijn maandelijks internet verbruik uit de mobiele bundel met 40%), en soms pakt ie die thuis ook, en doe je er ff snel een mobiele betaling op.
Heel vervelend zulk nieuws.
Nieuws? Het is echt geen nieuws dat je NOOIT betalingen en andere privacygevoelige zaken moet verrichten op netwerken die niet van jou zijn.
Klopt, maar je zou verwachten dat bank betalingen wel tot daar aan toe veilig zouden zijn, maar Ziggo hotspots zijn heel makkelijk te manipuleren omdat ze heen certificaar gebruiken.
Als iemand de wifi bij jouw thuis overstemt met een zelfde SSID zonder wachtwoord dan hoppen veel apparaten simpel weg gewoon over op die SSID.

Ik zou de wifi vermijden.
Internetbankieren via onbekende wifi-netwerken
Het televisieprogramma Kassa heeft op zaterdagavond 24 mei aandacht besteed aan de veiligheid van internetbankieren via onbekende wifi-netwerken. In de uitzending is een demonstratie te zien van een denkbeeldige aanval op internetbankieren. Inmiddels heeft de Rabobank maatregelen getroffen, waardoor een dergelijke aanval niet meer succesvol uitgevoerd kan worden.
BRON
Ik ben heel benieuwd hoe zij dit aangepakt hebben.. Aangezien het al langer een probleem is en lastig op te lossen is. Ik heb het gevoel dat dit een snelle "pleister" is in plaats van een werkelijke oplossing..

Ideetje om nog een keer zo'n poging te doen en goed te kijken wat voor data er terugkomt van de servers..

Curious!
Als dit klopt zullen de banken wel gaan adviseren iets anders dan IE te gebruiken binnenkort lijkt me.
ING heeft ook flinke downtime door onderhoud vannacht tot vijf uur.
Dat IE verhaal is gewoon stemmingmakerij, met een man in the middle attack, zoals dit is, gaat iedere browser stuk, of het nu IE is of FF of een ander.
Het lek betreft een HTTP header genaamd HSTS. Als een site de eerste keer bij een HTTPS verbinding deze header meestuurt, zal de browser voor de in de header gespecifieerde tijd alleen met HTTPS naar deze site verbinden. Hierdoor zal de exploit niet meer werken.

Internet Explorer heeft nog geen support voor HSTS. Firefox wel, al sinds versie 4.0. Hetzelfde geldt voor Chrome. En Safari.

Iemand met de laatste versie van Firefox die altijd alleen maar op geinfecteerde hotspots bankzaken doet is vatbaar. En die HSTS header staat (bij bijvoorbeeld de ABN Amro) op 365 dagen. En dat wordt elke nieuwe sessie gereset naar deze 365 dagen. De kans dat diegene dan door deze explot wordt getroffen is zeer klein.

[Reactie gewijzigd door maikoool op 23 juli 2024 08:25]

Anoniem: 457516 @maikoool25 mei 2014 07:47
De hele truc is dat de site WEL met https verbindt, namelijk naar de hotspot toe. Die kijkt vervolgens wat de broncode is, verandert deze zodanig dat https niet meer nodig is en stuurt een http pagina door naar de client. Die kan dan alles doen met de pagina wat hij normaal zou doen, maar omdat het dus via http loopt ziet de hotspot alles. Voordat de hotspot daarna het verkeer weer doorstuurt past hij alles dusdanig aan dat het weer via https loopt, wat kan omdat de hotspot de ssl connectie heeft opgezet.
Een mooie schematische weergave zoals bij IE

client <-- http --> hotspot <-- https --> bank

Stap 1
Client vraagt http pagina op bij bank.

Stap 2
Hotspot onderschept het begin van de request gelijk, bijvoorbeeld door dns intercepts of gewoon packet manipulatie. De meeste mensen typen geen https in bij bankzaken maar gebruiken de automatische redirect. Geen probleem voor de hotspot dus, want die hoeft niets te intercepten op de heenweg.

Stap 3
De terugweg begint de hotspot zijn werk te doen. Alle redirects naar https worden eruit gehaald en netjes gemapt (voor de volgende request), de https pagina wordt ook gestript van alles met https, zodat een http pagina overblijft. Deze wordt aan de client getoont. Als de client dan een verzoek doet, ziet de hotspot of deze voorheen gemapt was naar https. De hotspot doet dus dan het echte verzoek met https, wat kan aangezien die net zelf de connectie opgezet heeft (en daarna gestript doorgeeft aan de client).

Stap 4
Client heeft nu een http pagina voor zich. Alle requests worden verstuurd via http, de hotspot intercept alles, ziet alles, manipuleert alles en voor de bank is niets te zien, die zien alleen maar een https pagina.

Kijk ook even naar hoe sslstrip werkt.
http://www.thoughtcrime.org/software/sslstrip/

Waar HSTS nu van toepassing is, is dat de stap van http naar https al gelijk bij stap 1 plaatsvindt nog voor er verkeer naar de server toe gaat. Als er in het verleden een HSTS header is verzonden naar de gebruiker toe, zal er simpelweg NOOIT een http request verzoek worden gedaan. Alle volgende stappen gaan dan ook niet door, dus er kan ook niets gestript worden.
Het mag logisch zijn dat er natuurlijk geen downgrades van https naar http gedaan kunnen worden.

Edit: Niet goed gelezen. Aangepast op reactie van Glashelder.

[Reactie gewijzigd door Anoniem: 457516 op 23 juli 2024 08:25]

Dit werkt dus niet met een HSTS enabled browser die recent verbinding heeft gehad met de HSTS enabled web site.

De browser weigert dan de HTTP verbinding..
Ik vind het wel raar dat er zo'n groot probleem opeens wordt gemaakt over een security probleem op een open wifi. Iedereen weet toch dat er kans bestaat dat er iemand met ssl stripping of arp spoofing te werk kan gaan en het netwerk daarna kan manipuleren? Gebruikers die Firefox of chrome gebruiken zijn misschien met HTST beschermt, maar tegen dns spoofing weer niet..

Ik vind het stukken erger dat websites zoals digid.nl vatbaar zijn voor sslstripping, terwijl de meeste banken als ing.nl er wel tegen bestand zijn.

HTST is inderdaad voor browers een goede manier om hier tegen te beschermen en gelukkig ondersteund Microsoft het met nieuwe release van Internet Explorer.
Iedereen weet toch dat er kans bestaat dat er iemand met ssl stripping of arp spoofing te werk kan gaan en het netwerk daarna kan manipuleren?
Hoor je jezelf ook praten als je dit zegt? ssl stripping? arp spoofing? De gemiddelde consument heeft geen idee waar je het over hebt.

De gemiddelde Tweaker weet dan nog wel dat ie voorzichtig moet zijn, de gemiddelde consument denkt: "ik zie een slotje, ik zit goed".
Hoor je jezelf ook praten als je dit zegt? ssl stripping? arp spoofing? De gemiddelde consument heeft geen idee waar je het over hebt.
We zitten hier toch op tweakers.net? Ik vind dat de publiek het hier moeten weten, zeker anno 2014. Dat nu.nl aan bangmakerij doet is jammer genoeg de realiteit, maar van deze website had ik anders verwacht.

Dat de gemiddelde consument deze technieken van aanvallen niet begrijpt is niet meer dan logisch, ik heb geen idee hoe je een motor van een auto uit- en in elkaar kan zetten. Dat ze wel weten dat ze met een groene bank + slotje veilig zijn is er in ieder geval iets bereikt.
De gemiddelde Tweaker weet dan nog wel dat ie voorzichtig moet zijn, de gemiddelde consument denkt: "ik zie een slotje, ik zit goed".
Da's dan ook precies voldoende. Want dat slotje; dat verschijnt bij deze hack niet.

Verschijnt dat slotje wel, dan zul je eigenlijk alsnog even de details op moeten halen van het certificaat dat gebruikt wordt en moeten controleren dat de naam van de houder overeenkomt met de instantie die je bezoekt en dat de verstrekker v/h certificaat in orde is. (In Firefox verschijnt de naam van de certificaathouder al direct naast het slotje en kost dat dus nul moeite. Door één keer op het slotje of de naam te klikken opent een doorhanger menu waarin ook de andere belangrijke gegevens meteen zichtbaar zijn.)

Hier is eigenlijk nog steeds niet echt iets technisch aan. Het behoort gewoon tot de basishandelingen die je altijd zou moeten verrichten voordat je belangrijke zaken via internet regelt. Er zijn hele reclamecampagnes voor opgezet geweest vanuit de overheid om mensen hierover te informeren. De '3x kloppen' campagne, bijvoorbeeld.
Wat ik nu vreemd vind is dat dat dus bij mijn Firefox (28) niet gebeurt. Wel slotje en HTTPS, maar geen groene balk. Terwijl als ik het certificaat lees er toch echt sprake is van een EV variant.
Anoniem: 457516 @Glashelder25 mei 2014 08:18
Excuus, je hebt gelijk en ik heb niet goed gelezen. Ik zal mijn bericht aanpassen.
Daar ben ik van op de hoogte. Dat is ook waarom ik in mijn reactie heb geschreven dat als je alleen maar op openbare en gehackte wifi netwerken bankzaken doet, je vulnerable bent, ookal gebruik je de laatste Chrome/Firefox.

Als je ook maar een keer thuis op die site geweest bent, dan ben je dus in feite voor (in het geval van bijvoorbeeld de ABN Amro) 365 dagen hierna beschermd tegen deze exploit (mits je een recente versie van Firefox of Chrome hebt).
En volgens mij is er ook nog een vorm van DNS spoofing nodig, anders werkt het niet. In aanvulling tot HSTS kun je dus ook jezelf beschermen met anti-DNS-spoofing technieken.

Routering kan in theorie, maar in de praktijk vanwege de vele dynamic redirects en verschillende servers die vijrwel alle banken gebruiken in de praktijk een vrijwel gegarandeerde faal. Alleen al de login server en execution server zijn twee verschillende bij de meeste banken.
Anoniem: 63628 @maikoool25 mei 2014 04:24
Ja, en firefox draait weer niet in een sandbox (wat al jaren gewoon is bij IE en Chrome) EN kent de meeste aantal vulnerabilities van alle browsers over het algemeen, dus je hebt misschien minder risico bij dit kleine gaatje; overall is firefox echt een risicovolle browser om te gebruiken!

http://www.extremetech.co...o-day-exploits-at-pwn2own
http://vr-zone.com/articl...n2own-hackfest/74232.html
http://techspy.com/news/1...o-day-exploits-at-pwn2own

Dit was al zo in 2011 en is niet veranderd...
http://www.forbes.com/sit...le-approves-this-message/

Da's één van de redenen dat Google Firefox heeft laten vallen en met Webkit/Chromium verder is gegaan. Het laat ook zien dat Mozilla weinig prioriteit legt op de veiligheid van FF. Het is onbegrijpelijk hoe zo'n stuk software nog zulke "populariteit" geniet.
Hoewel je opzich wel een punt hebt is er ook wel wat nuancering noodzakelijk.

Firefox en Chrome zijn beiden open source, op zon hackfest is dat natuurlijk ideaal. Kudo's dus voor Chrome dat zo goed is blijven staan (wel beetje jammer van de privacy aspecten misschien, maar daarin is firefox ook niet heilig).

IE en Opera zijn daarentegen gesloten qua broncode en het vinden van nieuwe lekken is daarmee een stuk lastiger. Al helemaal wat betreft IE die toch al achterloopt in ontwikkeling. Elke feature heeft X bugs, minder features is minder bugs, echter is in dit geval (het artikel) het gebrek aan features ook gelijk een gat in de mogelijkheden tot beveiliging.

Op het web worden er zo nog wel wat meer nuancering gemaakt waardoor ik ernstige twijfels heb of je stelling eigenlijk niet de andere kant op zou moeten vallen.
Een voorbeeld: http://www.computerworld...._poor_Pwn2Own_performance

Uiteindelijk zie je hiet het voordeel van Open Source (review van de code lijd tot bugfixes) en het nadeel (niet elke review leidt tot melding die tot bugfix leidt). Echter bij open source is de kans zeer groot dat een ander de ontdekking ook zal doen en dit alsnog leidt tot melding, terwijl bij closed source de kans op misbruik in het wild juist theoretisch groter uit valt (kleinere kans op herhaalde ontdekking.)

[Reactie gewijzigd door cibrhusk op 23 juli 2024 08:25]

En Chrome doet default weer geen SSL certifciaat-controle.

Zo heeft elke browser weer zijn eigen nukken :(
Wat als je in het verleden slachtoffer bent geworden van dit lek? Valt dat onder 'eigen risico'? Daarnaast ben ik ook benieuwd wat voor een rekeningnummer er in de verwerkte transactie staat. Mocht deze wel onjuist zijn, dus een doorsluis-rekeningnummer, dan kun je binnen een bepaalde tijd nog actie ondernemen en contact opnemen met de bank.

Ik blijf het vreemd vinden hoe gemakkelijk mensen op een vreemd (wifi)netwerk internetbankieren, al is het via een app. Echter is dat een geheel andere discussie.

[Reactie gewijzigd door Pro-Rick op 23 juli 2024 08:25]

Anoniem: 63628 @Pro-Rick25 mei 2014 04:13
"Deze lek"? Serieus?

Overigens is zo'n app een heel stuk veiliger dan een browser, door de meerdere lagen van beveiliging. Ik durf het wel aan via een app over een open AP te internetbankieren. Browser; iets meer moeite mee.

Alle banken stellen je tot nu toe in bijna alle gevallen bij "cybercrime" schadeloos. Mits er grove nalatigheid aan jouw kant is vast te stellen (en dat is er doorgaans niet). Wel kan ik mij voorstellen dat het gebruik van WinXP onder grove nalatigheid kan komen te vallen over niet al te lange tijd.
Hoe wil je het dan formuleren? Gemis van de browsers? Als mensen steeds meer apps gaan gebruiken om te internetbankieren dan wordt het alleen maar aantrekkelijker om daar misbruik van te maken.

Wat betreft grove nalatigheid. Het wordt nu wel erg eenvoudig om opzettelijk geld naar een andere rekening door te sluizen en het vervolgens aan de andere kant weer terug te krijgen... Dat kan niet de bedoeling zijn.
Anoniem: 63628 @Pro-Rick25 mei 2014 15:36
Op het feit na dat dit effectief geen lek in een stuk software is, maar simpelweg een zwakte in de gebruikte techniek is het altijd nog "dit lek" en niet "deze lek".
Dat is inderdaad wel wat dom en slordig. Mogelijk was het al wat te laat voor een gedegen reactie op het bericht. Dat neemt niet weg dat ik het zojuist had kunnen zien. Ik meende dat je het inhoudelijk bedoelde.

De definitie en interpretatie van een 'lek' voldoet mijns inziens. Hiermee doel ik op IE dat een gat heeft in de beveiliging door nalatigheid betreffende http sts.

[Reactie gewijzigd door Pro-Rick op 23 juli 2024 08:25]

Er lopen hier ook lui rond die het vertikken om hun zin met een hoofdletter te beginnen, en geen interpunctie gebruiken. Dan is een dit/deze fout toch niet zo erg?

Zet het anders gewoon onderin je post met kleine lettertjes, duidelijk genoeg:

Het is overigens 'dit lek', en niet 'deze lek'
Ik blijf het vreemd vinden hoe gemakkelijk mensen op een vreemd (wifi)netwerk internetbankieren, al is het via een app
Ik maak me anders echt geen zorgen. Maar ik controleer dan ook goed wat voor verbinding mijn telefoon maakt. Als dat gewoon HTTPS is naar de juiste URL en ik geen certificaatwaarschuwing krijg dan zeg ik: veel succes met spoofen.

[Reactie gewijzigd door .oisyn op 23 juli 2024 08:25]

Op dit item kan niet meer gereageerd worden.