Aptabaseセルフホスト版に認証回避の脆弱性、修正版あり
セルフホスト版Aptabaseがサンプルの AUTH_SECRET のまま動いていると、メールアドレスを知る第三者に任意のユーザーとしてログインされます。該当する環境は、AUTH_SECRETを秘密の値に替えて更新し、アプリの所有者に不審な変更がないかも確認してください。
急ぎ度: 早めに
CVSS v4は9.1、v3は7.4で、サンプルの値のままの環境では認証なしにユーザーへなりすませますが、修正版が出ており、自前の乱数を設定していた環境は影響を受けません。
関係があるか
公式のセルフホスト用docker-compose.yml、またはその値を写したサードパーティーのデプロイテンプレートで構築し、サンプルのAUTH_SECRETを変えずに運用しているAptabaseが該当します。製品にAUTH_SECRETの初期値はなく、自分でランダムな値を設定していた環境は影響を受けません。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| ghcr.io/aptabase/aptabase | mainの61d4c01より前 | mainの61d4c01以降（61d4c01298a706d575265461ac07bb956ca7b8d2） |
| aptabase/self-hosting の docker-compose.yml | サンプルのAUTH_SECRETが直接書かれていた版 | b79a472以降（AUTH_SECRETが必須の変数になり、未設定だとdocker compose upが失敗する） |
確かめ方
- 1運用中のdocker-compose.ymlや環境変数ファイルでAUTH_SECRETの値を確認し、旧版のself-hostingリポジトリに書かれていたサンプルの値や、使ったテンプレートのサンプルの値と一致していないかを見ます。一致していれば該当します。
- 2AUTH_SECRETを自分で変えていた場合でも、動いているイメージがmainの61d4c01以降かどうかは確認してください。
何が起きたか
サンプルのAUTH_SECRETのまま運用しているセルフホスト版Aptabaseでは、第三者が任意のユーザーのサインインリンクを偽造し、そのユーザーとしてログインできます。
Aptabaseのサインインリンクと登録リンクは、AUTH_SECRETで署名したHS256のJWTです。サーバーはAUTH_SECRETの強さも、公開されているサンプルの値かどうかも検査せずに受け入れていました。aptabase/self-hostingリポジトリのdocker-compose.ymlには固定のサンプル値が入っており、同じ値がサードパーティーのデプロイテンプレートにもそのまま写されていました。署名が正しいトークンであれば、/api/_auth/continueはその中のメールアドレスをそのまま信用します。
修正では、AUTH_SECRETが32文字より短い場合や公開されているサンプルの値と同じ場合に、サーバーが起動を拒否するようになりました。サインインと登録のリンクも1回限りになり、固有のIDを持たないトークンは拒否されます。
評価は割れています。CVSS v3は7.4、v4は9.1で、GitHubのアドバイザリは深刻度をLowとしています。弱点の分類はCWE-294、CWE-798、CWE-1188です。
攻撃の流れ
-
1
対象の特定
サンプルのAUTH_SECRETのまま動いているインスタンスが狙われる。
-
2
メールの確認
サインインの応答の違いから、登録済みのメールアドレスを絞り込める。
-
3
リンクの偽造
公開されているAUTH_SECRETで署名した、偽のサインインリンクを作る。
-
4
なりすまし
サーバーがトークン内のメールを信用し、そのユーザーとしてログインが成立する。
-
5
窃取と移転
イベントデータを書き出し、アプリの所有権を攻撃者のアカウントへ移す。
どう悪用されるか
認証は要らず、利用者の操作も要りません。ネットワーク経由でインスタンスに到達でき、対象ユーザーのメールアドレスを知っていて、インスタンスがサンプルのAUTH_SECRETで動いていれば成立します。メールアドレスが分からなくても、サインインのエンドポイントが登録済みなら200、未登録なら404を返すため、先に絞り込めます。CVSS v3が攻撃の複雑さを高とし、v4が低（攻撃の前提条件あり）とするのは、このサンプルの値が公開されているかどうかの見方の差と考えられます。
成立すると、メールボックスにもアカウントにも触れずにそのユーザーとしてログインされます。そのユーザーのアプリのイベントは、イベントのプロパティを含めてすべて読まれ、書き出されます。さらに、偽造した登録トークンで攻撃者が自分のアカウントを作り、アプリの所有権をそこへ移せます。この移転はAUTH_SECRETを替えたあとも残り、元の所有者は読み取り専用のメンバーになります。
今すぐやること
-
1
AUTH_SECRETの値を確認する
docker-compose.yml、環境変数ファイル、使ったテンプレートの設定を調べ、サンプルの値のままになっていないかを見ます。画面共有や記録に値が残らないよう注意してください。
grep -n AUTH_SECRET docker-compose.yml -
2
秘密の値を設定して修正版へ更新する
32文字以上のランダムな値をAUTH_SECRETに設定し、mainの61d4c01以降のイメージを取得し直して、コンテナーは再起動ではなく作り直します。修正版は32文字未満の値だと起動を拒否するため、短い値を使っていた環境は長い値に替える必要があります。self-hostingのcomposeファイルも、AUTH_SECRETが必須になった版に合わせてください。
-
3
所有者と共有の変更を調べる
データベースのapps.owner_idとapp_sharesテーブルを見て、身に覚えのない所有者の変更や共有がないかを確認します。所有権の移転はAUTH_SECRETを替えても残るため、サンプルの値で運用していた期間があるなら必ず調べてください。見つかった場合は、その間に書き出された可能性のあるイベントデータも洗い出します。
-
4
ほかのテンプレートから作った環境も洗い出す
同じサンプル値を写したテンプレートで立てたインスタンスが社内にないか、デプロイ元を一覧で確認します。
すぐ更新できないとき
すぐに更新できないときは、AUTH_SECRETをopenssl rand -base64 32の出力のような秘密のランダムな値に替え、コンテナーを再起動ではなく作り直します。セッションのCookieはAUTH_SECRETと別物で、値を替えるだけでは攻撃者のログイン状態が残るため、作り直して既存のセッションを無効にする必要があります。あくまで更新までのつなぎで、1回限りのリンクや起動時の検査は修正版にしかありません。
背景
Aptabaseは、アプリの利用状況をイベントとして集めるアナリティクス基盤です。セルフホスト用にはdocker composeの構成が公開されており、社内のサーバーに自分で立てる運用ができます。集まるイベントにはプロパティが含まれるため、ログインを突破されると利用状況のデータがまとめて読まれます。
今回の根は、サンプルの設定に入っていた値が、そのまま本番の秘密として使われたことです。公式のcomposeファイルの値が他社のテンプレートにも写されていたため、公式リポジトリを使わずに構築した環境も対象になりえます。製品自体にはAUTH_SECRETの初期値がなく、修正版は起動時に値を検査する形で、サンプルをそのまま使えない構成に変わりました。
よくある質問
Q.AUTH_SECRETを替えれば、更新しなくても安全になりますか。
まだ分かっていないこと
- サンプルの値を写したサードパーティーのデプロイテンプレートが、具体的にどれかは挙げられていません。
- 修正はmainブランチのコミットで示されており、版番号付きのリリースは挙げられていません。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
影響パッケージ
| パッケージ | 影響を受ける版 → 修正版 | |
|---|---|---|
| aptabaseaptabase |
61d4c01298a706d575265461ac07bb956ca7b8d2 未満→ 61d4c01298a706d575265461ac07bb956ca7b8d2 |
61d4c01298a706d575265461ac07bb956ca7b8d2 |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
Aptabase before commit 61d4c01 contains an authentication bypass vulnerability that allows unauthenticated attackers to forge sign-in links by using the publicly known example AUTH_SECRET. Attackers can enumerate registered e-mails via /api/_auth/signin, forge HS256 JWTs redeemed by /api/_auth/continue, impersonate users, export analytics data, and transfer app ownership.
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory
参照URL
- web github.com
- web github.com
- web github.com
- web github.com
- web vulncheck.com
- web nvd.nist.gov
- web github.com