Hoe unicode-domeinnamen je in de val lokken
Een kwetsbaarheid in meerdere browsers met speciale karakters (‘unicode’) is in april verholpen in de Chrome-browser. Tot voor kort was het mogelijk je voor te doen als een andere website door misbruik te maken van speciale karakters, waardoor deze in onder andere Chrome nauwelijks van een legitieme website te onderscheiden was. Naast de maatregelen die browsers nemen voor het verhelpen van dit soort kwetsbaarheden, kun je hier als website-eigenaar of -bezoeker ook wat aan doen.
Wat hield de phishingaanval in?
Zogenaamde unicode-domeinen zijn in het leven geroepen om domeinnamen met speciale karakters, voornamelijk voor buitenlandse doeleinden, te kunnen gebruiken. Een struikelblok hierbij is dat de unicode-versie van een domeinnaam door iedereen geregistreerd kan worden, ongeacht of het ‘normale’ domein al in bezit van een ander is. Hierdoor is het mogelijk een domein als ‘xn--xlphin-wxa.nl’ te registreren. Browsers als Google Chrome en Mozilla Firefox tonen deze speciale domeinen in de adresbalk als de voor het publiek bekende versie ervan, waardoor ze moeilijk te onderscheiden zijn van het legitieme domein.
SSL-certificaten kunnen zonder problemen voor het speciale unicode-domein worden uitgegeven. Omdat browsers het domein gewoon als de normale versie ervan tonen, lijkt het er dus net op alsof het SSL-certificaat voor het legitieme domein is uitgegeven en je op de correcte website bent beland.
Dit onderscheidt deze phishingaanval van anderen: het is praktisch niet mogelijk om de unicode-versie te onderscheiden van de ‘echte’ website. Omdat SSL-certificaten als indicator voor vertrouwen worden gebruikt, speelt deze aanval direct in op het vertrouwen van de bezoeker. De bezoeker zal deze website vertrouwen omdat het SSL-certificaat gewoon geldig is – deze is immers uitgegeven voor de speciale domeinnaam. Hierdoor zijn zelfs mensen die proactief een oogje in het zeil houden vatbaar voor phishing.
Dit type aanval is over het algemeen bekend als een homografische aanval en bestaat ook in andere vormen. Een bekend voorbeeld hiervan is Wikipedia: door het vervangen van de ‘e’ en ‘a’ in ‘wikipedia.org’ met Cyrillische letters, is er geen verschil te bekennen, ook al gaat het wel degelijk om een andere domeinnaam.
Hoe is deze phishingaanval opgelost?
Beveiligingsonderzoeker Xudong Zheng heeft deze kwetsbaarheid openlijk gepubliceerd op zijn blog, met een beknopte uitleg van de werking. Google Chrome heeft deze kwetsbaarheid erkend en opgelost in versie 58.0.3029.81. Unicode-domeinen worden nu getoond als het originele domein, in plaats van de reguliere versie ervan.
Browsers hebben over het algemeen goede mechanismen om hun gebruikers tegen soortgelijke aanvallen te beschermen:
- Opera en Firefox limiteren de karakters die gebruikt mogen worden;
- Internet Explorer controleert via externe lijsten of een website een risico vormt voor een dergelijke phishingaanval;
- Safari toont de uiteindelijke domeinnaam (bijvoorbeeld ‘würzburg.de’ in plaats van ‘xn--wrzburg-n2a.de’);
- Google Chrome toont de speciale versie van de domeinnaam enkel als deze opgenomen is in de lijst van talen die de gebruiker ingesteld heeft
De overkoepelende instantie voor domeinnamen, ICANN, heeft een beleid opgesteld dat misbruik in deze vorm tegen probeert te gaan. Hierdoor kunnen SSL-leveranciers SSL-certificaten blijven uitgeven voor legitiem gebruik van deze speciale ‘unicode’-domeinnamen.
Wat kun je hier zelf aan doen?
Naast de maatregelen die browsers nemen, kun je hier als website-eigenaar of -bezoeker ook wat aan doen: respectievelijk een EV-certificaat installeren op je website, en hier goed op letten. EV-certificaten met groene adresbalk, die grote spelers als Apple gebruiken, werden voor deze aanval niet gebruikt. Voor de uitgifte van EV-certificaten zijn immers strikte regels waardoor een phishingsite deze nooit kan krijgen inclusief de ‘gestolen’ bedrijfsnaam in de adresbalk. In plaats daarvan werden er certificaten zonder bedrijfsgegevens gebruikt, waarbij alleen het domein wordt gecontroleerd en de organisatie achter de website niet.
Dit is een mooi voorbeeld van de meerwaarde van EV: bezoekers kunnen door de bedrijfsnaam in de groene adresbalk in een oogopslag zien of ze op de website van de juiste organisatie zitten, of misschien toch van een partij die zich voordoet als deze organisatie.
Veel grote organisaties gebruiken EV-certificaten op hun website. Als bezoeker kun je het certificaat controleren om een phishingwebsite te onderscheiden van een echte: in het laatste geval wordt de juiste bedrijfsnaam naast de domeinnaam in de adresbalk getoond.
Een kwetsbaarheid in meerdere browsers met speciale karakters (‘unicode’) is in april verholpen in de Chrome-browser. Tot voor kort was het mogelijk je voor te doen als een andere website door misbruik te maken van speciale karakters, waardoor deze in onder andere Chrome nauwelijks van een legitieme website te onderscheiden was. Naast de maatregelen die browsers nemen voor het verhelpen van dit soort kwetsbaarheden, kun je hier als website-eigenaar of -bezoeker ook wat aan doen.
Wat hield de phishingaanval in?
Zogenaamde unicode-domeinen zijn in het leven geroepen om domeinnamen met speciale karakters, voornamelijk voor buitenlandse doeleinden, te kunnen gebruiken. Een struikelblok hierbij is dat de unicode-versie van een domeinnaam door iedereen geregistreerd kan worden, ongeacht of het ‘normale’ domein al in bezit van een ander is. Hierdoor is het mogelijk een domein als ‘xn--xlphin-wxa.nl’ te registreren. Browsers als Google Chrome en Mozilla Firefox tonen deze speciale domeinen in de adresbalk als de voor het publiek bekende versie ervan, waardoor ze moeilijk te onderscheiden zijn van het legitieme domein.
SSL-certificaten kunnen zonder problemen voor het speciale unicode-domein worden uitgegeven. Omdat browsers het domein gewoon als de normale versie ervan tonen, lijkt het er dus net op alsof het SSL-certificaat voor het legitieme domein is uitgegeven en je op de correcte website bent beland.
Dit onderscheidt deze phishingaanval van anderen: het is praktisch niet mogelijk om de unicode-versie te onderscheiden van de ‘echte’ website. Omdat SSL-certificaten als indicator voor vertrouwen worden gebruikt, speelt deze aanval direct in op het vertrouwen van de bezoeker. De bezoeker zal deze website vertrouwen omdat het SSL-certificaat gewoon geldig is – deze is immers uitgegeven voor de speciale domeinnaam. Hierdoor zijn zelfs mensen die proactief een oogje in het zeil houden vatbaar voor phishing.
Dit type aanval is over het algemeen bekend als een homografische aanval en bestaat ook in andere vormen. Een bekend voorbeeld hiervan is Wikipedia: door het vervangen van de ‘e’ en ‘a’ in ‘wikipedia.org’ met Cyrillische letters, is er geen verschil te bekennen, ook al gaat het wel degelijk om een andere domeinnaam.
Hoe is deze phishingaanval opgelost?
Beveiligingsonderzoeker Xudong Zheng heeft deze kwetsbaarheid openlijk gepubliceerd op zijn blog, met een beknopte uitleg van de werking. Google Chrome heeft deze kwetsbaarheid erkend en opgelost in versie 58.0.3029.81. Unicode-domeinen worden nu getoond als het originele domein, in plaats van de reguliere versie ervan.
Browsers hebben over het algemeen goede mechanismen om hun gebruikers tegen soortgelijke aanvallen te beschermen:
- Opera en Firefox limiteren de karakters die gebruikt mogen worden;
- Internet Explorer controleert via externe lijsten of een website een risico vormt voor een dergelijke phishingaanval;
- Safari toont de uiteindelijke domeinnaam (bijvoorbeeld ‘würzburg.de’ in plaats van ‘xn--wrzburg-n2a.de’);
- Google Chrome toont de speciale versie van de domeinnaam enkel als deze opgenomen is in de lijst van talen die de gebruiker ingesteld heeft
De overkoepelende instantie voor domeinnamen, ICANN, heeft een beleid opgesteld dat misbruik in deze vorm tegen probeert te gaan. Hierdoor kunnen SSL-leveranciers SSL-certificaten blijven uitgeven voor legitiem gebruik van deze speciale ‘unicode’-domeinnamen.
Wat kun je hier zelf aan doen?
Naast de maatregelen die browsers nemen, kun je hier als website-eigenaar of -bezoeker ook wat aan doen: respectievelijk een EV-certificaat installeren op je website, en hier goed op letten. EV-certificaten met groene adresbalk, die grote spelers als Apple gebruiken, werden voor deze aanval niet gebruikt. Voor de uitgifte van EV-certificaten zijn immers strikte regels waardoor een phishingsite deze nooit kan krijgen inclusief de ‘gestolen’ bedrijfsnaam in de adresbalk. In plaats daarvan werden er certificaten zonder bedrijfsgegevens gebruikt, waarbij alleen het domein wordt gecontroleerd en de organisatie achter de website niet.
Dit is een mooi voorbeeld van de meerwaarde van EV: bezoekers kunnen door de bedrijfsnaam in de groene adresbalk in een oogopslag zien of ze op de website van de juiste organisatie zitten, of misschien toch van een partij die zich voordoet als deze organisatie.
Veel grote organisaties gebruiken EV-certificaten op hun website. Als bezoeker kun je het certificaat controleren om een phishingwebsite te onderscheiden van een echte: in het laatste geval wordt de juiste bedrijfsnaam naast de domeinnaam in de adresbalk getoond.
