'Android-wachtwoordmanagers schermen inloggegevens bij autofill niet goed af'

Indiase onderzoekers hebben ontdekt dat Android-wachtwoordmanagers inloggegevens niet goed afschermen als gebruik wordt gemaakt van de autofill-functie. Volgens de onderzoekers ligt een framework binnen Android aan de basis van het probleem.

De kwetsbaarheid kreeg de naam AutoSpill mee en werd uit de doeken gedaan op Black Hat Europe. Daar toonden de onderzoekers aan dat als een Android-gebruiker zich wil aanmelden via een app, die ook de optie kan krijgen om dat te doen via een webpagina van de in-app-browser.

Wachtwoordmanagers kunnen op die pagina inloggegevens invullen via de autofill-functie, maar zouden daarbij volgens de onderzoekers ook de inloggegevens delen met de onderliggende app, en niet uitsluitend met de webpagina met invoervelden die via de autofill-functie ingevuld kunnen worden. Malafide app-makers zouden hierdoor de inloggegevens van gebruikers kunnen buitmaken.

Volgens de onderzoekers ligt een framework binnen Android aan de basis van het probleem. De kwetsbaarheid zou vervat zitten in versie 10, 11 en 12 van het Android-besturingssysteem en in wachtwoordmanagers 1Password, LastPass, Keeper, Enpass en Keepass2Android. De bedrijven achter deze wachtwoordmanagers zouden op de hoogte zijn van de kwetsbaarheid.

Reacties (62)

[Anoniem: 1576590]

Mijn duiding van deze "kwetsbaarheid" is als volgt.

Uitgangspunt is een kwaadaardige App met WebView (een deel van de default webbrouwser ingebed in de app), die de gebruiker, in die WebView, laat inloggen op een third party website (zoals "Log in with Google").

Uit de presentatie (PDF) pagina 56 en 57, en de reactie van Google onderaan deze pagina van BleepingComputer, maak ik het volgende op:

1) Sommige wachtwoordmanagers zijn buggy bij Android AutoFill: de inloggegevens worden niet naar de WebView maar naar de "omhullende" App gestuurd.

2) Punt 1 is totaal irrelevant als de App zelf JavaScript in de WebView injecteert - en daarmee de ingevoerde inloggegegevens kaapt. Dan maakt het ook niet meer uit of de gebruiker diens inloggegevens handmatig invoert, copy/paste gebruikt, "MagiKeyboard" van KeepassDX inzet of Autofill benut.

3) Niet genoemd, maar als in de App "hardcoded" een soort WebView zit, is er natuurlijk helemaal geen sprake meer van enige isolatie tussen de App en de ingevoerde gegevens.

Als gebruiker wéét je simpelweg niet of gegevens die je invoert, in iets dat op een WebView lijkt, tevens in de App zelf (en bij diens makers) terechtkomen. Daarom is het verstandig om ervan uit te gaan dat dit zal gebeuren, en dus nooit inloggegevens van een derde partij in een App in te voeren.

Google raadt deze constructie dan ook af, bijv. halverwege uit deze pagina:

Using OAuth for authentication in a WebView can make your app susceptible to security problems and hurt usability by disconnecting the user from single sign-on sessions.

Enkele makers van passwordmanagers hebben al aangegeven dat zij gebruikers duidelijker zullen gaan waarschuwen als zij, in een (potentieel onbetrouwbare) app, vragen om inloggegevens auromatisch in te voeren voor een account bij een derde partij.

Maar dat helpt niet als je een passwordmanager gebruikt zonder AutoFill, of helemaal geen wachtwoordmanager; het is dus vooral cybersecurity awarenes dat je inloggegevens voor een specifieke partij uitsluitend deelt indien je zeker weet dat je een geïsoleerde verbinding hebt met daadwerkelijk die specifieke partij.

Sowieso vormt inloggen via een derde partij een risico. Als je een wachtwoordmanager gebruikt zie ik het nut daar niet eens van in: voor elke partij een uniek wachtwoord gebruiken is dan goed te doen.

Enkele eerdere lekken gerelateerd aan WebView:

• Apps with 5.8 million Google Play downloads stole users’ Facebook passwords
• Clever phishing method bypasses MFA using Microsoft WebView2 apps

[Reactie gewijzigd door Anoniem: 1576590 op 22 juli 2024 14:11]

[kodak]

Het uitgangspunt lijkt me hier niet slechts een kwaadaardige app maar om te beginnen het risico wie verantwoordelijk is voor welke bescherming.

De presentatie van het probleem stelt namelijk niet voor niets dat het om verschillende redenen mis gaat en er samenwerking tussen android en ontwikkelaars nodig is om voor voldoende bescherming te zorgen.

Het is duidelijk dat een app hoe dan ook niet zomaar betrouwbaar is met vooral vrijheid in implementaties van mogelijkheden. Dus ook password-apps niet. Google is hier ook een belangrijke partij in: het aanbieden van beveiliging valt niet slechts op te lossen door onveilige mogelijkheden aan te bieden en dan simpelweg stellen dat het een probleem van de appbouwer is. En aangezien zowel de appbouwers als google geen duidelijke verantwoordelijkheid nemen voor de gevolgen komt het er dus op neer dat gebruikers de bijkomende risico's dragen. Terwijl die zelf nauwelijks mogelijkheden voor hebben om bij een keuze te weten welk risico ze lopen. Ja, door op de appstore of gebrekkige informatie te vertrouwen die niet zomaar bescherming geven.

[Anoniem: 1576590]

Door kodak:

Het uitgangspunt lijkt me hier niet slechts een kwaadaardige app maar om te beginnen het risico wie verantwoordelijk is voor welke bescherming.

Kennelijk zijn er passwordmanagers die, bij het automatisch invullen van velden in een App (niet zijnde een browser), niet checken of het wellicht om velden in een WebView gaat die runtime in die app is opgenomen. Indien die "bug" repareren ertoe zou leiden dat zo'n App op geen enkele manier meer bij third party inloggegegevens kan, is zo'n fix natuurlijk zeer verstandig.

Uit de presentatie (PDF) vanaf pagina 61 maak ik op dat Android tijdens AutoFill een AssistStructure vult, welke een passwordmanager (optioneel) kan parsen om te achterhalen of het om velden in de App zelf of in een "child" WebView gaat, en de inloggegevens specifiek daar naartoe te sturen - zodat ze niet in de "omhullende" App zelf terechtkomen.

Dat laatste lijkt mij geen ernstig probleem als de App niet kwaadaardig is. Als de App wél kwaadaardig is, schiet je echter bar weinig op met fixes van passwordmanagers hiervoor, want een App kan sowieso inloggegevens in een WebView "afluisteren". Bijvoorbeeld uit deze blog:

With JS injection, developers can dynamically modify elements, handle user interactions, and communicate between WebView and the host app.

Een belangrijke pijler van de beveiliging in mobiele besturingssystemen is isolatie tussen apps onderling. Als je een "plugin" zoals een WebView in een App opneemt, profiteer je niet van die isolatie. Sterker, dat interactie tussen de App en de WebView mogelijk is, is by design.

Door kodak:

De presentatie van het probleem stelt namelijk niet voor niets dat het om verschillende redenen mis gaat en er samenwerking tussen android en ontwikkelaars nodig is om voor voldoende bescherming te zorgen.

Ik vermoed dat je doelt op de volgende zin uit pagina 64 van de presentatie:

Android and PM developers must work together to fix AutoSpill

Daarbij stellen de auteurs dat "AutoSpill" een probleem is dat opgelost moet worden, waarbij je de oplossing kunt vergelijken met het afsluiten van een raampje terwijl de deur daarnaast wagenwijd open staat.

Bovendien zou het mij verbazen als er geen "legitieme" Apps bestaan die van WebView met third party inloggegevens gebruikmaken (tegen het advies van Google in) - waar "gefikste" passwordmanagers niet meer op zullen willen autofillen (in hun presentatie lijken de auteurs te suggereren dat Microsoft's OneDrive app zo werkt). Dat gaat tot gefrustreerde gebruikers leiden.

[Cerberus_tm]

Ik vraag mij dit af, maar misschien heb jij ook geen idee: stel ik gebruik Stoute App die een webview met ABN Amro erin heeft. Waarom zou Lastpass dan mijn ABN-wachtwoord invullen in Stoute App? Is het niet zo dat Lastpass alleen een wachtwoord in Stoute App zal invullen wanneer dat wachtwoord in mijn vault gekoppeld is aan Stoute App? En mijn ABN-wachtwoord is dat niet. Dus hoe zou dit in de praktijk daar ingevuld kunnen worden?

Ik kan twee dingen bedenken.

1. Een gebruiker zoekt handmatig in zijn vault naar ABN, kopieert dat wachtwoord, en de gebruiker plakt het handmatig in Stoute App. Dit lijkt me dan vooral een fout van de gebruiker.

2. Lastpass analyseert op de een of andere manier welke URL er actief is in een webview, en stuurt dan het wachtwoord dat past bij dat domein naar Stoute App. Als dat zo is, dan zou ik dat bijzonder slecht vinden van Lastpass. Misschien kan Google dit voorkomen door iets te veranderen in Android; maar in de grond is dit een fout van Lastpass, niet van Android?

[Anoniem: 1576590]

Door Cerberus_tm:

Ik vraag mij dit af, maar misschien heb jij ook geen idee: stel ik gebruik Stoute App die een webview met ABN Amro erin heeft. Waarom zou Lastpass dan mijn ABN-wachtwoord invullen in Stoute App?

Dank voor jouw vraag, dit helpt mij inzien dat gebruikers vanuit een ander perspectief (verwachtingspatroon) kunnen redeneren.

Ik weet niet of een app met een WebView zich richting het Android Autofill Framework kan voordoen als een generieke webbrowser, en via dat framework een URL naar de wachtwoordmanager kan sturen (ik heb wel ooit geprogrammeerd, maar nooit voor Android). Als dat mogelijk is zie ik sowieso geen reden waarom een wachtwoordmanager die URL (of de "origin" daarin) niet zou herkennen en aanbieden om inloggegevens in te vullen als er een record voor de betreffende website in die wachtwoordmanager zit.

Maar ook als een app met WebView zich niet voordoet als een generieke browser, maak ik op uit de presentatie (PDF) dat de passwordmanager een AssistStructure ontvangt waarin de URL teruggevonden kan worden (de onderhavige bug lijkt dat sommige wachtwoordmanagers niet checken of er sprake is van een WebView met URL, maar "App-based" credentials terugsturen, dus naar de App i.p.v. naar de WebView daarin).

Door Cerberus_tm:

Is het niet zo dat Lastpass alleen een wachtwoord in Stoute App zal invullen wanneer dat wachtwoord in mijn vault gekoppeld is aan Stoute App? En mijn ABN-wachtwoord is dat niet. Dus hoe zou dit in de praktijk daar ingevuld kunnen worden?

Ik kan twee dingen bedenken.

1. Een gebruiker zoekt handmatig in zijn vault naar ABN, kopieert dat wachtwoord, en de gebruiker plakt het handmatig in Stoute App. Dit lijkt me dan vooral een fout van de gebruiker.

Veiligheidshalve heb ik geen hoge verwachtingen van allerlei aanvullende beveiligingsmaatregelen in wachtwoordmanagers (en het OS).

Als ik mijn bank-app op mijn Android phone start, vraagt deze om een pincode. Android Autofill plaatst daar een popup bij met de vraag of ik KeePassDX wil gebruiken om in te loggen. In die popup wordt de app-naam vermeld ("com.<banknaam>.<nog_iets>").

Die pincode heb ik nooit in KeePassDX gezet (het Autofill Framework weet dat niet, ik heb op dat moment nog niet eens een KeePassDX database gekozen). Na het intikken verschijnt er een nieuwe Autofill popup met de vraag of ik de zojuist ingevoerde gegevens in KeePassDX wil opslaan.

Als test heb ik zojuist de karakterreeks "com.<banknaam>.<nog_iets>" toegevoegd aan de Application Blocklist van KeePassDX. Nu krijg ik geen Autofill popups meer in die bank app.

KeePassDX heeft overigens ook een "Web domain blocklist".

Door Cerberus_tm:

2. Lastpass analyseert op de een of andere manier welke URL er actief is in een webview, en stuurt dan het wachtwoord dat past bij dat domein naar Stoute App. Als dat zo is, dan zou ik dat bijzonder slecht vinden van Lastpass. Misschien kan Google dit voorkomen door iets te veranderen in Android; maar in de grond is dit een fout van Lastpass, niet van Android?

De wachtwoordmanager communiceert niet zelf met "de app" (browser, app met WebView of app zonder WebView). Als jij Stoute App vertrouwt, waarom zou Lastpass jou dan tegen jouzelf moeten beschermen?

Uit de presentatie maak ik op dat 1Password weigert om te "AutoFillen" in WebViews, maar ik kan mij voorstellen dat sommige gebruikers dit als betuttelend zullen beschouwen.

In de presentatie, maar bijv. ook in deze habr.com blog: "Autofill input fields in Android WebView" kun je zien dat gegevens uit de app via een AssistStructure naar de wachtwoordmanager worden overgedragen. In die habr.com blog zie je dat geantwoord wordt met een FillResponse.

In die blog kun je ook zien dat app-makers middels JavaScript Injection toegang hebben tot invoervelden in een WebView, waardoor het fixen van de onderhavige "kwetsbaarheid" nauwelijks zin heeft. Er is simpelweg geen sprake van betrouwbare isolatie tussen een app en een daarin opgenomen WebView.

Prio 1 is dat jouw device niet gecompromitteerd is (dat kan ook door een kwaadaardige app die permissies heeft om als "Accessibility Service" te werken) en prio 2 is dat je uitsluitend apps van betrouwbare makers installeert.

Omdat je vooral dat laatste nooit zeker weet: voer geen vertrouwelijke gegevens bestemd voor partij A in in een app van partij B (ook niet als er een WebView gebruikt wordt). Bij het OS en webbrowsers (plus eventuele plug-ins) heb je op dit punt geen keus, die zul je moeten vertrouwen.

Autofill is hartstikke handig (als je het goed gebruikt) omdat het phishing kan helpen voorkómen. Als ik in een bericht op een link klik en via mijn browser op een nepwebsite uitkom, zal KeePassDX daar geen credentials voor vinden. Als die website als twee druppels water op de echte lijkt, betekent dit dat de domeinnaam niet correct is; alle alarmbellen moeten dan afgaan.

Veel te veel mensen checken niet of een gegeven domeinnaam van een kennelijke organisatie is voordat zij inloggen, of hebben geen idee hoe zij dat moeten doen. Autofill kan dus helpen; het zou zonde zijn als de onderhavige non-issue ertoe leidt dat mensen Autofill uitschakelen.

[kodak]

Dat webview by design bestaat gaat net zo goed op voor andere ontwikkeling. Maar dat zorgt er niet zomaar voor dat het voor dat het dus maar acceptabel moet zijn dat malafide apps er maar gemakkelijk gebruik van kunnen maken.

Omgekeerd is het niet zomaar acceptabel om by design onveilig situatie te accepteren, en zeker niet bij het streven naar veilige verwerkinng van belangrijke gegevens zoals accountgegevens.

Ik lees niet dat het voorstel tot samenwerken de betekenis heeft dat webview maar gestopt moet worden. Maar samenwerken om het uit te faseren voor veiliger alternatief lijkt me een een mogelijkheid.

Maar zelfs al wil men dat, dan hebben we nog steeds het probleem dat in de tussentijd er een situatie is dat zowel android als de passwordmanagers niet samenwerken om het risico te beperken. Google schuift het probleem af op de ontwikkelaars, de passwordmanagers zijn afhankelijk van google om de gebruiker zekerheid te kunnen geven, de gebruikers zijn afhankelijk van google en de appontwikkelaars en ondertussen worden de malafide apps niet duidelijk beperkt voor door het afschuiven.

Het samenwerken lijkt me hier al een stuk beter te zijn als google (waar gebruikers en passwordmanagers zwaar afhankelijk van zijn) strengere grenzen gaat stellen aan autofill. Bijvoorbeeld dat legitieme apps alleen nog acceptabel zijn als verwerking van authenticatiegegevens op een veilige wijze tot stand komt en passwordmamagers hierop kunnen controleren. En voor iemand nu stelt dat dat moeite kost voor google of app ontwikkelaars: het belang om by design voor jezelf en je gebruikers privacy te gunnen lijkt me een stuk redelijker dan risico op lekken accepteren waarvan we jaren geleden al stelden dat dit ongewenst is.

[Anoniem: 1576590]

Door kodak:

Ik lees niet dat het voorstel tot samenwerken de betekenis heeft dat webview maar gestopt moet worden. Maar samenwerken om het uit te faseren voor veiliger alternatief lijkt me een een mogelijkheid.

Ik begrijp jouw wens, maar die is niet realistisch; ook zonder WebView kan een App jou om inloggegevens van een third party site vragen.

Als je bijvoorbeeld de Microsoft Outlook app voor Android gebruikt om te e-mailen via een third party mailserver (zoals gmail), zul je -vanzelfsprekend- die app de login-gegevens van die third party mailserver moeten toevertrouwen. Wat echter niet voor iedereen duidelijk is, is dat die inloggegevens naar een Microsoft server worden gekopieerd, en alle mail van/naar die third party mailserver vervolgens via servers van Microsoft wordt omgeleid (en Microsoft die mails dus ook kan meelezen, en/of als lesmateriaal aan ChatGPT kan voeren).

Dit gebeurt overigens al sinds 2015 (Duitstalig); sinds kort geldt dit ook voor de "nieuwe Outlook" voor Windows 11 (Engelstalig).

Het Duitse BSI vindt dit een slechte ontwikkeling (Duitstalig), een woordvoerder uitte zich als volgt:

"Passwörter sollten in der Regel geheim gehalten und somit Dritten nicht zugänglich gemacht werden. In Ausnahmefällen sollten Nutzende aktive und informierte Entscheidungen treffen können, ob sie einem Diensteanbieter vertrauen und mit diesem Zugangsdaten für andere Dienste teilen möchten".

Is zo'n Android app dan dusdanig "kwaadaardig" dat Google en Apple deze uit hun app stores zouden moeten verwijderen? Mag een passwordmanager daar credentials voor aanleveren? Wie bepaalt wat acceptabel is?

ICT voor eindgebruikers is een compromis tussen veel zaken, waaronder enerzijds gebruiksgemak en winstoogmerk, en anderzijds privacy en beveiliging. Eindgebruikers zelf hebben daar nauwelijks tot niets over te zeggen, en ontwikkelaars willen voor een kwartje op de eerste rij zitten. Google draagt meerdere petten, en veel van hun keuzes zijn simpelweg niet in het belang van privacy- en securitybewuste gebruikers.

Door kodak:

Bijvoorbeeld dat legitieme apps alleen nog acceptabel zijn als verwerking van authenticatiegegevens op een veilige wijze tot stand komt en passwordmamagers hierop kunnen controleren.

M.i. moet je niet willen dat passwordmanagers (ook niet samen met Android) controleren of een app authenticatiegegevens veilig verwerkt; dat krijg je nooit voldoende betrouwbaar en het zal leiden tot veel gebruikersklachten.

Naast wat ik schreef over Outlook apps: een veelgemaakte fout in apps was dat zij wel https gebruikten voor de verbinding met "hun" server, én het certificaat op geldigheid werd gecheckt, maar in de code werd vergeten om te checken of de domeinnaam in het certificaat van de bedoelde server was. No way dat een passwordmanager zoiets zou kunnen detecteren.

Helaas komt er alleen maar meer complexiteit op ons af: de eerste Android malware app die een wrapper om een legitieme app vormt (die na installatie tussen die app en het OS zit, een soort van virtualisatiecontainer dus) is al gesignaleerd.

En om het (niet alleen goedaardige) ontwikkelaars makkelijker te maken, gaat Android zelf ook virtualisatie ondersteunen. In die pagina zie ik wel een hoofdstuk "Benefits of AVF", maar onderwerpen zoals "Disadvantages" en "Potential Security Risks" ontbreken - en dat is niet omdat die niet bestaan.

[kodak]

Aangezien Google en ontwikkelaars van apps als outlook het vooral zelf ingewikkeld gemaakt hebben om ervan te profiteren is verweer met complexiteit te makkelijk. Zeker nu weer blijkt dat de complexiteit onduidelijkheid over betrouwbaarheid en bijkomende risico zoals datalekken voor gebruikers en passwordmanagers veroorzaakt. Terwijl we daarover controle verwachten en men wel verwacht dat gebruiker vertouwen heeft.

Beroep doen dat we uitzoeken en uitwisselen van belangrijke kenmerken maar niet moeten willen omdat het niet voldoende betrouwbaar zou zijn en vragen oproept is ook niet redelijk. De huidige situatie is dat gebruikers en passwordmanagers onvoldoende kunnen weten of men risico loopt door dit soort selectief gebruik van complexiteit. Als je als Google en ontwikkelaars graag hebt dat men afhankelijk van je is, zeker om er aan te verdienen, dan moet je ook bereid zijn risico te accepteren dat een oplossingen met 'complexe' mogelijke risico's niet zomaar redelijk voor de gebruiker is en je dan 'lastige' vragen krijgt waarom je te vertrouwen bent. Dat is eerder realistisch met de problemen die mogelijke datalekken veroorzaken en men als google en ontwikkelaars meent dat die gebruikers en hun gegevens waardevol zijn.

Het lijkt me duidelijk dat de huidige situatie alleen houdbaar is als op zijn minst google en de ontwikkelaars meer gaan samenwerken op gebied van onderkennen van mogelijke risico's bij verwerken van persoonlijke gegevens voor de gebruiker en de gebruiker duidelijk te informeren. Want met afschuiven en opzettelijk onwetend houden van gebruikers worden datalekken niet onbelangrijk of irrelevant.

[BounceMeister]

Wanneer ik mijn wachtwoord invul in een app, dan deel ik die gegevens toch sowieso met die app? Wat gaat er dan precies mis?

[wildhagen]

Dat staat toch letterlijk in het artikel:

Wachtwoordmanagers kunnen op die pagina inloggegevens invullen via de autofill-functie, maar zouden daarbij volgens de onderzoekers ook de inloggegevens delen met de onderliggende app, en niet uitsluitend met de webpagina met invoervelden die via de autofill-functie ingevuld kunnen worden. Malafide app-makers zouden hierdoor de inloggegevens van gebruikers kunnen buitmaken.

Het gaat hier dus om dat je die wachtwoorden deelt met de website, maar dat die "onder water" ook naar een app gestuurd wordt, wat niet zo hoort.

Als die app dan vervolgens malafide is, liggen je inloggegevens dus bij een kwaadwillende app-ontwikelaar, die er dan van alles mee kan doen.

[Edsger]

Nee, zo duidelijk is het niet.
Een website wordt altijd gehost in een app. Deze app zal atlijd toegang hebben tot het wachtwoord, want deze app versleutelt het wachtwoord (bij https). Dat doet de wachtwoord manager niet. Dus het ontgaat mij ook een beetje waar precies de kwetsbaarheid nu zit.

[Aardedraadje]

Ik gok dat standaard, webpagina's 'gehost' worden in Android's eigen WebView of een andere geregistrerede webviewer. Dus de app is meer een soort container voor een externe webviewer. Dus geen directe toegang tot de pages.

[HakanX]

Nee, zo duidelijk is het niet.
Een website wordt altijd gehost in een app. Deze app zal atlijd toegang hebben tot het wachtwoord, want deze app versleutelt het wachtwoord (bij https). Dat doet de wachtwoord manager niet. Dus het ontgaat mij ook een beetje waar precies de kwetsbaarheid nu zit.

Denk aan een game waar je met je Facebook account kan inloggen. Die opent dan een webview waar je in je Facebook inlogt en toestemming geeft om bepaalde data met de game te delen. Het is niet de bedoeling dat de game je Facebook wachtwoord krijgt. Dat is heel het idee dat het via een webview gaat en geen standaard invulveld in de game zelf, maar hier is het nu dus wel het geval dat ze je Facebook wachtwoord kunnen zien. Dát is de kwetsbaarheid.

[ultimate-tester]

Zo moeilijk is het niet… stel, je hebt een app genaamd A. Deze opent een webview voor wat voor reden dan ook. Stel, je navigeert binnen deze webview nu naar een andere site bijv. Tweakers.nl. Je gebruikt autofill in de webview van app A. Je verwacht dat rechtstreeks met de webview wordt gecommuniceerd, maar de credentials gaan eerst door een laagje in de app heen die dat dan (als het goeie bedoelingen heeft) door pushed naar de webview. Met andere woorden, als app ontwikkelaar zou je net zo goed dat autofill event kunnen onderscheppen en daar de credentials uit halen van welke site dan ook zolang het maar in die webview bezocht wordt.


Dan de andere helft van de comments: ja, je kunt gewoon via JavaScript velden uitlezen als je wilt.

[Aldy]

Ik krijg de indruk dat het artikel meer vragen oproept dan beantwoordt. Misschien is het artikel niet compleet, verkeerd vertaald of gepapegaaid zonder zelf na te denken.

[GertMenkel]

De website opent binnen de webview van een app, en de app kan Javascriptcode injecteren in die webview als de app dat wil. In dit geval wordt directe toegang tot de autofill-API misbruikt, maar de app kan net zo goed via JS de credentials uit de applicatie halen.

Ik snap zelf de relevantie van het issue niet zo, ook niet na het lezen van het slidedeck.

Diverse partijen hebben in het artikel op Bleepingcomputer van een paar dagen geleden een reactie gegeven, en ook zij lijken te zeggen dat het risico wel meevalt.

Wellicht dat er tijdens de Black Hat-presentatie iets gezegd is dat niet direct in de slides staat dat het verschil maakt.

[Risce]

Is het verschil niet dat javascript gedetecteerd kan worden en dat Google adviseert om geen gegevens in te vullen maar alleen hun inlogapi te gebruiken? En dat in dit nieuwe geval blijkt dat er een ondetecteerbare autofill kwetsbaarheid onder ligt?

[GertMenkel]

Ik denk niet dat Javascript te detecteren valt. Google kan het wel proberen met de JS op hun pagina, maar dan zouden ze moeten gaan vechten tegen de browser waar ze in werken. Bij een WebView ben je nu eenmaal overgeleverd aan de app eromheen.

Het probleem, volgens mij, is dat bepaalde password managers niet doorhebben dat ze een wachtwoord aan het invullen zijn in een WebView, en denken dat ze in een browser aan het inloggen zijn? Maar zelfs dan geven de wachtwoordmanagers die ik ken een waarschuwing. Google zegt dan ook in hun reactie dat ze een API aanbieden die het verschil aanduidt en legt daarmee de verantwoordelijkheid vooral bij de wachtwoordmanagers die deze API niet juist implementeren.

[Cerberus_tm]

Hmm ik gebruik gewoon de Chrome-extensie van Lastpass in mijn browser Kiwi Browser in Android. De applicatie Lastpass gebruik ik eigenlijk niet. Dit lijkt me veel veiliger dan het gerommel met dingen invullen in webviews binnen applicaties dat hier bovenkomt!

[Chris.nl]

Zoals ik het lees zou een malafide app een webpagina naar legitieme inlog kunnen openen en deze buitmaken.

[BernardV]

In het originele artikel hebben ze het ook over inloggen met Google en Facebook bijvoorbeeld.
Dan zouden je gegevens van die partijen beschikbaar zijn voor de app-maker.

Another key use of such in-app functionality is the "Login with Apple/Facebook/Google" button for user authentication within a third-party mobile app.

[__fred__]

De meeste apps maken tegenwoordig gebruik van OIDC/OAuth. Eerst embedde iedereen gewoon een webview en deed de afhandeling van de inlog in die webview. Deze hack misbruikt die methode omdat je via de webview (in Android) kennelijk alsnog bij gebruikersnaam / wachtwoord kunt komen.

Wat ik niet snap is dat er tegenwoordig zowel in iOS als in Android API's zijn om OIDC requests af te handelen via de webbrowser. Die starten juist een instantie van de OS browser en geen webview om toegang tot de browser te minimaliseren. Sterker nog, op iOS kun je het vergeten dat je password manager actief wordt binnen een embedded webview, waarschijnlijk om dit soort ellende te voorkomen.

[swhnld]

Stel je opent de Facebook app. In die app wordt een AD nieuwsbericht gedeeld. Klik je daarop wordt er binnen de Facebook app een browser pagina geladen van het AD. Die pagina toont de AD website, maar om het artikel te kunnen lezen eist die website weer dat je op het AD inlogt met dat account.
Probleem is nu dus met dit lek dat als je telefoon Android 10, 11 of 12 draait, er een bug is die je AD inloggegevens deelt met de Facebook app.
En dit is het eerste voorbeeld dat bij mij op komt, maar andere sociale media apps, en mogelijk meer type apps loop je eenzelfde risico.

[dasiro]

niet per sé, net zoals je je pincode ook niet naar een webwinkel stuurt word je vaak omgeleid naar een ingebouwde webpagina. Je ziet dit als je inlogt zonder paswoordmanager, dat plots chrome, edge, firefox of de hardwaremaker z'n eigen browser vragen om het wachtwoord op te slaan. Het gevolg van het wisselen van browser of het clearen van diens data is dat je plots een hoop apps hebt waar je opnieuw moet inloggen.

[William_H]

Ik lees niet dat een app als KeePassXD hier last van heeft,die heeft geen online component zoals de eerder genoemde apps, dus hier zit waarschijnlijk het issue.

[RobertMe]

Het gaat er niet om dat de password manager online is, het gaat om de plek waar je de autofill toepast.

Eender welke app kan bv een optie bevatten om in te loggen met Facebook (willekeurig voorbeeld), waarbij de app binnen de app zelf een "webview" (/"browser") opent die de login pagina van Facebook inlaad. Vervolgens geeft de password manager de optie om de login gegevens in te vullen. En terwijl je dit doet / nadat je dit gedaan hebt heeft de app in kwestie de mogelijkheid om de ingevulde ogin gegevens (van Facebook in het voorbeeld) uit te lezen.

Waarbij ik mij overigens afvraag of die app niet exact dezelfde mogelijkheden heeft als je geen password manager gebruikt maar je gewoon met de hand invult. Als het immers zo simpel is als hier gesteld wordt dat de app een extra stuk JavaScript injecteert in de webview dan maakt het namelijk helemaal niks uit hoe de gebruikersnaam en wachtwoord worden ingevuld. Immers heeft JavaScript ten alle tijden toegang tot de (plain text) waardes van alle invoervelden. De enige oplossing is dan dat voor dit soort toepassingen een aparte webview wordt gebruikt waarin geen scripts geïnjecteerd kunnen worden door de app (en in de normale webview waarbij dit wel kan dus geen password manager autofill toe te passen).

[SirBlade]

Ik gok dat als je een password met de hand kan invullen (zeker met een onscreen keyboard) het over het algemeen niet een erg sterk password zal zijn en deze aanval niet je grootste probleem zal zijn.

[Seal64]

Ik ken geen KeePassXD, en Google ook niet. Wel een KeePassXC, maar daar is dan weer geen Android app van - die draait alleen op desktops. Ik gebruik 'm zelf ook.

Op Android heb je wel Keepass2Android wat overweg kan met dezelfde database als KeePassXC en die wordt gewoon in het artikel genoemd.

[William_H]

Twee seconden Google:
https://www.keepassdx.com/

[Seal64]

Da's DX, niet XD wat je eerder riep. Als je namelijk zoekt op XD kom je niets tegen - ja, de site van XC.

Tikfoutje, snap ik ook wel, maar niet denigrerend reageren omdat ik jouw tikfoutje niet kan vinden aub, da's nergens voor nodig.

[WybrenPC]

Dus als ik het artikel goed begrijp heeft bitwarden geen last van dit probleem? Ik vraag me dan af hoe bitwarden het autofill systeem dan anders gebruikt dat bijvoorbeeld een LastPass.

[arnoud_h]

Ze hebben geen andere password managers getest, dus nee, die vraag hebben ze niet beantwoord.

[arnoud_h]

Ik heb de presenatie maar eens bekeken, maar waarom hebben ze dezelfde testen niet gedaan met een apparaat welke up-to-date qua security updates was?

Ze hebben bijvoorbeeld de Galaxy A52 getest met Android 12 en security patches van ruim anderhalf jaar oud. Die wordt toch nog gewoon door Samsung geupdated (snelle zoektocht was dat Android 14 er nog voor gaat komen)?

De hele grote vraag: is dit iets wat een up-to-date apparaat ook kwetsbaar voor is? Idem voor de gebruikte versies van de password managers. Ze hebben getest met 1Password 7.9.4 (anderhalf jaar oude versie), terwijl 8.10.20 de huidige actuele versie is?

[Glassertje]

Volgens dit artikel hebben ze dat wel gedaan.

The researchers tested the AutoSpill vulnerability using some of the most popular password managers, including 1Password, LastPass, Keeper and Enpass, on new and up-to-date Android devices.

[arnoud_h]

Volgens de powerpoint die op de gelinkte pagina staat niet (zie pagina 55). Daar staat dat ze de aangehaalde A52 met Android 12 en april 2022 security patches hebben getest.

Nu kan het zijn dat ze de tests meer dan een jaar geleden al hebben gedaan, maar de PPT is van december 2023.

[Reactie gewijzigd door arnoud_h op 22 juli 2024 14:11]

[Dutchredgaming]

Geldt dat ook voor Google's, Samsung's en Microsoft's password managers op Android?

[Glassertje]

Lees op Reddit dat Bitwarden niet eens op de hoogte is gebracht. Maar de dev heeft het in onderzoek en mocht het wel zo zijn, komt er een fix.

[kodak]

Aangezien het ook niet onderzocht is lijkt dat me niet vreemd.

Het lijkt me eerder vreemd dat een passwordmanager dit niet zelf onderzocht zou hebben. Dus is eerder de vraag wat de passwordmanagers dan precies wel onderzocht hebben en wanneer ze dit een risico vinden.

Wat men op Reddit stelt dat gebruikers er goed aan doen alleen betrouwbare apps te gebruiken gaat immers ook (of zelfs meer) op voor gebruik van passwordmanagers. Daar mag toch wel van verwacht worden dat die niet simpel stellen dat kunnen lekken met autofill etc maar acceptabel is omdat er onvoldoende beveiliging is.

[haam]

Als het aan android ligt, vraag ik me af wat de makers van wachtwoordmanagers daaraan kunnen doen

[Gubbel]

Er wordt niet geconcludeerd dat de ontwikkelaars van de wachtwoordmanagers iets moeten doen.

[SunnieNL]

De titel is een clickbait. De wachtwoordmanagers doen niets verkeerd, het Android OS bevat een bug. Betere titel zou dan ook zijn ‘Android framework lekt autofill gegevens naar apps’. Of ik moet het artikel verkeerd lezen.

[djwice]

Niet helemaal. Als je de wachtwoord manager van Google gebruikt hebben dit probleem niet.
Andere wachtwoord managers hebben vaak de neiging de data via het klembord of andere functie van de app (overlay) in te vullen in plaats van direct in de browser/WebView.

Als de wachtwoord pagina een goede content-security-policy ( CSP ) en referer-policy bevat, zal de login-data niet verder komen dan de pagina zelf.
Maar als de data via een layer van de app ingevuld wordt op de webpagina, kan de app ook bij de logingegevens.

[Reactie gewijzigd door djwice op 22 juli 2024 14:11]

[R4gnax]

Als de wachtwoord pagina een goede content-security-policy ( CSP ) en referer-policy bevat, zal de login-data niet verder komen dan de pagina zelf.

Niet noodzakelijk. De app die de 'in-app browser' webview beheert kan er alsnog voor kiezen om op elke pagina een extra stukje script te implementeren met een 'native binding' en direct alles wat er aan invoer plaatsvindt onderscheppen en terug geven aan de app zelf.

Vziw doet of deed bijv. Facebook/Meta dit met hun in-app browser. Daar zijn nog eens vanuit de journalistiek vragen over gesteld en kwam als antwoord op terug dat dat onderdeel van de debugging ondersteuning was en dat dat standaard aan de app kant uitstond en er niets mee gedaan werd. (En daar moet je dan ook maar vanuit gaan.)

Een daadwerkelijk malafide app kan natuurlijk wel direct en doelbewust met gegevens aan de haal gaan als ze zo'n zelfde opzet hanteren. Dit is dan ook waarom o.a. voor inloggen op je Google account, geen in-app webview meer gebruikt kan worden. Dat wordt door Google geblokkeerd.

[Reactie gewijzigd door R4gnax op 22 juli 2024 14:11]

[djwice]

Daarvoor heb je dus de CSP, die zorgt er voor dat het geïnjecteerde script niet wordt uitgevoerd.

De Content Security Policy is een prettige functie voor website eigenaren om te zorgen dat je controle houdt over de inhoud van je website en de data die via jouw website wordt verwerkt.
Met CSP kun je expliciet aangeven welke code mag worden uitgevoerd in jouw webpagina, al het andere kun je laten blokkeren. Externe referenties naar scripts die niet voldoen worden zelfs niet eens gedownload. Dus die servers krijgen zelfs geen meting van het aantal hits op de pagina.

Het blokkeert bij goed gebruik dus onderandere XSS-attacks zoals jij die beschrijft.

[Reactie gewijzigd door djwice op 22 juli 2024 14:11]

[R4gnax]

Je hebt verschillende manieren om script te injecteren. Het hoeft niet een geinjecteerde <script> tag onderhevig aan CSP te zijn. Zijn alle wegen waarmee script geinjecteerd kan worden onderhevig aan CSP?

Sowieso is er al eentje die dat niet is; dezelfde weg als waar middels browser extensies werken.

Daarnaast heeft een webview ook verder gaande mogelijkheden voor request interception en als er daar ergens een gaatje zit waar een respons niet langer opaque maar editbaar is, kan dat natuurlijk ook gebruikt worden om CSP HTTP headers of <meta> directives er af te slopen.

CSP was hier niet zaligmakend en dekkend. Dat is waarom Google gestopt is in-app webviews toe te staan om in te loggen op Google accounts, en nu vereist dat dit via de normale systeembrowser gebruikt. als CSP wel dekkend was geweest, dan hadden ze wel gewoon CSP gebruikt, niet?

[Reactie gewijzigd door R4gnax op 22 juli 2024 14:11]

[djwice]

Als het goed is omvat CSP alle script, styling, plaatjes, video's, fonts en embeddingen op de webpagina.
Ik ben me niet bewust van scripts die - in een Chrome container - er omheen kunnen werken anders dan via een bug. Zelfs scripts die je injecteert via de dev-console worden geblokkeerd (tekst komt wel in de HTML, maar de code wordt niet uitgevoerd).

Als je de HTTPS verbinding en DNS goed configureert, komt je een heel eind met het stoppen van de man-in-the-middle.

Uiteraard kan een hacker zelf connectie maken met de website, de content downloaden en die content opnieuw in een andere URL laten zien. Die aanval kun je deels stoppen door gebruikers via een 2e weg een bericht te sturen waarop ze moeten reageren voordat de login wordt goedgekeurd. Maar zoals bij alle fishing aanvallen, is dat niet dekkend genoeg.

Dus het verplichten om in de Chrome browser te openen en niet in de WebView helpt in die zin, dat de bezoeker hopelijk valideert of domein van de login-url klopt.

Maar niets is perfect natuurlijk. Een goed besluit dat Google geen WebView login toestaat. Hoe zouden ze dat regelen? Zou het user-agent header zijn? Dan maar hopen dat er geen custum browser in de app wordt gestopt met een andere User-Agent string. Ik heb dan nog wel wat extra dingen op de server om dit te detecteren, maar dan nog, het blijft lastig inderdaad. Niets is perfect.

[Reactie gewijzigd door djwice op 22 juli 2024 14:11]

[Glassertje]

Hier meer info over dit artikel.

[Soldaatje]

Wellicht is het een optie om per app de webview-browser uit te schakelen, dan worden koppelingen geopend in de standaard browser.