De kranten staan er vol mee: hackers ontdekken gigantisch lek in internet. Eigenlijk is dit oud nieuws en ook is al een belangrijke patch geweest. Reeds in 2006 was al bekend dat er met DNS geknoeid kon worden.
Ergens einde 2006 bestond al de mogelijkheid dat een gebruiker die als website bijvoorbeeld www.rabobank.nl of www.abnamro.nl invoerde, naar een andere server werd geleid. In de adresbalk van de website staat dan wel de juiste url, maar je zat op een andere site. Belangrijk daarbij was het slotje beneden in de internetbrowser. Dat kon namelijk niet op slot omdat het certificaat niet klopte. In tegenstelling tot Internet Explorer worden de certificaten op ip-adres EN url gecontroleerd en is het bijna onmogelijk om een valide certificaat te gebruiken bij een phishingsite, zoals deze methode heet.
Opeens is het weer 'groot nieuws': het lek is als een gebruiker een url invoert dit door DNS wordt omgezet in een ip-adres. Door een DNS-server mee te laten draaien op hoog niveau, kan het zijn dat een url word ingegeven en naar een andere pagina gaat verwijzen, zonder dat de gebruiker dit ziet.
Best gevaarlijk dus, vooral voor thuisgebruikers. Helemaal omdat veel thuisgebruikers ook een eigen DNS-servertje hebben. In Windows, routers en zelfs in de veel gebruikte experiaboksen draait een DNS-servertje mee, die weer wordt voorzien van zijn gegevens door een DNS-server van een provider. Deze DNS-servers van de provider halen hun informatie vervolgens weer van grote DNS-servers die willekeurig verspreid staan. Door het lek ontstaat dus de mogelijkheid dat de DNS-servers van je provider verkeerde tabellen laden en dus naar verkeerde sites leiden.
Er is echter een vrij simpele oplossing beschikbaar die dit kan voorkomen. Ik gebruik al jaren een aangepaste methode om te bankieren zodat het risico op een phisingsite te belanden heel ver wordt teruggebracht. In C:windowssystem32driversetc staat een bestandje genaam LMhost, dus zonder extensie. Open dit bestandje. Voeg beneden een regel toe met daarin een naam en het ip-adres van de bank die je gebruikt. Als voorbeeld staat in dit bestandje altijd de regel localhost 127.0.0.1.
In mijn geval staat er als naam bankieren en het ip-adres van mijn bank. Dit ip-adres kun je vrij gemakkelijk achterhalen door een DOS-prompt te starten en dan het commando 'ping www.banknaam.nl' uit te voeren. Je krijgt vervolgens het ip-adres dat je dan opgeeft. Als je dan gaat bankieren, dan geef je niet de url naar je bank op, maar gewoon de naam die je hebt verzonnen. Deze word door je LMhost omgezet naar het juiste ip-adres en je gaat meteen naar de server van de bank. Vervolgens controleer je wel nog of het slotje dicht gaat beneden in de balk van de browser.
Heb je meerdere banken, dan kun je gewoon per bank een regeltje toevoegen. Deze vrij simpele methode gebruik ik al bijna twee jaar en ik heb nergens last van. Deze methode is binnen één minuut uit te voeren. Succes ermee!
Volstrekt onnodige maatregel voor wat betreft internetbankieren. Deze websites zijn al beveiligd met behulp van een SSL certificaat. Zie ook de reclamecampagne over 3x kloppen.
Wat wel een goede tip is, is om SSL websites voor internetbankieren alleen te bezoeken via je bladwijzers. Bijvoorbeeld via https://bankieren.rabobank.nl/rib/rib.cgi of https://mijn.postbank.nl/internetbankieren/
Jack,
Linkjes volgen helpt dus niet, want jouw pc praat simpelweg tegen een andere server omdat je op een veel lager niveau aangevallen bent.
Ssl certs kunnen prima gefaked worden, want iedereen die een slotje ziet denk dat het allemaal werkt en veilig is.
Erik,
Het is opeens weer nieuws omdat er nu niet 1 willekeurig domein gespoofd kan worden , maar de hele authorative server uit de dns pool gegooid kan worden, inc nameservers voor een door de aanvaller in te vullen tijdsspanne. Deze exploit is verder massaal uitvoerbaar in tegenstelling tot de eerdere foutjes die je maar met weinig succes, en weinig bereik kon uitvoeren.
Volgens moet het bestand ‘hosts’ heten en niet ‘LMHosts’. LMHosts is, naar mijn informatie, voor het resolven van NETBIOS namen naar IP adressen en niet van URL’s. Maar ik kan er naast zitten…
Hm… Via ping kom je vaak op een webserver uit, of een loadbalancer die je vaak ook nog eens redirect naar een https-pagina. Het ip-adres (http) kan ook nog eens eentje uit een range komen, waar de bank onderhoud op loslaat.
Firefox 3 (of IE met anti-phishing-plugin) geven duidelijk aan wanneer een site op een blacklist staat, en 3x kloppen met sleuteltje checken lijkt me genoeg.
Inderdaad het moet HOSTS bestand zijn.
… “Best gevaarlijk dus, vooral voor thuisgebruikers. Helemaal omdat veel thuisgebruikers ook een eigen DNS-servertje hebben.” …
Ik vraag me af waarom veel thuisgebruikers een DNS servertje hebben draaien. Ik denk dat dit onzin is.
Het gaat al fout bij het doen van een PING.
De PING doet ook niks anders dan een DNS lookup. Als je daarmee al het verkeerde IP adres te pakken hebt ben je jezelf aan het infecteren met verkeerde info.
De DNS kwetsbaarheid die aangetoond is door Dan Kaminsky zit zo in het fundament van DNS, dat een aanvalsscenario zich niet zozeer zou richten op de individuele internetbankierder, maar op het functioneren van het fundament van het internet.
Stel je voor dat emailverkeer en browsing niet meer mogelijk zijn omdat geen enkele DNS naam meer correct omgezet wordt naar het bijbehorende IP adres. Dit zou zoveel zinloos verkeer opleveren dat iemand die een IP adres gebruikt er ook niet meer door komt.
Ik zou de gemiddelde thuisgebruiker trouwens afraden zelf het HOSTS bestand te gaan wijzigen, als ze het uberhaupt kunnen vinden. Dit is net zoals de Windows registry aanpassen: het is een leek niet aan te raden.
Het voorgestelde scenario/maatregel is een druppel om een gloeiende plaat. Indien je bank in zijn wijsheid de frontend (webserver/loadbalancer/packeteer) van een ander ip-adres wil voorzien dan zit je. Buiten het eerder beschreven feit dat je er vanuit gaat dat bij de resolv je dns-keten nog juist werkte.
Ook is er een mogelijkheid dat de dns-keten van de bank besmet is geraakt (of in de dns-keten er omheen). In dat geval helpt de maatregel al helemaal niet meer. Immers de frontend/applicaties praten met andere systemen (binnen en buiten het domein)
Het grootste probleem zit ‘m in het feit dat de dns-hack het eenvoudiger maakt om met gecombineerde aanvallen (zowel bij de eindgebruiker als bij de bank) in te breken in sessie, te re-routen of malware te injecteren.
Dus de maatregel werkt maar gedeeltelijk en biedt zeker geen voldoende bescherming.
Zo lost Dennis het op:
http://www.dennisbaaten.com/2008/09/05/dns-lek-het-is-tijd-voor-de-rabobank/
Dit kun je ook eenvoudig oplossen door een bookmark te maken in je browser met een IP-adres i.p.v. een URL naam naar een internet bankieren adres.
Het is op zich interessant i.p.v. een “ping” een “route trace” naar een URL te doen. Dan zie je alle knooppunten waar het verkeer langsgaat. Dit kan bijvoorbeeld met windows door een dos shell te starten en het commando “tracert” in te typen.
Vervolgens kun je controleren of de URL https: en https: dezelfde resultaten opleveren.
Vervolgens kun je de eignaar van het IP-nummer opzoeken met bijvoorbeeld https://www.db.ripe.net/whois
Als dit allemaal klopt, dan kun je het vaste IP-nummer als bookmark openemen en in de toekomst gebruiken , inclusief https://, dus https://