Onderzoeker toont hoe autofill-browserfunctie voor phishing gebruikt kan worden

De Finse beveiligingsonderzoeker Viljami Kuosmanen heeft getoond hoe kwaadwillenden van de browserfunctie voor het automatisch vullen van formuliervelden gebruik kunnen maken om gegevens te stelen. De methode werkt aan de hand van verborgen formuliervelden.

Kuosmanen voorzag de Duitse site Golem van uitleg over zijn project en publiceerde de broncode op zijn GitHub-pagina. Zijn methode maakt gebruik van verborgen formuliervelden, die met wat css buiten het zicht van de gebruiker worden gehouden. Dit weerhoudt de browser er echter niet van om de verborgen velden in te vullen, ook al zijn er maar een of twee zichtbaar voor de gebruiker.

Zo denkt de gebruiker bijvoorbeeld alleen de velden voor naam en e-mail in te vullen, maar geeft hij via de verborgen velden meer informatie prijs. Om dit te demonstreren, bouwde de onderzoeker een demosite. Hij testte zijn methode in Chrome en in Safari, die beide vatbaar zijn voor een dergelijke aanval. Voor gegevens als gebruikersnamen, wachtwoorden en creditcardgegevens is de methode niet te gebruiken, omdat de browsers daarbij een waarschuwing tonen.

Safari toont aan de gebruiker welke gegevens ingevuld worden, maar een onoplettende gebruiker kan hierdoor alsnog te veel in laten vullen. Firefox is niet vatbaar voor de methode, omdat deze niet zozeer over een autofill-functie beschikt, maar meer over een autocomplete-variant, legt de onderzoeker aan Golem uit. Zo moet een gebruiker elk veld afzonderlijk selecteren om een lijst met eerder ingevulde opties te zien te krijgen.

De onderzoeker zegt dat hij op het idee kwam toen hij zich ergerde aan de autofill-functie in Chrome en wilde achterhalen hoeveel gegevens de browser eigenlijk van hem heeft opgeslagen. Hij voegt daaraan toe dat de methode niet nieuw is, omdat deze bijvoorbeeld ook voor honeypots wordt gebruikt. De methode toont echter aan dat browsers niet detecteren dat bepaalde velden voor de gebruiker onzichtbaar zijn en dat er nog steeds geen oplossing voor het probleem is. Volgens Kuosmanen is een mogelijke verdediging het uitschakelen van autofill, wat überhaupt een goede maatregel is. Daarnaast ziet hij het meest in de aanpak van Firefox.

Demonstratie van de meegezonden gegevens, via GitHub

Reacties (46)

[WK100]

Misschien interessant: mijn Dashlane Password Manager maakt deze fout dan weer niet. Dit ondanks ik op de autofill-optie heb geklikt. Ook dit in Google Chrome; nog een reden om over te stappen lijkt mij

[Reactie gewijzigd door WK100 op 22 juli 2024 16:36]

[ustinov]

Ik ontdek net dat mijn password manager Roboform er wel gevoelig voor is. En wat nog erger is: de waarschuwing dat je credit card gegevens zijn ingevuld blijkt niet meer te werken. Had hij stiekum CC, expiry date en security code ook ingevuld.
Toch maar even een aparte identiteit zonder CC en bankgegevens aangemaakt.

[Mrten]

Dit is niet nieuw toch? Yoast toonde in 2013 het zelfde principe hier.

[biglia]

Iemand heeft hem dit nu gemeld: https://github.com/anttiv...utofill-phishing/issues/7
Hij antwoordt: Gladly. PR please? . Geen idee wat hij daarmee wil zeggen.

[djwice]

Vraag het hem, wellicht de referentie regel die hij moet opnemen (naam, link etc.).

[Reactie gewijzigd door djwice op 22 juli 2024 16:36]

[basst85]

PR is waarschijnlijk de Git term "Pull Request"

[maxplanck]

PR please betekent in dit geval dat hij je uitnodigt om een oplossing te coderen en dit via een Pull Request op github aan te bieden aan zijn project. Het mooie van open source

[Ienni1983]

Maar dan vul ik dus op die pagina mijn naam in en gebruik de autocomplete functie.

Er komt bij mij niks tevoorschijn.

[b2vjfvj75gjx7]

Het werkt daar weer wel als je als "naam" een "email-adres" invult... bij mij althans

[Ienni1983]

Hier niet aangezien ik geen e-mail ingevuld heb op een autocomplete voor naam

[b2vjfvj75gjx7]

Ik ook niet - maar zowel naam als mail beginnen bij mij met dezelfde letter...

Mijn naam doet daar niets, maar als ik de 1e letter van mijn naam in tik, vult hij het aan met de rest van mijn mail - als ik dan op submit druk, staat al mijn hebben en houwen in beeld...

<label for="name">Email</label>

Ook niet zo vreemd als je ziet dat hij de name heeft binded aan de mail...

[Reactie gewijzigd door b2vjfvj75gjx7 op 22 juli 2024 16:36]

[BLACKfm]

Die HTML die je quote is maar een 'label' naampje, het gaat om het "name" deel van het inputveld, wat overgens bij Name ook 'name' is.

In mijn geval toont google mij bij het dubbelklikken op het inputveld enkel een e-mail adres. Mogelijk dat google chrome de opgeslagen gegevens 'benoemd' onder een e-mail adres. Tenslotte zijn dat meestal de gegevens die er toe doen bij een formulier op het web (9 van de 10x contactformulier) en kun je op basis van je naam (als 'profielnaam' van al je overige gegevens) niet altijd bepalen of daar ook het juiste e-mail adres bij hoort als je meerdere gebruikt.

[b2vjfvj75gjx7]

Het wordt in JSON formaat opgeslagen, waarbij de parent-key je naam is.

Je kan dus meerdere entries maken, op basis van je naam - afhankelijk van de user van Chrome zelf.

In principe zijn die gegevens gescheiden, maar door te spelen met telkens een andere 1e letter, zie je alle entries voorbij komen.

Vandaar dat het label expliciet is gesteld op name, voor alle credentials.

http://i.imgur.com/LpPAmlf.png

Verder heeft Crome twee data-bunkers; één voor de naw-gegevens en één voor CC-credentials, maar ik mag hopen dat niemand die gebrui,t...

[WillySis]

Je moet inderdaad minimaal één letter invullen. De auto complete vult dan aan met het gegeven wat eerder bij bij input velden met de dezelfde naam is ingevuld. Die letter kan je met javascript invullen, of al gelijk in het veld meegeven.

Ik heb zelf die autocomplete functie uit staan, juist voor dit grapje. Ik had al lang het gevoel dat dit mogelijk zou zijn.

[Cerberus_tm]

Array
(
[name] => X.
[email] =>
[tel] =>
[street-address] =>
[city] =>
[postal-code] =>
[country] =>
[organization] =>
[org-title] =>
)

[Danny]

Dit was toch al jaren bekend? Kan me van een paar jaar geleden al een soortgelijk artikel herinneren...

edit:
2010: https://productforums.goo...!topic/chrome/xfKNQMlce9w

Maar is toen ook al wel in de media geweest. Mogelijk zelfs gewoon hier op tweakers.

[Reactie gewijzigd door Danny op 22 juli 2024 16:36]

[sigmundfreund]

Dit kunnen de browserbouwers dan weer dichten met een update die alleen zichtbare velden laat invullen toch? Rest dan nog dat iedereen hun browser up 2 date krijgt.

[graey]

Klopt, maar zelfs dan: soms vul ik een of twee velden in, waarna Chrome wil autofillen en, als ik dat aanklik, alle velden in een keer vol plempt. Ook velden die bij de ene website wel verplicht zijn (en daarom bij Chrome bekend zijn voor de autofill) en bij de andere niet vult hij dan graag in, zonder dat ik dat persé wil. Dat is niet echt gewenst gedrag vind ik.

[sigmundfreund]

En precies dat wordt nu dus aangetoond, waardoor er actie op ondernomen kan worden.

[graey]

Dat begrijp ik, ik reageerde op jouw reactie om aan te geven dat je voorgestelde update niet alle problemen die hier worden aangetoond verhelpt.

[Anoniem: 420148]

Er zijn veel manieren om zo'n veld te verbergen. Buiten de viewport spawnen, een plaatje met hoger Z-index eroverheen zetten, width op 1 of 0px, input velden volledig wit maken met CSS en de tekst erin ook... als je dit allemaal zou blokkeren, ga je waarschijnlijk websites dwarsbomen die conditional input tonen wanneer jij een bepaalde optie kiest of een menu uitklapt e.d.

[kuurtjes]

Dit. Er zijn teveel verschillende methods hoe je zo iets kan verstoppen.

[Blaise]

Zichtbaarheid is relatief en een hele lastige om te implementeren voor browsermakers. Wat voorbeelden: CSS opacity: 0.1, transform: scale(0.05), inputveld met (bijna) zelfde tekst- en achtergrondkleur, half transparant plaatje over een veld, eerst moeten scrollen om een veld te zien, etc. Er zijn talloze mogelijkheden.

Het zou beter zijn als autofill een melding geeft hoe veel, en/of welke velden er zijn ingevuld.

[mad_max234]

En wat meer beheer opties zou ook wel prettig zijn, zoals white/black list voor websites, en welke velden wel en welke velden nooit automatisch ingevuld mogen worden.

[Dreamvoid]

Het is echt niet zo eenvoudig om nauwkeurig genoeg te detecteren of een veld zichtbaar is, je kan er allerlei dynamische elementen voor plaatsen.

[biglia]

Als websitebouwer wil je die autofill ook wel eens uitschakelen, maar er is geen enkele html attribute die hiervoor kan zorgen. Het is een pure browserfunctie. Vroeger werd het wel eens ondersteund door bepaalde browsers.

[internjet]

Tegenwoordig kan dat wel weer in Chrome (Chromium) met autocomplete="new-password". Andere waarden voor het autocomplete attribuut werken niet ("off" of "false").
Het is eigenlijk bedoeld om - de naam zegt het al - een nieuw wachtwoord te kunnen kiezen dat natuurlijk niet vooringevuld moet worden.
Zie https://bugs.chromium.org/p/chromium/issues/detail?id=370363#c7

[MarcelRijk]

Zodan! Auto-fill gaat dus uit.
Ik wist dat je met autofill op iemand zijn pc het wachtwoord naar naar text type kon zetten. Dat alle gegevens gewoon zo worden gesubmit, daar ben ik niet zo'n fan!

[graey]

Let wel: het wordt alleen gesubmit als je het form verstuurt, of de maker van de website AJAX heeft toegepast (wat bij zo'n phishing-scam natuurlijk wel voor de hand ligt).

[faim]

Een form kan ook gewoon via javascript gesubmit worden.
Overigens worden wachtwoord velden niet opgeslagen in de autocompleter.

[graey]

En de J in AJAX staat dan ook voor Javascript, inderdaad. En de overige data die te pas en helaas onpas daardoor meegestuurd kan worden is soms ook best ongewenst.

[thegve]

En de eerste A in Ajax staat voor Asynchronous.
Als je het form submit is het synchronous geworden en dus geen Ajax.

edit:
En de laatste X in Ajax staat dan weer voor XML. En omdat dat al lang niet meer hip is, bijna altijd word JSON gebruikt, word Ajax alleen al om die reden nog redelijk regematig misbruikt als term. Maar dit terzijde..

[Reactie gewijzigd door thegve op 22 juli 2024 16:36]

[graey]

Het is wel asynchroon, want het (her)laadt niet de hele pagina of een nieuwe, en er hoeft zelfs niks zichtbaar te gebeuren. En inderdaad, XML is vaak vervangen door JSON, maar daar gaat het inderdaad nu niet om.

[thegve]

form.submit() is synchroon

https://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-76767676

Submits the form. It performs the same action as a submit button.

Misschien vergis je je met functies van diverse Javascript frameworks als JQuery oid?
Een form submit herlaad de pagina.

[graey]

Ik had het niet perse over form.submit, al formuleerde ik niet heel duidelijk, ik zat meer te denken aan het versturen van (delen van) een form via bijvoorbeeld XMLHttpRequest, zoals inderdaad ook gebruikt door veel frameworks.

[djwice]

[darkmode]
Zo dan, ff alle velden op m'n site op autocomplete zetten. En wat extra verborgen velden toevoegen met https://html.spec.whatwg....forms.html#autofill-field attribute - even kijken in https://cs.chromium.org/#...tofill_regex_constants.cc welke waarden ik moet gebruiken.
[/darkmode]

Dit doen is wel een overtreding van de NL en Europese wetten; je verkrijgt meer persoonsgegevens dan noodzakelijk en verwerkt deze niet vertrouwelijk genoeg en zonder explicite toestemming van de persoon. Hier op staan boetes die je in je leven lang niet bij elkaar gespaard krijgt (6 digits per geval). Het gevolg zal zijn een jaren lange celstraf.

[Reactie gewijzigd door djwice op 22 juli 2024 16:36]

[stresstak]

Dit doen is wel een overtreding van de NL en Europese wetten;

Maar hey, het is phishing. Geen collecte voor de Zonnebloem.

Wat ik in wil vullen doe ik zelf wel. Ik typ misschien niet zo vlotjes, maar voorkomen is beter dan revalideren.

[.oisyn]

Ik wist dat je met autofill op iemand zijn pc het wachtwoord naar naar text type kon zetten

Wat bedoel je precies? Autofill is ongerelateerd aan het onthouden van wachtwoorden door je browser. En ja, het achterhalen van die wachtwoorden is idd een koud kunstje.

[Reactie gewijzigd door .oisyn op 22 juli 2024 16:36]

[djwice]

En wat heb je aan een wachtwoord dat je al kent [autocomplete van wachtwoorden is gebaseerd op hoofddomeinnaam van een site - kijk dus uit als je jou site host op Amazon S3 bijvoorbeeld en niet CloutFront only op eigen domein onder https; andere AWS S3 klanten kunnen dan autocomplete password gebruiken).

Maar als boef zou ik gewoon voor de makkelijke en korte termijn win gaan; creditcardnummer met datum etc. uit de autocomplete.

Voor Nederlanders als doelgroep vast niet zo relevant, verhuis je je focus naar Amerikanen ... niet doen hoor, je wilt hier echt niet voor gepakt en uitgeleverd worden!!

[.oisyn]

Ik vroeg wat MarcelRijk met zijn stelling bedoelde: "wachtwoord naar text type omzetten".

En wat je eraan hebt? Wat dacht je van even snel plaatsnemen op een pc van iemand anders? Niet dat ik dat als serieuze dreiging zie, hoor. Als je achter iemand's pc plaats kan nemen dan zijn de mogelijke problemen natuurlijk wel een stuk groter dan dat.

Overigens vind ik het voor mezelf ook wel praktisch - dat mijn browser mijn wachtwoord weet, impliceert niet per se dat ik 'm zelf ook (nog) weet . Er zijn wel situaties waarin je het ingevulde wachtwoord wilt verifieren/achterhalen.

[i7x]

Autofill jaren geleden al uitgeschakeld. Destijds omdat het vaak verkeerde gegevens in verkeerde velden zette. Maar er zijn meer voordelen zo blijkt. Zo veel werk is het niet even je adres opnieuw te typen.

[menne]

Klopt, laatst een een gedoe ivm een post pakket dat een webwinkel had gestuurd. Autofill had voor het huisnummer mijn viercijferige postcode gebruikt, voor de postcode de postcode van mijn werk in een andere stad en als stad wel weer mijn woonplaats. En toen heeft PostNL vervolgens "gegokt" wat het juiste adres moest zijn, en dat was niet bij mij thuis

[Anoniem: 200498]

Je zou met html2canvas ook een leuke kunnen maken; als je een goede OCR processor hebt moet het toch niet zo heel moeilijk zijn om toch zichtbare velden te cappen.
Zo is er wel meer leuks daarmee te verzinnen nog, vrees ik

[edit]
zolang de dom ook aangepast wordt.. hmm...

[Reactie gewijzigd door Anoniem: 200498 op 22 juli 2024 16:36]

[dsmink]

Dit wist ik jaren geleden al. Ik had onderzoeker moeten worden

[Armin]

Jammer dat dit soort "security" figuren niet ook even Edge en Internet Explorer testen. Niet alleen qua gebruikers aantallen significant, maar ook qua doelwit relevant want juist in Enterprise omgevingen is het vaak gewild om één persoon te hacken en zo te proberen daarna het verdere bedrijf binnen te dringen.

Het lijkt erop dat deze persoon enkel een Mac ter beschikking had!? Dat is extra relevant, want soms werkt een browser anders op Windows vs Mac.

Hoe dan ook de exploit werkt ook niet op Edge om dezelfde reden als Firefox - en wel dat er geen autofil maar autocomplete gebruikt wordt. Op IE11 idem, ware het niet dat ik het niet kan verifieren want het script werkt niet in IE11 op Windows 10