Skip to content
KitploitKITPLOIT
FerramentasExploitsBlog
Log in
Enviar
FerramentasExploitsBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

FeedsContatoPrivacidade© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
CVE-2026-31431-detection-defense — Orientação de pesquisa e detecção para CVE-2026-31431, uma bypass baseada em io_uring do monitoramento de chamadas de sistema. Fornece regras de detecção para Tetragon, Falco e Wazuh, além de estratégias de endurecimento. | Kitploit
Ferramentas/GitHubGitHub/detect-defenselab/cve-2026-31431-detection-defense
Ferramentas DefensivasSegurança de ContêineresAnálise de VulnerabilidadesExploraçãoDetecção de Intrusão
GitHubdetect-defenselab/cve-2026-31431-detection-defense

CVE-2026-31431-detection-defense

Orientação de pesquisa e detecção para CVE-2026-31431, uma bypass baseada em io_uring do monitoramento de chamadas de sistema. Fornece regras de detecção para Tetragon, Falco e Wazuh, além de estratégias de endurecimento.

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Ver Repositório
29há 5 mesesAinda não revisado
Compartilhar

CVE-2026-31431: Detecção e Defesa Contra Bypass do io_uring em Detecções Existentes

Autores: fz0x00, qiwuSEC

Pesquisa

Para o CVE-2026-31431 ("Copy Fail"), demonstramos fraquezas sistemáticas em produtos de segurança mainstream combinando três estratégias de bypass: caminho de I/O assíncrono io_uring, divisão de processos (fork + SCM_RIGHTS) e reutilização de sockets. Através de testes empíricos, provamos que essas técnicas podem evadir praticamente todas as ferramentas de detecção baseadas em syscalls.

Principais Descobertas

1. io_uring Bypassa Praticamente Toda Detecção Baseada em Syscalls

O io_uring submete requisições via buffers de anel em memória compartilhada, contornando os pontos de entrada tradicionais de syscalls. Isso significa que:

  • auditd / Wazuh / Elastic Security Agent e outros produtos dependentes de auditoria de syscalls ficam completamente cegos quando atacantes usam o caminho io_uring — zero eventos, zero alertas
  • As threads de trabalho do io_uring (iou-wrk-XXXXX) executam operações dentro do kernel sem acionar audit_syscall_entry()
  • Políticas Seccomp que apenas bloqueiam socket(AF_ALG) podem ser bypassadas via IORING_OP_SOCKET — o seccomp só verifica na entrada do syscall, e as operações do io_uring não passam por essa entrada

2. Divisão de Processos Quebra a Correlação em Nível de PID

Ao usar fork + SCM_RIGHTS (passagem de fd via socket de domínio Unix), a criação de sockets e as operações de splice podem ser colocadas em processos diferentes:

  • A correlação same_field(audit.pid) do Wazuh quebra — PID do socket ≠ PID do splice, a regra CRITICAL não dispara
  • O rastreamento de fd em nível de processo do libsinsp do Falco é completamente quebrado em cenários SCM_RIGHTS

3. Reutilização de Sockets Bypassa Regras de Limite de Contagem

O PoC original cria um novo socket por iteração (produzindo 40+ chamadas socket(AF_ALG)). A reutilização de sockets cria apenas um socket de escuta; o loop chama accept() que não produz novos eventos de socket. Regras baseadas em count >= N são completamente derrotadas.

4. A Combinação de Variantes Mais Difícil de Detectar

caminho io_uring + splice + /etc/passwd + algoritmo authenc + divisão SCM_RIGHTS + reutilização de sockets

Sob essa combinação: ferramentas baseadas em syscalls ficam completamente cegas, a correlação em nível de processo é quebrada, os limites de contagem falham. Apenas a detecção por ponto de convergência com kprobe pode capturar essa combinação.

5. Monitoramento em Nível de LSM Pode Detectar Exploração Perfeitamente

__sock_create(family=38) é um ponto de convergência impossível de bypassar para todos os caminhos (syscall e io_uring) — AF_ALG é a única API de criptografia em espaço de usuário no kernel Linux. Não importa como os atacantes variem sua abordagem, eles precisam criar um socket AF_ALG. Monitorar essa função no nível LSM fornece 100% de recall e não é afetado por nenhuma variante.

Resultados de Testes Específicos por Produto

ProdutoCamada de DetecçãoSyscall TradicionalCaminho io_uringDivisão Multi-ProcessoReutilização de SocketsAvaliação
Tetragon (kprobe)Função do kernel✅✅✅✅Única cobertura de cadeia completa
Falco + plugin krsifexit/fentry✅✅✅✅Precisa de krsi para io_uring; apenas entrada
Falco (modern_ebpf)tracepoint de syscall✅❌✅✅io_uring completamente invisível
auditd / Wazuhauditoria de syscall✅❌❌ PID quebrado⚠️io_uring cego + correlação de PID quebrada
Elastic Security Agentsyscall✅❌⚠️⚠️Igual ao Wazuh; dependente de syscall = cego

Falco Requer o Plugin krsi

O driver nativo modern_ebpf do Falco apenas captura o caminho de syscall. O plugin krsi é necessário — ele usa rastreamento fexit nas saídas das funções do kernel io_socket() e __sys_socket() para cobrir o caminho io_uring para criação de sockets AF_ALG. Regra de fallback recomendada:

- rule: AF_ALG Socket Created
  condition: >
    (evt.type = socket and evt.args contains AF_ALG) or
    (evt.type = krsi_socket and krsi.domain = 38)
  output: >
    AF_ALG socket created (source=%evt.type domain=%evt.arg.domain
    krsi_domain=%krsi.domain proc=%proc.name pid=%proc.pid)
  priority: WARNING
  tags: [cve-2026-31431, crypto, container_escape]

A abordagem de detecção da regra recomendada: cobre simultaneamente eventos socket (caminho de syscall, usando correspondência de string evt.args contains AF_ALG para contornar a limitação de tipo ENUMFLAGS32) e eventos krsi_socket (caminho io_uring, usando comparação de inteiro krsi.domain = 38). Sem limites de contagem (derrotados pela reutilização de sockets), sem dependência de correlação de PID (derrotada pela divisão multi-processo).

Nota: As três camadas de defesa da regra da comunidade ThreatBear são todas bypassáveis — incompatibilidade de tipo ENUMFLAGS32 (evt.arg[0]=38 sempre falso), reutilização de sockets derrota o limite de contagem (count=1 < 40), divisão multi-processo quebra a correlação de PID. Veja Análise de Bypass de Regra.

Wazuh / Elastic Security Agent Não Conseguem Detectar Exploração via io_uring

O Wazuh depende inteiramente dos eventos de auditoria de syscalls do auditd. As operações do io_uring não passam pela entrada de syscall, então o auditd produz zero eventos e todas as 7 regras do Wazuh falham. O mesmo se aplica ao Elastic Security Agent — produtos dependentes de entrada de syscall são estruturalmente cegos ao caminho io_uring. Veja Análise de Limitações do Wazuh.

Demonstração de Bypass

O diretório bypass_demo/ contém descrições conceituais das abordagens de bypass de detecção. O código PoC real é apenas para uso interno e não é distribuído publicamente.

Índice de Documentação

Teoria

DocumentoConteúdo
VULNERABILITY.mdCausa raiz — sobreposição de três mudanças no kernel, cadeia de ataque em 9 etapas, características de escrita no page cache
EXPLOIT_VARIANTS.md6 dimensões de variantes de exploração — caminho de I/O × submissão de dados × arquivo alvo × algoritmo AEAD × divisão de processos × reutilização de sockets
DETECTION_THEORY.mdTeoria de detecção — pontos de convergência vs. divergência, arquitetura de detecção em 4 camadas, correlação temporal multi-sinal

Soluções de Detecção

Baixar ferramenta