Uma das principais ferramentas de desenvolvedores é o Python Package Index, ou popularmente conhecida como PyPI. Essa ferramenta continua a surpreender a todos de uma forma bem negativa. Depois de muitos problemas, o Python Package Index volta a ser encontrado cheio de chaves AWS e malware.
Ele funciona como uma fonte de bibliotecas Python que os desenvolvedores podem incluir em seus projetos para economizar tempo. Assim, o PyPI foi novamente pego hospedando pacotes com chaves Amazon Web Services (AWS) live e malware para roubo de dados. Não foi a primeira vez que isso aconteceu.
Infelizmente, pacotes maliciosos não são novidade para PyPI ou para sistemas de empacotamento como npm, RubyGems, crates.io e similares. Os ataques à cadeia de suprimentos – comprometendo bibliotecas de software ou typosquatting – têm sido um problema há anos, embora tenham recebido mais atenção recentemente com incidentes como o comprometimento da SolarWinds.
Apesar da vigilância reforçada, esses incidentes ainda ocorrem com frequência alarmante. Pouco antes do Ano Novo, os mantenedores da estrutura de aprendizado de máquina PyTorch alertaram que o PyTorch-nightly, se instalado no Linux via pip, incluía uma dependência comprometida disponível por meio do PyPI chamada torchtriton.
Vários casos
Menos de uma semana depois, a empresa de segurança Phylum disse que em dezembro havia identificado um trojan de acesso remoto em um pacote PyPI chamado pyrologin. Outra empresa de segurança, a ReversingLabs, também detectou um pacote PyPI malicioso naquele mês: o malware estava disfarçado como um SDK da empresa de segurança SentinelOne . E em novembro, descobriu-se que dezenas de pacotes PyPI recém-publicados incluíam malware W4SP .
O PyPI teve uma seleção de malware em massa em março de 2021 que resultou na remoção de 3.653 blocos de código malicioso. Mas as ervas daninhas voltaram, para não falar dos problemas de segurança identificados por meio de análises automatizadas alguns meses depois em quase metade das bibliotecas PyPI.
Além das bibliotecas subvertidas e do código meio decente, o que o PyPI já nos deu? Ultimamente, tem oferecido chaves que fornecem acesso aos recursos e dados de computação da AWS usados pela Amazon, Intel, várias universidades dos EUA, governo australiano, empresa de energia dos EUA Fusion Atomics e Top Glove, com sede na Malásia, maior fabricante de luvas do mundo, entre outros. outras.
Os britânicos encontram as chaves AWS e Malwares no Python Package Index
O desenvolvedor de software baseado no Reino Unido, Tom Forbes, publicou na sexta-feira uma postagem no blog descrevendo como ele encontrou 57 chaves de acesso de API ativas para serviços da AWS das empresas mencionadas acima.
A Forbes criou uma ferramenta Rust para verificar automaticamente todos os novos pacotes lançados no PyPI para a inclusão de chaves de API da AWS. E, bem, funciona.
Forbes em seu post explica que seu scanner é executado periodicamente usando GitHub Actions e procura por chaves AWS em novos lançamentos de PyPI, HexPM e RubyGems. Se encontrar algum, ele gera um relatório com os detalhes relevantes que são confirmados no repositório aws-cred-scanner.
“Este relatório contém as chaves que foram encontradas, bem como um link público para as chaves e outros metadados sobre o lançamento”, disse Forbes em seu post. “Como essas chaves estão comprometidas com um repositório público do GitHub, o serviço de verificação secreta do Github entra em ação e notifica a AWS de que as chaves vazaram”.
Como resultado, a AWS abre um tíquete de suporte para notificar o desenvolvedor infrator e aplica uma política de quarentena para limitar o potencial de uso indevido da chave.
Notícias Relacionadas
O problema, claro, é que uma pessoa menos escrupulosa poderia criar um script de varredura semelhante para fins de exploração e abuso. E seria surpreendente se isso já não estivesse acontecendo.
Forbes em um e-mail disse que as chaves AWS desse tipo podem ser mal utilizadas.
“Depende das permissões exatas dadas à própria chave”, explicou Forbes. “A chave que encontrei vazada pela InfoSys [em novembro] tinha ‘acesso total de administrador’, o que significa que ela pode fazer qualquer coisa, e outras chaves que encontrei no PyPI eram ‘chaves raiz’, que também podem fazer qualquer coisa. Um invasor segurando essas chaves teria acesso total à conta da AWS à qual está vinculada.”
Outras chaves, disse ele, podem ter permissões mais limitadas, mas ainda excessivas. Por exemplo, ele disse que é comum que uma chave destinada a fornecer acesso a um único depósito de armazenamento S3 da AWS tenha sido provisionada por engano para fornecer acesso a todos os depósitos S3 associados a essa conta.
Python Package Index cheio de chaves AWS e malware
A Forbes apontou a verificação automatizada de chaves do GitHub, que também abrange chaves em pacotes npm, como um exemplo de medida defensiva útil. Mas ele disse que a abordagem da empresa tem limitações.
“O GitHub também se preocupa muito com a segurança da cadeia de suprimentos, mas eles cavaram um buraco: a maneira como eles verificam os segredos envolve muita colaboração com fornecedores que podem divulgar informações internas sobre como as chaves são construídas no GitHub”, explicou ele.
“Isso significa que as expressões regulares que o GitHub usa para verificar segredos não podem ser tornadas públicas e são confidenciais, o que também significa que terceiros como o PyPI são efetivamente incapazes de utilizar essa incrível infraestrutura sem enviar cada bit de código publicado no PyPI para o GitHub.”
Problemas se acumulam com o Pypi
A Forbes disse que é uma pena porque, embora o PyPI possa fazer mais para aumentar a segurança da cadeia de suprimentos, é um trabalho difícil de fazer bem.
“O GitHub tem uma equipe inteira trabalhando nisso, enquanto o PyPI simplesmente não tem esse tipo de recurso”, disse ele. “Acredito que há melhorias a serem feitas no ecossistema Python para ajudar a evitar que as chaves (e o código) sejam agrupadas e publicadas acidentalmente no PyPI, e isso pode ser um uso mais eficaz dos recursos”.
Um porta-voz da Fundação Python não respondeu a um pedido de comentário.
“Acredito que um pouco da culpa pode ser atribuída aos desenvolvedores, mas esse tipo de coisa pode não fazer parte de sua competência principal – a segurança é difícil de acertar na melhor das hipóteses”, disse Forbes. “A AWS tem algumas culpas para compartilhar aqui também: o IAM é notoriamente difícil de depurar e acertar, o que leva a permissões excessivamente amplas concedidas às chaves.”
A Forbes também sugeriu que as empresas deveriam pensar com mais cuidado sobre suas políticas de segurança.
“As políticas podem impor que ‘nada no S3 deve ser público’ e, quando algo é necessário para ser público, pode ser mais simples tornar as credenciais do IAM públicas em vez de tentar trabalhar com as políticas de segurança e obter uma exceção. Isso é algo Já ouvi falar disso antes.”
