Na conferência DEF CON 33, foi apresentado um método de ataque a extensões de navegador que inserem seus elementos de interface na página exibida. A aplicação do ataque a extensões com gerenciadores de senhas pode resultar na exposição de informações armazenadas nesses gerenciadores, como credenciais de autenticação, dados de cartões de crédito, informações pessoais e senhas únicas para autenticação em duas etapas. O problema afeta todos os gerenciadores de senha testados, incluindo 1Password, Bitwarden, LastPass, KeePassXC-Browser, NordPass, ProtonPass e Keeper.
O método de ataque baseia-se no fato de que as extensões de navegador inserem um diálogo solicitando a autocompletação da senha diretamente na página exibida, integrando seus elementos ao DOM (Document Object Model) dessa página. Se o atacante tiver a capacidade de executar seu código JavaScript na página, por exemplo, explorando uma vulnerabilidade XSS no site, ele pode manipular todos os elementos no DOM, incluindo as extensões de navegador inseridas.
Entre outras coisas, há a possibilidade de tornar o diálogo de confirmação transparente e spatialmente alinhar o botão nesse diálogo com o botão de um diálogo falso, criado pelo atacante e que induz o usuário a clicar. Diálogos falsos podem incluir solicitações fraudulentas para permissões de cookies, banners publicitários ou formulários com CAPTCHA. Ao posicionar o diálogo falso sob o diálogo transparente do gerenciador de senhas e alinhar a localização dos botões na tela, é possível fazer com que o clique do usuário acabe na confirmação de preenchimento das credenciais no diálogo do gerenciador de senhas, apesar de o usuário pensar que clicou, por exemplo, no botão de fechar uma janela publicitária.
O ataque consiste nos seguintes passos:
- Criação de um elemento intrusivo na página, incentivando o clique.
- Adição de um formulário web para login ou preenchimento de dados pessoais.
- Aplicação de transparência ao formulário web ("opacity: 0.001" em CSS).
- Uso do método focus() para definir o foco no campo dentro do formulário, levando à ativação do diálogo de autocompletação do gerenciador de senhas.
- Busca pelo diálogo de gerenciador de senhas que apareceu no DOM e aplicação de transparência a ele.
- Espera pelo clique do usuário em um elemento visível e intrusivo na página, que, ao juntar elementos visíveis e invisíveis, levará ao clique em um botão em um diálogo transparente e ao preenchimento dos campos pelo gerenciador de senhas.
- Extração de dados de um formulário web preenchido e envio destes para o servidor do atacante.
Como o preenchimento automático dos parâmetros de autenticação no gerenciador de senhas é ativado apenas para sites nos quais esses parâmetros foram salvos, para realizar o ataque é necessário ter a capacidade de executar seu código JavaScript no site atacado ou em um subdomínio. Assim, para o ataque, é necessário obter um subdomínio no mesmo domínio que o site atacado ou encontrar uma vulnerabilidade XSS no site que permita injetar seu código no conteúdo entregue ao usuário.
Observa-se que muitos usuários utilizam um único gerenciador de senhas tanto para armazenar os parâmetros de login quanto para gerar senhas temporárias para autenticação em duas etapas, o que possibilita o uso do método de ataque quando se preenche automaticamente senhas temporárias. Como exemplo, é demonstrado um ataque ao site issuetracker.google.com, que contém uma vulnerabilidade XSS. Para obter os parâmetros de login e o código para autenticação em duas etapas, basta enviar ao usuário um link que explore a vulnerabilidade XSS e conseguir três cliques através da inserção de solicitações intrusivas fictícias (autorização para processamento de Cookies, autorização para personalização e consentimento com a política de privacidade).
Além de sites com vulnerabilidades XSS, o ataque pode ser realizado em serviços que fornecem subdomínios a todos os interessados — a maioria dos gerenciadores de senhas, na configuração padrão, realiza o preenchimento dos parâmetros de login não apenas para o domínio principal, mas também para subdomínios.
O ataque também pode ser usado para determinar os dados pessoais do usuário e os detalhes do cartão de crédito salvos no gerenciador de senhas. Nesse caso, não é necessário executar código JavaScript no contexto de um site estranho, basta enganar a vítima a acessar uma página no site do atacante — no caso dos dados pessoais, o preenchimento de formulários web é realizado com base em seu tipo (endereço, número do cartão de crédito, nome completo), sem ligação a domínio. A mais perigosa é a vazamento dos dados do cartão de crédito, pois os gerenciadores de senhas inserem não apenas o número do cartão, mas também a data de validade e o código de verificação.
O pesquisador que identificou o problema testou 11 extensões de navegador com gerenciadores de senhas, totalizando 39,7 milhões de instalações ativas, e todas se mostraram vulneráveis a esse tipo de ataque. Alguns fabricantes lançaram atualizações (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), nas quais tentaram bloquear a realização do ataque de forma indireta. Outras extensões (KeePassXC-Browser, 1Password, iCloud Passwords, Enpass, LastPass, LogMeOnce) ainda estão sem correção. Para verificar a manifestação da vulnerabilidade em diferentes gerenciadores de senhas, foi publicado um conjunto de páginas de teste.
A posição dos desenvolvedores do 1Password, que não lançaram uma correção, é de que a vulnerabilidade é fundamental e não está diretamente relacionada a uma extensão de navegador específica; portanto, as tentativas de solucioná-la pelo lado da extensão apenas bloqueiam vetores de ataque isolados, mas não eliminam o problema em si, que deve ser tratado no navegador ou com a solicitação de confirmação separada antes do preenchimento automático dos campos. É mencionado que o 1Password já suporta a exibição de um pedido de confirmação antes do preenchimento automático dos parâmetros de pagamento e na próxima versão será adicionada a opção de exibir um pedido semelhante para todos os tipos de dados preenchidos automaticamente (devido à diminuição da conveniência, tal opção não será ativada por padrão).
Entre os métodos de proteção sugeridos pelo autor da pesquisa, menciona-se o rastreamento de alterações nos estilos dos elementos inseridos na página por meio da API MutationObserver, o bloqueio de alterações através do Shadow DOM no modo "closed", o monitoramento da transparência dos elementos, a utilização da API Popover para exibir diálogos, a verificação de sobreposição de camadas, e a desativação temporária do tratamento de eventos de ponteiro (pointer-events:none) em todos os elementos flutuantes durante a exibição do diálogo do gerenciador de senhas. Assim, para um bloqueio completo da classe descrita. ataques recomenda-se implementar, no nível do navegador, uma API separada para proteção. contra clickjacking.
Como um método universal de proteção em navegadores baseados no motor Chromium, os usuários são aconselhados a ativar o modo de confirmação de acesso a complementos ao site (Configurações do complemento → "acesso ao site" → "on click"), onde o complemento obtém acesso ao site somente após um clique no ícone à direita da barra de endereços. Como uma solução alternativa de proteção, também se menciona a desativação da autocompletar de formulários e a cópia manual de senhas através da área de transferência, mas isso levanta o problema de vazamento de dados da área de transferência compartilhada e o risco de não perceber tentativas de phishing.
Fonte: opennet.ru
