Se han formado actualizaciones correctivas para todas las versiones compatibles de PostgreSQL 17.3, 16.7, 15.11, 14.16 y 13.19, que corrigen más de 70 errores y eliminan una vulnerabilidad (CVE-2025-1094), involucrada a finales de diciembre en el ataque a la empresa BeyondTrust y al Ministerio de Finanzas de EE. UU. El problema en PostgreSQL se identificó durante el análisis de una vulnerabilidad remota (CVE-2024-12356) en los servicios de BeyondTrust PRA (Privileged Remote Access) y BeyondTrust RS (Remote Support), en la cual se utilizó una vulnerabilidad previamente desconocida (0-day) en libpq.
Como resultado del ataque, los delincuentes lograron obtener la clave de acceso a la API utilizada para proporcionar servicios de soporte técnico remoto a los clientes de los servicios SaaS de BeyondTrust. Esta API se utilizó para restablecer la contraseña y comprometer la infraestructura del Ministerio de Finanzas de EE. UU., que utiliza productos de BeyondTrust. Durante el ataque, los delincuentes pudieron cargar documentos confidenciales y accedieron a las estaciones de trabajo de los empleados del ministerio.
La vulnerabilidad se manifiesta en la biblioteca libpq, que proporciona una API para la interacción con el SGBD desde programas en lenguaje C (también se han implementado bibliotecas de enlace para C++, Perl, PHP y Python 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 inyección de su código SQL si el texto recibido externamente se escapa utilizando las funciones libpq mencionadas antes antes de ser usado dentro de una consulta SQL. En las aplicaciones de BeyondTrust, las solicitudes escapadas de esta manera se pasaron a través de la utilidad de línea de comandos psql. La vulnerabilidad se debe a la falta de verificación de la validez de los caracteres Unicode utilizados en el texto en las funciones de escape, lo que permite eludir la normalización de comillas mediante la especificación de secuencias de bytes múltiples UTF-8 incorrectas.
Para explotar la vulnerabilidad, se puede utilizar un símbolo UTF-8 incorrecto, que consta de los bytes 0xC0 y 0x27 («└'»). El byte 0x27 en la codificación ASCII corresponde a una comilla simple («‘»), que debe ser escapada. En el código de escape, la combinación de bytes 0xC0 y 0x27 se procesa como un solo símbolo Unicode. Por lo tanto, el byte 0x27 en tal secuencia permanece sin escapar, mientras que durante el procesamiento de la consulta SQL en la utilidad psql se trata como una comilla.
Al ejecución de consultas SQL a través de la utilidad psql para organizar la ejecución de código arbitrario se puede utilizar la sustitución en la cadena de comandos «\!», destinada en psql para ejecutar programas arbitrarios. Por ejemplo, para ejecutar en servidor la utilidad «id» se puede pasar el valor «hax\xC0′; \! id #». En el siguiente ejemplo, se llama a un script PHP dbquote para el escape, que utiliza la función PHP pg_escape_string, que trabaja sobre la función PQescapeString de libpq: $ echo -e «hello \xC0’world'» | .\dbquote ‘hello └’world»’ $ 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
