Danbooruで11月4日にXSS攻撃、約300人のIPアドレスを取得

Danbooruで11月4日、悪意あるFlashファイルによるXSS攻撃が発生し、約300人のIPアドレスが取得されました。このうちログイン中だった100人はユーザー名も取得され、アカウントを一時的に乗っ取られて攻撃の拡散に利用されました。サイトが停止されたのは約6分後で、その後のセキュリティ対策やサーバー保守のため、停止期間は1週間に及びました。

約6分間に閲覧した利用者へ被害が拡大

攻撃に使われたのは、閲覧者のブラウザーで不正な処理を実行するXSS（クロスサイトスクリプティング）と、自分のコピーを広めるワームを組み合わせたFlashファイルです。感染した投稿は約600回閲覧され、そのうち実際にワームが動作したのは約300人で、未ログインが200人、ログイン中が100人でした。

ワームは最初に攻撃者のサイトから動画を読み込み、閲覧者のIPアドレスを取得しました。ログイン中の利用者の権限で、ファイルのコピーの投稿、別のコピーへの賛成票の追加、フォーラムへの誘導リンクの投稿も行いました。投稿を承認できる権限がある場合には、コピーの承認も試みています。

攻撃によってワームのコピー68件、フォーラム投稿129件が作られ、感染した投稿には約5000回の賛成票が入りました。また、48人のお気に入り計1000件が削除されましたが、お気に入りは復元され、ワームのコピーもすべて削除されました。

サーバー自体への侵入や、ファイルによる利用者のコンピューターの侵害は起きていません。管理者権限を使ったメールアドレスの収集や他のアカウントの昇格も試みられましたが、管理者のアカウントが乗っ取られる前にサイトが停止されたため、実行には至りませんでした。

1行のバグ修正でFlashの投稿が再び可能に

Flashファイルのアップロード機能は2021年に無効化されましたが、2022年のアップロード処理の改修時に誤って有効に戻っていました。ただし、別のバグがアップロードを妨げていたため、実際には投稿できない状態が続いていました。

2026年10月28日、サムネイルを生成できないとアップロードが失敗するバグの修正案が提出されました。提出者は攻撃者で、この修正を取り込んだ結果、Flashのアップロードを妨げていた最後の要因も取り除かれました。修正自体は実在するバグを直す1行の変更で、悪意あるコードは含まれていませんでした。

Flash投稿の無効化を検証するテストが追加されていなかったことも、有効化の見落としにつながりました。また、Flash動画の再生に使うRuffleには、実行環境を制限するサンドボックスが適用されていませんでした。新しいFlashの投稿はすでに無効になっているとの認識が、その判断の背景にありました。

Ruffleの設定と埋め込み先の権限制限

今回使われたRuffleには、FlashコンテンツからJavaScriptを通じて埋め込み先のページとやり取りできる「allowScriptAccess」という設定があります。初期値は無効で、信頼できるコンテンツだけに有効化する設定です。通信時には、コンテンツを読み込んだページと同じオリジン、つまりプロトコルやホストなどが共通する送信先に、認証情報であるCookieが常に送られます。

別の文書をページ内に埋め込むHTMLのiframeには、埋め込んだ内容の動作を制限するsandbox属性があります。これは、今回欠けていたサンドボックスに関連する仕組みです。スクリプトの実行や同一オリジンとしての扱いを個別に制限でき、同一オリジンとして扱わなければ、Cookieやデータ保存領域、一部のJavaScript機能へのアクセスが制約されます。同じオリジンの埋め込みでスクリプト実行と同一オリジンの扱いを両方許可すると、埋め込まれた文書がsandbox属性を取り除けるため、制限が無効になり得ます。

不正なAPIキー7人分を削除

ワームは、外部からアカウントを操作するための認証情報であるAPIキーの作成も試みました。作成できたのは過去1時間以内にパスワードを入力していた7人分で、これらのキーは使われないまま削除されました。継続的なアカウント侵害の兆候はありません。

OWASPの認証指針では、パスワードやメールアドレスの変更など重要な操作に再認証を求めています。現在の認証情報を確認しない場合、XSSなどを通じて、攻撃者がパスワードを知らなくても重要な操作を実行できるためです。

また、二要素認証の復旧後も、発行済みのセッションやトークンが有効なままなら、以前の権限が残る場合があります。APIキーはセッションとは別の認証情報として扱われるため、今回削除された7人分のキーのように、個別に失効させる必要があります。Danbooruは、パスワード変更、二要素認証の有効化、ログイン履歴とAPIキーの確認を、利用者向けの確認項目に挙げました。

LLM利用への警戒と研究で示された条件

運営側のevazion氏は、攻撃者が大規模言語モデル（LLM）を使って脆弱性を見つけたと判断し、早期に再開すれば別の弱点も探されると警戒しました。このため、最初の脆弱性を修正した後も、見つけられるセキュリティ上の問題への対応と全般的な防御強化を続けました。停止中には、先送りしていたサーバー保守や更新も実施し、これにも数日を要しています。

LLMによる攻撃支援を扱う研究では、成功しやすさは対象や実行条件によって異なります。Bin Liu氏らの研究チームは、既知の脆弱性80件を使ったWeb脆弱性の再現評価で、単純なライブラリーの脆弱性では一定の成功を得た一方、複数の構成要素を持つサービスでは環境設定や認証が障壁になったと報告しました。認証情報が不完全な条件では、性能が33％超低下しました。

別の研究であるSEC-benchでは、イリノイ大学アーバナ・シャンペーン校とパデュー大学の研究チームが、C/C++のメモリー安全性に関する既知の脆弱性200件を検証しました。そのデータセットを使ったLLMエージェントの評価では、脆弱性を実証するコードの生成成功率は最大18.0％、修正の成功率は最大34.0％でした。