Beveiligde verbindingen voor internetbankieren zijn niet meer helemaal te vertrouwen. Door een ernstig DNS-lek is het aanvragen van een SSL-certificaat voor andermans domein namelijk gemakkelijker geworden. Daarom vindt Govcert, het computerincidentrespons team van de Nederlandse overheid, dat de procedures van SSL-providers moeten veranderen.
Een gewaarschuwde ict'er controleert de SSL-verbinding van zijn bank. Als er https:// in de adresbalk staat, het slotje rechtsonderin aanwezig is en er bij dubbelklikken een certificaat verschijnt met de domeinnaam van je bank, dan weet je het zeker: je hebt verbinding met je eigen bank en niet met een of andere DNS-hacker, die je inlogcodes wil stelen om je bankrekening te plunderen.
Was het maar zo. Dat laatste hoeft namelijk niet meer zo te zijn. Beveiligingsonderzoeker Dan Kaminsky wees er anderhalve week geleden op dat een beveiligingslek in het Domain Name System (DNS) verstrekkende gevolgen kan hebben. Zo'n beetje elke internettechniek is namelijk gebaseerd op het DNS-fundament. En dat geldt ook voor het Secure Sockets Layer (SSL), een beveiligingsprotocol voor authenticatie en versleuteling. Kaminsky wees erop dat de bedrijven die SSL-certificaten verkopen, mail gebruiken om te controleren of aanvragers zijn wie ze zeggen te zijn. Kaminsky: "Raad eens hoe veilig die instanties zijn voor DNS-aanvallen. Niet."
Certificaataanvraag deugt niet
Govcert, het computerincidentrespons team van de Nederlandse overheid, vindt daarom nu dat de procedures van SSL-providers moeten veranderen. Woordvoerder Ella Broos: "De procedure van het aanvragen van SSL-certificaten door instanties moet onder de loep worden genomen en minder geautomatiseerd verlopen. Er valt te denken aan extra authenticatie en identificatie van de aanvrager door de leverancier. Op dit moment verschillen de procedures van de CA's (Certificate Authority) veel van elkaar. Bij de een gebeurt het grondiger dan bij de ander."
SSL-certificaat voor andermans domein
Doordat een deel van de SSL-providers minder grondig te werk gaat, is momenteel de volgende aanval mogelijk: je zoekt een ongepatchte server van een bedrijf dat SSL-certificaten verkoopt. Dat moet lukken, want er bestaan wereldwijd enkele duizenden ‘SSL-providers'.
Via het lek dat Dan Kaminsky ontdekte neem je de DNS-server van deze provider over. Vervolgens vraag je bij de SSL-provider een SSL-certificaat aan voor internetbank.nl. De controles die een SSL-provider uitvoert om te achterhalen of je echt de eigenaar bent van internetbank.nl kunnen variëren, maar vaak blijft het bij het versturen van een paar mailtjes aan het domein internetbank.nl. Meestal wordt daarbij gekozen voor algemene adressen zoals info@internetbank.nl en admin@internetbank.nl.
Als één van deze mailtjes beantwoord wordt, is dat voor een SSL-provider vaak voldoende bewijs dat de aanvrager het domein bezit. Omdat je de DNS-server van de SSL-provider hebt overgenomen, is het omleiden van die controlemails voor jou een fluitje van een cent. Je kunt daarna die mailtjes beantwoorden en zo ‘bewijzen' dat jij degene bent die internetbank.nl beheert. Vervolgens ontvang je een certificaat voor interbank.nl. Dat certificaat zet je op een webserver. Je zoekt een ongepatchte DNS-server van een bankklant, neemt die over, vervalst het ip-adres van de bank en leidt bankklanten naar een nepsite. Wanneer ze het certificaat van de bank controleren, lijkt alles in orde te zijn. Maar dat is het niet.
Procedures van SSL-providers
Broos: "Hoewel dit scenario heel omslachtig is, doordat eerst de server van de leverancier van SSL-certificaten moet worden gecompromitteerd, is het niet ondenkbaar. In dat geval is het onmogelijk om als eindgebruiker iets te doen om het op te merken en te voorkomen. Het compromitteren van de server van SSL-certificatenleveranciers is overigens niet zomaar gebeurd als we ervan uit mogen gaan dat die vanwege de aard van hun dienstverlening goed beveiligd zijn. Naar onze mening is dit scenario wel een aanleiding om daar extra alert op te zijn."
Olaf Kolkman, directeur NLnet Labs (dat open-source DNS-servers ontwikkelt zoals NSD en Unbound) formuleert het voorzichtig: "Zolang alle controles die een certificerende instantie uitvoert om de identiteit van een aanvrager te achterhalen over internet verlopen, is het gevaar dat een malafide persoon een certificaat ontvangt voor een domein dat niet van hem is, niet geheel academisch."
Antoin Verschuren, technisch adviseur bij SIDN, de organisatie die het .nl-domein beheert: "Het risico is niet geheel verwaarloosbaar meer. Beveiliging is nooit honderd procent te garanderen, maar door de DNS-kwetsbaarheid is de kans dat zo'n aanval slaagt iets groter geworden. Het probleem zit niet zozeer in het SSL-protocol, maar in de procedures van SSL-providers. Je kunt je afvragen of het verscherpen van die procedures een gewenst algemeen beveilingsdoel dient. Als de procedure moeilijker en complexer wordt gemaakt, dan kan dat aanvragers van een SSL certificaat ontmoedigen om er überhaupt een aan te vragen. De echte oplossing is het repareren van de DNS-kwetsbaarheid. De enige lange termijn end-to-end oplossing daarvoor is DNSSEC, een DNS-protocol dat beter beveiligd is."
Blijf het slotje controleren
Broos: "Blijft een feit dat we het risico van deze tijdrovende manier van frauderen niet hoog inschatten, vanwege de complexiteit en de inspanning die het kost. Wij zien als Govcert dat phishing zonder SSL-certificaat al lucratief genoeg blijft: veel mensen controleren helemaal niet of ze veilig aan het werk zijn. Daarom blijft het op dit moment een goed advies om als eindgebruiker te checken of er een beveiligde verbinding tot stand is gekomen, via het hangslotje, https en de url. Het zou de eerste, bijna automatische handeling moeten zijn van iedere internetgebruiker."
Ook volgens Kolkman zijn internetbankklanten vaak niet alert genoeg: "Veel gebruikers controleren niet eens of het slotje aanwezig is. Als je als crimineel erin slaagt internetgebruikers om te leiden naar een nepbankiersite, en dat kan via het lek van Dan Kaminsky, dan heb je dus ook al een aardige kans van slagen."
3x kloppen
De woordvoerster van de Nederlandse Vereniging van Banken (NVB): "De Nederlandse banken doen er alles aan om er voor te zorgen dat de producten die zij hun klanten bieden goed en veilig zijn. Dit geldt uiteraard ook voor internetbankieren. Honderd procent veiligheid kunnen wij niet garanderen, maar wij zijn ons ook bewust van de gevaren die, bijvoorbeeld, internetbankieren met zich mee kan brengen. Daarom investeren wij, als banken, jaarlijks fors in het optimaliseren en de beveiliging van onze producten en helpen wij onze klanten bij het bestrijden van onder andere internetfraude door middel van campagnes als 3x kloppen. Bovendien heeft elke bank een vulnerabilitymanagementproces ingericht om de interne infrastructuur te beschermen tegen (nieuwe) kwetsbaarheden, waaronder die in de DNS-omgeving."
Het lek dat Kaminksy ontdekte
Domain Name System-servers vertalen domeinnamen naar ip-adressen. Er zijn twee soorten DNS-servers: authoritative en caching nameservers. Alleen het tweede type DNS-server (ook wel ‘resolving name servers' genoemd) is vatbaar voor de kwetsbaarheid die Kaminsky ontdekte. Caching nameservers zijn namelijk niet op de hoogte van alle domeinnamen op het hele internet, en sturen daarom vertaalverzoeken aan ‘autoritieve' DNS-servers. In zo'n vertaalverzoek vraagt een DNS-server naar het ip-adres dat hoort bij een bepaald website- of mailadres. Het huidige DNS-lek maakt het voor kwaadwillenden mogelijk zich uit te geven voor een autoritieve DNS-server. Ze kunnen binnen 0,7 seconden na de start van een ‘brute force' aanval de macht te grijpen over een (ongepatchte) name server en de cache vervuilen met foutieve ip-adressen. Vanaf dat moment is er veel meer mogelijk dan enkel mail afvangen en websitebezoekers omleiden naar nepsites. Ook bijvoorbeeld het File Transfer Protocol (FTP) kan misbruikt worden via het lek, net als het authenticatie- en encryptieprotocol Secure Socket Layer (SSL). Internetbanken gebruiken SSL om geldtransacties over http te beveiligen (via https). Ook automatische software updatediensten kunnen na de overname van een name server worden misbruikt voor het installeren van malware binnen bedrijfsnetwerken. Volgens Kaminksy vormt Windows Update hierop een uitzondering.
Snelle check
Wie snel wil controleren of de patch is doorgevoerd binnen zijn eigen bedrijf, kan op de website van Dan Kaminsky via één druk op de knop achterhalen of de gebruikte DNS-server kwetsbaar is of niet. Een meer gedetailleerde controle kan elders worden uitgevoerd. Als blijkt dat de DNS-server die je gebruikt kwetsbaar is, informeer dan je netwerkbeheerder.
Dit probleem speelt dus alleen voor nieuwe SSL certificaten. Voor bestaande certificaten van je internet bank is dat dus geen probleem lijkt me.
Er is een vielige manier, volgens mij, door alleen bij je bank in te loggen met het ip-adres. Want dan heb je geen dns-server meer nodig.
Vic: Niet helemaal. Waar het volgens mij om gaat is dat je door het toepassen van deze truc een SSL certificaat kunt bemachtigen voor je eigen namaak banksite, waar je
gebruikers (via het DNS-lek) naartoe kunt omleiden. Of snap ik het nou verkeerd?
De SIGN-IN SEAL zou de oplossing zijn. Kijk maar eens hoe Yahoo! dat heeft opgelost op http://mail.yahoo.com/
Je kiest een plaatje of upload een fototje. Alleen als de DNS je naar de echte site toe leidt wordt dit getoond.
Nu gaat het artikel over het “illegaal” aanmaken en faciliteren van ssl certificaten. Onbekender is waarschijnlijk dat iedereen met een beetje kennis een tijdelijk eigen SSl certificate store kan maken, en gedurende 60 dagen zelf certificaten kan maken. Ongeacht voor welke site.
Het is een erg bewerkelijke methode.
Vele malen gemakkelijker is het om verkeer van paypal af te vangen. Iedereen met een beetje kennis kan zo een paypal spoof inrichten.
Voordeel daarvan is dat je geen authenticatie methodes als extra kastjes waarin je codes moet opgeven etc.
Bij paypall log je met een gebruikersnaam en wachtwoord in.
Vervolgens toon je een out of order pagina.
En dan heb je de inloggegevens van de gebruiker al.
Vervolgens doe je een betaling aan je eigen paypall account, die je behoorlijk anoniem kunt maken, en je bent al niet meer te achterhalen.
De credit cards of automatische bankafschrijvingen komen pas een week of langer later, en dan is het leed al geleden.
Erik: inderdaad heel erg sneaky 🙂 Ongelofelijk eigenlijk dat de beveiliging van PayPal tegenwoordig zo beperkt is, en dus achterloopt bij die van de banken. Moet dat niet eens aangepakt worden?