FileRise 3.23.0 より前のバージョンでは、失敗した TOTP 検証試行が PHP セッション状態に保存されていました。カウンターは 1 つのセッション内での試行回数を制限していましたが、新しく作成されたセッション間では保持されませんでした。
対象アカウントの有効なプライマリ資格情報をすでに所持している攻撃者は、ログインワークフローを再開し、新しい保留中ログインセッションを受け取り、TOTP 試行許容量を復元することができました。このプロセスを繰り返すことで、意図された 5 回の試行制限を超えてオンラインでの TOTP 推測を継続することが可能でした。
TOTP 検証フローは、失敗カウンターを $_SESSION で管理していました。5 回の失敗送信後、そのセッションでの以降の試行は HTTP 429 を返しました。
しかし、新しいセッションでプライマリ認証を正常に完了すると、新しい TOTP 失敗カウンターを持つ新しい保留中ログイン状態が作成されました。したがって、以前のアカウントの TOTP 失敗は引き継がれませんでした。
この問題は、同じ永続的な制限を適用していなかった別の保留中ログイン TOTP ハンドラーにも影響していました。そのため、修正はすべての保留中ログイン TOTP 検証パスに一元的に適用されました。
この問題は CWE-307: 過剰な認証試行の不適切な制限に分類されます。
悪用には、資格情報の再利用、フィッシング、またはその他の侵害によって取得されたパスワードなど、対象アカウントの有効なプライマリ資格情報を所持している必要があります。
この脆弱性は資格情報を開示したり、TOTP を直ちにバイパスしたりするものではありません。アカウント全体で永続的な制限なしに、自動化された TOTP 推測を継続することを可能にします。推測が成功すると、影響を受けるアカウントの権限(管理者権限を含む可能性があります)で認証が完了します。
TOTP が有効になっていないアカウントは、この特定の第二要素レート制限の問題による影響を受けません。
FileRise 3.23.0 では、集中化された永続的な TOTP 試行制限が導入されています:
既存のアカウント、TOTP シークレット、セッション、Docker インストール、およびデプロイメント設定に移行は不要です。
ユーザーは FileRise 3.23.0 以降にアップグレードする必要があります。
責任ある開示と詳細な再現手順をありがとうございます。
私たちは TOTP 検証ワークフローをレビューし、根本的な問題を確認しました。失敗した TOTP 送信は、プライマリフロントエンド検証エンドポイントの PHP セッションカウンターによってのみ制限されていました。したがって、新しいセッションでプライマリ認証の成功ステップを繰り返すことで、第二要素の試行予算を復元することができました。私たちのレビューでは、同じ試行カウンターを適用していなかった別の保留中ログイン TOTP ハンドラーも特定したため、修正は報告されたエンドポイントだけでなく、検証パス全体に一元的に適用されました。
修正は FileRise v3.23.0 に実装されています:
アカウント制限は 15 分間のウィンドウで 5 回の試行です。ソース全体の制限は、共有ネットワークでの誤検知を減らすために、同じウィンドウで意図的に 50 回と高く設定されています。既存のアカウント、TOTP シークレット、セッション、Docker インストール、およびデプロイメント設定に移行は不要です。
Credit: Pervin Zahidli (@ech0void ) Ref : https://github.com/error311/FileRise/security/advisories/GHSA-4hfj-6478-5cv7