WinVerifyTrust Signature Validation Vulnerability

A CVE-2013-3900 descreve uma falha na função WinVerifyTrust do Windows que permite anexar dados arbitrários a um arquivo executável (PE) validamente assinado sem invalidar a assinatura Authenticode. Isso deixa binários maliciosos com payload extra embutido passando por 'assinado e confiável', o que quebra controles que decidem confiança com base em assinatura digital. Não é uma RCE remota clássica: o impacto real é bypass de verificação de integridade/confiança, e ganhou relevância nova em 2022 quando foi usada ativamente em campanhas de malware, entrando no catálogo KEV da CISA quase 9 anos depois da publicação original.

O Authenticode assina apenas partes específicas de um arquivo PE conforme a especificação da Microsoft — cabeçalho, seções de código e recursos, mas não necessariamente o arquivo completo. A WinVerifyTrust (wintrust.dll), ao validar a assinatura, verifica o hash das regiões previstas pela especificação, mas historicamente não rejeitava dados extras anexados após o bloco de assinatura (padding/appended data). O CVE está catalogado sob CWE-20 (Improper Input Validation) pela CISA, refletindo que a verificação não trata corretamente entradas fora do formato esperado.

O atacante não precisa de acesso remoto à rede; precisa apenas conseguir modificar um arquivo PE já assinado — de qualquer editor confiável — anexando bytes extras (script, payload, dados de outro formato de arquivo) após a área coberta pela assinatura, e depois fazer a vítima executar ou instalar esse arquivo modificado. Como a assinatura permanece 'válida' aos olhos da WinVerifyTrust padrão, controles de segurança que confiam em binários assinados (allowlisting por assinatura, alguns AV/EDR) tratam o arquivo como legítimo, apesar do conteúdo malicioso anexado. O vetor CVSS (AV:L/PR:N/UI:R) reflete exatamente isso: execução local, sem privilégio prévio, mas com interação do usuário para rodar o arquivo trojanizado.

A Microsoft não corrigiu o comportamento por padrão nem planeja fazê-lo: a verificação estrita é opt-in via chave de registro EnableCertPaddingCheck, disponível desde o boletim original (dezembro de 2013) e presente em todas as versões atualmente suportadas de Windows 10 e Windows 11 sem necessidade de atualização adicional — só é preciso configurar a chave. A configuração exata está descrita no Security Advisory 2915720 da Microsoft; ative-a testando previamente, pois pode quebrar softwares legítimos que dependem de dados anexados a arquivos assinados (um custo real de compatibilidade, motivo pelo qual nunca se tornou padrão). Aplicar apenas as atualizações do MS13-098 de 2013 não resolve o problema de fundo — aquele boletim corrigiu apenas parte do comportamento; a mitigação completa depende da chave de registro, que continua desativada por padrão em toda instalação nova.

Não há assinatura de rede ou log padrão que indique exploração, já que o vetor é local/execução de arquivo e a evasão ocorre no nível de verificação de confiança, não de tráfego. Um indício técnico é comparar o tamanho do arquivo assinado com a região efetivamente coberta pela assinatura digital (ferramentas como sigcheck ou análise de PE que expõem o offset de fim de assinatura vs. tamanho real do arquivo); arquivos com dados anexados após o certificado, mas ainda reportando assinatura 'válida', são o padrão a procurar. A ausência da chave EnableCertPaddingCheck no registro indica que o host está com a verificação padrão (frouxa) ativa.