Alla conferenza DEF CON 33 è stato presentato un metodo di attacco agli addon del browser che inseriscono i propri elementi dell'interfaccia nella pagina visualizzata. L'applicazione dell'attacco agli addon con gestori di password può portare a una fuga di informazioni memorizzate, come dati di autenticazione, dettagli delle carte di credito, informazioni personali e password usa e getta per l'autenticazione a due fattori. Il problema coinvolge tutti i gestori di password testati, tra cui 1Password, Bitwarden, LastPass, KeePassXC-Browser, NordPass, ProtonPass e Keeper.
Il metodo di attacco si basa sul fatto che gli addon del browser inseriscono una finestra di dialogo per la richiesta di autocompletamento della password direttamente nella pagina visualizzata, integrando i propri elementi nel DOM (Document Object Model) di tale pagina. Se l'attaccante ha la possibilità di eseguire il proprio codice JavaScript sulla pagina, ad esempio sfruttando una vulnerabilità XSS sul sito, può manipolare tutti gli elementi nel DOM, compresi quelli forniti dagli addon del browser.
Tra l'altro, è possibile rendere il dialogo di conferma trasparente e sovrapporre il pulsante in questo dialogo con il pulsante di un dialogo fittizio creato dall'attaccante, che spinge l'utente a cliccare. Questi dialoghi ingannevoli possono includere richieste fittizie di autorizzazione per gestire i Cookie, banner pubblicitari o moduli con CAPTCHA. Posizionando il dialogo fittizio sotto il dialogo trasparente del gestore delle password e allineando le posizioni dei pulsanti sullo schermo, è possibile far sì che il clic dell'utente si traduca in un clic sul pulsante di conferma per il completamento dei parametri di autenticazione nel dialogo del gestore delle password, anche se l'utente crede di aver cliccato, ad esempio, sul pulsante di chiusura della finestra pubblicitaria.
L'attacco consiste nei seguenti passaggi:
- Creazione di un elemento invadente sulla pagina, che incoraggia a cliccare.
- Aggiunta di un modulo web per il login o la compilazione di dati personali.
- Impostazione della trasparenza per il modulo web («opacity: 0.001» in CSS).
- Utilizzo del metodo focus() per posizionare il cursore nel campo di input di un modulo, attivando il dialogo di autocompletamento del gestore di password.
- Ricerca del dialogo del gestore di password apparso nel DOM e impostazione della sua trasparenza.
- Attesa di un clic dell'utente su un elemento visibile e invadente sulla pagina, che, con la corretta sovrapposizione di elementi visibili e invisibili, porterà a una pressione del pulsante nel dialogo trasparente e alla compilazione dei campi da parte del gestore di password.
- Estrazione dei dati dal modulo web compilato e invio a un server di attacco.
Poiché l'autocompletamento dei parametri di autenticazione nel gestore di password si attiva solo per i siti dove tali parametri sono stati salvati, per organizzare un attacco è necessario poter eseguire il proprio codice JavaScript sul sito attaccato o su un sottodominio. Pertanto, per attaccare è necessario ottenere un sottodominio nello stesso dominio del sito attaccato, o trovare una vulnerabilità XSS sul sito che consenta di inserire il proprio codice nel contenuto restituito all'utente.
Si segnala che molti utenti utilizzano un unico gestore di password sia per memorizzare le credenziali di accesso sia per generare codici temporanei per l'autenticazione a due fattori, il che consente di sfruttare il metodo di attacco esaminato durante il riempimento automatico dei codici temporanei. Come esempio, è stata dimostrata un'attacco al sito issuetracker.google.com, che presenta una vulnerabilità XSS. Per ottenere le credenziali di accesso e il codice per l'autenticazione a due fattori, è sufficiente inviare all'utente un link che sfrutti la vulnerabilità XSS, convincendolo a cliccare tre volte tramite l'inserimento di richieste invasive fittizie (autorizzazione al trattamento dei cookie, autorizzazione alla personalizzazione e accettazione della politica sulla privacy).
Oltre ai siti con vulnerabilità XSS, l'attacco può essere effettuato su servizi che offrono sottodomini a chiunque - la maggior parte dei gestori di password, nella configurazione predefinita, riempie le credenziali di accesso non solo per il dominio principale, ma anche per i sottodomini.
L'attacco può essere utilizzato anche per identificare le informazioni personali dell'utente e i dettagli delle carte di credito memorizzati nel gestore delle password. Non è necessario eseguire codice JavaScript nel contesto di un sito esterno per la fuga di tali dati; è sufficiente attirare la vittima su una pagina del sito dell'attaccante. Nel caso delle informazioni personali, il compilazione dei web form avviene in base al loro tipo (indirizzo, numero della carta di credito, nome e cognome), senza legami con dominio. La fuga dei dati delle carte di credito è particolarmente pericolosa, poiché i gestori delle password inseriscono non solo il numero della carta, ma anche la data di scadenza e il codice di verifica.
Un ricercatore che ha individuato il problema ha testato 11 estensioni per browser con gestori di password, che contano in totale 39,7 milioni di installazioni attive, e tutte si sono rivelate vulnerabili a questo tipo di attacco. Alcuni produttori hanno rilasciato aggiornamenti (NordPass 5.13.24, ProtonPass 1.31.6, RoboForm 9.7.6, Dashlane 6.2531.1, Keeper 17.2.0, Enpass 6.11.6, Bitwarden 2025.8.1) in cui hanno cercato di bloccare l'attacco attraverso soluzioni alternative. Altre estensioni (KeePassXC-Browser, 1Password, iCloud Passwords, Enpass, LastPass, LogMeOnce) rimangono ancora senza correzioni. È stato pubblicato un insieme di pagine di test per verificare l'emergere della vulnerabilità in diversi gestori di password.
La posizione degli sviluppatori di 1Password, che non hanno rilasciato una correzione, è che la vulnerabilità è fondamentale e non è direttamente legata a un'estensione specifica del browser. Pertanto, i tentativi di risolverla a livello dell'estensione bloccano solo alcuni vettori di attacco, ma non affrontano il problema stesso, che deve essere risolto nel browser o con la richiesta di una conferma separata prima del completamento automatico dei campi. Si menziona che in 1Password è già supportata la richiesta di conferma prima del completamento automatico dei parametri di pagamento e che nella prossima versione sarà aggiunta un'opzione per visualizzare una richiesta simile per tutti i tipi di dati da completare automaticamente (a causa della riduzione della facilità d'uso, questa opzione non sarà attivata di default).
Tra i metodi di protezione proposti dall'autore della ricerca, si menzionano il monitoraggio delle modifiche agli stili degli elementi inseriti nella pagina tramite l'API MutationObserver, il blocco delle modifiche attraverso il Shadow DOM in modalità «closed», il monitoraggio della trasparenza degli elementi, l'utilizzo dell'API Popover per la visualizzazione di dialoghi, il controllo della sovrapposizione dei livelli e la disabilitazione temporanea della gestione degli eventi puntatore (pointer-events:none) in tutti gli elementi flottanti durante la visualizzazione del dialogo del gestore delle password. Per una completa protezione di questa classe si raccomanda di implementare a livello del browser un'API separata per la protezione da clickjacking.
Come metodo universale di protezione nei browser basati sul motore Chromium, si consiglia agli utenti di attivare la modalità di conferma dell'accesso delle estensioni al sito (Impostazioni estensione → «accesso al sito» → «su clic»), in cui l'estensione ottiene accesso al sito solo dopo un clic sull'icona a destra della barra degli indirizzi. Come soluzione alternativa per la protezione viene anche menzionata la disattivazione della compilazione automatica dei moduli e la copia delle password manualmente tramite il copia e incolla, ma ciò comporta il rischio di perdite di dati dal clipboard condiviso e la possibilità di non notare tentativi di phishing.
Fonte: opennet.ru
