Matomo 認証済み SiteContentDetector ブラインド SSRF

報告者

名前: CYBER-SEC
連絡先: [email protected]

概要

Matomo では、認証済みのサイト管理者がサイトの main_url を内部アドレスで設定できます。閲覧権限を持つ認証済みユーザーは、後から getTrackingMethodsForSite をトリガーでき、サーバーが設定された URL に対してブラインド HTTP リクエストを実行します。

宛先はホスト名ベースの保護のみで検証され、解決後のループバック、RFC1918、リンクローカルアドレスを適切に拒否しません。その結果、このアプリケーションは内部サービスへのブラインドサーバーサイドリクエストに悪用される可能性があります。

影響を受ける製品

製品: Matomo
影響を受けるバージョン: 5.11.2 で検証済み
コンポーネント: SiteContentDetector / SitesManager

CWE

CWE-918: サーバーサイドリクエストフォージェリ (SSRF)

CVSS v3.1

ベクター: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N
ベーススコア: 5.8 Medium

攻撃要件

enable_internet_features が有効である必要があります。
サイトの main_url を設定するには、認証済みのサイト管理者が必要です。
閲覧権限を持つ認証済みユーザーがサーバーサイドリクエストをトリガーできます。
攻撃者は、制御するリスナーまたはサイドチャネルを通じてブラインドリクエストを観測できる必要があります。

技術的詳細

この問題は以下のフローに関係します:

ソース:
SitesManager.updateSite は、基本的な URL 検証後に main_url を保存します。

トリガー:
GET /index.php?module=SitesManager&action=getTrackingMethodsForSite&idSite=<id>

シンク:
SiteContentDetector::requestSiteResponse()
  -> Http::sendHttpRequestBy()

この実装は、以下のような内部宛先を適切に拒否しません:

127.0.0.0/8
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
169.254.0.0/16
::1
fc00::/7
fe80::/10

リダイレクト先も再検証する必要があります。初期の許可されたホスト名が内部アドレスにリダイレクトする場合、ホスト名ベースのフィルタリングはバイパスされる可能性があるためです。

概念実証

1. 制御する内部リスナーを起動する

認可されたラボ環境で制御するリスナーを使用します:

python3 -m http.server 8088

2. Matomo サイト URL を設定する

認証済みのサイト管理者として、サイトの main_url を制御する内部リスナーに向けて設定します:

http://<controlled-internal-listener>:8088/ssrf-test

第三者システムやクラウドメタデータエンドポイントに対しては、その環境を所有しテストする権限がない限りテストしないでください。

3. SiteContentDetector をトリガーする

閲覧権限を持つ認証済みユーザーとして、以下をトリガーします:

GET /index.php?module=SitesManager&action=getTrackingMethodsForSite&idSite=1

4. ブラインドリクエストを観測する

制御するリスナーが Matomo サーバーからサーバーサイド HTTP リクエストを受信します。

リスナー出力の例:

GET /ssrf-test HTTP/1.1
Host: <controlled-internal-listener>:8088
User-Agent: Matomo

観測された動作

getTrackingMethodsForSite がトリガーされると、Matomo は設定された main_url に対してサーバーサイド GET リクエストを実行します。

これは、外部から到達できない内部ループバック/内部 HTTP リスナーを使用して検証され、ブラインド SSRF の動作が確認されました。

影響

認証済みの攻撃者は、この動作を以下の目的で悪用する可能性があります:

内部サービスへのブラインドアクセス。
内部ネットワークの偵察。
ループバックまたはプライベートインターフェースにバインドされたサービスとの相互作用。
影響を受けるデプロイメントにおけるクラウドメタデータサービスへのリクエスト。
ホスト名のみの保護に対するリダイレクトベースのバイパス。

SSRF はブラインドであるため、攻撃者は Matomo を通じて HTTP レスポンスボディを直接受信しません。ただし、リクエストの配信だけでも、内部ネットワークやクラウド環境ではセキュリティ上重要となる可能性があります。

修復

推奨される修正:

リクエストを行う前にホスト名を IP アドレスに解決します。
DNS 解決後に、プライベート、ループバック、リンクローカル、マルチキャスト、その他の安全でない IP レンジを拒否します。
リダイレクトを追跡する前に、すべてのリダイレクト先を再検証します。
ホスト名のブロックリストではなく、許可された送信ドメインの厳格な許可リストを優先します。
サイト URL 設定時だけでなく、最終的な HTTP リクエストシンクで SSRF 保護を一貫して適用します。
getTrackingMethodsForSite または SiteContentDetector のトリガーを、より高い権限を持つユーザーに制限することを検討します。
サイト設定によってトリガーされる送信サーバーサイドリクエストの監査ログを追加します。

発見

公式の Matomo 5.11.2 Docker イメージに対して、ソースコードを変更せずに検証しました。

開示

この問題は CYBER-SEC によって報告されました。

CVE-2026-78850

人気