Na semana passada, o GitHub lançou a função de revogação de credenciais em modo de autoatendimento para o Enterprise. Esta funcionalidade permite aos proprietários das organizações bloquear credenciais comprometidas em toda a organização com uma única ação, em vez de terem de procurar tokens individuais durante um incidente em curso.
Esta correção demorou muito tempo a chegar, uma vez que os últimos meses demonstraram o que acontece quando a revogação é lenta ou incompleta. Trivy , em março, voltou a ocorrer porque a primeira limpeza deixou pelo menos uma credencial ativa, e essa reação em cadeia atingiu Checkmarx depois. Em junho, os próprios repositórios «durabletask» da Microsoft foram alvo de um ataque através de uma conta que nunca tinha sido totalmente limpa após um ataque anterior.
A Microsoft tem estado em grande forma ultimamente no que diz respeito a correções de segurança. Apenas alguns dias antes disto, introduziram períodos de espera para a publicação após alterações na conta e, no início de junho, também atualizaram o npm para impedir a execução automática de scripts pós-instalação. Vamos ficar atentos ao que mais vierem a lançar e ao impacto que isso terá nos ataques a software de código aberto.
O que o GitHub lançou
Os proprietários de empresas com a permissão «Gerir credenciais da empresa» podem agora revogar ou eliminar em massa as credenciais de todos os utilizadores da organização, ou selecionar uma conta específica. Isto abrange as autorizações de SSO para Tokens de Acesso Pessoais (PATs), chaves SSH e tokens OAuth. Está disponível uma opção para eliminar tudo nas organizações com Utilizadores Geridos pela Empresa (EMU), e as APIs REST ao nível da organização permitem uma revogação mais granular por organização. Cada ação cria uma entrada no registo de auditoria e envia notificações por e-mail aos utilizadores afetados.
Os membros individuais têm agora acesso a uma nova vista em «Definições > Credenciais», que apresenta todas as credenciais associadas à sua conta, tanto as autorizadas por SSO como as pessoais. A partir daí, basta uma única ação para remover o acesso de todas essas credenciais aos recursos empresariais protegidos por SSO, num único passo, eliminando o processo demorado de percorrer uma lista de tokens, entrada a entrada. Os membros das organizações EMU têm também uma opção separada para eliminar permanentemente todos os seus tokens e chaves SSH.
Antes desta funcionalidade de emergência, era necessário utilizar várias ferramentas diferentes para revogar as credenciais de uma conta. Os PATs detalhados podiam ser revogados a partir do ecrã de tokens da organização. Os tokens clássicos só podiam ser revogados através da revogação da autorização SSO por token, e apenas se o SSO SAML estivesse ativado. A API de revogação de credenciais podia desativar um token, mas apenas se já se dispusesse da cadeia de caracteres do token, o que funciona no caso de um segredo divulgado, mas não no caso de uma conta comprometida (isto é apenas uma breve abordagem das complexidades, mas vamos ficar por aqui). A questão é que isto tornava bastante complicada a tentativa de coordenar as alterações de credenciais.
Nota: Os tokens do GitHub Actions não são abrangidos neste contexto, uma vez que são gerados por tarefa e expiram quando a tarefa termina, pelo que não há nada que possa ser revogado. A forma de limitar os danos durante um incidente é desativar o Actions no repositório.
Porquê agora?
Os recentes ataques de malware têm afetado diretamente a Microsoft.
A 19 de maio, os atacantes utilizaram credenciais roubadas anteriormente para enviar três versões maliciosas do software da Microsoft durabletask pacote para o PyPI, no âmbito da campanha do worm Miasma. A Microsoft retirou os pacotes em poucas horas. No entanto, a 5 de junho, a mesma conta enviou um commit malicioso para o repositório GitHub `Azure/durabletask`, disseminando novamente o worm. O GitHub respondeu desativando 73 repositórios em quatro das organizações da Microsoft no GitHub. Isto incluiu as ferramentas do Azure Functions, através das quais muitas equipas efetuam as suas implementações, interrompendo os pipelines de CI/CD para além da Microsoft. Os investigadores apontam algumas explicações possíveis para a repetição do incidente, mas a principal é que as credenciais de maio nunca foram totalmente substituídas. Uma empresa de monitorização descobriu posteriormente que as credenciais da conta no GitHub constavam de registos de programas de roubo de informações que remontavam a abril. Seja qual for o mecanismo exato, a mesma conta foi utilizada em ambos os ataques.
Mas isto não é novidade, e o problema já se manifestou várias vezes este ano. No final de fevereiro de 2026, um programa malicioso O bot de IA aproveitou-se de uma configuração incorreta pull_request_target Fluxo de trabalho do GitHub Actions no repositório Trivy, o que permitiu ao atacante roubar um PAT com acesso de escrita a mais de 33 fluxos de trabalho na organização Aqua Security . Aqua Security a violação e procedeu à rotação das credenciais. No entanto, infelizmente, a rotação não foi concluída e nem todas as credenciais foram revogadas simultaneamente.
A 19 de março, os atacantes utilizaram credenciais que tinham sobrevivido à rotação incompleta para forçar a submissão de 75 das 76 etiquetas de versão notrivy a commits maliciosos. A carga maliciosa era executada antes da Trivy real Trivy em cada pipeline, pelo que todos os fluxos de trabalho pareciam concluir-se normalmente. Os pipelines de CI/CD que executavam Trivy recolher credenciais dos seus próprios executores, tais como chaves SSH, credenciais de nuvem, tokens do Kubernetes e PATs do GitHub.
Quatro dias depois, as credenciais roubadas desses pipelines foram utilizadas para contaminar as GitHub Actions Checkmarx com uma carga maliciosa idêntica destinada ao roubo de dados. Checkmarx que a atividade do autor da ameaça persistiu no seu ambiente até 22 de abril, tendo os dados exfiltrados sido publicados na dark web a 25 de abril.
Toda esta Checkmarx , Trivy Checkmarx , tem origem numa rotação incompleta. Se Aqua Security conseguido bloquear instantaneamente todas as credenciais da conta de serviço comprometida após a violação de fevereiro, o ataque teria terminado aí.
Rotação atómica... o quê?
A rotação atómica consiste na substituição de uma credencial através de uma única operação do tipo «tudo ou nada», pelo que não há nenhum momento em que as credenciais novas e antigas funcionem em simultâneo. O objetivo é evitar qualquer tempo de inatividade no sistema. Em teoria, isto é fantástico. Num sistema distribuído, porém, não é assim que as coisas funcionam. A coordenação necessária é simplesmente demasiado complexa. À escala de uma organização como o GitHub, a rotação atómica não faz sentido.
Assim, a rotação efetiva opta por um de dois caminhos, ambos imperfeitos. A rotação de rotina mantém ambas as credenciais válidas durante um período, para que nada deixe de funcionar, o que é aceitável quando não há problemas, mas deixa a credencial antiga ativa. A resposta a incidentes faz o oposto, desativando a credencial antiga instantaneamente e aceitando que haja falhas até que se reemita uma nova credencial.
Um botão de emergência permite-lhe fazer a única coisa que é realmente «atómica», que consiste simplesmente em eliminar todas as credenciais abrangidas de uma só vez. Claro que isso interrompe o CI/CD. Mas expulsar um invasor da sua infraestrutura é muito mais importante e vale bem a pena algumas horas ou dias de compilações interrompidas.
Até agora, cortar todas as credenciais de uma só vez era simplesmente difícil de concretizar. Este novo corte com uma única ação é o que torna a operação exequível sob pressão e, embora a rotação atómica completa ainda seja bastante difícil de alcançar, isto aproxima-nos do mundo ideal.
O que fazer
Na sua organização do GitHub, certifique-se de que a permissão «Gerir credenciais empresariais» está atribuída a alguém que possa agir de imediato, e faça-o antes de ocorrer um incidente. Consulte agora «Definições > Credenciais» para compreender o que está abrangido.
Além disso, enquanto estiver a atualizar as suas definições de segurança, fixe as suas GitHub Actions aos SHAs completos dos commits, em vez de às etiquetas de versão. As etiquetas podem ser submetidas à força para apontar para código totalmente diferente, o que constitui a técnica central por trás do Trivy . Um SHA de commit fixado não pode ser alterado.
Aikido monitoriza as suas aplicações em tempo real para detetar pacotes comprometidos. Quando algo no seu pipeline é comprometido, recebe um alerta antes de o programa de recolha de credenciais ser executado. Esta funcionalidade é suportada pelo Aikido , que analisa as novas versões dos pacotes assim que estas são disponibilizadas.
Obrigado por todas as atualizações, Microsoft. Continuem assim, por favor. 🙏
