Se han generado actualizaciones correctivas para todas las ramas de PostgreSQL compatibles 17.3, 16.7, 15.11, 14.16 y 13.19, corrigiendo más de 70 errores y eliminando la vulnerabilidad (CVE-2025-1094) que se utilizó en el ataque a BeyondTrust y al Departamento del Tesoro de EE. UU. a fines de diciembre. El problema en PostgreSQL fue descubierto durante el análisis de una vulnerabilidad remota (CVE-2024-12356) en los servicios BeyondTrust PRA (Privileged Remote Access) y BeyondTrust RS (Remote Support), cuya explotación involucraba adicionalmente una vulnerabilidad previamente desconocida (0-day) en libpq.
Como resultado del ataque, los atacantes lograron obtener una clave para acceder a la API utilizada para brindar de forma remota servicios de soporte técnico a los clientes de BeyondTrust SaaS. Esta API se utilizó para restablecer contraseñas y comprometer la infraestructura del Departamento del Tesoro de Estados Unidos, que utiliza productos BeyondTrust. Durante el ataque, los atacantes lograron descargar documentos confidenciales y acceder a las estaciones de trabajo de los empleados del ministerio.
La vulnerabilidad aparece en la biblioteca libpq, que proporciona una API para interactuar con el DBMS desde programas C (las bibliotecas de enlace para C++, Perl, PHP y Python también están implementadas sobre la biblioteca). El problema afecta a las aplicaciones que utilizan las funciones PQescapeLiteral(), PQescapeIdentifier(), PQescapeString() o PQescapeStringConn() para escapar caracteres especiales y neutralizar comillas.
Un atacante puede lograr la sustitución de SQL si el texto recibido desde el exterior se escapa utilizando las funciones libpq anteriores antes de usarse dentro de la consulta SQL. En las aplicaciones BeyondTrust, las consultas escapadas de esta manera se pasaban a través de la utilidad de línea de comandos psql. La vulnerabilidad se debe a la falta de una comprobación en las funciones de escape de la corrección de los caracteres Unicode utilizados en el texto, lo que permite eludir la normalización de las comillas al especificar secuencias UTF-8 multibyte incorrectas.
Para explotar la vulnerabilidad, se puede utilizar un carácter UTF-8 no válido formado por los bytes 0xC0 y 0x27 (“└'”). El byte 0x27 en la codificación ASCII corresponde a una comilla simple ("'") que debe escaparse. En el código de escape, la combinación de los bytes 0xC0 y 0x27 se trata como un solo carácter Unicode. En consecuencia, el byte 0x27 en dicha secuencia permanece sin escapar, a pesar del hecho de que al procesar una consulta SQL en la utilidad psql, se procesa como una comilla.
en ejecutar consultas SQL Con la utilidad psql, puede usar la sustitución "\!" en la cadena de comandos para organizar la ejecución de código arbitrario, lo cual está diseñado en psql para ejecutar programas arbitrarios. Por ejemplo, para ejecutar en servidor A la utilidad "id" se le puede pasar el valor "hax\xC0′; \! id #". El siguiente ejemplo llama al script PHP dbquote para el escape, usando la función PHP pg_escape_string, que funciona sobre la función PQescapeString de libpq: $ echo -e "hello \xC0'world'" | ./dbquote 'hola └'mundo"' $ quoted=$(echo -e "hax\xC0′; \! id # " | ./dbquote) $ echo "SELECT COUNT(1) FROM gw_sessions WHERE session_key = $quoted AND session_type = 'sdcust' AND (expiration IS NULL OR expiration>NOW())" | psql -e SELECT COUNT(1) FROM gw_sessions WHERE session_key = 'hax└'; ERROR: secuencia de bytes no válida para la codificación "UTF8": 0xc0 0x27 uid=1000(myexamplecompany) gid=1000(myexamplecompany)
Fuente: opennet.ru
