cat posts/%e4%bb%8a%e9%80%b1%e3%81%ae%e3%82%bb%e3%82%ad%e3%83%a5%e3%83%aa%e3%83%86%e3%82%a3%e8%80%83%e5%af%9f%ef%bc%9amoveit-transfer-%e3%81%ae%e8%aa%8d%e8%a8%bc%e3%83%90%e3%82%a4%e3%83%91%e3%82%b9%e8%84%86.md

今週のセキュリティ考察:「鍵を渡していないのにドアが開いた」MOVEit Transfer の認証バイパス

「鍵を渡していないのにドアが開いた」——それが今週話題になった 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