CVE-2010-2568

Falha no Windows Shell que executa código arbitrário só de exibir o ícone de um atalho .LNK ou .PIF malicioso — sem precisar clicar nele. Foi o vetor usado pelo Stuxnet para atingir estações de engenharia com Siemens WinCC/SCADA em 2010, propagando-se via pendrive USB e compartilhamentos de rede. Importa porque a superfície de exploração é ampla (basta o Explorer renderizar a pasta) e afeta praticamente toda a base instalada de Windows da época, de XP a Windows 7/Server 2008 R2.

O Windows Shell obtém dinamicamente o ícone de um atalho consultando o objeto referenciado — inclusive itens do Painel de Controle, que são instanciados via CLSID para fornecer ícones dinâmicos. O Shell não valida corretamente essa referência: um arquivo .LNK pode apontar para uma DLL controlada pelo atacante (local, em compartilhamento de rede, WebDAV, CD-ROM ou USB), e o simples processo de resolver o ícone para exibição no Explorer carrega e executa essa DLL no contexto do usuário que está navegando na pasta.

O ponto crítico, confirmado por pesquisadores (ISC/SANS): o .LNK usado nos ataques reais era um arquivo de atalho legítimo do ponto de vista de formato — não há overflow nem corrupção de memória. A falha está na lógica de validação de que referência de ícone é segura para carregar, não na parsing do próprio arquivo LNK. Os LNKs maliciosos observados tinham os campos CreationTime, AccessTime e WriteTime zerados, um artefato de terem sido criados manualmente/programaticamente em vez de pelo Explorer.

O gatilho é a exibição do ícone, que ocorre automaticamente quando o Explorer lista o conteúdo de uma pasta — não exige duplo clique no atalho. Isso vale para qualquer origem: mídia removível (USB), compartilhamento SMB, ou, combinado com um recurso WebDAV, uma página aberta no Internet Explorer, cenário em que nenhuma interação além de visualizar a página é necessária.

Vetores documentados: (1) USB com AutoRun/AutoPlay habilitado, abrindo o Explorer automaticamente na unidade e disparando a resolução de ícone; (2) navegação a um compartilhamento de rede (SMB) contendo o LNK malicioso — a vítima só precisa abrir a pasta; (3) IE + WebDAV, onde visualizar uma página é suficiente, sem qualquer clique adicional. Em todos os casos não é necessária autenticação prévia no sistema-alvo além do acesso de leitura/listagem ao local onde o LNK está.

A exploração foi observada in the wild antes da correção, associada a malware (posteriormente identificado como Stuxnet) que usava esta falha como um dos mecanismos de propagação lateral para atingir sistemas WinCC SCADA (CVE-2010-2772). A CVE está no catálogo KEV da CISA, confirmando exploração ativa, e há módulo Metasploit e PoC pública, o que reduz bastante a barreira técnica para reprodução após a divulgação.

O resultado da exploração é execução de código com os privilégios do usuário que navegou até o LNK — não é elevação de privilégio por si só, mas em ambientes onde administradores acessam compartilhamentos ou pendrives com privilégios elevados, o impacto equivale a comprometimento total da máquina.

Correção definitiva: aplicar a atualização do MS10-046 (KB2286198), publicada em 02/08/2010, disponível para todas as versões afetadas listadas pela Microsoft. Não há como corrigir isso via configuração — a correção altera a validação de referências de ícone no Shell.

Se o patch não puder ser aplicado imediatamente, a Microsoft descreveu workarounds parciais, cada um com custo real: (a) remover o valor da chave de registro HKEY_CLASSES_ROOT\lnkfile\shellex\IconHandler e HKEY_CLASSES_ROOT\piffile\shellex\IconHandler, que desativa a exibição de ícones para atalhos — bloqueia o vetor de exploração, mas atalhos passam a mostrar ícone genérico; (b) desabilitar o serviço WebClient, o que neutraliza o vetor via WebDAV/IE mas quebra qualquer uso legítimo de WebDAV; (c) desabilitar AutoRun (KB967715), que reduz o vetor de USB mas não elimina o risco, já que a exploração dispara ao simplesmente navegar até a pasta com o Explorer, autorun ou não; (d) bloquear tráfego SMB de saída (portas 139/445 tcp/udp) no perímetro, mitigando o vetor de compartilhamento remoto sem remover a vulnerabilidade local.

Mito a descartar: desabilitar AutoRun sozinho NÃO mitiga a falha — ele só impede o disparo automático ao inserir o USB, mas o usuário abrindo a pasta manualmente no Explorer ainda é suficiente para acionar o bug. Da mesma forma, uso de conta com privilégios reduzidos limita o impacto, mas não impede a execução de código.

Indicadores em host: arquivos .LNK/.PIF fora do padrão gerado pelo Explorer, notadamente com os campos CreationTime, AccessTime e WriteTime zerados (padrão observado nas amostras reais analisadas pela comunidade ISC/SANS); atalhos referenciando DLLs em caminhos incomuns (mídia removível, compartilhamentos de rede) via CLSID de itens de Painel de Controle. Em rede: tráfego SMB anômalo de escrita/leitura em pastas raiz de compartilhamentos, ou requisições WebDAV/IE para recursos externos incomuns que resultem em carregamento de DLL.

Não há assinatura de exploração de rede confiável e única, porque o LNK malicioso é estruturalmente um arquivo de atalho válido — detecção depende de heurística de antivírus/EDR sobre o conteúdo do LNK e sobre carregamento de DLL a partir de mídia removível ou compartilhamento, não de um padrão de payload fixo.