Alternatieve browsers kwetsbaar voor phishing

Op Schmoocon, een bijeenkomst voor hackers, is een nieuwe exploit gedemonstreerd die bruikbaar is op alternatieve browsers. Doordat de phishing exploit misbruik maakt van de International Domain Name karakterondersteuning, die in Internet Explorer standaard niet aanwezig is, zijn enkel alternatieven als FireFox en Opera vatbaar voor misbruik met behulp van dit principe. Met behulp van een proof-of-concept kan men controleren of een browserconfiguratie IDN-ondersteuning biedt en daardoor misbruikt kan worden. Doordat Internet Explorer standaard echter niet vatbaar is - IDN-ondersteuning moet met een plugin toegevoegd worden - wordt verwacht dat het lek niet zo interessant zal zijn voor phishers. Door de eigenschap network.enableIDN in Firefox op 'false' te zetten, kan dit lek niet meer misbruikt worden. Belangrijk hierbij is dat eerst de cache leeggemaakt moet worden en dat naar verluidt de exploit terug werkzaam is nadat de browser opnieuw opgestart werd.

De exploit werkt ook bij met ssl-beveiligde sites

Reacties (92)

[Gerco]

Misschien is het handig om te vermelden dat dit geen bug is, maar een gevolg van het correct implementeren van de standaard.

In de URL worden characters uit andere charactersets gebruikt die er precies hetzelfde uitzien als characters in de "normale" set. Hierdoor zie je dus een domeinnaam, maar is het een andere.

Zowel het displayen van de domainnaam als het opvragen van de paginas is volkomen correct in alle ondersteunende browsers. Dit is eerder het gevolg van een bug in de standaard dan een bug in de browsers. (IE is ook vulnerable als je de plugin installeert met IDN ondersteuning, het ligt dus meer aan IDN dan aan de browsers)

In December 2001, a paper was released describing Homograph attacks [1]. This
new attack allows an attacker/phisher to spoof the domain/URLs of businesses.
At the time this paper was written, no browsers had implemented Unicode/UTF8
domain name resolution.

Deze bug in de standaard is dus al in 2001 beschreven, lang voordat browsers er ondersteuning voor hadden. Het KAN dus per definitie geen browserbug zijn.

Wel behoorlijk beschamend dat de standaard nog niet is aangepast moet ik zeggen.

[sopsop]

Valt hier de vergelijking te trekken met het 'lek' in Microsoft's DRM? (het beschreven lek is 'by design'):
http://www.tweakers.net/nieuws/35749/

Valt me op dat er in dat geval een stuk meer gebashed wordt dan in dit geval.

[Gerco]

Ik denk het wel ja. Dit "lek" is niet op zichzelf te gebruiken, net als die DRM kwestie is het op zichzelf niet gevaarlijk.

Het enige andere aan die DRM kwestie is dat altijd IE gestart wordt (ook als dat niet je default browser is) en daarna met behulp van andere IE exploits spyware geinstalleerd kan worden.

Op zich allemaal niets nieuws, het enige wat die DRM kwestie erger maakt is dat media player altijd IE opstart ipv de default browser, maar als je bedenkt dat dat ook niet anders KAN (die license download heeft ActiveX nodig) is dat ook niet zo erg meer.

Wat deze kwestie erg maakt is dat het "lek" al jaren bekend is en er niets aan is gedaan...

[Verwijderd]

Moet je toch eens het proof of concept bekijken.
Ik vind het heel erg dat mijn browser aangeeft dat ik met SSL verbonden ben met paypal (of de abnamro of...) terwijl dat dus niet zo is.

[locke960]

Hmm, IDN is een standaard ontwikkeld door de IETF (www.ietf.org). De IETF is een activiteit van de Internet Society, [url="http://www.isoc.org."]www.isoc.org.[/url] en wat lezen we daar: ISOC would like to acknowledge the Microsoft Corporation for donating software for our office operations.

poe.. gelukkig is het toch nog Microsofts schuld

[Verwijderd]

Misschien is het handig om te vermelden dat dit geen bug is, maar een gevolg van het correct implementeren van de standaard.

Wat koop ik nou voor dit geneuzel? Altijd maar dat relativeren van problemen in andere browsers... bah. Ik gebruik zelf Firefox en baal hier van. Hier moet gewoon een bugfix voor komen. En gaarne snel!

[Verwijderd]

Waar je dan aan voorbij gaat is dat de exploit anders is dan anders. De a in paypal in het voorbeeld is eigenlijk een а ( & # 1 0 7 2 ; ) en dat is dus een andere letter dan de a die we in de ascii-tekenset gebruiken. Ondersteuning hiervoor maakt het mogelijk dat ze in china url met hun eigen karakterset kunnen registreren en weergeven. Moeten we dat dan weer snel terugdraaien?

[Gerco]

Ik zeg toch ook niet dat het geen groot probleem is? Het is zeker een probleem, maar geen browserbug. Er is een verschil.

Dat de developers hadden moeten kiezen om de standaard niet te implementeren of op zn minst aanvullen met wat waarschuwingen hier en daar staat buiten kijf.

[Verwijderd]

Waarmee je eigenlijk aangeeft dat het "achterlopen" van MS op dit gebied wel eens een bewuste keuze kan zijn geweest. Vergeet niet: Dit probleem was al in 2001 bekend. Nog voordat IDN geimplementeerd werd.

Edit @Killercow
Zou jij een standaard implementeren waar van je weet dat die grote problemen voor de gebruikers gaat geven?
Het is onzin om dit te vergelijken met een auto die maar 40 kan. Ik heb nog nooit iemand IDN als belangrijk voordeel van Firefox horen aanhalen en heb ook nog nooit gehad dat een site die ik wil bezoeken niet met IE toegankelijk was. En ik denk dat in ieder geval dat laatste voor 99% van de internet gebruikers geldt.

[killercow]

Zelfs als het een bewuste keuze van MS is is het een lompe beslissing, Zou jij een auto kopen waarvan de fabrikant zegt dat je er maar 40 mee kunt omdat je je dan niet dood kan rijden?

nee toch? dan wil je toch ook gewoon 120? en dan wil je er gewoon gordels en bumpers bij toch?

[Biertjuh]

Maar ik wil geen gordels waarvan bekend was dat ze niet deugden.

[GORby]

(reactie op killercow): Zelfs als Mozilla-gebruiker vind ik dit een beetje erover. Het is nu niet dat het browsen met deze feature ineens 3x sneller zou gaan hoor. Het is eerder zoiets als 'wil u graag de optionele parkeersensoren?', want het is een vrij triviale feature, die via een plugin ook beschikbaar is in IE.

Ik vraag me eigenlijk af waarom die feature geimplementeerd werd in de alternatieve browsers als deze fout in het protocol al zo lang bekend is.

[Olaf van der Spek]

Het KAN dus per definitie geen browserbug zijn.

Hoezo niet?
Het is dus wel een bug in de browser. De browser is namelijk het geheel van zijn (onder)delen en een van de (onder)delen is kapot en dat wordt niet door de andere (onder)delen gefixed/opgevangen.

[cavey]

Nah,

zoals zovelen al zeggen: het is geen bug in de browser.

Het is een design fout in de standaard. Een bug dus die op een veel hoger niveau staat.

Tenzij jij natuurlijk ook wil aangeven dat Windows eigenlijk stuk is ... aangezien de browser daar onderdeel van is (al dan niet volledig geintegreerd)... je kan jouw vergelijking best ver door trekken zeg maar "het geheel van zijn (onder)delen".

Ruim begrip

[Gerco]

Ik definieer een bug als software die zich anders gedraagt dan het is ontworpen. Deze gedraging staat wel in het ontwerp, dit is dus wel een fout, maar geen bug.

Als het een bug (=programmeerfout) had geweest, hadden niet alle browsers die het ondersteunen het op dezelfde manier fout gedaan. Zelfs IE met de optionele plugin werkt correct (en dus in dit geval fout).

[tommy320]

Sinds wanneer is het incorrect implementeren van een standaard geen bug? Alles wat niet werkt zoals het zou moeten werken is een bug.

Als het een bug is in de standaard dan moet je zorgen dat het niet standaard aanstaat.

[Gerco]

le-zen... de standaard is correct geimplementeerd, dit werkt precies zoals het zou moeten werken. Helaas heeft de standaard een (niet eens onverwacht) gevolg.

[JeroenB]

Het correct implementeren van een retegevaarlijke standaard is misschien geen bug, maar het is de ontwikkelaars in ieder geval aan te rekenen dat ze het gewoon gedaan hebben en dat het standaard allemaal aanstaat.

Tenslotte, veel van de MS-verwijten zijn gebaseerd op correct werkende, maar standaard gevaarlijk geconfigureerde applicaties (zoals IIS).

[Verwijderd]

Dan is de standaard fout en moet die opnieuw op de tekentafel..
Het is niet altijd goed de standaarden te volgen als je de gevolgen kunt inschatten.

[Aaargh!]

Als je het bericht waarop je reageert eens beter leest: het gaat om het CORRECT implementeren van de standaard.
De 'fout' (als je 't dat al kan noemen) zit in de standaard.

[BTB]

Je zou kunnen zeggen dat de fout in Unicode zit: een normaal mens denkt: als het er uit ziet als een `a' dan is het een `a'. Maar dat blijkt dus niet zo te zijn. Er zal misschien best een goeie reden voor zijn om verschillende tekens te hebben die er hetzelfde uitzien, maar leg dat maar eens uit.....

[florizla]

De standaar is correct geimplementeerd, niet INcorrect. Het is dus geen bug maar wel een beveiligingsprobleem(pje).
Edit: te laat...

[Modalen]

Dit is een serieus probleem. Banken wijzen gebruikers van bijv. internet bankieren er vaak op dat ze moeten controleren of de juiste URL zichtbaar is in de adresbalk, en dat is hier het geval. Een nietsvermoedende bezoeker ziet nergens aan dat hij of zij niet de site van de bank bezoekt. Dan wordt het dus wachten op de eerste virussen die links in bookmarks aanpassen...

[Aaargh!]

Banken wijzen gebruikers van bijv. internet bankieren er vaak op dat ze moeten controleren of de juiste URL zichtbaar is in de adresbalk, en dat is hier het geval.

Nee, dat is niet het geval. Het probleem is dat mensen de rare neiging hebben om te kijken naar de vorm v/d tekentjes ipv de achterliggende unicode waarde

[miw]

Maar er zit dus gen enkele voorziening in Mozilla/Firefox om die unicode waardes te bekijken. Het wordt gelijk voor je omgezet in glyphs. Ook in de properties van een link krijg je niet de unicode string te zien.
Verder schiet Mozilla gewoon te kort doordat de network.enableIDN op false te zetten de kwestie niet echt oplost na een herstart van het programma. Verder mis ik een soort tussenvorm waarin een aantal redelijke IDN extensies toegestaan worden. Er is dus heel wat af te dingen op het argument dat de "alternatieve browsers" de IDN standaard correct geimplementeerd hebben, terwijl allang bekend was dat er problemen kleven aan die standaard.

[Aaargh!]

Maar er zit dus gen enkele voorziening in Mozilla/Firefox om die unicode waardes te bekijken.

Right click -> view page source . of de tekst selecteren en dan "view selection source"

[Remus]

Als je in about:config network.enableIDN op false zet, dan blijft dat na een herstart gewoon behouden.

edit:

Aha, ondanks de instelling, werkt het na een herstart inderdaad niet meer...

[Rataplan]

Extreem onveilig is het niet, als je tenminste alleen over secure connecties persoonlijke en financiële details verzendt.

SSL is immers gekoppeld aan certificates. Als je een site bezoekt die geen certificaat van een trusted certificate authority heeft, krijg je keurig een waarschuwing: certificate not valid! Een paar hele bekende authorities worden met je browser meegeleverd; andere moet je zelf met de hand toevoegen.

Krijg je die waarschuwing niet, zoals in het geval van de "proof of concept" uit het nieuwsbericht; dan heb je of een rare authority toegevoegd (eigen schuld) of je kan de eigenaar van het certificate, dus de phisher, via de trusted authority terugvinden. Bij bijvoorbeeld fraude met telebankieren zijn phishers dus aansprakelijk te stellen.

Met deze proof-of-concept-pagina wordt er de indruk gewekt dat phishers zomaar met je PC kunnen klooien, maar daar hebben ze zich wel op een herleidbare plaats voor moeten registreren - dus als ze iets naars met mijn PC doen zal ik ze meestal wel weten te vinden

[Zwartoog]

Wat dus eigenlijk het probleem is, is dat er twee manieren zijn om een bepaalde letter te presenteren: namelijk een (ouderwetse) ASCII waarde en een IDN waarde.

In dat geval is dit een zwak punt van de domain name registars, die toestaan dezelfde letter op twee verschillende manieren weer te geven.

Klopt dat, of sla ik hier de plank mis? En zou het nog kunnen om dit terug te draaien?

[Unverter]

In dit topic op MozillaZine is te lezen hoe dit probleem in Firefox 1.0 en Mozilla 1.7.5 wel op te lossen is. Er moet dus iets meer moeite voor gedaan worden, maar het kan wel zonder het iedere keer bij het opnieuw starten weer uit te schakelen.

Verder ben ik met veel mensen hier eens dat ze bij alle browsers wat beter na hadden moeten denken, hoewel in principe aan de standaard ligt.

Ik las trouwens ergens anders dat ze bij Mozilla over een oplossing aan het nadenken zijn, terwijl ze bij Opera de standaard als schuldige aanwijzen. Bron kan ik zo snel ff niet meer vinden.

[emgaron]

Grappig dat MS dus deze keer toch eens een voordeel heeft door hopeloos achter te lopen in de browser ontwikkeling...

[oZy]

Misschien moeten we ons gewoon eens gaan realiseren dat *niets* bij voorbaat 100% veilig zal zijn.

[labtech]

Ik blijf het inderdaad vreemd vinden dat heel veel mesen dondersgoed weten dat hoe goed je je huis , auto of fiets ook beveiligd, je nog altijd kans loopt om slachtoffer te worden van een inbraak.

Bij computers is het al snel "Maar ik heb toch een firewall?"

[Verwijderd]

Simpel op te lossen: type zelf je belangrijke urls.

[Verwijderd]

Goh kom je daar nu pas achter..

[Verwijderd]

Misschien moeten we ons gewoon eens gaan realiseren dat *niets* bij voorbaat 100% veilig zal zijn.

Inderdaad.. als je NIETS gebruikt, heb je ook nergens problemen mee...

[zetta]

m.a.w. alleen onder specifieke condities dat phishing weer gedaan kan worden door hackers. Altijd weer hetzelfde verhaal lijkt mij, mensen die op hele foute sites foute dingen lopen te klikken zijn met FireFox of Opera echt nog niet veilig. Das niks nieuws.

[Verwijderd]

Ik ben er ook zeker van dat je met firefox en andere al een heel stuk veiliger bent op allerlei twijfelachtige sites dan met IE (ActiveX .....).

Misschien moeten we de mensen eens "opleiden" en ze bewust maken dat ze niet zomaar in het wilde weg moeten klikken.

[Verwijderd]

Misschien moeten we de mensen eens "opleiden" en ze bewust maken dat ze niet zomaar in het wilde weg moeten klikken.

Ik las op Webwereld.nl het volgende artikel. Ministerie komt met diploma Veilig Internet: http://www.webwereld.nl/nieuws/20735.phtml

[the_stickie]

ik surf altijd met IE, en heb nog maar één keer er spyware door binnengehaald: toen IE me kwam vragen het script uit te voeren of niet, ik twijfelde klikte toch maar ja...

Mijn idee is dat IE standaard te onveilig is, maar zeker voldoende veilig te maken is door de juiste instellingen te doen. Op dat vlak sla je met "opleiden" imho de nagel op de kop. Veel mensen (incl een hoop tweakers blijkbaar) vinden IE bij voorbaat slecht en onveilig zonder dat ze weten wat je allemaal zélf in de hand hebt dmv instellingen

[Facer]

IE is misschien voor jou niet onveilig maar voor een persoon die niet er zoveel koek van gegeten hebben misschien wel...

Die personen willen nog wel is snel op Ja drukken en alles eromheen installeren.

Firefox herkent dit gewoon niet waardoor je dus ook de vragen van installeren ook niet krijgt

[Verwijderd]

Dus als mijn hele systeem bij wijze van vol loopt met spyware, doordat de browser dit toelaat, dan moet ik dit zoeken bij de standaard.

Dat is tof, moet ik onthouden voor mijn klanten die een bug in hun software voorgeschoteld krijgen waarbij volgens standaarden is gewerkt. "het is niet onze schuld, het is de standaard".. wat denk je dat de klant dan zegt ".. ow .. ok is goed" ?

[DJ Henk]

Als de standaard het toelaat dat twee verschillende domeinen er hetzelfde uitzien is het inderdaad een standaard met een bug.

Van welke prutsers is deze standaard eigenlijk afkomstig?

"het is niet onze schuld, het is de standaard".. wat denk je dat de klant dan zegt ".. ow .. ok is goed"

Welkom in de wereld van webdevelopment, waar iedereen weet hoe het beter kan, maar iedereen klem zit tussen klanten en opgedrongen standaarden.

[pinockio]

Wat zie ik daar? Boven in het venster staat [url="https://www.paypal.com."]https://paypal.com.[/url] Maar onderin staat: bezig met laden van *.4ve.com. Kortom, als je oplet kun je zien dat je niet de originele Paypal website bezoekt.

[Verwijderd]

Ik zie niks
Maar misschien komt het doordat bij mij die popup ook niet verschijnt.

[Rafe]

Staat gewoon in de advisory:

The links are directed at "http://www.pаypal.com/", which the browsers punycode handlers render as [url="http://www.xn--pypal-4ve.com."]www.xn--pypal-4ve.com[/url].

[LeX-333]

Is dit niet een beetje de fout van de instantie die de domeinnamen toewijst, paypal.com en p#1072ypal.com zien er exact hetzelfde uit. Voor de gebruiker is dit dus gewoon dezelfde domeinnaam. Het is een beetje vies om dit client-side door middel van een waarschuwing ofzo op te lossen.

[Verwijderd]

Even de reacties doorgelezen, en je bent de enige die deze oplossing aangeeft waar ik direct aan dacht. Je noemt hem dan wel vies, maar ik zou het niet zo erg vinden als ik een bevestiging moet geven als ik naar een url gestuurd wordt die bestaat uit eventueel verwarrende tekens. Dus niet alle tekens buiten de ascci set hoeven tot problemen te leiden, maar wel degene die voor ons moeilijk te herkennen zijn als anders van ons eigen alfabet.

[miw]

Het is ieder geval wel degelijk voorgesteld om een aantal beperkingen op te leggen aan de registratie van IDN domeinnamen. Kennelijk is dat niet in praktijk genomen.
Als je dit wilt voorkomen, kan je natuurlijk via de automatic proxy configuration (pac files), je eigen restricties programmeren om die foute URL's eruit te vissen. Er zijn ook andere boeiende toepassingen van pac-files, die goed de mogelijkheden demonstreren.

[Frank071]

Nou... correct implementeren van de standaard... Ik ben het er wel mee eens dat dit probleem door slecht nadenken met IDN is geintroduceerd, maar bij het implementeren had dan wel weer goed nagedacht kunnen worden. FireFox strooit (terecht) met security warnings als je iets klikt of doet wat kan duiden op 'misbruik', dus dat had hier ook wel gekund:
"You have clicked 'www.paypal.com' but will visit 'www.xn-pypal-tr44.com'. Do you want to continue?"

(Eventueel met een Help button dat je naar informatie over IDN verwijst).

Frank

[Modalen]

Dat is wel mogelijk, maar ook weer heel gemakkelijk te omzeilen. Namelijk: laat in plaats van een tekstuele representatie van de url (HTML) een gifje zien waar de url in staat. Dan lijkt het net alsof je een 'gewone' HTML-link aanklikt.
Gevolg is dat je nog steeds naar de verkeerde site wordt doorverwezen, en dat dat uit de adresbalk niet blijkt. Een browser kan niet controleren welke url in het gifje stond, en kan dus nooit een waarschuwing geven.

[RSpliet]

Maakt niet uit, het IDN systeem wordt nog steeds aangeroepen. De browser weet toch ook waar het heen moet .
Mijn voorstel is dan ook om in ieder geval tot deze design flaw is opgelost een waarschuwing weer te geven als er een link wordt gevolgt naar zo'n IDN-site van een andere site, of vanuit een ander programma, en dan eventueel een whitelist bij te houden. In die waarschuwing moet worden weergegeven om welke tekens het gaat, misschien ook handig om een lijst van op-"basic latijn"-lijkende tekens in te bouwen en die laten testen op de URL. Maargoed, laten we maar wachten wat de Mozilla crew ermee doet (en uiteraard de Opera crew etc.)

[Verwijderd]

idd, in dit geval denk ik dat de browserbouwers wel een waarschuwing kunnen geven. Zeker nu het 'algemeen' bekend is zal er vaker misbruik gemaakt gaan worden van dit 'probleem'.

Wat ik me wel meteen afvraag.. Hoevaak is dit al gebruikt? en hoeveel mensen zijn erin getrapt?