「鍵を渡していないのにドアが開いた」——それが今週話題になった MOVEit Transfer の脆弱性(CVE-2024-5806、CVSS 9.1)の本質だ。公開から 24 時間で悪用が始まった。
「本物らしく見えれば通れる」認証の罠
SFTP の公開鍵認証は本来こういう流れだ。「この鍵、サーバーに登録してある?」→「ある」→「じゃあ本物か確かめる」→「確認できた、入って」。MOVEit の実装には 3 番目のステップ——「本物か確かめる」——に抜け穴があった。細工したリクエストを送ると、確認の答えを返す前に「入って」の状態に遷移してしまう。鍵の持ち主かどうかを確かめずに入館証を渡している状態だ。
sequenceDiagram
autonumber
participant A as 攻撃者
participant S as MOVEit SFTP
participant DB as ファイルストレージ
A->>S: 細工した公開鍵リクエスト
Note over S: ⚠ 本人確認をスキップ
S-->>A: 認証成功(バイパス)
A->>DB: ファイル一覧を要求
DB-->>A: 機密ファイルを返却
A->>DB: 窃取・改ざん
なぜ同じ製品が 2 年連続でやられるのか
去年の MOVEit は SQL インジェクション(CVE-2023-34362)、今年は認証バイパス。「同じ場所の別の穴」が続いている。これは珍しくない。1 か所で脆弱性が見つかると、同じコードの近くを掘り進める研究者・攻撃者が増える。「この製品、狙われやすくなった」と認識して動くのが現実的な対応だ。
flowchart LR
A[2023年\nSQL インジェクション] -->|同じ製品の\n別の入口| B[2024年\n認証バイパス]
B -->|継続的な\nターゲット化| C[次の脆弱性を\n掘り進める攻撃者]
style A fill:#e67e22,color:#fff
style B fill:#c0392b,color:#fff
style C fill:#7f8c8d,color:#fff
今日できること
MOVEit を使っているなら今すぐパッチ(2024.0.1 以降)を適用する。SFTP ポートの外部公開範囲を確認して IP 制限をかけ、認証ログの過去 7 日分に不審なリクエストがないか確認する。
MOVEit を使っていないとしても——SSH 公開鍵認証を自前で実装している部分があるなら、「鍵の検証」を省略できるコードパスが存在しないか確かめてほしい。今回の欠陥は製品固有の問題ではなく、認証処理の「順序を守る」ことがいかに重要かを示している。
一つ問いかけ
「CVSS 9.1 のパッチが出た日に気づける仕組みがあるか」を確かめてほしい。セキュリティアドバイザリを Slack や RSS に流す仕組みはあるか。仕組みが先、対応が後だ。今回のように 24 時間で悪用が始まる世界では、「あとで読む」では間に合わない。
参考: BleepingComputer – New MOVEit Transfer critical bug is already under attack