Uma extensão envenenada do VS Code roubou 3.800 repositórios internos do GitHub

O GitHub investiga um acesso não autorizado aos seus repositórios internos e confirmou que um atacante conseguiu exfiltrar dados de cerca de 3.800 deles. A intrusão chegou por meio de uma extensão envenenada do Visual Studio Code instalada por um funcionário, dando ao atacante acesso àquela máquina e, dali, ao código interno que deveria viver atrás dos muros da própria companhia.

A fronteira que o GitHub aponta, entre os repositórios internos e a plataforma voltada ao cliente, é a única coisa entre um incidente contido e uma emergência global de cadeia de suprimentos. O GitHub hospeda cerca de 100 milhões de desenvolvedores e uma parte significativa do código aberto sobre o qual a internet moderna funciona. Quando a empresa fala em “interno”, refere-se ao código da própria plataforma, às suas ferramentas, à sua configuração operacional, ao material com que o GitHub é construído e operado. As organizações de clientes, as empresas e os repositórios públicos e privados que esses clientes guardam no GitHub estão, segundo a própria empresa, fora do raio de impacto desta intrusão.

Essa distinção está fazendo bastante trabalho no comunicado publicado pela empresa na sua conta oficial do X. “Embora atualmente não tenhamos evidência de impacto nas informações dos clientes armazenadas fora dos repositórios internos do GitHub”, diz o texto, “estamos monitorando de perto nossa infraestrutura por sinais de atividade subsequente”. A redação é precisa, e a precisão num aviso de violação costuma significar que a investigação ainda está em movimento. “Sem evidência de impacto” não é o mesmo que “sem impacto”. Incidentes em grandes plataformas têm o costume de crescer à medida que a perícia alcança a atividade do atacante, e a linha entre sistemas internos e voltados ao cliente raramente é uma parede física limpa. É um conjunto de controles de acesso, credenciais e contas de serviço que precisa ser pensado um a um.

Você também pode gostarUma varredura de 380 mil apps feitas com IA encontrou milhares sem nenhum tipo de autenticação

O mecanismo é a parte desta história que deveria preocupar qualquer desenvolvedor. O Visual Studio Code é o editor de código dominante do planeta, presente em quase toda grande organização de engenharia. Sua loja de extensões roda sobre confiança comunitária: qualquer pessoa pode publicar, e a maioria dos engenheiros instala plug-ins com a mesma leveza com que adiciona favoritos ao navegador. Uma extensão envenenada distribuída por esse canal e executada na máquina de um desenvolvedor dá ao atacante acesso a tudo que aquela sessão consegue alcançar: repositórios, tokens, registros de pacotes, serviços internos. O nome específico da extensão usada neste caso ainda não foi divulgado, mas o padrão não é novo. O Nx Console, uma extensão popular de ferramentas para desenvolvedores, sofreu um comprometimento parecido.

O grupo que se chama TeamPCP assumiu a intrusão e oferece o conjunto de dados à venda em fóruns clandestinos com piso de cinquenta mil dólares. O enquadramento do grupo, “isto não é um resgate”, já é em si um sinal. Eles não estão tentando extorquir o GitHub diretamente. Estão tratando código-fonte interno roubado como qualquer outro criminoso trata dumps de cartão de crédito: como mercadoria com compradores. Quem ficar com aquele arquivo de 3.800 repositórios vai pentear o material atrás de credenciais embutidas, segredos cravados em código, detalhes úteis para atacar a própria infraestrutura do GitHub e qualquer coisa que sirva para comprometer alvos a jusante. O mesmo grupo é apontado como ligado ao worm Mini Shai-Hulud que atingiu o pacote durabletask no PyPI, o que sublinha o fundo real desta história: ataques à cadeia de suprimentos do desenvolvimento saíram do cenário teórico e viraram ofício operacional.

A resposta de contenção, na descrição da própria GitHub, foi rápida. A máquina comprometida foi isolada. A extensão maliciosa foi removida. A empresa diz ter rotacionado segredos críticos, priorizando as credenciais de maior impacto, e que vai notificar clientes afetados pelos seus canais de resposta a incidentes se a investigação se ampliar. A subsidiária da Microsoft não identificou o funcionário do GitHub cuja máquina foi comprometida, não nomeou a extensão e não precisou por quanto tempo o atacante manteve acesso antes da detecção. Esses detalhes costumam aparecer no relatório pós-incidente mais longo, que chega semanas depois do aviso inicial.

Para o resto do setor, a lição prática é mais simples do que o invólucro de inteligência de ameaças sugere. Toda organização de engenharia está a uma instalação descuidada de extensão do mesmo incidente. Qualquer um que já tenha instalado uma extensão do VS Code recomendada num tópico de fórum correu o mesmo risco que caiu sobre um funcionário do GitHub. As defesas que funcionam são conhecidas e aplicadas de forma irregular: restringir a instalação de extensões a uma lista permitida, isolar as máquinas dos desenvolvedores das credenciais de produção, rotacionar segredos em cadência curta. Esta violação vai empurrá-las para o topo da lista de prioridades em empresas que as adiavam.

O GitHub não deu prazo para um post-mortem público completo. Investigações desse tamanho em plataformas dessa escala costumam levar várias semanas para mostrar todo o alcance, e as atualizações chegarão pelos canais oficiais da empresa conforme forem produzidas. O próximo ponto a observar é se o arquivo de 3.800 repositórios realmente aparece à venda e a que preço o piso se move depois que o mercado clandestino tiver alguns dias para examinar o índice.

Mais como este

A agência federal de cibersegurança dos EUA deixou as chaves da AWS no GitHub

Uma IA escreveu um zero-day funcional e o Google interceptou antes do ataque

Uma falha de login deixou 70 milhões de sites cPanel abertos a qualquer um