1枚の番号から始まる、思った以上に長い連鎖
画像: samcurry.net より
車のセキュリティというと、まず思い浮かぶのは鍵や通信の暗号化だろう。だが実際には、遠隔操作の入口はもっと地味なところにある。スマホアプリ、認証基盤、社員向け管理画面、そしてその周辺にぶら下がる補助機能だ。そこが崩れると、鍵そのものを触らなくても車の操作に近づいてしまう。
今回の話題は、その入口を「ナンバープレート」からたどっていく。オーストラリア側の調査では、まずナンバープレートから州の登録照会でVINを引き、さらに登録情報の粒度を上げていった。番号だけではただの識別子に見えるが、実務上は車台番号に結びつき、そこから所有者情報へ、さらに認証基盤のアカウントへとつながる。各段は単独では些細でも、鎖になると急に重くなる。
自動車メーカーの connected car では、ユーザー向けアプリが表に出ていても、裏では社内向けの管理画面や共通の認証基盤が動いている。利用者から見えるのは「車を開ける」「位置を見る」といった機能だけだが、その前段にはログイン、セッション、トークン交換、権限確認がある。攻撃者はたいてい、最後の操作画面より前の層を狙う。
この種の事案が厄介なのは、攻撃の各段階がそれぞれ“ありそう”に見えることだ。VIN の参照、顧客情報の検索、メール確認、社員向けの管理ツール、どれも業務上は必要に見える。だからこそ、一本の線として見ないと危険が見えにくい。表面上は雑多な機能でも、裏では同じ認証基盤に接続されていることがある。
アプリの裏で同じ認証基盤が動いていた
調査の起点になったのは、スマホアプリの通信だった。アプリを分解すると、ブランドごとに見た目は違っても、ログインの流れはほぼ同じで、ForgeRock の認証基盤に戻っていく。最初のリクエストは空の JSON を投げ、サーバーが次に何を求めるかを返す。つまり、ログイン画面は固定のフォームではなく、サーバー主導で会話が進む。
ここで押さえたいのは、認証が「1回の入力で終わるもの」ではない点だ。サーバーは authId を返し、クライアントは callback に従って値を埋める。アカウント、端末、ワンタイムパスワードなどの段階を、サーバーが順に案内する。この流れは便利だが、同じ基盤に複数ブランドのアプリが乗ると、ひとつの穴が横展開しやすい。
さらにその先では、ログインセッションがそのまま車両操作の権限になるわけではない。いったん ForgeRock のセッションを取り、別のトークンに交換して、はじめて車両 API に触れる。普通の利用者から見れば自然な設計だが、攻撃者の視点では「認証が通ったあとに何を発行するか」が本丸になる。そこを奪えれば、車に対する遠隔操作が現実味を帯びる。
似た構図は他社事例にもある。ユーザー向けアプリの裏側に、社員向けや管理者向けの機能が残り、そこが認証の抜け道になる。自動車業界はとくに、販売店、整備、テレマティクス、モバイルアプリが絡み合うので、ログインの経路が多い。日本の現場でも、ブランド別アプリを持ちながら中核だけ共通化している構成なら、同じ種類の不整合が起きうる。
WAFは止めたのに、サーバーは通した——そのズレ
問題の核は、WAF とサーバーが同じ URL を同じものとして扱っていなかったことにある。WAF は危険そうなパスを先に弾くが、Java 側のサーブレットコンテナは別の形に正規化してから解釈する。さらにその奥のアプリも、また別の規則でルーティングする。外から見るとひとつの文字列でも、層ごとに見えている“道”が違う。
このズレを狙うと、表向きは静的ファイルの配下に見せながら、実際には管理用パスへ届くことがある。たとえば /static のような見かけの前置きに、エンコードされたスラッシュ、ドットセグメント、セミコロンを混ぜる。どこで復元されるか次第で、WAF には安全な静的資産に見え、オリジンでは /openidm や /system/console に化ける。
調査者は、まずヘルスチェック系のエンドポイントで挙動を確かめた。ある形ではロードバランサーの 403 で落ち、別の形では認証フィルターまで届いて 401 が返る。さらに Felix の Web Console では、認証を通すと bundle の一覧が見えた。つまり、入口の防御は働いているように見えて、別の解釈経路から中に入れてしまう余地があった。
ここで重要なのは、WAF そのものが無能だったという話ではないことだ。むしろ、危険なパスをかなり意識していたからこそ、別の正規化経路が隙になった。防御が厚いのに穴が残るのは珍しくない。特に Java 系のスタックでは、URL の扱いが複数箇所に分散しやすい。前段の監視、サーブレット、アプリ本体が、同じ文字列を同じ意味で見ているとは限らない。
2時間で塞がった理由を考える前に、見えている範囲を押さえる
この事案では、報告後およそ2時間で修正と資格情報のローテーションが行われたとされる。短い。だが、ここまでの流れを見ると、修正が急がれた理由は見えてくる。単なる認証画面の不具合ではなく、認証基盤そのものを経由して任意の顧客セッションを作れてしまう可能性があったからだ。その先に車両操作がぶら下がっている。
なお、ForgeRock 側の連鎖は複数地域の顧客を抱えるサービスに対するもので、完全なチェーンを確認したのは米国アカウントと車両に限られている。ここは大事で、広く影響しうる構成でも、実証した範囲と想定される範囲は分けて読む必要がある。第三者が見た事実と、運用側がどこまで把握していたかも同じではない。
自動車メーカーの connected car は、ユーザー体験としては一つのアプリに見えるが、裏側では認証、顧客管理、車両テレマティクス、社員用ツールが絡み合う。どこか1か所で URL の見え方がずれると、保護したかった管理用機能がすり抜ける。日本の読者に引きつけて考えるなら、販売店向け、整備向け、オーナー向けが別々に進化したサービスほど、同じ構造の事故を抱えやすい。
ここまでで分かるのは、番号から車両操作へ至る道筋が、単一の脆弱性ではなく「積み重なった前提」でできていたことだ。アプリ、認証、管理画面、WAF、サーブレットの順に見ても、ひとつひとつはもっともらしい。だが、その間に生まれたズレがどこで決定的になったのかは、まだ半分しか見えていない。あとは、URL がどう“別の道”に変わったのかだ。
👉 続き（核心はここから）は PaPoo で読めます: https://papoo.work/doc/595cabb82492858e