Resumo

  • O certificado forjado do Flame encadeava até uma raiz da Microsoft sem que a chave privada dessa raiz tivesse sido extraída. Campos previsíveis na emissão de licenças e uma colisão MD5 de prefixos escolhidos permitiram que a assinatura feita sobre um certificado legítimo também validasse outro, sem a extensão crítica que impediria seu uso em versões modernas do Windows.
  • A resposta teve de retirar uma capacidade inteira, não apenas bloquear um arquivo. A Microsoft tornou não confiável toda a hierarquia antiga de licenciamento, separou a substituta das raízes aceitas por clientes comuns, removeu assinatura de código, restringiu o novo caminho ao licenciamento e acelerou a distribuição do estado de desconfiança.

Uma cadeia válida respondeu à pergunta errada

Em junho de 2012, alguns componentes associados ao Flame apresentavam uma assinatura que o Windows conseguia conduzir até uma autoridade-raiz da Microsoft. O fato parecia responder a uma pergunta simples: “isto veio da Microsoft?”. Na realidade, a verificação havia combinado várias perguntas distintas e devolvido uma resposta ampla demais.

Uma assinatura prova que determinada chave assinou determinado resumo. A cadeia comprova que o cliente aceita uma sequência de delegações. Nenhuma dessas afirmações, isoladamente, decide se uma infraestrutura criada para licenças de Remote Desktop deve autorizar código ou uma atualização de sistema. Esse último poder nasce da interseção entre política de emissão, usos de chave, extensões, regras do aplicativo e estado local de confiança.

O Security Advisory 2718704 informou que certificados não autorizados derivados de uma autoridade da Microsoft estavam sendo usados em ataques ativos. A investigação apontou para o Terminal Server Licensing Service. Esse serviço tratava uma função comercial limitada, mas assinava por um algoritmo antigo e fazia parte de uma hierarquia que podia produzir certificados com capacidade de assinatura de código.

O defeito organizacional não era simplesmente a presença de MD5. Um fluxo acessível para licenciamento conseguia alcançar uma raiz cuja reputação era interpretada por componentes muito mais importantes. A proximidade dentro da mesma empresa havia sido convertida em equivalência técnica de autoridade.

Uma raiz, portanto, não deve ser inventariada apenas como “confiável”. É preciso listar as decisões que cada cadeia abaixo dela pode provocar: executar código, autenticar servidor, emitir identidade, ativar produto ou aprovar atualização. Se um emissor de baixo risco consegue acionar uma decisão de alto risco, o grafo de confiança contém uma promoção de privilégio.

Quando a emissão previsível vira um oráculo de assinatura

O pedido de certificado de licenciamento não exigia acesso à PKI interna da Microsoft. A assinatura era md5RSA; os períodos de validade eram conhecidos; e os números de série podiam ser previstos com alta probabilidade. Essas características permitiram preparar a entrada antes que a autoridade legítima a assinasse.

Numa colisão de prefixos escolhidos, o atacante constrói dois inícios diferentes. Um descreve o objeto aparentemente legítimo que será submetido ao emissor. O outro descreve o certificado que o atacante pretende usar. Sufixos calculados fazem os dois objetos completos produzirem o mesmo resumo MD5. A autoridade assina o resumo da primeira versão; como o resumo coincide, a assinatura também verifica sobre a segunda.

Isso não equivale a editar livremente um certificado existente. Tampouco equivale a descobrir a chave privada. A operação depende de influenciar a estrutura antes da emissão, prever campos suficientes e conseguir que uma autoridade real faça a assinatura. O serviço de licenciamento fornecia exatamente essa operação privilegiada.

O inventário tradicional separaria esses elementos: algoritmo numa planilha, portal de inscrição em outra, modelo de certificado num repositório e raiz em um cofre. O Flame demonstrou que o risco reside no produto entre eles. Um algoritmo vulnerável se torna operacional quando o solicitante controla parte do texto; a previsibilidade permite o cálculo antecipado; a raiz ampla transforma o resultado em uma credencial valiosa.

Qualquer quebra nessa composição teria alterado o ataque: um hash resistente a colisões, campos imprevisíveis, um emissor fora das raízes aceitas pelos clientes ou uma limitação de propósito realmente imposta. Segurança de PKI não é a soma de controles presentes; é a capacidade que permanece quando eles são combinados.

A colisão não recuperou a chave da Microsoft

Marc Stevens, do CWI, concluiu que o Flame utilizara uma variante até então desconhecida de ataque de colisão com prefixos escolhidos. Não era apenas a execução da construção pública de 2009 que ele inicialmente suspeitara, embora aquela pesquisa já tivesse mostrado que dois certificados X.509 distintos podiam ser completados para compartilhar um resumo MD5.

A distinção importa. As fontes não sustentam que uma chave-raiz ou intermediária da Microsoft tenha sido extraída. A autoridade legítima continuou protegendo e usando sua chave. O atacante quebrou a unicidade semântica da assinatura: uma operação destinada a aprovar um objeto passou a valer para dois objetos com poderes diferentes.

Também seria errado minimizar o caso porque a chave não saiu do dispositivo. Custódia de chave é somente uma fronteira. Quando uma CA assina dados influenciáveis por um adversário usando uma função sem resistência adequada a colisões, a autoridade pode escapar sem que o segredo escape.

O RFC 6151 já afirmava, em 2011, que MD5 não era aceitável onde a resistência a colisões fosse necessária, inclusive em assinaturas digitais. O documento também separava esse problema de usos como HMAC-MD5. Logo, um alerta genérico para a palavra “MD5” é pouco útil. A pergunta operacional é: quem molda a mensagem, qual propriedade criptográfica é exigida e que autoridade o objeto herda após uma colisão?

A extensão crítica era uma instrução de recusa

Um certificado comum da infraestrutura de licenciamento continha pontos de distribuição de CRL, acesso à informação da autoridade e uma extensão crítica Microsoft Hydra. O certificado observado no Flame não apresentava essas extensões da forma esperada.

“Crítica” não é uma classificação editorial. No X.509, é uma ordem para a implementação dependente: se ela não compreender a extensão, deve rejeitar o certificado. O RFC 5280 também descreve como Key Usage e Extended Key Usage limitam conjuntamente os propósitos quando ambos estão presentes.

No Windows Vista e em versões posteriores, o tratamento da extensão Hydra impedia que o certificado normal de licenciamento servisse ao propósito desejado pelo atacante. Segundo a análise da Microsoft, a colisão foi necessária para produzir uma versão alternativa sem a restrição crítica, preservando ao mesmo tempo o resumo assinado. Em sistemas anteriores ao Vista, a Microsoft afirmou que o ataque poderia funcionar sem a colisão. Essa diferença pertence à validação de gerações específicas do Windows e não deve ser generalizada para toda biblioteca X.509.

Uma extensão escrita no modelo não é, por si, um controle. É preciso provar que ela está dentro da parte assinada, não pode ser omitida por variantes de emissão, é marcada como crítica quando necessário e causa recusa consistente em todos os clientes relevantes. O Flame não convenceu um cliente moderno a ignorar a regra; apresentou um objeto no qual a regra havia desaparecido.

O caso oferece uma métrica melhor para testes: não perguntar apenas se o certificado normal passa, mas se cada versão reduzida, desconhecida ou malformada falha. A prova de uma restrição está no comportamento de recusa, não na intenção do modelo.

Uma assinatura ainda precisava de uma posição de entrega

A Microsoft explicou que falsificar o Windows Update exigia mais do que o certificado não autorizado. O adversário também precisava ocupar uma posição de intermediário e entregar o pacote assinado ao mecanismo de atualização. As fontes não descrevem uma tomada dos servidores centrais do Windows Update.

Três capacidades limitadas se encontraram. A construção do certificado criou uma origem aparentemente aceitável. A posição na rede permitiu substituir uma resposta legítima. A política do agente de atualização decidiu se uma assinatura sob a ampla raiz corporativa bastava para tratar o pacote como atualização.

Essa decomposição evita duas conclusões falsas. A primeira é que revogar o certificado resolveria qualquer forma de entrega hostil. A segunda é que proteger o canal seria suficiente enquanto uma credencial de código indevida continuasse aceita. Defesa exige separar identidade do assinante, autorização para um produto e integridade do transporte.

Em redes empresariais, proxies, caches, WSUS, SCCM, inspeção TLS e resolução interna multiplicam os pontos de substituição. Eles não são automaticamente a causa do incidente, mas fazem parte do modelo de capacidade: quem pode colocar um objeto diante do verificador e sob quais credenciais esse objeto será executado?

A correção retirou uma hierarquia inteira

Na resposta emergencial, a Microsoft colocou três intermediárias na loja de certificados não confiáveis: duas Microsoft Enforced Licensing Intermediate PCA e uma Microsoft Enforced Licensing Registration Authority CA (SHA1). Em seguida, invalidou toda a hierarquia de CA de licenciamento, presente e passada, para proteger rapidamente o maior número de clientes e limitar cópias do método.

Era uma decisão mais ampla que revogar o artefato observado. Se o emissor, seus modelos e seu histórico não podiam ser delimitados com certeza suficiente, preservar certificados irmãos reduziria a interrupção ao custo de manter capacidade desconhecida. A desconfiança da hierarquia escolheu remover a classe de autoridade.

A arquitetura substituta foi explicitamente menor. Ela passou a usar uma raiz autônoma que clientes Windows comuns não confiavam, deixou de emitir certificados de assinatura de código e adicionou um Extended Key Usage não usado para código, dedicado ao licenciamento de Terminal Server. A função comercial permaneceu, mas deixou de herdar o poder público da raiz corporativa.

A Microsoft também fortaleceu o Windows Update e introduziu um atualizador automático para a Disallowed Certificate Trust List. Isso reduziu a dependência de uma atualização manual separada sempre que um certificado precisasse ser rapidamente rejeitado. A recusa tornou-se uma capacidade distribuível, não apenas uma decisão central.

Retirar autoridade tem custo operacional

As licenças de acesso de cliente já instaladas não foram invalidadas. Ainda assim, administradores que precisassem instalar um novo pacote de CALs, configurar ou reativar um servidor de licenças tinham de reativá-lo porque os certificados do Product Activation Clearinghouse haviam mudado.

Esse detalhe transforma a resposta em uma lição de continuidade. Um vínculo de confiança amplo pode parecer conveniente enquanto funciona; sua remoção revela dependências que não estavam precificadas. Se a organização não conhece quais operações legítimas dependem de uma hierarquia, hesitará justamente quando precisar encerrá-la.

O plano de saída deve existir antes do incidente. Deve incluir inventário de clientes isolados, mecanismo de desconfiança, substituição de raiz, reativação, comunicação administrativa e prova de que a nova cadeia não reintroduz assinatura de código. A agilidade de revogar é uma propriedade arquitetural, não uma improvisação da equipe de resposta.

No princípio de primazia do código em execução formulado por Heng Lu, o estado que importa é o que os clientes efetivamente aceitam. Uma política anunciada não remove uma cadeia ainda confiável, e uma lista distribuída não protege um equipamento que não a consumiu. A soberania prática sobre a confiança reside na capacidade de alterar esse estado em toda a população relevante.

Limites da evidência

As fontes oficiais confirmam abuso ativo, a cadeia forjada e a resposta técnica, mas não oferecem uma contagem completa de vítimas ou de todas as implantações do Flame. Também não identificam, nos materiais usados aqui, o Estado, a organização ou a pessoa responsável; atribuição não faz parte desta análise.

A colisão não prova recuperação de chave nem alteração arbitrária de qualquer certificado já emitido. A distinção entre sistemas anteriores e posteriores ao Vista é específica do comportamento relatado pela Microsoft. A falsificação de atualização exigia posição de entrega e não deve ser recontada como comprometimento do serviço central.

A utilização de SHA-1 na nova hierarquia é um fato histórico; a depreciação posterior de SHA-1 não deve ser confundida retroativamente com a colisão MD5 de 2012. Os RFCs explicam propriedades gerais, não a cronologia do incidente. Os textos de Heng Lu são uma lente analítica declarada, não fonte probatória do caso.

Fontes