Nunca instalaria uma aplicação capaz de iniciar sessão no seu Google Docs, ler as teclas que digita no navegador, interceptar pedidos em trânsito, funcionar continuamente, atualizar-se silenciosamente E que fosse suficientemente poderosa para roubar as suas palavras-passe, certo? Bem, é mais ou menos isto que as extensões do navegador podem fazer, e criam vulnerabilidades que vão além de um único computador ou mesmo de uma única empresa.
Há alguns meses, um funcionário da Vercel instalou a extensão de navegador Context.ai, relativamente nova e popular, que oferecia um «pacote de escritório com IA». A extensão exigia autorização OAuth para se ligar às aplicações; assim, quando o ecrã de autorizações solicitou que concedessem acesso à ferramenta à sua conta Google, clicaram em «Permitir». Não era uma extensão aprovada internamente pela Vercel, mas também não era uma extensão bloqueada.
No final de fevereiro, um funcionário da Context.ai instalou posteriormente um programa de download de cheats para o Roblox que continha um infostealer. Esse malware, denominado « », descobriu o token OAuth da Vercel, que se tornou o ponto de entrada para um ataque em grande escala contra a Vercel. O atacante não precisou de invadir a Vercel. Bastou-lhe invadir a startup de IA cujo software já tinha recebido as credenciais de um funcionário da Vercel.
Um malware roubou dados recolhidos por uma extensão de navegador em segundo plano. Este padrão parece-lhe familiar? Parece um ataque à cadeia de abastecimento, e é exatamente isso que é.
Como a violação da Vercel constituiu um ataque à cadeia de abastecimento
As extensões de navegador tornaram-se um dos vetores de ataque mais subestimados na segurança empresarial, e a violação da Vercel é apenas o exemplo mais recente. O ataque seguiu um padrão que o setor de segurança conhece bem no que diz respeito às dependências de código aberto, em que algum código de terceiros é implicitamente considerado confiável, mas acaba por ser comprometido a montante. Temos um nome para esse padrão e toda uma categoria de ferramentas criadas em torno dele, mas o setor, no seu conjunto, ainda não as aplicou às extensões de navegador.
Um ataque à cadeia de abastecimento tem alguns ingredientes principais. É necessário que haja código de terceiros a ser executado com privilégios reais, confiança implícita e vítimas sem uma relação direta com a fonte do comprometimento inicial. A violação da Vercel preenche todos estes três requisitos. A Context.ai era um produto real a desempenhar uma função real, e o acesso OAuth que lhe tinha sido concedido ao Google Workspace era um pedido razoável para o que pretendia fazer (embora, possivelmente, fosse um pouco excessivo em termos de confiança e poder). Isso significava que um token OAuth altamente privilegiado se encontrava no backend da AWS da Context.ai, a apenas um dispositivo de funcionário comprometido de se tornar propriedade de um atacante.
Quando aquele funcionário da Context.ai instalou um programa de roubo de dados no seu próprio computador, a confiança que um único funcionário depositou numa extensão anteriormente legítima tornou-se a porta de entrada para os seus ambientes internos. A violação inicial ocorreu noutro local, mas foi a Vercel que acabou por ser afetada. E é a isso que chamamos um ataque à cadeia de abastecimento.
O caso da Vercel não é o primeiro ataque de malware a utilizar extensões de navegador como parte de um ataque à cadeia de abastecimento. Por exemplo, a violação da Cyberhaven no final de 2024 foi uma versão direcionada de um cenário semelhante, com extensões destinadas a programadores especificamente na mira dos atacantes. A própria extensão do Chrome da Cyberhaven foi comprometida através de um ataque de phishing a uma conta de programador, e uma atualização maliciosa foi enviada aos utilizadores antes que alguém a detetasse. A versão maliciosa esteve ativa durante cerca de 24 horas.
O modelo de atualização silenciosa cria mais riscos
O modelo de atualização das extensões é um pouco preocupante quando analisado do ponto de vista da segurança. Ao contrário do software do sistema operativo, as extensões do navegador atualizam-se de forma silenciosa e automática. O código que está a ser executado no seu navegador hoje pode não ser o da aplicação com a qual concordou quando a instalou. Ao contrário de outras atualizações de software que solicitam a sua confirmação (durante meses, enquanto continua a clicar em «Atualizar mais tarde»), não há qualquer aviso para obter o consentimento do utilizador para a atualização. A única altura em que receberia uma notificação seria quando a extensão solicitasse permissões adicionais. Uma extensão que estava limpa no mês passado poderia receber uma atualização maliciosa esta noite, e todos os utilizadores que a tivessem instalada receberiam-na automaticamente. Se já tivesse muitas permissões, estaria em apuros. Imagine se as dependências de software estivessem a atualizar-se automaticamente e de forma silenciosa na sua máquina de desenvolvimento.
O que não tem funcionado
As empresas têm frequentemente tentado criar listas de extensões permitidas (bloqueando todas as outras) ou o inverso, ou seja, listas de extensões bloqueadas. Mas, em ambos os casos, manter a lista atualizada e bem gerida apresenta alguns obstáculos óbvios. Cerca de metade dos autores de extensões são desconhecidos e a maioria dos editores publicou apenas uma extensão, pelo que a gestão de extensões com base na reputação só funciona para uma pequena parte delas. De qualquer forma, mesmo as grandes empresas publicam extensões que não são totalmente irrepreensíveis. É impossível manter manualmente uma lista interna precisa e atualizada.
SCA foi criada para resolver este problema no que diz respeito aos pacotes. Os mecanismos que funcionam para as dependências de código aberto baseiam-se no que o pacote faz (e não no nome ou na funcionalidade declarada). Aprovar pacotes npm apenas com base no nome do pacote, sem análise de código nem Threat Intelligence, não constituiria segurança da cadeia de abastecimento para as dependências. Mas se substituirmos «pacote npm» por «extensão do Chrome», essa tem sido, mais ou menos, a abordagem à segurança dos navegadores nos últimos anos.
Vamos tratar as extensões do navegador como outros vetores da cadeia de abastecimento
Embora as lojas de aplicações não o reflitam, a confiança no momento da instalação não é suficiente. Temos de aplicar aqui a mesma filosofia que aplicamos à segurança dos pacotes. As organizações precisam de saber o que está instalado em todas as máquinas e necessitam de monitoramento contínuo que uma extensão aparentemente inofensiva que se torne maliciosa não passe despercebida.
A maioria das equipas de segurança consegue definir um modelo de ameaças à cadeia de abastecimento para as dependências. Sabem que as contas dos mantenedores podem ser comprometidas e que um pacote que estava limpo no trimestre passado pode ser hoje um vetor de ataque (e temos assistido a muitos ataques à Supply chain de grande visibilidade ataques à Supply chain ). No entanto, enquanto setor, ainda não aplicámos esse conhecimento às extensões de navegador na mesma medida.
O que funciona para as dependências também pode funcionar para as extensões do navegador. análise de dependências de software análise de dependências porque a Threat Intelligence subjacente Threat Intelligence atualizada, verificando bases de dados que são atualizadas à medida que novas ameaças são descobertas, em vez de uma lista compilada por alguém no trimestre passado. O bloqueio pré-instalação para extensões do navegador precisa de funcionar da mesma forma. ataques à Supply chain rapidamente, e uma lista de permissões que estava correta no mês passado não sabe que uma extensão mudou de mãos ou recebeu uma atualização maliciosa na semana passada.
As organizações também precisam de ter uma visão clara do que está instalado em todos os dispositivos dos programadores. Os gestores de pacotes deixam um rasto digital, como ficheiros de bloqueio e listas de dependências que ficam nos repositórios, mas as extensões de navegador não têm isso. A única forma de saber é auditar ativamente todos os dispositivos da organização. Não é possível responder a ameaças cuja existência se desconhece, e muitas empresas não dispõem das ferramentas necessárias para o fazer.
Por fim, todos os membros de uma organização, desde os engenheiros até ao departamento de RH, devem estar cientes dos riscos associados às extensões do navegador. As vulnerabilidades de dependência têm recebido muita atenção da imprensa, mas a segurança dos navegadores, nem tanto. Embora as pessoas possam, em geral, saber que a segurança dos navegadores não é das melhores, muitas vezes não estão tão conscientes destas vulnerabilidades graves, como o roubo de credenciais. Temos de sensibilizar as nossas equipas e organizações para os riscos e as melhores práticas (por exemplo, enviando-lhes este artigo).
Evite o próximo ataque à cadeia de abastecimento do tipo Vercel
A violação da Vercel não será o último incidente em que uma extensão de navegador faça parte da cadeia de ataque. A superfície de ataque é demasiado valiosa e os controlos em que a maioria das organizações confia são demasiado limitados para que isso mude por si só. Encarem a segurança das extensões de navegador como o problema da cadeia de abastecimento que já é, de preferência antes do próximo ataque (e não depois).
Aikido aplica um modelo de segurança da cadeia de abastecimento para proteger os dispositivos dos programadores. As extensões maliciosas são bloqueadas antes de serem instaladas; as que são reconhecidas como maliciosas são verificadas contra Aikido antes de chegarem ao dispositivo. A base Aikido , que está na base deste sistema, identifica até 100 000 pacotes maliciosos por dia e é pública e de acesso gratuito em intel.aikido.dev.
Saiba mais sobre Aikido ou explore o feedAikido para ver, em tempo real, o que foi detetado nos ecossistemas de código aberto.
