5. Proteção SEH: Fortalecendo o Tratamento de Exceções do Windows

Introdução

O Windows implementa o Structured Exception Handling (SEH) como parte de seu mecanismo de tratamento de exceções, permitindo que programas capturem e tratem erros de execução (como acesso inválido à memória, instruções ilegais etc.). Essa arquitetura inclui uma cadeia de registros (exception registration records) na pilha de cada thread, em que existe um ponteiro para o próximo registro (Next) e outro para o manipulador de exceção (Handler).

Mas o que acontece que atores mal intencionados podem explorar vulnerabilidades de estouro de buffer, ou outras corrupções de memória, para sobrescrever registros dessa cadeia de SEH, substituindo o campo Handler de modo que seja executado código arbitrário.

Para mitigar esses ataques, foram introduzidos mecanismos como SafeSEH (que obriga o binário a declarar handlers seguros em uma lista estática) e SEHOP (que verifica, em tempo de execução, se a cadeia de SEH não foi corrompida).

Exemplos de exploração

A seguir está um exemplo de pseudocódigo simplificado para ilustrar como um ataque clássico de SEH overwrite pode funcionar:

// função vulnerável

void vulnerable(char *input) {

    char buffer[256];

    strcpy(buffer, input);  // sem verificação de tamanho

    // __try / __except (Windows)

    __try {

        // operação que pode gerar exceção

    } __except (EXCEPTION_EXECUTE_HANDLER) {

        // handler legítimo

    }

}

• Se input for maior que buffer, o invasor pode sobrescrever o campo Handler no registro de exceção, inserindo um endereço malicioso.
• Quando ocorrer uma exceção, o Windows percorre a cadeia de SEH e chamará o handler especificado — se esse handler for malicioso, o ataque se completa.

Evolução de exploração combinada

Com o tempo, ataques passaram a combinar SEH overwrite com outras técnicas para contornar mitigadores modernos. Essas técnicas já foram explicadas em publicações anteriores. São elas:

• Heap spraying ou preenchimento de heap, para posicionar shellcode em locais previsíveis.
• Return-Oriented Programming (ROP), para evitar restrições como DEP (Data Execution Prevention).
• Em sistemas onde ASLR (Address Space Layout Randomization) está presente, ataques tentam descobrir ou contornar essas aleatorizações para apontar o handler ou saltar para gadgets ROP válidos.

Avaliação das proteções

• SafeSEH: Requer que o binário (ou módulos) declare quais handlers são válidos, na seção /SAFESEH em tempo de link. Porém, só funciona para binários compilados com suporte a essa flag; DLLs ou módulos antigos ou que não possuam essa lista ficam vulneráveis [1].
• SEHOP (Structured Exception Handle Overwrite Protection): uma mitigação dinâmica que, antes de disparar o handler de exceção, verifica se a cadeia SEH parece íntegra, ou seja, se o último handler da cadeia é o handler padrão em ntdll (por exemplo _except_handler4) [2].

Limitações:

1. Em ambientes sem ASLR (Address Space Layout Randomization) ou com módulos não randomizados, muitos ataques continuam possíveis. Por exemplo, um estudo mostrou que em Windows XP ou Server 2003, ou mesmo Vista, certas combinações de SafeSEH + SEHOP + DEP ainda deixavam espaço para exploração.
2. Algumas versões antigas do Windows ou DLLs herdadas não suportam SEHOP, ou têm implementações incompletas.
3. Há trabalhos acadêmicos recentes que identificam vetores de bypass via manipulação indireta de fluxos de exceção ou exploração de “unwinding” (quando a pilha está sendo “desenrolada” durante exceções), como o paradigma CHOP – Catch Handler Oriented Programming [3].

Integração com outros mitigadores

Para proteção real e robusta, é crucial que SEHOP / SafeSEH sejam usados em conjunto com:

• DEP / NX (Data Execution Prevention / No-eXecute bit) — para impedir execução de código em regiões de dados [5].
• ASLR (Address Space Layout Randomization) — para randomização de layout de memória, dificultando prever endereços de handlers ou gadgets [6].
• Refinamentos de compilador / flags de segurança no link (como /GS, /SAFESEH, /DYNAMICBASE, /NXCOMPAT), além de auditoria de uso de DLLs externas (módulos não seguros) [7].

Como o Cortex XSIAM pode auxiliar

O Cortex XSIAM da Palo Alto Networks pode ser uma peça importante para fortalecer a defesa contra ataques que envolvem manipulação de SEH ou exploração de cadeias de exceção de maneira anômala. Aqui estão formas concretas de uso:

• Detecção comportamental: monitoramento de logs de sistema (eventos de falhas de exceção, acesso à manipulação de exceções, tentativas repetidas de exceção em aplicações específicas) pode indicar padrões compatíveis com exploração de SEH overwrite ou comportamentos atípicos de tratamento de exceção.
• Correlacionar eventos: ao coletar dados de endpoint + sistema operacional + execução de DLLs, XSIAM pode identificar processos que carregaram módulos sem SafeSEH ou que têm handlers desconhecidos, ou que invocam exceções em locais suspeitos.
• Playbooks de resposta: automação de resposta quando um alerta indica possível exploração — por exemplo, isolar o endpoint, extrair dump de memória, verificar integridade da cadeia SEH, alertar time de malware / forense.
• Gestão de políticas de exceção: permite configurar perfis de exceção para processos legítimos enquanto fortalece o baseline para todos os demais, reduzindo falso-positivos mas mantendo políticas de segurança rígidas.
• Visibilidade ampliada: como o XSIAM consolida dados de endpoints, rede, nuvem, ele pode capturar mudanças de comportamento em DLLs ou bibliotecas de terceiros, identificar novos módulos sem assinatura conhecida ou com flags de segurança desativadas, o que pode ser pré-requisito para ataques de SEH.

Conclusão

Em resumo, SEH overwrites continuam sendo um vetor relevante de ataque, especialmente em ambientes legados ou mal configurados. As mitigação SafeSEH e SEHOP deram uma melhoria substancial, mas não eliminam todos os riscos.

Para mitigar de forma eficaz, recomenda-se:

1. Habilitar SafeSEH durante compilação sempre que possível;
2. Garantir que SEHOP esteja ativo em sistemas modernos;
3. Combinar com DEP, ASLR e outras proteções de mitigação de controle de fluxo;
4. Usar ferramentas de segurança modernas (como Cortex XSIAM) para monitoramento, correlação e automação de resposta.

Referências

[1] Litchfield, D. (2003). Defeating the Stack Based Buffer Overflow Prevention Mechanism of Microsoft Windows 2003 Server. NGS Software. http://www.ngssoftware.com/papers/defeating-w2k3-stack-protection.pdf

[2] Microsoft. (2009). Preventing the Exploitation of Structured Exception Handler (SEH) Overwrites with SEHOP. Microsoft Security Response Center. https://msrc.microsoft.com/blog/2009/02/preventing-the-exploitation-of-structured-exception-handler-seh-overwrites-with-sehop/

[3] A. Seshadri, D. Korczynski, D. Balzarotti, and G. Pellegrino, “Let Me Unwind That For You: Exceptions to Backward-Edge Protection,” in Proc. Network and Distributed System Security Symposium (NDSS), San Diego, CA, USA, Feb. 2023. [Online]. https://www.ndss-symposium.org/wp-content/uploads/2023-295-paper.pdf

[5] M. Howard, J. Pincus, and J. Wing, “Measuring Relative Attack Surfaces,” in Proc. Workshop on Advanced Developments in Software and Systems Security (WADS), 2003. [Online]. https://www.microsoft.com/en-us/research/publication/measuring-relative-attack-surfaces/

[6] H. Shacham, M. Page, B. Pfaff, E. Goh, N. Modadugu, and D. Boneh, “On the Effectiveness of Address-Space Randomization,” in Proc. 11th ACM Conference on Computer and Communications Security (CCS), Washington, DC, USA, 2004, pp. 298–307. doi: 10.1145/1030083.1030124 – https://dl.acm.org/doi/10.1145/1030083.1030124