SiYuanのログイン保護を回避される脆弱性、3.8.9で修正
SiYuan 2.1.0以上3.8.9未満で、アクセスコードのログイン画面にあるCAPTCHAを使い回され、総当たりで管理者セッションを得られる脆弱性が公表されました。ネットワークから到達できる環境で使っている組織は、3.8.9へ更新してください。
急ぎ度: 早めに
CVSS v3は7.4、v4は9.1で、攻撃の難度は高めとされていますが、認証なしで管理者権限に届く内容で、修正版3.8.9がすでに出ています。
関係があるか
SiYuanをサーバーやコンテナーで動かし、アクセスコードのログイン画面にネットワークから到達できる組織が対象です。社内の共有ノートや手順書を置いている場合は影響が大きくなります。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| SiYuan（カーネル。Goモジュール名は github.com/siyuan-note/siyuan/kernel） | 2.1.0以上3.8.9未満 | 3.8.9 |
確かめ方
- 1利用中のSiYuanの版を確認し、2.1.0以上3.8.9未満に当たるかを見ます。
- 2アクセスコードによるログインを有効にしているか、そのログイン画面にどこから到達できるか（インターネット、社内LAN、VPN内など）を、ポート公開やリバースプロキシの設定から確認します。
- 3Dockerで動かしている場合は、イメージのタグから版を確認します。
何が起きたか
SiYuanのアクセスコードによるログインには、誤入力が続くとCAPTCHAを求める追加の確認があります。この確認を一度解くと、そのまま使い回せてしまう脆弱性が見つかりました。突破されると、アクセスコードを総当たりで当てられ、管理者としてログインされる恐れがあります。
原因は、CAPTCHAの出題内容が、署名付きのクライアント側cookieに入っていることです。誤ったコードを送ると、サーバーは新しい出題を返してcookieを差し替えます。ところが、差し替え前の古いcookieも有効なままで、解答済みの状態を保っています。サーバー側に、使った出題を無効にする記録がありません。
弱点の種類はCWE-307（認証試行の回数制限が不十分）です。GitHubの勧告は重要度をHighとし、VulnCheckはCVSS v4の9.1に基づいてcriticalとしています。
攻撃の流れ
-
1
ログイン画面に到達
アクセスコードのログインと、CAPTCHAの取得は、どちらも認証なしで呼び出せます。
-
2
CAPTCHAを一度解く
誤入力が重なって求められたCAPTCHAに、一度だけ正しく答えます。
-
3
古いcookieを使い回す
差し替えられる前の署名付きcookieを使い続け、解答済みの状態を保ちます。
-
4
コードを総当たり
CAPTCHAに邪魔されないまま、アクセスコードの候補を試し続けます。
-
5
管理者セッション獲得
コードが一致すると、管理者権限が必要な機能を使えるセッションが成立します。
どう悪用されるか
認証は要りません。攻撃者は、アクセスコードのログイン画面にネットワーク経由で到達できればよく、利用者の操作も不要です。CVSSの評価では、攻撃の難度は高めとされています。アクセスコードそのものを当てる必要があるためです。
成功すると、管理者としてのセッションを得られます。機密性と完全性への影響が高いと評価されており、ノートの閲覧や書き換えにつながります。可用性への影響は評価されていません。
アクセスコードが短い、推測しやすいといった環境ほど、突破までの試行回数は少なくて済むでしょう。
今すぐやること
-
1
使っている版を確認する
SiYuanの版が2.1.0以上3.8.9未満かを確認します。コンテナー運用なら、イメージのタグを見ます。複数台ある場合は、台数ぶん洗い出します。
docker images | grep -i siyuan -
2
3.8.9以上に更新する
該当する環境は、修正版の3.8.9以上へ更新します。インターネットに公開している環境から先に行います。
-
3
ログイン画面の到達範囲を絞る
更新前でも、公開が不要ならネットワークから閉じます。必要な場合も、VPNや接続元IPの制限の内側に置きます。
-
4
アクセスコードと痕跡を見直す
更新と合わせて、長く推測されにくいアクセスコードに変えます。公開状態で運用していた期間があれば、短時間に大量のログイン失敗がなかったか、身に覚えのない管理操作がなかったかを、ログやリバースプロキシの記録から調べます。
-
5
ベンダーの告知を確認する
SiYuanのGitHubにあるセキュリティアドバイザリで、更新手順や追加の注意が出ていないかを確認します。
すぐ更新できないとき
修正版を当てられない間は、SiYuanのログイン画面をインターネットに出さず、VPNや接続元IPの制限、リバースプロキシでの認証など、別の入口の内側に置いてください。これは一般的なつなぎの対策で、この脆弱性を直すものではありません。アクセスコードを強くすると総当たりに時間はかかりますが、CAPTCHAの使い回しは防げません。
背景
SiYuanはオープンソースのノート・ナレッジ管理ツールで、手元のアプリとして使うほか、サーバーやコンテナーで動かしてブラウザーから使う運用もできます。後者では、アクセスコードのログイン画面が入口になります。ここを破られると、社内の手順書、設計メモ、認証情報の控えなど、ノートに置いたものがまとめて読み書きされるおそれがあります。
今回の問題は、回数制限を補うCAPTCHAの状態を、サーバーではなくクライアント側のcookieに持たせたことにあります。署名があるので改ざんはできませんが、古いcookieを無効にする仕組みがなく、署名付きでも使い回しは防げませんでした。誤入力のたびにCAPTCHAを差し替える設計だったからこそ、差し替え前のcookieが残ることが抜け道になりました。
よくある質問
Q.GitHubはHigh、VulnCheckはcriticalと書いています。どちらで判断すればよいですか。
Q.アクセスコードを長くすれば、更新しなくても安全ですか。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
影響パッケージ
| パッケージ | 影響を受ける版 → 修正版 | |
|---|---|---|
| siyuan-notesiyuan |
2.1.0 以上 3.8.9 未満→ 3.8.9 |
3.8.9 |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
SiYuan 2.1.0 before 3.8.9 contains a flaw where the loginAuth CAPTCHA challenge lives in a signed client-side cookie, allowing reuse of a solved challenge. Attackers can replay the original signed siyuan cookie with distinct wrong access codes to brute-force the code and gain an administrator session.
出典: CVE.org (CVE Program・cvelistV5) NVD