Tecnologia

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

Susan Hill

A GitHub investiga um acesso não autorizado aos seus repositórios internos e confirmou que um atacante conseguiu exfiltrar dados de cerca de 3800 deles. A intrusão chegou através de uma extensão envenenada do Visual Studio Code instalada por um colaborador, dando ao atacante acesso a essa máquina e, a partir dela, ao código interno que devia viver por trás dos muros da própria empresa.

A fronteira que a GitHub aponta, entre repositórios internos e a plataforma virada para o cliente, é a única coisa que separa um incidente contido de uma emergência global de cadeia de fornecimento. A GitHub aloja cerca de 100 milhões de programadores e uma parte significativa do código aberto em que a internet moderna assenta. Quando a empresa fala em “interno”, refere-se ao código da sua própria plataforma, às suas ferramentas, à sua configuração operacional, ao material com que a GitHub se constrói e opera a si mesma. As organizações clientes, as empresas e os repositórios públicos e privados que esses clientes guardam na GitHub ficam, segundo a própria empresa, fora do raio de impacto desta intrusão.

Essa distinção está a fazer bastante trabalho no comunicado publicado pela empresa na sua conta oficial no X. “Embora atualmente não tenhamos evidência de impacto na informação dos clientes guardada fora dos repositórios internos da GitHub”, lê-se, “estamos a monitorizar de perto a nossa infraestrutura para detetar atividade subsequente”. A redação é precisa, e a precisão num aviso de violação costuma significar que a investigação ainda está em curso. “Sem evidência de impacto” não é o mesmo que “sem impacto”. Incidentes em grandes plataformas têm o hábito de crescer à medida que a perícia alcança a atividade do atacante, e a linha entre sistemas internos e virados para o cliente raramente é uma parede física limpa. É um conjunto de controlos de acesso, credenciais e contas de serviço que tem de ser raciocinado um por um.

O mecanismo é a parte desta história que deveria preocupar qualquer programador. O Visual Studio Code é o editor de código dominante no planeta, presente em quase todas as grandes organizações de engenharia. A sua loja de extensões funciona 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 numa máquina de programador dá ao atacante acesso a tudo aquilo que a sessão desse programador consegue alcançar: repositórios, tokens, registos de pacotes, serviços internos. O nome concreto 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 programadores, sofreu um comprometimento semelhante.

O grupo que se autodenomina TeamPCP assumiu a intrusão e oferece o conjunto de dados para venda em fóruns clandestinos com um preço mínimo de cinquenta mil dólares. O enquadramento do grupo, “isto não é um resgate”, é já um sinal. Não estão a tentar extorquir a GitHub diretamente. Estão a tratar código-fonte interno roubado como qualquer outro criminoso trata dumps de cartões de crédito: como mercadoria com compradores. Quem ficar com aquele arquivo de 3800 repositórios vai pentear o material à procura de credenciais embutidas, segredos cravados no código, detalhes úteis para atacar a própria infraestrutura da 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 pano de fundo real desta história: os ataques à cadeia de fornecimento do desenvolvimento deixaram de ser cenário teórico e tornaram-se ofício operacional.

A resposta de contenção, na descrição da própria GitHub, foi rápida. O equipamento comprometido foi isolado. A extensão maliciosa foi retirada. A empresa afirma ter rodado credenciais críticas, dando prioridade às de maior impacto, e que vai notificar clientes afetados através dos seus canais de resposta a incidentes se a investigação se alargar. A subsidiária da Microsoft não identificou o colaborador da GitHub cuja máquina foi comprometida, não nomeou a extensão e não precisou durante quanto tempo o atacante manteve acesso antes da deteção. Esses detalhes aparecem geralmente 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 a embalagem de informações de ameaças faz parecer. Qualquer organização de engenharia está a uma instalação descuidada de extensão do mesmo incidente. Quem instalou uma extensão do VS Code recomendada num tópico de fórum correu o mesmo risco que caiu sobre um colaborador da 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 programadores das credenciais de produção, rodar segredos em cadência curta. Esta violação vai empurrá-las para o topo da lista de prioridades em empresas que as iam adiando.

A GitHub não deu prazo para um post-mortem público completo. Investigações deste tamanho em plataformas desta escala costumam levar várias semanas a expor todo o seu alcance, e as atualizações chegarão pelos canais oficiais da empresa à medida que forem surgindo. O próximo ponto a vigiar é se o arquivo de 3800 repositórios aparece efetivamente à venda, e a que preço se move o piso depois de o mercado clandestino ter alguns dias para examinar o índice.

Discussão

Existem 0 comentários.