Você nunca instalaria um aplicativo que pode fazer login nos seus Google Docs, ler suas digitações no seu navegador, interceptar requisições em trânsito, executar continuamente, atualizar silenciosamente E ser poderoso o suficiente para roubar suas senhas, certo? Bem, isso é mais ou menos o que as extensões de navegador podem fazer, e elas criam vulnerabilidades que se estendem para além de um computador ou até mesmo de uma empresa.
Alguns meses atrás, um funcionário da Vercel instalou a relativamente nova e popular extensão de navegador Context.ai, que fornecia uma “AI Office Suite”. Ela exigia permissão OAuth para se conectar aos aplicativos, então, quando a tela de permissões pediu para conceder à ferramenta acesso à sua conta Google, eles clicaram em permitir. Não era uma extensão que a Vercel aprovava internamente, mas também não era uma bloqueada.
No final de fevereiro, um funcionário da Context.ai instalou posteriormente um download de trapaça do Roblox que continha um infostealer. Esse malware encontrou o token OAuth da Vercel, que se tornou o ponto de entrada para um ataque em larga escala à Vercel. O atacante não precisou hackear a Vercel. Eles precisaram hackear a startup de IA cujo software um funcionário da Vercel já havia dado as chaves.
Um malware roubou dados coletados de uma extensão de navegador 'shadow'. O padrão parece familiar? Parece um ataque de cadeia de suprimentos, e é isso que é.
Como a violação da Vercel foi um ataque de cadeia de suprimentos
Extensões de navegador se tornaram um dos vetores de ataque mais subestimados na segurança corporativa, e a violação da Vercel é apenas o exemplo mais recente. O ataque seguiu um padrão que a indústria de segurança conhece bem das dependências de código aberto, onde algum código de terceiros é implicitamente confiado e depois comprometido upstream. Temos um nome para esse padrão e toda uma categoria de ferramentas construídas em torno dele, mas a indústria como um todo não os aplicou a extensões de navegador.
Um ataque de cadeia de suprimentos tem alguns ingredientes principais. Você precisa de código de terceiros executando 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 atende a todos os três. Context.ai era um produto real realizando um trabalho real, e o acesso OAuth que lhe havia sido concedido ao Google Workspace era uma solicitação razoável para o que estava tentando fazer (embora, discutivelmente, um pouco demais de confiança e poder). Isso significava que um token OAuth altamente privilegiado estava no backend 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 infostealer em sua própria máquina, a confiança que apenas um funcionário havia estendido a uma extensão anteriormente legítima se tornou o caminho para seus ambientes internos. A violação original aconteceu em outro lugar, mas a Vercel sofreu. E é isso que chamamos de ataque à supply chain.
O caso da Vercel não é o primeiro ataque de malware a usar extensões de navegador como parte de um ataque à supply chain. Por exemplo, a violação da Cyberhaven no final de 2024 foi uma versão direcionada de um cenário similar, com extensões focadas em desenvolvedores especificamente na mira dos atacantes. A própria extensão do Chrome da Cyberhaven foi comprometida via um ataque de phishing em uma conta de desenvolvedor, e uma atualização maliciosa foi enviada aos usuários antes que alguém percebesse. A versão maliciosa ficou ativa por aproximadamente 24 horas.
O modelo de atualização silenciosa cria mais perigo
O modelo de atualização para extensões é um tanto problemático quando visto de uma perspectiva de segurança. Ao contrário do software de sistema operacional, as extensões de navegador atualizam de forma silenciosa e automática. O código rodando no seu navegador hoje pode não ser o aplicativo que você concordou em instalar. Diferente de outras atualizações de software que solicitam que você atualize (por meses, enquanto você continua clicando em “Atualizar mais tarde”), não há um aviso para obter o consentimento do usuário para a atualização. A única vez que você receberia uma notificação é quando a extensão pede permissões adicionais. Uma extensão que estava limpa no mês passado poderia receber uma atualização maliciosa hoje à noite, e todo usuário com ela instalada a receberia automaticamente. Se ela já tivesse muitas permissões, você estaria em apuros. Imagine se as dependências de software estivessem atualizando automaticamente de forma silenciosa na sua máquina dev.
O que não tem funcionado
As empresas frequentemente tentaram criar listas de extensões permitidas (bloqueando todo o resto) ou o inverso, de extensões bloqueadas. Mas em ambos os casos, manter a lista curada e atualizada apresenta algumas barreiras óbvias. Cerca de metade dos autores de extensão são desconhecidos, e a maioria dos publicadores lançou apenas uma extensão, então gerenciar extensões com base na reputação funciona apenas para uma pequena parcela delas. Mesmo grandes empresas publicam extensões que não são totalmente limpas, de qualquer forma. Manter manualmente uma lista interna precisa e atualizada é impossível.
A análise SCA foi inventada para resolver isso para pacotes. Os mecanismos que funcionam para dependências de código aberto operam com base no que o pacote faz (não no nome ou na funcionalidade alegada). Aprovar pacotes npm apenas pelo nome do pacote, sem análise de código e sem Threat Intelligence, não seria considerado segurança da supply chain para dependências. Mas troque "pacote npm" por "extensão do Chrome", e essa é mais ou menos a abordagem para a segurança do navegador nos últimos anos.
Vamos tratar as extensões de navegador como outros vetores de supply chain
Embora os marketplaces não reflitam isso, a confiança no momento da instalação não é suficiente. Temos que aplicar a mesma filosofia aqui que aplicamos à segurança de pacotes. As organizações precisam saber o que está instalado em todas as máquinas, e precisam de monitoramento contínuo para que uma extensão aparentemente limpa que se torna maliciosa não passe despercebida.
A maioria das equipes de segurança consegue articular um modelo de ameaça da supply chain para dependências. Elas sabem que contas de mantenedores são comprometidas, e um pacote que estava limpo no último trimestre pode ser um vetor hoje (e temos visto muitos ataques à supply chain de alto perfil ultimamente). No entanto, como indústria, não aplicamos esse conhecimento às extensões de navegador na mesma medida.
O que funciona para dependências também pode funcionar para extensões de navegador. A análise de dependências de software funciona porque a Threat Intelligence subjacente se mantém atualizada, verificando contra bancos de dados que atualizam à medida que novas ameaças são descobertas, em vez de uma lista compilada por alguém no último trimestre. O bloqueio pré-instalação para extensões de navegador precisa funcionar da mesma forma. Ataques à supply chain se movem rapidamente, e uma allowlist que estava precisa 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 visibilidade sobre o que está instalado em cada dispositivo de desenvolvedor. Gerenciadores de pacotes deixam um rastro como arquivos de lock e listas de dependências que residem em repositórios, mas as extensões de navegador não têm isso. A única maneira de saber é auditar ativamente todos os dispositivos da organização. Você não pode responder a ameaças que não sabe que existem, e muitas empresas não têm as ferramentas em vigor para fazer isso.
Finalmente, todos em uma organização, de engenheiros a RH, precisam estar cientes dos riscos das extensões de navegador. Vulnerabilidades de dependência têm recebido muita atenção da mídia, mas a segurança do navegador menos. Embora as pessoas geralmente saibam que não são ótimas, elas frequentemente não estão tão cientes dessas grandes vulnerabilidades, como o roubo de credenciais. Temos que educar nossas equipes e organizações sobre riscos e melhores práticas (envie-lhes este artigo, por exemplo).
Evite o próximo ataque à supply chain no estilo Vercel
A violação da Vercel não será o último incidente em que uma extensão de navegador faz parte da kill chain. A superfície de ataque é muito valiosa, e os controles nos quais a maioria das organizações confia são muito limitados para que isso mude por conta própria. Trate a segurança das extensões de navegador como o problema de supply chain que ela já é, esperançosamente antes do próximo ataque (não depois).
Aikido Endpoint aplica um modelo de segurança de supply chain para proteger dispositivos de desenvolvedores. Extensões maliciosas são bloqueadas antes de serem instaladas, conhecidas como maliciosas, verificadas contra o Aikido Intel antes de tocarem o dispositivo. O feed do Aikido Intel que o alimenta identifica até 100.000 pacotes maliciosos por dia e é público e gratuito para explorar em intel.aikido.dev.
Saiba mais sobre Aikido Endpoint ou explore o feed do Aikido Intel para ver o que foi detectado em todos os ecossistemas de código aberto em tempo real.
