PyPI do Python revela seus segredos
GitGuardian é famoso por seu relatório anual State of Secrets and techniques Sprawl. Em seu relatório de 2023, eles encontraram mais de 10 milhões de senhas, chaves de API e outras credenciais expostas em commits públicos do GitHub. As conclusões do seu relatório de 2024 não destacaram apenas 12,8 milhões novo segredos expostos no GitHub, mas um número no widespread repositório de pacotes Python PyPI.
PyPI, abreviação de Python Bundle Index, hospeda mais de 20 terabytes de arquivos que estão disponíveis gratuitamente para uso em projetos Python. Se você já digitou pip set up (nome do pacote), provavelmente ele extraiu esse pacote do PyPI. Muita gente também usa. Quer seja GitHub, PyPI ou outros, afirma o relatório, “os pacotes de código aberto representam cerca de 90% do código executado em produção hoje.” É fácil ver por que isso acontece quando esses pacotes ajudam os desenvolvedores a evitar a reinvenção de milhões de rodas todos os dias.
No relatório de 2024, o GitGuardian relatou ter encontrado mais de 11.000 expostos exclusivo segredos, com 1.000 deles sendo adicionados ao PyPI em 2023. Isso não é muito comparado aos 12,8 milhões de novos segredos adicionados ao GitHub em 2023, mas o GitHub é muito maior.
Um facto mais preocupante é que, dos segredos introduzidos em 2017, quase 100 ainda eram válidos 6 a 7 anos depois. Eles não tiveram a capacidade de verificar a validade de todos os segredos. Ainda assim, foram descobertos mais de 300 segredos únicos e válidos. Embora isso seja ligeiramente alarmante para o observador informal e não necessariamente uma ameaça para desenvolvedores Python aleatórios (ao contrário dos 116 pacotes maliciosos relatados pela ESET no last de 2023), é uma ameaça de magnitude desconhecida para os proprietários desses pacotes.
Embora o GitGuardian tenha centenas de detectores de segredos, ele foi desenvolvido e refinado ao longo dos anos, alguns dos segredos mais comuns detectados em seu estudo geral de 2023 foram chaves de API OpenAI, chaves de API do Google e chaves do Google Cloud. Não é difícil para um programador competente escrever uma expressão common para encontrar um único formato secreto comum. E mesmo que surgissem muitos falsos positivos, automatizar as verificações para determinar se eram válidos poderia ajudar o desenvolvedor a encontrar um pequeno tesouro de segredos exploráveis.
Agora é uma lógica aceita que se uma chave foi publicada em um repositório público como GitHub ou PyPI, ela deve ser considerada comprometida. Em testes, os honeytokens (uma espécie de chave de API “desativada” sem acesso a nenhum recurso) foram testados quanto à validade por bots um minuto após serem publicados no GitHub. Na verdade, os honeytokens atuam como um “canário” para um número crescente de desenvolvedores. Dependendo de onde você colocou um honeytoken específico, você pode ver que alguém está bisbilhotando lá e obter algumas informações sobre ele com base em dados de telemetria coletados quando o honeytoken é usado.
A maior preocupação quando você publica acidentalmente um segredo não é apenas que um agente mal-intencionado possa aumentar sua conta na nuvem. É para onde eles podem ir a partir daí. Se um token AWS IAM com permissão excessiva vazasse, o que esse ator mal-intencionado poderia encontrar nos buckets S3 ou nos bancos de dados aos quais concede acesso? Esse ator mal-intencionado poderia obter acesso a outro código-fonte e corromper algo que será entregue a muitos outros?
Esteja você enviando segredos para GitHub, PyPI, NPM ou qualquer coleção pública de código-fonte, o melhor primeiro passo ao descobrir que um segredo vazou é revogá-lo. Lembre-se daquela pequena janela entre a publicação e a exploração de um honeytoken. Depois que um segredo é publicado, provavelmente ele foi copiado. Mesmo que você não tenha detectado um uso não autorizado, você deve presuma que alguém não autorizado e malicioso agora o possui.
Mesmo que seu código-fonte esteja em um repositório privado, há muitas histórias de atores mal-intencionados obtendo acesso a repositórios privados por meio de engenharia social, phishing e, claro, segredos vazados. Se há uma lição para tudo isso, é que segredos de texto simples no código-fonte eventualmente são encontrados. Quer sejam publicados acidentalmente em público ou encontrados por alguém com acesso que não deveriam, eles são encontrados.
Em resumo, onde quer que você armazene ou publique seu código-fonte, seja um repositório privado ou um registro público, você deve seguir algumas regras simples:
- Não armazene segredos em texto simples no código-fonte.
- Evite que aqueles que conseguem um segredo participem de uma expedição, mantendo os privilégios concedidos por esses segredos estritamente definidos.
- Se você descobrir que vazou um segredo, revogue-o. Talvez seja necessário reservar um pouco de tempo para garantir que seus sistemas de produção tenham o segredo novo e não vazado para a continuidade dos negócios, mas revogue-o assim que possível.
- Implemente automações como as oferecidas pelo GitGuardian para garantir que você não dependa de humanos imperfeitos para observar perfeitamente as práticas recomendadas em torno do gerenciamento de segredos.
Se você segui-los, talvez não exact aprender as lições que 11.000 proprietários de segredos provavelmente aprenderam da maneira mais difícil, publicando-os no PyPI.
