Browsers kwetsbaar voor phishingaanval via unicode-domein
De manier waarop browsers omgaan met domeinen die volledig uit unicode-karakters bestaan maakt het mogelijk om phishingaanvallen uit te voeren die erg lastig voor gebruikers zijn om te detecteren, zo heeft een beveiligingsonderzoeker genaamd Xudong Zheng aangetoond. Via Punycode is het mogelijk om domeinen met buitenlandse karakters te registreren. Veel unicode-karakters zijn echter lastig van gewone ASCII-karakters te onderscheiden.
Zo is het mogelijk om een domein als "xn--pple-43d.com" te registreren, wat als "Apple.com" wordt weergegeven. Het domein gebruikt echter de Cyrillische "a" (U+0430) in plaats van de ASCII "a" (U+0041). Dit wordt ook wel een "homograph" aanval genoemd. Browserontwikkelaars hebben maatregelen genomen om dit soort aanvallen tegen te gaan. Zo zullen Chrome en Firefox de unicode-karakters niet in de oorspronkelijke vorm weergeven als er karakters van verschillende talen in het domein worden gebruikt. De nepversie van apple.com zal dan als "xn--pple-43d.com" worden weergegeven.
Zheng ontdekte dat deze maatregel niet beschermt tegen domeinen waarbij alle karakters door unicode-karakters zijn vervangen, zoals "xn--80ak6aa92e.com". In dit geval zal het domein als apple.com worden weergegeven, zo blijkt uit de demonstratie van Zheng. De onderzoeker meldde het probleem in januari van dit jaar aan Google en Mozilla. In een toekomstige versie van Chrome zal het probleem worden opgelost. Het is echter onduidelijk of Mozilla een oplossing voor Firefox zal uitrollen.
Gebruikers krijgen dan ook het advies om een wachtwoordmanager te gebruiken, aangezien die niet op het nepdomein actief wordt. Daarnaast moeten gebruikers goed opletten als ze informatie op een website invoeren, aldus de onderzoeker. "Ik hoop dat Mozilla een oplossing voor dit probleem overweegt, omdat het voor serieuze verwarring kan zorgen, zelfs bij mensen die alert op phishing zijn", besluit Zheng.
Unicode(UTF-8) staat bij mij aan, en "Auto-Detect" uit.
Van browsermakers om allerlei kletspraatjestekst in groen voor de url weer te geven.
Wat het verkleint het 'psychologisch visuele' verschil met de ev certificaat tekst.
Want bij apple staat er : Apple Inc. (US) | https://www.apple.com
Apple heeft geen gewoon slotje maar een e.v. slotje.
In groen is "Apple Inc. (US)"
De 'oogkleppen lullos' van de browsermaker(s) in het voorbeeld hebben er voor gekozen eenzelfde karakterlengte* in groen te gaan weergeven waardoor bij snel kijken naar "slotje + groen" de verwarring eenvoudiger optreedt.
De oude situatie was beter omdat het contrast groter was, alleen met een e.v. certificaat had je een lang groenig tekstje voor de url en was in contrast een goed visueel verschil met andere slotjes of geen slotjes.
Met gerommel en gepiel voor de url marge is dus e.e.a. verkeerd complexer gemaakt en je krijgt gewoon zin op te gaan webdesignen op phishing methoden om aan te tonen dat je misbruikkansen aanmerkelijk vergroot.
Want die kans was er namelijk niet geweest zonder browser aanpassing, dan had de methode van Zheng, hoe slim ook, visueel weinig (geen) groen opgeleverd voor de url balk en was phishing duidelijker te herkennen.
Tenzij, tenzij men een e.v. certificaat gaat combineren met typosquatting.
Maar of het haalbaar is om een e.v. certificaat te registreren op naam van
bijvoorbeeld "Aple Inc. (VS)" ?
Hoe het ook zij, dit visuele gekloot met kleuren en "secure" toevoegen terwijl dat eigenlijk helemaal niet zo secure is als een e.v. certificaat dat ook groen wordt weergeven, dat is dom dom dom.
Maar wel heel erg leuk als je phisherwebdeveloperdesigner zou zijn.
Stoppen dus met dat visuele gekloot daar voor de url !!!
Of mozilla dat nog haalt is gissen, but thats another story.
* Vergelijkbaar visueel lang in groen en dus onvergeeflijk domme visuele aanpassing van browsermakers!
Apple Inc. (US)
network.IDN_show_punycode = true
network.IDN_show_punycode = true
De wens om domeinnamen niet tot ASCII te beperken is legitiem, er zijn landen waar heel andere tekensets gangbaar zijn (en onze letters nauwelijks) en daar wil men ook domeinnamen kunnen gebruiken die voor hun leesbaar zijn. De term "punycode" die in die instelling voorkomt is de naam van een codering om non-ASCII-tekens in ASCII weer te geven die in domeinnamen wordt gebruikt. Het is voor de meeste westerse gebruikers vermoedelijk prima om dat uit te zetten, onleesbare domeinnamen horen voor hun vermoedelijk bij onleesbare websites en de ene vorm van onleesbaarheid uitwisselen voor de andere is dan geen groot probleem. Maar grote delen van de wereld gebruiken niet-westerse alfabetten, en voor mensen uit die streken is het een heel ander verhaal.
De true-instelling betekent dat Firefox de URL's laat zien zoals ze bedoeld zijn. Meestal is dat toe te juichen, het kan alleen misbruikt worden.
Ik denk dat het default uitzetten meer een tijdelijke work-around is dan een oplossing. Wat hier uiteindelijk nodig is is een doordachtere manier om homograafaanvallen tegen te gaan dan nu wordt gehanteerd. Alleen kijken naar het mengen van talen volstaat niet, het moet op een database met op elkaar lijkende tekens gebaseerd worden. Daarin moeten ook homografen die tussen niet-westerse schriften optreden opgenomen worden, want waarom zou je alleen westerlingen beschermen? Da's al met al best een lastige klus, lijkt me.
Nu merk ik wel dat het grootste deel van het westerse alfabet echt afwijkt van het cyrillisch. Bij onze firmanaam krijg je hooguit de de helft van de letters enigszins gelijkend. b.v. een d, n of r vind ik alleen in gespiegelde vorm. Het gros van de domeinnamen is niet zo perfect te vervangen als de naam "apple".
Eigenlijk zou dat bij de domeinnaam registratie opgevangen worden, door geen domeinen toe te staan waarvan er al een versie bestaat met gelijkvormige ascii tekens.
network.IDN_show_punycode = true betekent dat je de punycode ziet, dus https://www.xn--80ak6aa92e.com/
false (default) betekent dat Firefox de URL's laat zien zoals ze bedoeld zijn, dus https://www.apple.com/
Zonder aangepaste config punycode parameter zelfs.
Een security beleidskwestie dus en geen technische kwestie.
Maar net waar je het accent legt in de securitybalans.
Ja en waar je inboet op security, daar zien anderen weer mogelijkheden.
Iemand Opera nog getest, wel interessant want zit in dezelfde geografische hoek.
Zonder aangepaste config punycode parameter zelfs.
Een security beleidskwestie dus en geen technische kwestie.
Maar net waar je het accent legt in de securitybalans.
Ja en waar je inboet op security, daar zien anderen weer mogelijkheden.
Iemand Opera nog getest, wel interessant want zit in dezelfde geografische hoek.
Correctie, heeft er wel last van.
Op de Epic voorbeeldsite werkt de truuk wel, zie forumpost
https://www.security.nl/posting/511208/Unicode+aanval+-+Phishing
luntrus
bij mij komt dit https://i.gyazo.com/dbb103d37ba24f6db02782ec8c65f0fd.png
firefox dit is idd serieus probleem !
Deze posting is gelocked. Reageren is niet meer mogelijk.
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?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
