Abuso da infraestrutura do Go

Problema

• Na noite passada, enquanto explorava o conteúdo do banco de dados de checksums do Go, encontrei um resultado interessante.
• Ao executar o comando sqlite> select path, count(path) from modules group by path order by count(path) desc;, o resultado foi:
  • github.com/homebrew/homebrew-core|39438
  • github.com/Homebrew/homebrew-core|30896
  • github.com/concourse/concourse|25372
  • github.com/openshift/release|24065
  • github.com/cilium/cilium|22138
• O Homebrew é conhecido por usar Ruby, então a ligação com Go parecia estranha.
• As estatísticas de linguagem do GitHub também confirmaram isso.
• Clonei o repositório para procurar arquivos relacionados a Go (go.mod ou arquivos-fonte Go), mas não encontrei nada.

Pesquisa

• Um novo dia começou, e a curiosidade exigia uma resposta.
• Se o repositório Git não tinha relação com código Go, fiquei me perguntando como ele aparecia no banco de dados de checksums do Go.
• Descobri que proxy.golang.org é o proxy de módulos padrão e sum.golang.org é o banco de dados de checksums.
• Ao ler a documentação do Go, descobri que, se a versão do módulo ainda não tiver sido registrada no log, o banco de dados de checksums tenta buscar o módulo no servidor de origem.
• Para verificar se um novo repositório de módulos Go seria adicionado ao banco de dados de checksums e ao proxy, tentei chamar o endpoint lookup.
• Criei um novo módulo Go, enviei para minha conta no GitHub e então tentei o comando lookup em dois formatos, mas ambos retornaram erro.
• Gereia a pseudoversão correta e consultei novamente o banco de dados de checksums para verificar se o módulo tinha sido baixado.
• Consultei o proxy e baixei o zip do módulo, provando que é possível armazenar dados arbitrários na infraestrutura do Go.

Possibilidades de abuso

• Pode ser usado para contornar restrições de download em máquinas de desenvolvedores e servidores de CI/CD.
• Um malware pode armazenar payloads e buscá-los no proxy quando necessário.
• Pode ser possível realizar um ataque de negação de serviço (DoS) contra proxy.golang.org.
• Um sistema de comando e controle (C2) pode ser implementado com facilidade.

Conclusão

• Passei a entender como funciona o processo do banco de dados de checksums.
• No momento, isso não parece ser um problema grave na infraestrutura do Go, mas há potencial para abuso.
• Continuam existindo dúvidas adicionais sobre por que projetos não-Go estão no banco de dados.
• Esta pesquisa me deu muitas ideias, e pretendo explorar mais.

Opinião do GN⁺

1. Vulnerabilidade de segurança: Este artigo aponta uma vulnerabilidade de segurança no banco de dados de checksums do Go, que pode armazenar dados arbitrários. Isso pode fornecer um caminho para a distribuição fácil de código malicioso.
2. Necessidade de melhorias: É necessário melhorar o controle de acesso ao banco de dados de checksums e aos servidores proxy para reforçar a segurança e a integridade da infraestrutura do Go.
3. Integração com outras linguagens: É preciso esclarecer por que projetos não-Go estão incluídos no banco de dados de checksums do Go e adicionar procedimentos extras de validação para evitar isso.
4. Educação de desenvolvedores: É necessário educar os desenvolvedores para que reconheçam esse tipo de vulnerabilidade e entendam as melhores formas de preveni-la.
5. Soluções alternativas: Pode ser útil comparar bancos de dados de checksums e servidores proxy de outras linguagens que oferecem funções semelhantes, usando isso como referência para melhorar a infraestrutura do Go.

[GN⁺]

Comentários do Hacker News

Resumo da coletânea de comentários do Hacker News

• Possibilidade de abuso de serviços online

  • Todo serviço online pode acabar sendo abusado para comando e controle, violação de direitos autorais e hospedagem de CSAM. Twitter, Telegram e a infraestrutura de chaves PGP já tiveram casos assim.

• Problema de hospedagem de arquivos no Google

  • Como o Google lida com frequência com problemas de hospedagem de arquivos maliciosos, é possível que a equipe do Go tenha trabalhado em conjunto com o GCP e o Drive. Isso não é muito diferente de outros endpoints que o Google já permite.

• Comparação com o GitHub

  • Há a opinião de que isso não é muito diferente de enviar arquivos para o GitHub. O GitHub também permite armazenar dados arbitrários para qualquer pessoa com uma conta.

• Projetos não Python no PyPI

  • Existem projetos não Python no PyPI, e é necessário haver uma forma de distribuir wheels (binários compilados) para casos em que o usuário não consegue compilar o código da biblioteca. Isso também pode valer para código escrito em C e Golang.

• Proxy do Golang e log de checksums

  • Houve a experiência de tentar usar o proxy do Golang e o sumdb para registrar de forma transparente checksums de URLs arbitrárias.

• Exploração de domínio

  • Ao explorar um domínio específico, a maior parte do que se esperava encontrar realmente estava lá.

• Problema conhecido

  • Foi compartilhado um link sobre um problema conhecido do Golang.

• Sistema de módulos do CUE

  • O sistema de módulos do CUE está sendo lançado; embora haja apreço pelo MVS do Go, ele foi construído com base na infraestrutura OCI. Se você tem interesse em sistemas de gerenciamento de dependências, vale conferir o link relacionado.

• Problema de cache na web

  • O W3C tornou tudo na web passível de cache, mas há curiosidade sobre por que quase não existem caches proxy de propósito geral. Fica a dúvida se os publicadores enviam respostas com Cache-Control: max-age desnecessariamente curto ou Vary: Cookie, ou se ISPs demais acabam pagando custos de trânsito.

• Problema de cache proxy

  • Pode ser desperdício fazer o proxy armazenar em cache repositórios que não são de Go, mas se ele armazenar repositórios Go em cache, também pode acabar armazenando dados arbitrários. Não parece ser um grande problema.