Especialista em segurança da informação Alex Birsan falou sobre um novo ataque chamada “confusão de dependência”. O problema é uma variação do ataque à cadeia de abastecimento. Além do nome “confusão de dependência”, os ataques também são chamados de “ataque de substituição”.
Para detectar este método de ataques, o pesquisador já recebeu mais de $130,000 de várias empresas por meio de programas de recompensa por bugs. O fato é que, usando esse problema, o especialista conseguiu fazer upload do seu próprio (inofensivo) código para os sistemas da Microsoft, Maçã, PayPal, Shopify, Netflix, Yelp, Tesla, Uber e outras empresas.
A essência da confusão de dependência é simples: malware de repositórios de código aberto (incluindo PyPI, npm e RubyGems) é automaticamente distribuído ao longo de toda a cadeia de abastecimento, penetrar em aplicações internas de empresas sem qualquer envolvimento do usuário. Isto é o que distingue o ataque do typequatting usual.
Esta ideia simples de Birsan foi promovida no ano passado pelo seu colega, outro especialista em segurança da informação, Justin Gardner. Ele compartilhou com Birsan o arquivo de manifesto package.json do pacote npm usado internamente pelo PayPal. Descobriu-se que alguns dos pacotes do manifesto não estão no repositório público npm, são pacotes privados criados por engenheiros do PayPal, e eles são usados e armazenados apenas dentro da empresa.
Olhando para isso, Birsan se perguntou se um pacote com o mesmo nome deveria existir no repositório público npm, e se, qual acabaria por ter precedência?
Para testar sua teoria, o pesquisador começou a procurar nomes de outros pacotes privados que podem ser encontrados em arquivos de manifesto em repositórios GitHub ou CDNs de empresas conhecidas, que não estão nos repositórios públicos.
Depois de descobrir vários desses alvos, Birsan começou a criar projetos falsos com os mesmos nomes no npm, PyPI e RubyGems (embora Birsan observe que outros gerenciadores de pacotes, incluindo JFrog e NuGet, também são vulneráveis).
O especialista criou essas falsificações a partir de sua conta e as acompanhou com uma explicação de que elas se destinavam exclusivamente a pesquisas de segurança e não continham nenhum código útil..
Este experimento mostrou que se um pacote de dependência usado por um aplicativo existir tanto em um repositório público de código aberto quanto em um repositório de compilação privado, o pacote público eventualmente terá prioridade e será usado sem qualquer ação do desenvolvedor. Acontece também que, no caso de pacotes PyPI, a versão superior tem precedência, não importa onde esteja localizada.
Então, usando as mesmas táticas, Birsan lançou ataques bem-sucedidos contra a Microsoft, Maçã, PayPal, Shopify, Netflix, Tesla, Yelp, Uber e outras grandes empresas, simplesmente publicando pacotes com os mesmos nomes dos pacotes usados internamente.
Todos os pacotes de testes do investigador continham scripts pré-instalados que executam automaticamente um script para recuperar informações de identificação do “infetado” máquina, logo após o pool de pacotes. Percebendo que seus scripts estabeleceriam conexões a partir de redes corporativas seguras, Birsan decidiu contornar os mecanismos de segurança usando DNS para recuperar dados.
Um exemplo desse script pode ser visto na ilustração abaixo: informa ao pesquisador que o endereço IP de onde se origina a solicitação pertence ao PayPal, e também informa o nome de usuário e o diretório inicial do sistema afetado.
Depois de coletar os dados e ter certeza de que ele estava certo, o pesquisador começou a relatar suas descobertas para empresas vulneráveis, recebendo recompensas através de programas de recompensas de bugs. Por exemplo, PayPal já publicou relatório de especialista no HackerOne e pagou-lhe $30,000; Yelp também confirmado as descobertas de Birsan e o recompensou com $15,000.
No entanto, A Microsoft é talvez a mais séria em relação à confusão de dependências. Este problema recebeu um identificador CVE-2021-24105 (para Azure Artifactory), e a empresa não só pagou ao perito $40,000, mas também publicou o seu próprio papel branco detalhando o problema e propondo soluções.
Em particular, Os engenheiros da Microsoft recomendam minimizar os riscos protegendo pacotes privados usando áreas controladas em repositórios públicos, bem como usar a verificação do lado do cliente (versionamento, verificação de integridade).
Deixe-me lembrar também que o pesquisador descobriu que a função Chrome Sync pode ser usada para roubar dados.
