Snowflakeが管理するPostgreSQLのセキュリティテストにより、権限の限られたデータベースロールが、データベースを稼働させるサーバーの掌握につながり得ることが明らかになりました。
CyberSecurity Tools
Snowflakeは、SQL経由でコマンドを実行したりファイルにアクセスしたりする一般的な手口を封じていました。それでも研究者らは、PostgreSQLに標準搭載された複数の機能を連鎖させ、オペレーティングシステム（OS）のコマンド実行にたどり着きました。
今回の発見は、小さな権限同士が組み合わさることで、マネージドクラウドサービスに深刻なリスクが生じ得ることを示しています。研究者らによると、攻撃の連鎖は、スーパーユーザーではないアカウントsnowflake_adminから始まりました。
このアカウントの鍵となる権限はCREATEROLEで、ロールの作成と管理を可能にするものです。この権限だけでは、データベースの完全な制御は得られません。しかし今回のケースでは、データベースが信頼する他の機能を経由する道を開く助けとなりました。
Varonis Threat Labsの研究者らがこの権限昇格の連鎖を特定し、Snowflakeに報告しました。
Varonisによると、Snowflakeは研究の公表前にこの問題を修正済みです。そのため、Snowflake Postgresを利用している顧客が、今回の発見に関して追加の対応を取る必要はありません。研究チームは2026年5月31日にこの連鎖を最初に報告し、10月17日に公表しました。
Snowflake PostgreSQLデータベースを突破した手法
最初の一手はCREATEROLEに依存していました。研究者らはこの権限を使い、出発点のアカウントに2つの組み込みロールpg_read_all_dataとpg_write_all_dataを付与しました。
この2つのロールは、データベースのテーブルやシステムカタログへの幅広いアクセスを提供します。このアクセス権により、研究者らは、スケジュールされたジョブを実行するPostgreSQL拡張機能pg_cronのエントリーを変更できました。
研究者らはスケジュール済みジョブを書き換え、高い権限を持つpostgresアカウントとして実行されるようにしました。ジョブが実行されると、SECURITY DEFINER関数が作成されました。
この種の関数は、呼び出したユーザーではなく、所有者の権限で実行されます。研究者らはこの関数を利用して、Snowflakeが封じていた直接的なロール変更を使わずに、PostgreSQLのスーパーユーザー権限を獲得しました。
ただし、このデータベースレベルのアクセスは、まだサーバーの制御と同じではありませんでした。Snowflakeは、サーバー上のファイルの読み取り、システム設定の変更、SQL経由でのプログラム実行といった、よく知られた経路を遮断していました。
そこで研究者らは、PostgreSQLのinternal言語を使えば、新しいデータベース関数名を、サーバーソフトウェアにすでに存在するC関数に紐づけられることを発見しました。これにより、遮断されたファイル読み取り・書き込み関数へのアクセスを、別の名前で復活させることができました。
ファイルへのアクセスを得た研究チームは、PostgreSQLのラージオブジェクト機能を使って設定ファイルに書き込みました。変更したのはarchive_commandです。これは、PostgreSQLが完了したWAL（先行書き込みログ）セグメントをアーカイブする際に、シェルコマンドを実行する設定です。
WALは、データベースの変更をデータファイルへ完全に書き込む前に記録するものです。設定したコマンドが実行された時点で、研究者らはpostgresシステムアカウントとしてOSのコマンド実行に到達しました。
今回の発見は、SQLからOSにアクセスするよく知られた関数を封じるだけでは不十分な場合があることを示しています。関連する機能が別の経路で利用できる状態のままだと、防御をすり抜けられるおそれがあるためです。
また、マネージドデータベースでは、サーバーとOSの制御をプロバイダーが握る一方、データベースロールの割り当て方は顧客が決めます。この点でも今回の発見は重要です。
データベースからサーバーへ及ぶ同様のリスクは、ほかの環境でも確認されています。たとえば、PostgreSQLのコード実行の脆弱性や、pgAdminのシェルコマンド実行の脆弱性があります。
想定される影響と対応
脅威アクターが同様のアクセス権を得た場合、データベースファイルの改ざんや破壊、復旧の妨害、ローカルログの書き換えなどを行える可能性があります。
OSレベルの活動は通常のSQLクエリを経由しないことがあるため、データベースの監査記録だけでは全体像が把握できない可能性があります。
Varonisによると、実証された活動は研究者ら自身のシングルテナントのテスト環境にとどまっており、Snowflakeの顧客データにアクセスしたとの記載はレポートにありません。
Snowflakeは、公表前にサーバー側でこの連鎖に対処しました。レポートによると、同社は6月1日に報告を受領し、6月9日には、Snowflake Postgresの仮想マシン内でのローカルコード実行がセキュリティ境界を越えるものだと確認しました。
CyberSecurity Tools
研究者らは、今回の発見が新たに特定されたマルウェアの検体ではなく、PostgreSQLの複数の挙動を連鎖させたものだと述べています。PostgreSQLに関連する別のコード実行リスクについては、GBHackersのAppsmithのPostgreSQLリモートコード実行に関する記事も参考になります。
自前でPostgreSQLサーバーを運用するチームに対し、研究者らはCREATEROLEを高リスクの権限として扱うよう推奨しています。必要な場合を除き、アプリケーション用アカウントからは削除すべきだとしています。
管理者は、ロールの付与状況、スケジュール済みのpg_cronジョブ、SECURITY DEFINER関数に、想定外の変更がないか確認する必要があります。
さらに、internal関数やC言語関数を作成できるユーザーを制限し、データベースの設定ファイルを保護するとともに、データベースサービスを不要なネットワークアクセスから隔離しておくことも求められます。
侵害指標（IoC）：
| IoCの種類 | 値 |
|---|---|
| ファイルハッシュ | 公表なし |
| ドメインまたはIPアドレス | 公表なし |
| マルウェア名 | 公表なし |
注： IPアドレスとドメインは、誤って名前解決されたりハイパーリンク化されたりするのを防ぐため、意図的に無害化（例： [.]）しています。無害化の解除は、MISP、VirusTotal、自社のSIEMなど、管理された脅威インテリジェンスプラットフォーム内でのみ行ってください。
16,000以上のSOCチームがANY.RUNを利用し、脅威調査の効率化と手作業の削減を実現しています。 自社チームで試す
翻訳元: https://gbhackers.com/researchers-hack-snowflake/
