MuseBotに管理者なりすましの脆弱性、2.0.0で修正
MuseBotの2.0.0より前の版では、パスワードを知らない第三者が管理者として管理画面に入れてしまいます。ボットを自社や顧客向けに運用している組織が対象で、2.0.0への更新と、管理画面の公開範囲の確認が先決です。
急ぎ度: 早めに
CVSS v3は9.8で認証も不要ですが、悪用が確認されたという情報はなく、修正版の2.0.0が出ているため、管理画面が外部に公開されているなら即日、そうでなければ早めの更新が妥当です。
関係があるか
MuseBotを自前で動かし、管理画面にネットワーク越しで届く環境が対象です。管理画面をインターネットに公開している場合は、最も影響を受けやすい構成です。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| MuseBot（yincongcyincong） | 2.0.0より前のすべての版 | 2.0.0 |
確かめ方
- 1社内でMuseBotを動かしているサーバーやコンテナがないか、情シスと開発部門の両方に聞いて洗い出します。
- 2動いているものがあれば、導入した版を確認します。2.0.0より前なら対象です。
- 3管理画面がインターネットや取引先のネットワークから到達できるか、ファイアウォールやリバースプロキシの設定で確かめます。
何が起きたか
MuseBotの管理画面に、ログインせずに管理者になりすませる脆弱性が見つかりました。2.0.0より前の版が対象です。
原因は、ログイン状態を示すセッションの署名に使う鍵が、製品に最初から入っている固定値のままだったことです。この鍵は公開されているソースコードに書かれており、MuseBotを使う全員が同じ値を共有していました。鍵を知っていれば、正規の管理者がいなくても、管理者のログイン状態を自分で作れてしまいます。
脆弱性の種類はCWE-1394（既定の暗号鍵の使用）に分類されています。
攻撃の流れ
-
1
管理画面に到達
ネットワークからMuseBotの管理画面にアクセスできる状態です。
-
2
既定の鍵を入手
公開されているソースコードから、全利用者共通の固定の署名鍵が分かります。
-
3
ログイン状態を偽造
その鍵で署名した偽の管理者セッションを管理画面に提示します。
-
4
管理者として認識
MuseBotは偽のセッションを正規のものと判断し、管理権限を与えます。
-
5
情報閲覧・停止
チャット記録や設定を読み出され、ボットを止められます。
どう悪用されるか
攻撃にIDやパスワードは要りません。管理画面にネットワークから到達できれば成立し、利用者に何かを操作させる必要もありません。難易度は低いと評価されています。
悪用されると、管理者と同じ権限を持たれます。管理者のパスワードハッシュ、チャット記録、ボットの設定を読み取られ、ボットを停止される恐れがあります。チャット記録に顧客や従業員とのやり取りが含まれていれば、情報漏えいの事故として扱うことになります。
今すぐやること
-
1
利用状況と版を確認する
MuseBotを動かしている環境をすべて洗い出し、版を確認します。ソースから導入した場合は、リポジトリで次のコマンドを実行すると、いまのタグが分かります。
git -C /path/to/MuseBot describe --tags -
2
2.0.0に更新する
修正版の2.0.0に更新します。検証環境で管理画面へのログインとボットの起動を確かめてから、本番に反映すると手戻りが少なくなります。
-
3
更新までの間は管理画面の公開を絞る
インターネットに公開されている場合は、更新より先に公開範囲を絞ります。具体的な方法は回避策に書きました。
-
4
過去のアクセスを調べる
管理画面を外部に公開していた期間があれば、リバースプロキシやサーバーのアクセスログで、心当たりのない送信元から管理画面に入った形跡がないかを見ます。
-
5
資格情報を見直す
不審なアクセスが見つかった場合は、管理者パスワードを変更します。ボットの設定にほかのサービスの認証情報が入っていれば、その鍵やトークンも更新します。
すぐ更新できないとき
更新がすぐにできないときは、管理画面へのアクセスを社内ネットワークやVPNからだけに制限します。リバースプロキシやファイアウォールで送信元のIPアドレスを絞るか、管理画面の前段に別の認証を置いて、MuseBotに直接届かないようにします。これは暫定の措置で、脆弱性そのものは2.0.0に更新するまで残ります。
背景
MuseBotは、ボットの設定、チャット記録、管理者アカウントを一つの管理画面で扱う製品です。管理者として入られると、閲覧も停止も一度にできてしまうため、この画面を守る仕組みが破られた影響は大きくなります。
セッション署名は、サーバーだけが知る鍵で、ログイン状態の改ざんを防ぐ仕組みです。ところが全利用者共通の鍵が公開コードに載っていると、署名はあっても本人確認の役に立ちません。今回の脆弱性は、この鍵が製品の既定値のまま使われていたことが原因です。
よくある質問
Q.パスワードハッシュを読まれたら、パスワードも知られたことになりますか。
まだ分かっていないこと
- 実際の攻撃で悪用されたという情報は、現時点で公表されていません。
- 2.0.0で、固定の鍵がどのように置き換えられたか（鍵の自動生成か、設定の必須化か）は分かっていません。
- 影響を受ける最も古い版や、パスワードハッシュの方式は示されていません。詳細はベンダーのリポジトリとアドバイザリで確認してください。
この記事は、取得元の公開情報をもとに生成 AI で作成しています。誤りを含むことがあります。対応を決める前に、下の原文と参照先を確認してください。
影響パッケージ
| 種類 | パッケージ | 影響を受ける版 | 修正版 |
|---|---|---|---|
| yincongcyincong | MuseBot |
2.0.0 未満 |
2.0.0 |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
MuseBot before 2.0.0 contains an authentication bypass vulnerability that allows unauthenticated attackers to forge admin sessions by using the hard-coded default session_key 'muse_bot_session_key'. Attackers can sign a MuseBot-session cookie carrying a user_id to gain full administrative access, reading password hashes, chat records, and bot configuration, and stopping bots.
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory