ghrc.io parece ser um site malicioso

• A simples confusão entre ghcr.io e ghrc.io por erro de digitação pode causar uma ameaça de segurança grave
• À primeira vista, ghrc.io parece apenas um servidor nginx padrão, mas internamente foi detectado que imita a API OCI
• Este site usa o cabeçalho www-authenticate para induzir clientes de contêiner a enviar informações sensíveis de autenticação
• Se alguém inserir credenciais por engano com docker login ou usar um registro incorreto, pode ocorrer vazamento de credenciais
• Se você fez login no servidor errado, é necessário alterar a senha, revogar o PAT e verificar atividades anormais na conta do GitHub

---

Visão geral

A confusão frequente entre ghcr.io e ghrc.io causada por um simples erro de digitação é um caso que gera um problema de segurança muito perigoso. Foi detectada uma tentativa de roubo de credenciais em ghrc.io, uma versão com erro de digitação do GitHub Container Registry (ghcr.io), usado por muitos desenvolvedores e equipes.

O que é ghcr.io

• ghcr.io é um registro compatível com OCI para imagens de contêiner e artefatos OCI
• Como parte do GitHub, é usado como um registro popular em inúmeros projetos open source

ghrc.io: aparência na superfície

• Ao acessar ghrc.io, aparece apenas a tela padrão do nginx
• O comportamento básico, incluindo erros 404 típicos, é igual ao de um servidor nginx comum

A natureza da atividade maliciosa

• O problema central aparece em chamadas da API OCI sob o prefixo /v2/
• Ao acessar esse caminho, o site responde com cabeçalho www-authenticate e status 401, exibindo um comportamento muito semelhante ao de um registro oficial de contêineres
• O cabeçalho www-authenticate: Bearer realm="https://ghrc.io/token"; está presente
• Por causa desse cabeçalho, clientes como Docker, containerd, podman e Kubernetes tentam enviar automaticamente as credenciais do usuário para https://ghrc.io/token
• Como a configuração padrão do nginx não inclui esse cabeçalho, trata-se de algo claramente configurado de forma intencional

Risco: cenário de roubo de credenciais

• Esse padrão é considerado um ataque de roubo de credenciais baseado em typo-squatting
• O risco só existe quando o cliente do usuário insere ou armazena credenciais para ghrc.io
• Exemplos de situações em que credenciais reais podem ser expostas
  • Ao executar docker login ghrc.io
  • Ao usar docker/login-action dentro de um GitHub Action com o registro definido como ghrc.io
  • Ao salvar credenciais de registro para ghrc.io em um secret do Kubernetes e tentar fazer pull da imagem
• Apenas tentar fazer push/pull de imagens em ghrc.io não expõe credenciais (após uma tentativa de token anônimo, o retorno é erro)

Como responder

• Se você fez login por engano em ghrc.io, deve alterar imediatamente a senha e revogar o PAT (token de acesso pessoal) usado
• Também é essencial verificar logins suspeitos ou atividades maliciosas na conta do GitHub
• Um invasor pode usar isso para adicionar imagens maliciosas a repositórios no ghcr.io ou obter acesso à conta

Conclusão

• É necessário tomar cuidado com sites de phishing que usam endereços semelhantes ao ghcr.io
• São exigidas políticas ainda mais rigorosas para o gerenciamento de informações de segurança, como credenciais, tokens e senhas

[ndrgrd]

Talvez não seja melhor simplesmente mudar para um subdomínio de github.com?

[GN⁺]

Comentários do Hacker News

• Destaca a gravidade de o GitHub Container registry suportar apenas tokens clássicos legados, em vez de tokens granulares
  Também anexa links para a documentação e para a issue relacionada
  Documentação oficial
  Discussão na comunidade
  Issue no roadmap

  • Por causa desse problema, não é possível desativar completamente os PATs clássicos
    Como medida complementar, dá para usar sessões com validade curta e forçar reautenticação com Enterprise SSO, mas isso acaba sendo uma opção incômoda para o único PAT clássico realmente necessário

  • Seria bom se alguém comprasse todos os domínios com erro de digitação por boa fé e os repassasse para a Microsoft
    Acha que a Microsoft deveria mudar o nome do registro
    O nome é tão confuso que a própria pessoa já digitou errado várias vezes

• Diz que só conseguiu entender o problema depois de ler a questão do domínio várias vezes, o que mostra que é um vetor de ataque bastante convincente

  • Não foi só essa pessoa; várias outras passaram pelo mesmo
    Tentaram várias vezes, falharam e até reiniciaram o computador, mas o mesmo problema continuou acontecendo
    Como referências úteis, também cita uma resposta no Stack Overflow e uma discussão no fórum do Docker

• Apresenta um link para os resultados da busca de código por ghrc.io

• Não percebeu o problema até que o artigo apontasse diretamente que o c e o r estavam trocados

  • Esse é exatamente o tipo de erro de digitação que comete mais de 10 vezes por dia

  • O problema aqui é que o nome de domínio do GitHub é uma bagunça
    O nome do container registry é realmente muito ruim

• Compartilha um link para uma discussão anterior no Hacker News

• Diz que é possível confirmar via whois que esse domínio foi registrado na Dynadot
  Portanto, parece valer a pena denunciá-lo para [e-mail]

• Menciona que muitos projetos open source estão usando esse domínio e compartilha novamente os resultados da busca de código

  • O GitHub precisa internamente de uma ferramenta capaz de propor e distribuir correções automáticas em massa

  • Comenta que os resultados da busca de código no GitHub são, de fato, bem numerosos

• Expressa preocupação de que um erro de digitação em uma tarefa de CI possa causar um grande problema

• Aconselha evitar, sempre que possível, TLDs com menor valor em termos de segurança
  Segurança deve vir antes de qualquer tentativa de parecer "fofo"
  Como a remoção de registros maliciosos pode não ser tão rápida quanto em .com, considera .com, administrado pela Verisign nos EUA, mais confiável
  Acredita que depender do Território Britânico do Oceano Índico, da Colômbia ou de Anguilla é inadequado

  • Acrescenta que o TLD .io é administrado pela empresa americana Afilias

• Pergunta se o verdadeiro risco aqui é o problema de reutilização de token
  Um token Bearer não entrega diretamente a senha, então, citando a RFC e a documentação da Mozilla, questiona se o problema real não é o processo de obter novamente um token para autenticação, e não o token de autenticação em si
  Se o OAuth entre domínios não reutiliza o token, então não seria o caso de um domínio falso simplesmente não conseguir obter o token?

  • Responde como autor do blog e mantenedor de OCI
    Na requisição para obter o token Bearer, a senha ou o PAT é enviado no cabeçalho de autenticação básica codificado em base64, mas na prática em texto puro
    Quando a requisição é recebida, o cabeçalho www-authenticate é emitido, um token de autenticação é obtido para validar o acesso ao registro e, depois disso, o token expira
    A estrutura do ataque não é roubar o token em si, mas induzir a solicitação das próprias credenciais necessárias para obter o token Bearer