IDN eller International Domain Names, är ett system som utvecklats för att se till att vi kan använda internationella tecken när vi registrerar och använder domännamn. Med ”internationella” menas allting som inte finns i ASCII.

IDN fungerar genom att applikationer som vill kunna använda internationella domännamn konverterar originalet med dess Unicode-symboler till punycode. Det är ett sätt att konvertera IDN till ren ASCII och med punycodeversionen av namnet kan man sedan utan problem slå upp det i DNS et cetera utan att den delen av ekosystemet behöver kunna någonting om Unicode. ­Domänen räksmörgås.se blir till exempel

Tack vare IDN och punycode kan vi använda URL:er med åäö utan problem i diverse verktyg och webb­läsare, men även URL:er med domäner som är skrivna helt med arabiska, kinesiska, ­kyrilliska eller andra icke-latinska skriv­tecken. Därmed är

en fungerande URL, om även ganska svår att skriva in för många personer utanför Japan. Närapå hela Unicode-rymden finns tillgänglig, och detta är förstås attraktivt för stora delar av världen där ASCII inte räcker till för lokala namn och varumärken. Glömda är de dagar då alla namn och URL:er behövde skrivas med ASCII.

Så snart IDN lanserats insåg man att Unicode innehåller många symboler som är identiska eller nästan identiska med andra symboler och att det kan utnyttjas. Man kan hitta på ett namn och skapa fejkade sajter med namn som har väldigt få eller kanske inga visuella skillnader från det namn du försöker efterlikna.

Ett exempel är paypal.com. Den kan i de flesta typsnitt byta tecknet ”l” mot Cyrillic Capital Letter Iota och se helt identisk ut.

Det kallas för en homograf och tekniken att ersätta ett eller flera tecken mot symboler som ser identiska ut kallas en homograf­attack. Den kan försvåras i webbläsare, vilka bland annat byter till att visa adressen i URL-raden i punycodeformat när de bedömer det lämpligt, så att användare ska få en chans att upptäcka att det inte var det paypalnamn i adressfältet som de trodde att det var.

Domännamn med tecken från flera olika scripts (i princip från flera olika språk) visas till exempel alltid som punycode istället för med Unicodesymboler. Detta gör homografattacker lättare att genomskåda; i alla fall av de användare som läser och förstår adressfältet i webbläsaren.

Att webbläsare gör så hjälper hjälper dock inte om någon försöker få dig att köra till exempel ett curl-kommando som använder tricket:

Om någon kopierar den raden från ett on­line-dokument, klistrar in den i en terminal och trycker på return så kommer den kanske lite överraskande att visa

Det finns också en annan variant av symbolbytet ovan, som åtminstone för mig har flugit under radarn länge. Jag vill gärna kalla den en heterografattack eftersom den fungerar lite tvärtom: det är ett sätt att få namn att se olika ut men ändå i slutändan vara exakt samma.

IDN har ett inbyggt koncept där det ”hjälpsamt” ersätter ett antal symboler som ser likadana eller nästan likadana ut som ett ASCII-alternativ med just det ASCII-tecknet. Jag tycker att det här orsakar mer problem och smärta i folks liv än det gör nytta.

Det betyder att ett namn som använder en IDN-version av en eller flera symboler kan få dem översatta till sina ASCII-motsvarigheter. Effekten kan alltså bli att ett namn som använder IDN omvandlas och kanske inte längre använder IDN när processen är klar och därmed kan användas ”som vanligt” från den punkten – utan punycode. Exempel:

Kopierar man den här raden och klistrar in i en terminal så upptäcker man att den fungerar. Också i webbläsare, med det lilla tillägget att den visar adressen som curl.se – den färdigomvandlade versionen.

Den här metoden att skriva in alternativa versioner av namn kan användas för att undvika filter och blockeringar, och har redan använts för att hitta ett par säkerhetsproblem i curls HSTS-hantering. Det finns helt säkert många verktyg, filter och program ute i världen som kan luras med variationer av det här tricket.

Adressen fungerar för att symbolerna i namnet översätts automatiskt till sina ASCII-motsvarigheter av IDN-funktionen. När översättningen är klar är det bara curl.se kvar, vilken då inte ens behöver punycode.

Exemplet ovan visar också att heterografattacken kan byta ut punkter. Jag använder tecknet Halfwidth Ideographic Full Stop.

Unicode-rymden är stor och det finns mängder av alternativ för i stort sett varje ASCII-tecken i det latinska alfabetet. Bara för bokstaven C hittade jag snabbt minst 15 olika Unicode-symboler som översätts till den. Bokstaven E verkar ha ännu fler. De kallas confusables och du kan undersöka dem genom att följa QR-länken intill. Mängden möjliga permutationer för ett givet namn skrivet i ASCII är enorm.

Det slutar inte med att det finns Unicode-alternativ till bara bokstäver. Det finns även alternativ till andra i URL:er vanligt förekommande tecken som kan användas för att riktigt förvirra en vanligt dödlig. Till exempel är Fraction Slash förvirrande lik en vanlig ASCII framåt-slash. Stoppar du in den i en URL och ser till att du har din egen domän efter, kan du skapa konstverk som det här:

Om du klistrar in den URL:en i en webbläsare kommer den förstås att byta till punycode-läget direkt, men ändå. Det kanske är försent.

Som ett alternativ till slashen som inte är en slash så kan man också luras med något som ser ut som ett frågetecken men inte är det. Symbolen Latin Capital Letter Glottal Stop är väldigt lik ett frågetecken i många teckensnitt:

Självklart vore det enkelt att sätta upp en server med just dessa namn ifall vi verkligen ville lura användare.

Låt oss avrunda med ett tredje tecken som är vanligt i URLer: hash-symbolen som avgränsar den del av URL:en som kallas fragment. Just den delen av URL:en är ju normalt lite annorlunda eftersom den inte skickas över nätet och därmed egentligen bara har betydelse lokalt i webbläsaren. Så länge man inte byter ut den mot något annat då.

Symbolen Viewdata Square kan användas för att lura en användare här. Vid en snabb blick kan man lätt tro att följande URL leder till trusted.com:

Som om allt det där inte skulle räcka, lägger vi till en nivå på klurigheterna: procentkodning. I en URL kan man koda enskilda oktetter och ersätta dem med dess bytevärde skrivet som %HH där HH är ett tvåsiffrigt hexadecimalt tal. Tecknet ”a” kan därmed alltså istället skrivas som ”%61” i en URL.

Vi kan kombinera en heterografvariant från ovan med procentkodning så att följande harang fortfarande landar som curl.se:

Du kan klistra in den i en webbläsare och det fungerar lika fint där. Sekvensen är alltså sju stycken procentkodade Unicode-symboler skrivna i UTF-8.

Unicode har en rolig symbol som rent bokstavligt inte är någonting. Den heter Zero Width Space och är alltså ett mellanrum som inte har en bredd. Den syns inte och tar ingen plats när den används. IDN känner till den här symbolen och tar automatiskt bort den om den används i ett domännamn. Det betyder i sin tur att du kan stoppa in en eller flera sådana här mellanrum utan bredd i ett hostnamn i en URL utan att det förändrar hur URL:en hanteras. Den exakta sekvensen för den här symbolen skriven i procentkod är

Istället för curl.se kan vi alltså använda

Användare av curl eller andra kommandoradsverktyg kommer förstås inte se en punycode-version av URL:erna någonstans så kanske är de därmed lite enklare att lura med såna här trick. Det är ju dessutom numera vanligt i mycket dokumentation att erbjuda exempel-rader färdiga att kopiera och klistra in direkt i terminalen. Även i de fall användaren är mycket uppmärksam och kanske också kontrollerar verbose-data noggrant är ett sådant bedrägeri svårt att upptäcka.

Att det är HTTPS som används i de här fallen räddar eller hjälper inte någon heller eftersom det inte finns något som hindrar bedragare att skapa dessa domännamn och erbjuda helt legitima certifikat för såna namn.

Ett sätt att lura folk som inte är lätt att fånga är att förmå användare att ladda ner någonting genom en dylik fejk-sajt, medan det ser ut som att det sker från en känd och betrodd domän. Typ:

Eftersom frågetecknet i URL:en är en Unicode-symbol och curl stöder IDN, så laddas filen egentligen ner från fake.com istället för trusted.com. Ägaren av fake.com behöver bara se till att de har ett namn i sin DNS som heter trusted.xn--com-qt0a.fake.com och leverera innehåll över HTTPS där.

En attack skulle även kunna använda sig av en omdirigering till den riktiga trusted.com i 99 procent av fallen, eller kanske för samtliga fall där user-agenten eller source-IP:t inte stämmer överens med de som vi letar efter och vill lura.

Det gamla tricket att ”pipe:a output från curl direkt till shell” är förstås också något som väldigt tydligt skulle vara skadligt om man kan få användaren att ladda ner innehåll från fel sajt:

IDN och Unicode innehåller ännu fler finesser som kan användas för att snurra till det för användare. Det talas till exempel om att man genom att blanda vänster-till-höger text med höger-till-vänster i samma domän kan knöla till det ordentligt. Och det finns saker som att en Unicode-symbol kan omvandlas till två ASCII-tecken, et cetera. Det här är helt enkelt en skattkammare för den som vill erbjuda användare hjärngymnastik!

TLD-ägare och organisationer som erbjuder registrering av domäner har blocklistor för symboler de inte tillåter. Det förhindrar dock inte att vi kan använda dem i subdomäner. De trick jag visat ovan fungerar ju allihop utan att någon ny domän registreras. Alla TLD:er är dessutom inte lika strikta eller ens noga med att upprätthålla sina regler. Det har visat sig tidigare när domäner registrerats innehållandes smileys, et cetera.

Av Daniel Stenberg, Polhemspristagaren bakom det populära f ilöverföringsbiblioteket Curl