Pesquisador publica exploit que rouba tokens GitHub via VS Code e acusa Microsoft de quebrar disclosure responsável

O pesquisador Ammar Askar publicou um exploit funcional para uma falha no VS Code que permite roubar tokens de acesso GitHub com um único clique em link — e afirmou ter ignorado o processo oficial de disclosure da Microsoft em retaliação à forma como a empresa tratou reportes anteriores, em mais um sinal de que a relação entre a fabricante de Redmond e a comunidade de pesquisadores está em ruptura.

O que aconteceu

Na terça-feira passada, Askar publicou em seu blog pessoal e no tracker público de issues do VS Code um proof-of-concept completo para uma vulnerabilidade no editor de código da Microsoft. A falha permite que um atacante, ao induzir a vítima a clicar em um link malicioso, extraia o token de acesso pessoal do GitHub usado pela integração nativa do VS Code com o github.dev — credencial que pode dar acesso amplo a repositórios privados e fluxos de CI/CD vinculados à conta.

O caso vem semanas depois da invasão coordenada pelo grupo TeamPCP, que comprometeu milhares de repositórios internos do GitHub por meio de uma extensão envenenada para o próprio VS Code. O editor virou alvo recorrente para coletar credenciais, tokens e código-fonte diretamente das máquinas de desenvolvedores — um vetor de supply-chain particularmente eficaz porque atinge o ponto exato da cadeia onde segredos circulam em texto claro.

A publicação acontece dias após reação negativa da comunidade a declarações da Microsoft sobre pesquisadores que divulgam falhas sem coordenação. A empresa havia chamado essas práticas de “nunca justificáveis” e ameaçado, por meio da sua Digital Crimes Unit, “continuar abrindo casos” contra autores. A pressão pública obrigou a empresa a recuar e emitir, na semana, uma nota afirmando que “não tem intenção de processar” pesquisadores e que “algumas interações ficaram aquém”.

Detalhes da vulnerabilidade

Askar não recebeu CVE atribuído à falha que reportou anteriormente. Segundo ele, o Microsoft Security Response Center corrigiu silenciosamente um bug que ele havia divulgado em caráter responsável, sem dar crédito e negando publicamente que o problema tivesse impacto de segurança. Esse padrão — fix discreto, ausência de reconhecimento, posicionamento defensivo — foi o motivo declarado para abandonar o canal oficial.

“A comunidade de segurança tem um papel vital em nos ajudar a proteger clientes. Continuamos comprometidos com engajamento de boa-fé e em fornecer experiência respeitosa e profissional para todos os pesquisadores, independentemente de interações passadas”, afirmou a Microsoft em comunicado emitido após a polêmica.

A Microsoft não respondeu, até o fechamento da reportagem original, a perguntas sobre se Askar foi creditado pelo bug, por que nenhum CVE foi atribuído ou quantos usuários do github.dev ficaram expostos antes da correção.

Riscos para a comunidade de desenvolvedores

• Janela de exposição ampliada entre a publicação do exploit e o release do patch oficial — desenvolvedores e organizações que usam github.dev permanecem vulneráveis sem aviso coordenado.
• Roubo de tokens GitHub com escopos amplos, comuns em fluxos de desenvolvimento, abre porta para invasão de repositórios privados, código-fonte proprietário e segredos de pipeline.
• Risco de supply-chain em larga escala: um token comprometido pode ser usado para publicar pacotes maliciosos em registries com a identidade do desenvolvedor legítimo.
• Efeito psicológico nas equipes de segurança, que perdem confiança no processo de disclosure e tendem a replicar o comportamento de full-disclosure, agravando a janela de exposição em outros produtos.

Análise

O caso Askar não é isolado. Outro pesquisador, conhecido como Nightmare Eclipse, publicou nas últimas semanas vários zero-days do Windows sem coordenação prévia, citando queixas semelhantes. Quando dois pesquisadores independentes, em um curto intervalo, abandonam o canal oficial pelo mesmo motivo declarado, deixa-se de ter uma reclamação individual e passa-se a ter um problema sistêmico de relacionamento entre uma das maiores fabricantes de software do mundo e a comunidade de pesquisa que voluntariamente investiga seus produtos.

A virada de tom da Microsoft, da ameaça de processo à promessa de boa-fé em poucos dias, mostra que a empresa entendeu o tamanho do estrago. Mas a desconfiança não se desfaz com um comunicado. A coordinated disclosure depende de capital reputacional acumulado, e esse capital evapora quando pesquisadores percebem que reportes responsáveis viram correções não credenciadas e narrativas públicas que minimizam o que eles encontraram.

Há um custo direto disso para usuários finais: cada exploit publicado sem patch coordenado é uma janela aberta. O VS Code tem dezenas de milhões de usuários ativos, e a base de github.dev é proporcional. Defensores precisam tratar esse tipo de evento como o equivalente operacional a um zero-day em produto de uso massivo — porque, na prática, é exatamente isso.

Recomendações práticas

• Audite imediatamente os tokens de acesso pessoal em sua conta GitHub: revogue tokens com escopos amplos que não estejam em uso ativo e migre fluxos críticos para GitHub Apps com permissões granulares.
• Habilite SSO obrigatório e duplo fator para acesso a repositórios sensíveis; configure expiração curta para tokens persistentes (idealmente 30 dias).
• Monitore o log de auditoria do GitHub para acessos a partir de IPs ou agentes incomuns logo após a divulgação do exploit.
• Considere desabilitar temporariamente a integração github.dev em organizações sensíveis até confirmação do patch e atualização do VS Code.
• Reforce orientação aos desenvolvedores: evitar clicar em links de fontes não verificadas dentro do contexto da sessão autenticada do VS Code.
• Ative alertas de uso de token via webhook para detectar padrões anômalos cedo.

Fonte: The Record