A empresa de segurança de aplicações Aikido revelou que os endereços de e-mail do recurso Email work item to this project do GitLab aparecem às vezes em arquivos README, guias de contribuição e páginas públicas de suporte. Esses endereços contêm um token de longa duração associado à conta do desenvolvedor, o que torna sua publicação mais próxima da exposição de credenciais do que da publicação de um meio comum para receber relatórios de bugs.
O recurso permite que qualquer pessoa que envie uma mensagem para o endereço crie uma questão ou tarefa em um projeto do GitLab. Porém, os testes realizados pela Aikido mostraram que o invasor pode alterar o sufixo -issue no endereço para -merge-request, fazendo com que o GitLab aceite a mensagem e crie uma solicitação de mesclagem no projeto.
O que pode acontecer na prática?
O alcance do impacto depende das permissões da conta associada ao token. Os possíveis resultados podem incluir a introdução de alterações no código, a execução de tarefas de CI/CD, o acesso a repositórios privados ou a extração de segredos armazenados em variáveis de CI/CD, além da visualização de questões confidenciais. Em projetos de código aberto, os endereços expostos podem se transformar em um risco para a cadeia de suprimentos se forem usados para introduzir alterações em projetos dos quais um grande número de usuários depende.
Durante uma única tarde, os pesquisadores da Aikido encontraram cerca de 12 endereços ativos publicados em documentos públicos e disseram que alguns pertenciam a projetos de código aberto amplamente utilizados. O invasor não precisa falsificar o endereço de e-mail do proprietário do token; o GitLab processa a mensagem como se ela tivesse sido enviada pelo proprietário do token, e os testes também mostraram a superação das restrições de endereços IP.
Limites da exploração e responsabilidade dos administradores
A exposição do endereço não significa a superação das permissões da conta; as permissões do usuário continuam sendo uma limitação fundamental. O invasor também precisa conhecer o caminho e o identificador do projeto. Essas informações estão disponíveis em projetos públicos, enquanto o direcionamento a um projeto privado exige o vazamento do caminho, mesmo que seja possível adivinhar o identificador por força bruta.
A própria documentação do GitLab alerta contra o compartilhamento desses endereços e os descreve como privados e gerados para o usuário em questão, observando que quem os conhece pode criar questões ou solicitações de mesclagem como se fosse o proprietário. A plataforma recomenda redefinir o token imediatamente ao suspeitar de um vazamento.
O que isso significa para os projetos?
A Aikido comunicou o problema ao GitLab por meio do HackerOne em maio, mas o relatório foi encerrado sob a justificativa de que o comportamento era intencional. Após uma segunda notificação em junho, o GitLab atualizou sua interface para mencionar a possibilidade de criar solicitações de mesclagem, removeu afirmações imprecisas sobre o acesso aos dados do token e documentou que o recebimento de mensagens por e-mail contorna as restrições de IP.
A principal medida prática cabe aos administradores dos projetos: remover esses endereços da documentação pública e redefinir os tokens dos projetos que já foram publicados. As questões em aberto dizem respeito ao grau em que o GitLab adotará futuramente a correspondência entre o endereço do remetente e o e-mail do proprietário do token como uma camada adicional de defesa, mecanismo que, segundo a Aikido, a plataforma está atualmente estudando.