Dit is door Redactie gisteren al gepost: https://www.security.nl/posting/511152/Browsers+kwetsbaar+voor+phishingaanval+via+unicode-domein.

Gisteren om 17:29 heb ik ik die fix toch echt al gepost onder https://www.security.nl/posting/511152/Browsers+kwetsbaar+voor+phishingaanval+via+unicode-domein dus hoezo breaking news

Toch waardevol deze post

Want er bestaat ook een Epic browser.
Maar die is van Hidden Reflex en niet van Epic.
Of horen die twee bedrijven wel bijelkaar?
Hoe het ook zij, Epic browser is op Chromium gebaseerd dus ook vast niet gevrijwaard.

Ook toch niet gevrijwaard, Torbrowser.
Dat leek met het Chinese voorbeeld wel zo te zijn maar in het voorbeeld van Epic niet.
Wat wel zo is is dat je dit op drie manier kan controleren


Drie opties om het te controleren :

- "Hover" (schuifmetdemuis) over de link.
Onderaan laat de browser dan het originele adres zien, dat is een actie die je kan ondernemen voordat je naar de website gaat!

Maar meestal weet je vooraf niet van de hoed en de ssl rand van een website en dat gaan gebruikers vast niet doen met elke link (oeioeimoeihoeihoeitemoei)

- Op de website zelf en in bijvoorbeeld firefox, klik het slotje in de url balk voor weergave van het certificaat aan, klik op certificaat bekijken en dan zie je bij de vermelding Issued To Common name CN het ware domein staan.

- Webadres kopiëren naar een tekst editor dat staat ingesteld op plain text weergave.


De hier gegeven aanpassing in de about:config is een afweger voor gebruikers van Torbrowser.
Dat betekent een aanpassing in je browser, en een aanpassing kan betekenen..
Maar dat is een afweging die je kan maken en waarschijnlijk komen ze bij Torproject snel met een fix die misschien wel gelijk is aan de hier geopperde methode van het veranderen van een config waarde.

Nieuwe Tails versie komt pas over drie dagen uit dus dat kunnen ze ook nog net voor de release meenemen.

Blij dat je er een topic van hebt gemaakt.
Kunnen we hier verder discussiëren met het gemak dat we het kunnen zien als iemand weer informatie heeft ingebracht.

Ik weet het zo net nog niet of "network.IDN_show_punycode=true" de beste oplossing is.
Ook als bij mij (default) "network.IDN_show_punycode=false" in about:config is ingesteld, zie ik geen enkel probleem.
Als ik op zo'n voorbeeld klik, staat in de url gewoon iets wat begint met xn- met nog wat ascii karakters.
Is dus al meteen duidelijk zichtbaar dat het een vreemde website is.
Zelfs als ik alleen maar met mijn muisaanwijzer boven zo'n frauduleuze link sta,
zie ik links onder in mijn statusbar al dat het om een website met xn- etc. gaat.
Ik vraag me dus af waarom ik het probleem niet heb.
Zijn er meer mensen met windows en firefox die het probleem niet hebben,
maar waar wel network.IDN_show_punycode=false" in about:config is ingesteld?

Voor wie het interesseert:
Het probleem is ook aangemeld bij https://bugzilla.mozilla.org/show_bug.cgi?id=1332714
en daar wordt nog met geen woord gesproken over "network.IDN_show_punycode=true" als oplossing.

Deze link vertelt hoe Firefox er enkele jaren geleden over dacht:
https://wiki.mozilla.org/IDN_Display_Algorithm#Downsides

Dat is ook niet een echte oplossing voor dit fenomeen. Hier in Nederland misschien wel, maar als je in Rusland, China, of een ander land met niet westers schrift woont, is het juist prettig als je de website naam in leesbare tekst ziet en niet in een of andere "codetaaltje".

Je zegt het zelf al: "Hier in Nederland misschien wel".
Security.nl is een nederlandse site met veelal nederlandse bezoekers.

Maar zoals gewoonlijk met dit soort milimeterreacties, het zal vast niet alomvattend zijn, er zijn vast ook lezers te vinden die èn nederlandse sites èn russische sites lezen.
Voor die mensen zal de oplossing een spagaat opleveren maar gelukkig zijn er dan nog andere methoden om de echtheid van die website te controleren. Oplossingen die hier 'toevallig' ook ter sprake zijn gekomen.

Het probleem schijnt al aanwezig vanaf 2005, toen Bruce Schneier er al over schreef.

Men verwachtte toen dat het rond eind 2010 zou zijn opgelost, alleen de HTML 'slakken' haalden de uitgezette protocolstreep nog steeds niet.

Het zal nog wel even duren eer elke HTTP client bibliotheek en exotische applicatie in staat zal zijn om met ongecodeerde Unicode karakters om te gaan.

Bijkomend probleem is dat niet elke agent een web browser is, denk aan Google zelf met zijn api interactie. Die crawlen echt anders en spam bots houden zich in de regel ook niet aan de geldende regels, zie RobotHoiHoi botscans.

Stapt men allemaal over op HTML5 dan is het probleem wel gelijk opgelost, zie de specificatie hier: https://url.spec.whatwg.org/

Check maar eens met de validator hier: http://validator.w3.org/

Over de doorsnee browser als aanvalswapen: http://www.cgisecurity.com/lib/URLEmbeddedAttacks.html

Info credits voor bovenstaande info gaat uit naar leden van het StackOverflow platform.

luntrus

Dat vermoedde ik inderdaad ook. Zou best eens kunnen.

Blijft over hoe het kan dat Firefox browsers die ik heb geprobeerd helemaal geen probleem lijken te hebben daarmee.
Hebben jullie de voorbeelden uitgeprobeerd op je browser en gecontroleerd of je browser daarmee een probleem heeft zoals wordt verteld?
Als ik af ga op wat ik in mijn brower zie, zeg ik "lariekoek".

ik neem aan dat google wel in staat is om het kaf van het koren te scheiden, dus in het vervolg via de zoekmachine van google naar uw favoriete sites.

en anders zelf intypen, of copy & paste vanuit een textbestandje, scheelt weer tijd.

Nou dat wordt leuk dan als je op geen enkele http site en geen enkele niet helemaal betrouwbare https site en in geen enkele email nog op links kan klikken omdat je elke daarvan volgens jou eerst moet googlen of toevallig al kent en uit txt bestand copy-pasten.

Als mensen een mail afz. Apple krijgen (fishing) met klik hier en ze zien dan https//www.apple.com/ met slotje dan hebben ze toch precies gedaan wat idereen altijd zegt.

Tis niet realisties wat jij schrijft . . .

@Dongel (en waardevolle aanvullende posts), dank voor het delen.

Als HTTP wel met ongecodeerde Unicode karakters om kan gaan, dan los je dit probleem toch niet op? Het probleem is juist dat de lezer het verschil niet kan zien tussen twee verschillende Unicode karakters die optisch gelijk zijn.

Het maakt dan echt niet uit of die Unicode karacters via punycode gegenereerd worden of dat de browser native Unicode herkent.

--

Je kunt overigens nog geen domeinnaam met unicode tekens aanvragen. In de naam van onze firma zit een trema, zodat onze domeinnaam niet perfect met de firmanaam overeen komt. Met die punycode krijg ik wel een domeinnaam met die trema erin, en die domeinnaam is natuurlijk ook nog vrij.

Ik denk echter dat de gemiddelde klant moeite zal hebben om die url (of een mailadres) met de hand in te tikken, want dan moet dat ook in punycode gebeuren.

Edit: Voor mensen die zelf met punycode willen testen: https://www.punycoder.com

Ik heb voor de aardigheid eens onze domeinnaam met trema in punycode aangemaakt op onze eigen DNS server. (werkt dan alleen binnen de lan).

Mij viel dan op dat als je de punycode in de url balk van safari plakt, hij dus ogenblikkelijk decodeert en de domeinnaam met trema laat zien. Dus dan zie je niet de punycode zoals wel met de eerder aangehaalde phishing voorbeelden gebeurde. Blijkbaar test Safari die code voordat hij wel/geen punycode laat zien.

In Chrome kan ik nu gewoon de url met trema intikken en ik kom op onze site. Ik heb daar als gebruiker niets met punycode te maken.

Mail gaat minder netjes. Ik kan een mail aanmaken en versturen met een trema in de url. De mail komt ook aan, maar als ontvanger zie ik nu wel de punycode als adres. (Getest met apple Mail)

@Dongel,

Eerste post van de redactie was mij niet opgevallen. Hartelijk dank voor de herhaling.

p.s. aanpassing in about:config van de Pale Moon browser v27.2.1 werkt ook. (getest)

Ieder zal z'n eigen voorkeur hebben maar feit is dat je veel beter via Google naar bv. de site van Apple of de Rabobank kunt gaan dan via een link in een mailtje waarvan je de afzender niet eens kent.

Ik blijf het vreemd vinden dat mijn browser er helemaal geen last van lijkt te hebben.
Er moet blijkbaar ook nog een andere mogelijkheid zijn waarmee je dit kan verhelpen?
Het is me een raadsel.

fixed in Chrome 58.0.3029.81

maar niet in Outlook 2016, zie comment #5 in https://isc.sans.edu/forums/diary/Tool+to+Detect+Active+Phishing+Attacks+Using+Unicode+LookAlike+Domains/22310/

Nou mijn browser heeft er wel last van, hopelijk niet in de adres balk, maar dat ga ik niet proberen ;-)

Hieronder een poging om te laten zien wat Unicode is. Als je helemaal onderaan begint met lezen, daar begint de tekst met het woordje 'Voor', dat echter in Unicode is geschreven. Er is maar 1 manier om deze tekst prettig te lezen, los jij het raadsel op?

?u??o??? s? u??z ?u?M ?s? ?po??u? ??? ???? nu ?? ??p u? ?????? ??? ??p doo? ?I ??o ???q?? ?o ???qo? ?? ?p????p ?? ?o ???u ?? u? u??d nu ?? q?? u? p?oo? ?? ?? ?p????p u? u??oq??s??puo ?s??? ?z?p ?? s??? u????ss?W ?u???? ???pu? u?? u????q??d?? ???pu? ??n s?????? u?? u???? ?? ??n?q?? ?oop u?p?oo? ?uo??? do pu????ds ????? ??? ?p???? u?qq?? u???? ?? ?po??u? ??? ??oou ?ou ??p u?su?? ?oo?

Ik denk dat forum berichten alleen in ASCII zijn, en geen Unicode ondersteunen. Dat zie je op sommige forums ook. Je kan alleen Westerse tekens uit de ASCII set gebruiken. En dat resulteert dan in allemaal vraagtekens op het scherm. De parsing van een text voor het in de database komt bij security website kan ook de tekst ontdoen van Unicode karakters. Iemand kan hier dan waarschijnlijk geen buitenlandse tekens posten. (Eigenlijk wel zeker.)

Ik weet het wel zeker. Het is mij vaak genoeg gebeurd dat ik een tekst goed zag in de preview – waar unicode tekens wel getoond worden – maar verminkt werd na posting.

Het is vooral irritant dat de preview anders is dan de posting zelf omdat de preview nu juist bedoeld is om te lijken of je alles goed hebt gedaan.

Daar zat nu juist het risico. En daar gingen de voorbeelden over. Maar bij mij gebeurt er niet bijzonders.
Er komt in de urlbalk iets dat begint met "xn-", en geen www.apple.com of www.ace.com of ook maar iets wat daarop lijkt.
En die pagina met xn- etc.... die na klikken op het voorbeeld in de urlbalk komt, bestaat niet.

Open kladblok, kopieer de volgende tekst daarin:
en sla deze op als test.htm op je bureaublad of zo.

Open de file in de browser die je wilt testen. Wat zie je onderin als je de muispijl boven test in die pagina laat zweven?
En wat zie je in de URL balk nadat je op test in die pagina hebt geklikt?

Enne... welke browser en versienummer hebben we het eigenlijk over?

Goed plan!

Dan krijg ik zowel bij zweven met de muis links onderin, en na klikken in de URL-balk:

En daarbij tekst:


Waarom zou de versie van de browser belangrijk zijn? Dit probleem zit er toch al een paar jaar in?
Ik heb zelfs ook eens de oude FF28 geprobeerd. Ook geen probleem te bekennen.
Heeft FF28 bij jouw wel het probleem?

Ik vermoed eerder een bepaalde hardening in de prefs.
Maar niet "network.IDN_show_punycode=true", want die staat bij mij op "false".
Er moet volgens mij nog iets anders zijn wat het probleem "mitigeert".

Ik ga later nog wel wat proberen wanneer ik tijd heb of ik erachter kan komen welke "hardening" hier voor zorgt.
Laat gerust weten als jij nog iets opmerkelijks vindt, en of FF28 bij jou wel of niet het probleem heeft.

Je zou kunnen kijken welke regels vet gedrukt zijn (niet de standaard waarde hebben) als je in about:config van Firefox filtert op: idn

Het zou ook best kunnen dat dit probleem in oudere Firefox versies nog niet optrad. Maar dat er onder de bezoekers van security.nl mensen zijn die internetten met een oude webbrowser met veel ernstiger kwetsbaarheden snap ik niet (ik ga in elk geval geen oude Firefox installeren alleen om te kijken of die dit punicode lek niet heeft).

Alle instellingen met idn staan bij mij op default. (geen vetgedrukte instellingen)
Je gaat met die oude browser natuurlijk alleen het voorbeeld bekijken. De kans dat een security researcher je in de val laat lopen is zeer zeer klein. Dan zou immers nooit meer iemand hem vertrouwen, en kan hij zijn werk als security specialist verder wel vergeten.

Ik krijg inderdaad apple.com te zien wat blijkbaar inhoudt dat de browser het als UTF of Unicode ziet. Een truukje om in gewoon ASCII tekst toch Unicode karakters te gebruiken is denk ik UTF.

Van Wikipedia zoeken op UTF

UTF-16 (16-bit Unicode Transformation Format) is a character encoding capable of encoding all 1,112,064 possible characters in Unicode. The encoding is variable-length, as code points are encoded with one or two 16-bit code units. (also see Comparison of Unicode encodings for a comparison of UTF-8, -16 & -32)

In de praktijk ondersteunt DNS geen Unicode, maar slechts ASCII (zoals www.xn--80ak6aa92e.com).

Punycode is een truc van webbrowsers om ASCII domeinnamen (die met xn-- beginnen)om te zetten in Unicode en dat te tonen in o.a. de URL balk (i.p.v. de werkelijke DNS naam). Goed bedoeld maar helaas niet zonder risico's.

Punycode is helemaal geen truuk van webbrowsers.
Punycode is een efficiënte codeermethode om (delen van) domeinnamen die uit niet ondersteunde ASCII karakters bestaan (en zijn gevat in Unicode) om te zetten naar een reeks ondersteunde ASCII-tekens die deze Unicode teken(s) vertegenwoordigen.
Zo kunnen bijv. je browser en je e-mail cliënt er tenminste nog iets van maken.
Het DNS systeem kan die non-ASCII karakters op zich wel ondersteunen. Daar zit niet zozeer het probleem.
De restricties om alleen een subset van ASCII te gebruiken (letters, cijfers,-) zit 'em in de eis van de gebruikte standaard netwerkprotocollen. En daarom is het DNS-systeem gedwongen om daar rekening me te houden.

Een domeinnaam die met deze codeermethode is omgezet wordt een domeinnaam weergegeven "in punycode".
Net zoals bijvoorbeeld getallen of karakters kunnen zijn weergegeven "in hexadecimaal".
(hexadecimaal is in wezen een codeermethode voor het weergeven van getallen)

Een codeermethode dus. Punycode is een codeermethode.
xn-- maakt eigenlijk zelf geen deel uit van de punycode. (vergelijk: "0X" maakt zelf geen deel uit van een hexcode)
Het is een voorzetsel dat een IDN voor de punycode zet.
Dit hoeft niet altijd aan het begin te staan.
Als de websitenaam begint met "www." (=geen punicode) hoeft daar geen xn-- voor.
xn-- staat voor het deel tussen de puntjes van de websitenaam die punycode nodig heeft omdat er één of meer karakters zijn gebruikt die standaard niet in een domeinnaam mogen voorkomen.