Atualizações corretivas foram formuladas para todas as versões suportadas do PostgreSQL 17.3, 16.7, 15.11, 14.16 e 13.19, corrigindo mais de 70 erros e eliminando uma vulnerabilidade (CVE-2025-1094), que foi explorada no final de dezembro em um ataque à empresa BeyondTrust e ao Ministério das Finanças dos EUA. O problema no PostgreSQL foi identificado ao analisar uma vulnerabilidade remota (CVE-2024-12356) nos serviços BeyondTrust PRA (Privileged Remote Access) e BeyondTrust RS (Remote Support), na qual uma vulnerabilidade 0-day previamente desconhecida na libpq também foi utilizada.
Como resultado do ataque, os agressores conseguiram obter a chave de acesso à API utilizada para fornecer suporte técnico remoto aos clientes dos serviços SaaS da BeyondTrust. Essa API foi usada para redefinir senhas e comprometer a infraestrutura do Ministério das Finanças dos EUA, que utiliza produtos da BeyondTrust. Durante o ataque, os criminosos conseguiram baixar documentos confidenciais e tiveram acesso às estações de trabalho dos funcionários do ministério.
A vulnerabilidade ocorre na biblioteca libpq, que fornece uma API para interação com o SGBD a partir de programas em C (também existem bibliotecas de vínculo para C++, Perl, PHP e Python). O problema afeta aplicativos que usam as funções PQescapeLiteral(), PQescapeIdentifier(), PQescapeString() ou PQescapeStringConn() para escapar de caracteres especiais e neutralizar aspas.
O atacante pode conseguir injetar seu próprio código SQL se o texto recebido externamente for escapado usando as funções mencionadas da libpq antes de ser usado dentro da consulta SQL. Nos aplicativos da BeyondTrust, as consultas escapadas dessa forma foram passadas através da ferramenta de linha de comando psql. A vulnerabilidade é causada pela falta de verificação da validade dos caracteres Unicode utilizados no texto nas funções de escape, permitindo contornar a normalização das aspas por meio da especificação de sequências multibyte UTF-8 incorretas.
Para explorar uma vulnerabilidade, pode-se utilizar um caractere UTF-8 incorreto, composto pelos bytes 0xC0 e 0x27 ("└'"). O byte 0x27 na codificação ASCII corresponde à aspa simples ("‘"), que deve ser escapada. No código de escape, a combinação de bytes 0xC0 e 0x27 é tratada como um único símbolo Unicode. Assim, o byte 0x27 nesta sequência permanece não escapado, enquanto que, ao processar uma consulta SQL com a ferramenta psql, é tratado como uma aspa.
Ao executar consultas SQL usando a ferramenta psql para organizar a execução de código arbitrário, pode-se usar a substituição na string do comando "\!", destinada no psql para executar programas arbitrários. Por exemplo, para executar na servidor ferramenta "id", pode-se passar o valor "hax\xC0′; \! id #". No exemplo abaixo, para escapar, é chamado um script PHP dbquote, que utiliza a função PHP pg_escape_string, que opera em cima da função PQescapeString da 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: sequência de bytes inválida para codificação "UTF8": 0xc0 0x27 uid=1000(myexamplecompany) gid=1000(myexamplecompany)
Fonte: opennet.ru
