Questa analisi dettagliata, condotta il 14 marzo 2025, esplora CVE-2025-1094, una vulnerabilità ipotetica di SQL injection ad alta gravità in PostgreSQL, basata sulla configurazione di emulazione fornita e sull'esecuzione del proof-of-concept (PoC). L'analisi copre l'introduzione della vulnerabilità, la causa radice, i contributi dei file, le fasi del PoC e le mitigazioni, incorporando tutti i dettagli intricati del processo di emulazione.
CVE-2025-1094 è descritta come una vulnerabilità critica di SQL injection in PostgreSQL, che interessa le versioni precedenti alla 17.3, 16.7, 15.11, 14.16 e 13.19, con un punteggio base CVSS 3.1 di 8.1, indicando impatti significativi su riservatezza, integrità e disponibilità. Consente agli attaccanti di accedere a dati sensibili o eseguire codice remoto (RCE), ed è stata sfruttata in violazioni reali, come l'incidente BeyondTrust che ha colpito 17 clienti aziendali, riportato su BleepingComputer, e la violazione del Dipartimento del Tesoro degli Stati Uniti, dettagliata su The Register. L'emulazione, condotta il 14 marzo 2025, ha utilizzato una configurazione Docker con server_encoding=EUC_TW e client_encoding=BIG5, cruciale per attivare l'exploit. Il PoC ha comportato l'iniezione di un blocco DO per creare un large object, leggere /etc/passwd tramite pg_read_file, scriverlo nel large object con lo_put ed esportarlo in /tmp/payload utilizzando lo_export, confermando il ruolo della discrepanza di codifica nell'abilitare l'accesso non autorizzato ai file.
La causa radice è classificata sotto CWE-149: Improper Neutralization of Quoting Syntax, che comporta una gestione impropria nelle funzioni libpq di PostgreSQL—PQescapeLiteral(), PQescapeIdentifier(), PQescapeString() e PQescapeStringConn()—che non neutralizzano la sintassi di quotatura quando i risultati vengono utilizzati per costruire input per lo strumento a riga di comando psql. Ciò è aggravato quando client_encoding è impostato su BIG5 e server_encoding su EUC_TW, come visto nella nostra configurazione, consentendo SQL injection. L'emulazione ha richiesto EUC_TW e zh_TW.EUC_TW per creare la discrepanza, con problemi come la mancanza di supporto EUC_TW in psycopg2 risolti connettendosi con UTF8 e poi passando a BIG5. Il successo dell'exploit dipendeva dall'esecuzione di SQL grezzo tramite subprocess.run(["psql", ...]), bypassando la gestione sicura delle query, come dettagliato nei log.
Ogni file nella configurazione svolge un ruolo critico nell'emulazione di CVE-2025-1094. Di seguito una ripartizione dettagliata in forma tabellare:
Il PoC, eseguito il 14 marzo 2025, dimostra l'impatto dell'exploit attraverso le seguenti fasi, ciascuna con una spiegazione dettagliata:
sudo docker compose up --build
db e app), creando container con immagini aggiornate se necessario, e li collega nella rete postgre_default. Garantisce che l'ambiente vulnerabile sia configurato, con db che utilizza la codifica EUC_TW e app che espone /vuln-endpoint sulla porta 5000, cruciale per la discrepanza di codifica dell'exploit e l'accesso all'endpoint.curl -X POST http://localhost:5000/vuln-endpoint -d "input=test"
input=test, verificando la connettività e la funzionalità di base, aspettandosi "Executed". Conferma che l'app è in esecuzione e può connettersi al database, assicurando che la configurazione sia pronta per l'exploit.
Video Dimostrativo su Vimeo
Clicca per vedere la dimostrazione del PoC su Vimeo.
Per mitigare CVE-2025-1094, si raccomandano le seguenti misure, basate sulle intuizioni dell'emulazione e sulle linee guida del settore:
psql ai soli utenti fidati, riducendo la superficie di attacco.| File | Cosa Fa | Contributo al PoC | Perché è Necessario |
|---|
exploit.py | Invia una richiesta POST con un blocco DO per creare ed esportare un large object, leggendo /etc/passwd. | Attiva l'SQL injection, sfrutta la discrepanza di codifica per eseguire comandi SQL arbitrari. | Abilita l'esecuzione dell'exploit, critico per l'impatto del PoC. |
app.py | App Flask che espone /vuln-endpoint, esegue SQL grezzo tramite psql. | Fornisce l'endpoint vulnerabile per l'exploit. | Punto di ingresso per l'exploit, necessario per la dimostrazione della vulnerabilità. |
init.sql | Crea una tabella di test con id VARCHAR(255) per input di stringhe. | Imposta lo schema per l'iniezione, garantisce l'esecuzione del payload senza errori di tipo. | Configurazione del database per l'exploit, essenziale per l'SQL injection. |
Dockerfile | Crea il container dell'app Flask con le dipendenze necessarie. | Crea un servizio app isolato per la distribuzione dell'endpoint. | Distribuisce l'app vulnerabile, critico per la riproducibilità del PoC. |
docker-compose.yml | Definisce e collega i servizi db e app con configurazioni specifiche. | Orchestra la configurazione, garantisce la discrepanza di codifica e le dipendenze tra servizi. | Collega i servizi, essenziale per la configurazione dell'ambiente e l'isolamento. |
Dockerfile.db | Crea il container PostgreSQL con codifica EUC_TW. | Crea il database vulnerabile con la codifica richiesta. | Configura il database con la codifica richiesta, critico per l'attivazione della vulnerabilità. |
python3 cve-2025-1094-exploit.py
/etc/passwd al suo interno ed esportarlo in /tmp/payload, stampando lo stato di esecuzione. Attiva l'SQL injection, sfruttando la vulnerabilità per leggere /etc/passwd, critico per dimostrare l'impatto di CVE-2025-1094, come visto nei log con l'esportazione riuscita del file.
sudo docker ps
postgre-app-1 e postgre-db-1 siano attivi. Conferma la configurazione prima di eseguire l'exploit, assicurando che entrambi i servizi siano attivi, critico per l'affidabilità del PoC. Fornisce all'utente l'ID del container, necessario nei comandi successivi.sudo docker exec -it bash -c "LC_ALL=C ls -l /tmp/payload && LC_ALL=C cat /tmp/payload"
postgre-db-1, elencando e visualizzando /tmp/payload con output in inglese, verificando il risultato dell'exploit (dovrebbe mostrare /etc/passwd). Conferma che l'exploit ha funzionato controllando il file, assicurando che /tmp/payload contenga dati sensibili, allineandosi con la verifica del PoC, ed evitando la distorsione della locale con LC_ALL=C.
sudo docker exec -it psql -U postgres -d postgres -c "SELECT * FROM test;"
test, verificando l'INSERT dell'exploit (dovrebbe mostrare "Exploit ran with loid ..."). Conferma la modifica del database da parte dell'exploit, assicurando che il blocco DO sia stato eseguito, allineandosi con la verifica del PoC e validando la registrazione del loid.sudo docker compose down