CVE-2025-4396 - Kit de Ferramentas para Injeção SQL Cega Baseada em Tempo no WordPress Relevanssi

Visão Geral

Este repositório contém um kit prático de pesquisa e validação para CVE-2025-4396, uma Injeção SQL Cega Baseada em Tempo não autenticada que afeta o plugin Relevanssi do WordPress através do parâmetro cats.

O projeto foi desenvolvido para engajamentos autorizados de Purple Team com o objetivo de:

• validar a explorabilidade de forma controlada,
• demonstrar diferentes níveis de sofisticação de ataque,
• medir a cobertura de detecção do SOC,
• extrair um hash de senha do WordPress de forma realista,
• e automatizar o fluxo de cracking offline após a recuperação do hash.

O repositório inclui:

• um script de extração padrão,
• um script de extração mais rápido por busca binária,
• e um script auxiliar para preparar e quebrar o hash extraído do WordPress 6.8+ com o Hashcat.

Aviso Legal
Este projeto é fornecido apenas para fins educacionais, validação defensiva e testes de segurança autorizados.
Não o utilize contra sistemas que você não possui ou para os quais não tenha permissão explícita por escrito para avaliar.

Ambiente de Teste

• Servidor: Debian 11
• WordPress 6.9.1,
• Plugin Relevanssi 4.24.4 (baixado de https://wordpress.org/plugins/relevanssi/advanced/),
• PoC utilizado a partir do sistema operacional Kali Linux.

Descrição da CVE

CVE-2025-4396 é uma vulnerabilidade de Injeção SQL que afeta a funcionalidade de busca do Relevanssi no WordPress.

No cenário testado, o problema é acessível através do fluxo de busca e, mais especificamente, através do parâmetro cats. O caminho de código vulnerável permite que a entrada controlada pelo atacante influencie a consulta SQL gerada pelo plugin.

Como o endpoint vulnerável é acessível sem autenticação prévia, a falha pode ser explorada por um atacante remoto para realizar injeção SQL não autenticada.

O impacto prático inclui:

• manipulação de consultas no banco de dados,
• Injeção SQL Cega Baseada em Tempo,
• extração de dados sensíveis, como hashes de senhas,
• e, dependendo do ambiente, possível escalada de privilégios através da recuperação de credenciais válidas.

Como a Vulnerabilidade Funciona

Causa Raiz

A vulnerabilidade existe porque a entrada controlada pelo usuário, vinda de um parâmetro relacionado à busca, não é tratada de forma segura antes de ser incorporada em uma consulta SQL.

Na prática, isso significa que um atacante pode injetar expressões SQL na lógica da consulta do sistema e forçar o banco de dados a avaliar condições adicionais.

Por Que É Cega

A vulnerabilidade é explorada em modo cego, o que significa que a aplicação não exibe diretamente erros SQL ou resultados brutos do banco de dados.

Em vez de ler a saída da consulta na página, o atacante faz uma série de perguntas de verdadeiro/falso ao banco de dados e observa um efeito colateral:

• se a condição for verdadeira, o banco de dados pausa por alguns segundos,
• se a condição for falsa, a resposta retorna imediatamente.

Por Que É Baseada em Tempo

A exploração depende de funções SQL como SLEEP() para criar uma diferença mensurável no tempo de resposta do servidor.

Isso permite que um atacante infira dados sem nunca vê-los diretamente.

Por exemplo, o atacante pode fazer perguntas como:

• “O primeiro caractere é igual a $?”
• “O valor ASCII do segundo caractere é maior que 77?”
• “Os primeiros N caracteres correspondem a este padrão?”

Ao repetir esse processo, o atacante pode reconstruir um hash completo caractere por caractere.

Como a Exploração Funciona

Lógica de Extração Padrão

A abordagem padrão percorre um conjunto de caracteres conhecido e testa cada candidato um por um.

Para cada posição no hash alvo:

1. Construir uma condição SQL visando um caractere.
2. Acionar um atraso no servidor apenas se o palpite estiver correto.
3. Medir o tempo de resposta.
4. Reenviar a mesma requisição para reduzir falsos positivos causados por variações de rede.
5. Acrescentar o caractere confirmado ao hash extraído.
6. Avançar para a próxima posição.

Este método é simples e confiável, mas relativamente lento, pois pode exigir muitas requisições por caractere.

Lógica de Extração por Busca Binária

A abordagem mais rápida utiliza busca binária no valor ASCII de cada caractere.

Em vez de perguntar:

• “O caractere é igual a a?”
• “O caractere é igual a b?”
• “O caractere é igual a c?”

ela pergunta:

• “O valor ASCII é maior que 79?”
• “É maior que 55?”
• “É maior que 43?”

Isso divide o espaço de busca pela metade a cada requisição e reduz drasticamente o número de requisições HTTP.

Resultado Prático

O ataque permite que o operador extraia o valor user_pass de wp_users, geralmente para um ID de usuário WordPress escolhido, como:

• 1 para o administrador padrão,
• ou outro ID passado na linha de comando.

Em versões recentes do WordPress, esse valor pode usar o novo pipeline de senhas do WordPress 6.8+, que combina:

• uma etapa de pré-hashing usando HMAC-SHA384,
• codificação Base64,
• e um hash final bcrypt.

Scripts Inclusos

1. CVE_2025_4396.py

Este é o script de extração padrão.

Propósito:

Ele realiza uma Injeção SQL Cega Baseada em Tempo clássica e extrai o hash alvo caractere por caractere usando uma busca linear sobre um charset fixo.

Características Principais:

• simples e fácil de entender,
• confiável em ambientes estáveis,
• lógica de dupla verificação para reduzir falsos positivos,
• útil como base para engenharia de detecção e demonstrações de PoC.

Como Funciona:

Para cada posição do caractere:

• itera sobre um conjunto de caracteres predefinido,
• constrói uma condição SQL correspondente a um único caractere,
• aguarda a resposta do servidor,
• e confirma o acerto com uma segunda requisição.

Requisitos:

• python3
• requests
• urllib3

Instalação:

pip3 install requests urllib3

Uso:

python3 CVE_2025_4396.py -t "https://target.local/?s=test&cats=" -u 1 -s 3 -v

Argumentos:
    -t, --target : URL alvo vulnerável, incluindo o parâmetro injetável
    -u, --userid : ID do usuário WordPress a ser alvo
    -s, --sleep : limite de tempo de espera em segundos
    -v, --verbose : ativa o log de depuração

2. CVE_2025_4396_Stealth.py

Esta é a edição de busca binária.

Propósito:

Realiza o mesmo objetivo de extração que o script padrão, mas substitui a busca linear caractere por caractere por uma busca binária nos valores ASCII.

Características Principais:

• significativamente menos requisições HTTP,
• pegada de rede menor,
• ainda inclui uma etapa de dupla verificação para evitar falsos positivos.

Como Funciona:

Para cada posição:

• Defina um intervalo ASCII imprimível.
• Teste o ponto médio.
• Pergunte se o caractere alvo é maior que esse ponto médio.
• Reduza o intervalo de acordo.
• Continue até que o caractere exato seja identificado.

Requisitos:

• python3
• requests
• urllib3

Instalação:

pip3 install requests urllib3

Uso:

python3 CVE_2025_4396_Stealth.py -t "https://target.local/?s=test&cats=" -u 1 -s 3 -v

Quando Usar:

• o alvo está confirmado como vulnerável,
• a latência é suficientemente estável,
• e o objetivo é reduzir o volume de requisições.

Fluxo de Cracking de Hash Offline

Após a extração do hash de senha do WordPress, o próximo passo é quebrá-lo offline.

Notas sobre Hashing do WordPress 6.8+. No fluxo testado, o valor extraído pode parecer com:

$wp$2y$10$zPA8xGJMvr.kvAAIIYaCreIMnTDpgw/9o8K7.ONBm/KBbNIywQtu.

Para o Hashcat, a porção bcrypt utilizável é:

$2y$10$zPA8xGJMvr.kvAAIIYaCreIMnTDpgw/9o8K7.ONBm/KBbNIywQtu.

No entanto, este bcrypt não é aplicado diretamente à senha bruta. O WordPress primeiro aplica uma etapa de pré-processamento:

• remoção de espaços (trim) estilo PHP na senha candidata,
• HMAC-SHA384 usando a chave wp-sha384,
• codificação Base64 do resumo resultante,
• em seguida, verificação bcrypt.

Por Que uma Etapa de Pré-Hashing É Necessária

Isso significa que uma wordlist normal não pode ser enviada diretamente ao Hashcat se você deseja reproduzir a lógica exata do WordPress 6.8+.

Em vez disso, cada senha candidata deve ser transformada primeiro em sua representação de pré-hash compatível com o WordPress.

O repositório também inclui um script "auxiliar" que:

• aceita o hash extraído como argumento,
• remove o prefixo $wp$ quando necessário,
• pré-processa a wordlist fornecida,
• gera o dicionário transformado,
• opcionalmente cria um arquivo de mapeamento,
• inicia o Hashcat automaticamente,
• resolve o pré-hash recuperado de volta para a senha original em texto claro.

Fluxo Típico

Extraia o hash:

• Exemplo de resultado: $wp$2y$10$zPA8xGJMvr.kvAAIIYaCreIMnTDpgw/9o8K7.ONBm/KBbNIywQtu.

Prepare o ambiente de cracking:

• python3
• hashcat disponível no PATH

Execute Auto_Crack.py:

python3 Auto_Crack.py -H '\$wp\$2y\$10\$zPA8xGJMvr.kvAAIIYaCreIMnTDpgw/9o8K7.ONBm/KBbNIywQtu.' -w /usr/share/wordlists/rockyou.txt

Precisamos escapar "$" com "\" -> compatibilidade com bash

Orientação de Detecção para SOC

O seguinte conteúdo de detecção pode ser usado pelas equipes de SOC para identificar tentativas de exploração e medir a maturidade defensiva.

Detecção Sigma

title: Potential Time-Based Blind SQLi (CVE-2025-4396 Relevanssi)
id: 5a8a1c93-5c74-4b5b-a620-8e1c3e41ab5d
status: experimental
description: Detecta requisições HTTP GET contendo payloads típicos de Injeção SQL Cega Baseada em Tempo frequentemente usados para explorar CVE-2025-4396 no plugin Relevanssi do WordPress (contornando filtros de vírgula).
author: n3fhara
date: 2026-03-18
tags:
    - attack.initial_access
    - attack.t1190
    - cve.2025-4396
logsource:
    category: webserver
detection:
    selection_endpoint:
        cs-uri-query|contains:
            - 's='
            - 'cats='
            - 'tags='
    selection_payload:
        cs-uri-query|contains:
            - 'SLEEP('
            - 'WAITFOR'
            - 'SUBSTRING('
            - 'ASCII('
            - 'LENGTH('
    selection_bypass_indicators:
        cs-uri-query|contains:
            - 'FROM'
            - 'FOR 1'
            - '*('
    condition: selection_endpoint and selection_payload and selection_bypass_indicators
falsepositives:
    - Altamente improvável. Consultas de busca legítimas não devem conter funções SQL.
level: high

Detecção Suricata

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"ET EXPLOIT Tentativa de SQLi no WordPress Relevanssi (CVE-2025-4396)"; flow:established,to_server; content:"GET"; http_method; content:"cats="; http_uri; pcre:"/(cats|tags)=.*(SLEEP|WAITFOR)%28.*(%2A|\*).*SUBSTRING/i"; classtype:web-application-attack; sid:1000001; rev:1; metadata:created_at 2026_03_18, cve CVE_2025_4396;)

Detecção SPLUNK

index=web_logs sourcetype=access_combined 
| regex uri_query="(?i)cats=|tags="
| stats count as request_count, avg(response_time) as avg_time, max(response_time) as max_time, dc(uri_query) as unique_payloads by clientip
| where request_count > 20 AND max_time > 2000
| sort - max_time

Detecção KQL

url.query : (*cats=* OR *tags=* OR *s=*) AND url.query : (*SLEEP* OR *WAITFOR* OR *SUBSTRING* OR *ASCII*) AND url.query : (*FROM* OR *FOR* OR *%2A*)

Detecção EQL

sequence by source.ip with maxspan=1m
  [network where url.path == "/" and url.query : "*cats=*" and event.duration > 2000000000]
  [network where url.path == "/" and url.query : "*cats=*" and event.duration > 2000000000]
  [network where url.path == "/" and url.query : "*cats=*" and event.duration > 2000000000]

Lacunas de Detecção e Recomendações

As detecções de base acima são boas para exploração não ofuscada, mas tornam-se mais fracas quando um operador introduz táticas mais avançadas.

A visibilidade do SOC degrada quando o atacante começa a usar:

• funções SQL alternativas em vez das óbvias,
• ofuscação baseada em codificação URL e comentários,
• volume reduzido de requisições através de busca binária,
• variação de tempo (jitter) e ritmo lento e baixo,
• rotação de proxies,
• falsificação de navegador.

Ideias Adicionais de Detecção para o SOC:

• Detecte tráfego de busca incomum e lento,
• Monitore requisições ao endpoint de busca do WordPress onde:
  • os tempos de resposta estão repetidamente elevados,
  • o mesmo cliente realiza muitas requisições de busca,
  • ou o mesmo endpoint mostra padrões anormais de latência ao longo do tempo.
• Alerte sobre parâmetros de busca contendo operadores codificados,
• Mesmo que palavras-chave SQL óbvias não estejam visíveis, parâmetros de busca contendo combinações de:
  • operadores de comparação codificados,
  • densidade suspeita de parênteses,
  • lógica numérica repetida,
  • ou strings de consulta fortemente codificadas em URL.
• Correlacione por endpoint, não apenas por IP de origem,
• Se o atacante rotacionar proxies, a correlação por IP torna-se fraca. A detecção também deve focar em:
  • acesso repetido ao mesmo endpoint,
  • respostas atrasadas repetidas,
  • ou consultas de busca malformadas repetidas visando a mesma página do WordPress.
• Use detecção comportamental de janela longa:
  • janelas de 30 minutos,
  • 1 hora,
  • ou várias horas.
• Monitore consultas lentas no banco de dados

Estrutura do Repositório

.
├── CVE_2025_4396.py
├── CVE_2025_4396_Stealth.py
├── Auto_Crack.py
├── README.md
└── relevanssi.4.24.4.zip

Aviso Legal

Use apenas em ambientes onde você está explicitamente autorizado a testar. Os autores e contribuidores não assumem nenhuma responsabilidade por uso indevido.

Aviso Legal
Este projeto é fornecido apenas para fins educacionais, validação defensiva e testes de segurança autorizados.
Não o utilize contra sistemas que você não possui ou para os quais não tenha permissão explícita por escrito para avaliar.