【ITニュース解説】Logging Gaps That Hide Replayed MOVEit Transfer Sessions

MOVEit Transferというファイル転送ソフトウェアに、「認証リプレイ攻撃」と呼ばれる種類の脆弱性が見つかった。この脆弱性は、不正なアクセスが起こった際に、システムのログだけではその事実を見破ることが非常に難しいという点が特徴である。システムエンジニアを目指す上で、このようなセキュリティの落とし穴と、それに対する対策を理解することは極めて重要である。

今回話題になっているのは、CVE-2026-89070という識別番号が付与された脆弱性で、OpenID Connect（OIDC）という認証技術のモジュール内に存在する。OIDCとは、インターネット上でユーザーの認証情報を複数のWebサービス間で安全に連携させるための標準的な仕組みの一つであり、例えばGoogleやFacebookのアカウントを使って別のサービスにログインする際などに利用されている。この脆弱性は、認証をバイパス（回避）できる可能性があり、その深刻度を示す共通脆弱性評価システム（CVSS）のスコアは7.5と、比較的高いリスクに分類されている。影響を受けるMOVEit Transferのバージョンは2025.1.6より前、2026.0.3までのものが該当し、最新の修正パッチを適用することが求められる。

認証リプレイ攻撃とは、簡単に言えば、一度行われた正当な認証の情報を攻撃者が盗み出し、それを再利用してシステムに侵入する手口である。攻撃者は、ユーザー名やパスワードそのものを直接盗むのではなく、認証が成功した際に発行される「セッション情報」や「認証トークン」といったものを横取りする。そして、その盗んだ情報をあたかも正規のユーザーであるかのようにシステムに提示し、アクセスを試みる。この攻撃が厄介なのは、システム側から見ると、攻撃者が提示する情報が正規のものと全く同じに見える点にある。アプリケーションは、与えられた認証情報が有効であれば、それを「正当な認証成功」と判断し、通常のログインフローとして処理してしまうため、攻撃が行われていることに気づきにくい。

MOVEit Transferのログは、誰が、いつ、どのIPアドレスから、OpenID Connect経由で認証したか、そしてその後どのような操作を行ったかといった情報を正確に記録している。しかし、これらの記録は、攻撃者がリプレイ攻撃を成功させた場合でも、表面上は「正規のユーザーが正規の手順でログインし、操作を行った」と表示される。つまり、ログ自体は嘘をついていないが、その背後で不正が行われていることを見抜くための決定的な情報が不足しているのだ。

システムプラットフォーム側で唯一手がかりとなるのは、ユーザーの「行動パターン」の異常である。例えば、普段とは異なるIPアドレスからのログイン、通常のダウンロードパターンから外れたファイル転送、勤務時間外や異常な時間帯の活動、あるいは一つのアカウントで同時に複数のセッションが確立されている、といった状況だ。これらは、何か問題が起きているかもしれないという「兆候」ではあるが、これだけで不正であると断定することはできない。出張先からのアクセスや、複数のデバイスからの利用など、正当な理由でこれらの異常が発生することもあるからだ。そのため、これらの情報だけでは、リプレイ攻撃の確たる証拠とはならない。

では、この不足している証拠はどこにあるのだろうか。それは、認証情報を発行する「Identity Provider（アイデンティティプロバイダー、略してIdP）」側にある。OIDCのような認証連携の仕組みでは、ユーザーの本人確認を行う専門のシステム（IdP）が、認証が成功したことを証明する「アサーション」と呼ばれる情報を、サービスを提供するアプリケーション（この場合はMOVEit Transfer）に発行する。このアサーションには、「アサート（トークン）識別子」という一意のIDが含まれており、これが「この認証がいつ、誰によって、どのサービス向けに発行されたか」を特定するための鍵となる。

もしIdP側で、このアサート識別子を含めた詳細な認証発行記録が保存されていれば、検出は可能になる。例えば、ある特定のアサート識別子が、本来一度しか使われないはずなのに、ログ上で複数回利用されていることが判明すれば、それはリプレイ攻撃が行われた明確な証拠となる。つまり、「この認証情報が、正規のユーザーによって一度だけ使われたのか、それとも攻撃者によって複数回再利用されたのか」を比較することで、不正を見抜けるようになるのだ。しかし、多くのシステムでは、デフォルトの監査設定ではこの識別子を記録していない場合が多く、インシデント発生後にこの情報を参照することができない、という問題がある。

このログのギャップを埋め、認証リプレイ攻撃を検出・防止するための具体的な対策がいくつか存在する。まず最も重要なのは、Identity Provider側でMOVEit Transferアプリケーション向けに「識別子レベルのロギング」を有効にすることだ。これにより、アサート識別子を含めた詳細な認証発行記録がIdPのログに残るようになる。次に、このログの「保存期間」を十分に長く設定することが重要である。コンプライアンス上の最低限の期間だけでなく、万が一インシデントが発生した場合の調査に耐えうる期間（数ヶ月から数年）を確保する必要がある。

さらに、MOVEit Transferのような「リライングパーティー」（IdPが発行する認証情報を信頼して利用するサービス）向けのアサーションの有効期間をできるだけ短く設定することも有効な対策だ。例えば、15分間だけ有効なアサーションであれば、仮に攻撃者に盗まれたとしても、不正に利用できる時間が短くなり、被害を限定できる。数時間にわたって有効なアサーションに比べれば、攻撃の成功率も格段に下がる。最後に、IdPとMOVEit Transfer間の「時刻同期」を正確に行うことも忘れてはならない。認証の鮮度（有効期限内であるか）がタイムスタンプに依存しているため、両者間の時刻にずれがあると、本来は拒否すべき不正な認証を受け入れてしまったり、逆に正当な認証を誤って拒否してしまう可能性が生じる。

万が一、セキュリティインシデントが発生し、リプレイ攻撃の可能性が疑われた場合、調査官はIdPのログを詳しく分析する必要がある。具体的には、攻撃が疑われる期間（露出期間）において、MOVEit Transferアプリケーション向けに発行されたアサーションの記録をIdPから抽出し、それをユーザーごとにグループ化する。そして、各ユーザーのアサート識別子に重複がないかを確認する。もし重複が見つかれば、その発行タイムスタンプと、MOVEit Transfer側の認証イベントログを比較し、不一致がないか、あるいは同じ識別子が複数回使用されていないかを確認する。さらに、そのセッションで行われたファイル転送などの活動が、対象ユーザーの通常の業務内容や職務範囲と合致しているかも照合する。これにより、正規のユーザーによる行動か、それとも不正な行動かを判断する手助けとなる。

インターネット上には、ZoomEyeのようなツールを使って「MOVEit」製品のフィンガープリントを持つシステムが多数存在することが確認されている。これは、多くの組織がこのソフトウェアを利用していることを示しており、それだけこの脆弱性の影響範囲が広い可能性を示唆している。システムエンジニアにとって、セキュリティはシステムの信頼性を保つ上で不可欠な要素であり、特にログの適切な管理と設定は、インシデントの早期発見と対策において、非常に重要な役割を果たすことを今回の事例は教えてくれる。