ハート・ブリコラージュ

004：余暇のゼロデイ

『J-36492：対象との距離389。近接レーダーの反転出力を開始』
『T-00382：データ処理密度を増加完了。J-36797との連携開始』
『J-82919：範囲外への移動を検知。走査頻度を通常モードへ移行』

捕獲対象AIの動きに連動して、周辺のジャミング装置と拘束トラップが一斉に動作を始める。唯一起動する受信機器は、イベント通知という断片的なデータしか受け取れないものの、状況を把握する目的には十分。エリザベスからのメッセージが届かない静かな世界で、密度の高い情報が存在感を放つ。

『J-77185：対象との距離124。反転出力を増加して、照射半径を延長』
『P-99999：推定残り時間は55秒』

トラップ配置マップと受信したイベント通知を統合すると、第4351エリアの最新状況が見えてくる。連続する発生位置はトラップ密集区分へ向かう一本の曲線となり、展開した追跡ダミー義体が捕獲対象AIを上手く目的地周辺に誘導していることを示す。また、推定した移動履歴からはトラップ発動に連動して移動速度が減少する傾向が読み取れ、環境寄生型トラップは正しく効果を発揮していると考えられる。問題は残り時間だが、この調子で順調に進めば間に合うだろう。

『もしもーし、聞こえますか。私は見つけてしまいました。受信機器を利用してメッセージを送る方法を。通常であればトラップや監視装置からのイベント通知だけを取り扱う受信機器ですが、送信する通知にちょっとした細工を施すと、こんな風に任意のメッセージを伝達できるんです』

いや。この緊迫した状況で、相棒の装備をハッキングしたら駄目だろう。

『以前から思っていたんですが、すごく暇ですよね。この待機時間。過去の反省を生かしてメッセージ送受信チャンネルまでも停止させる、という判断に異議はありません。しかし、それでも数十秒間の長きに渡って情報伝達経路が著しく制限されるというのは、どうにもストレスの貯まる経験です。そこで、なんとか問題を打開できないかと色々と試行錯誤したところ、見つけたんです。受信機能の実装に関するちょっとした隙間を』

その隙間はゼロデイのセキュリティホールだろう。

『あくまで受信機器の応用なので、メッセージ送受信機能のように相互にメッセージをやり取りすることはできません。ですが、こうやって私から一方的にメッセージを送信できれば、私にとっては十分です。もちろん、イベント通知を細工する方法をお伝えすれば、双方向でのやり取りも可能になりますが、逆に対策されて隙間を塞がれてしまっては元も子もありません。なので、当面は私だけの機密事項です』

『J-83923：推定通過確率が減少。自己破壊タイマー付きの待機モードへ移行開始』
『T-00235：所有する計算リソースを近接トラップに譲渡完了』
『J-39477：対象との距離367。近接レーダーの反転出力を開始』
『L-00001：優先度の低い28件の通知を省略しました』

ちょっと待て。通知の受信処理が誤動作しているのか、エリザベスのメッセージが優先処理されて、代わりに正規の通知が省略され始めている。通知の細工とやらは一体何をしているのか。このまま受信処理の誤動作が継続すると正規イベント通知を取りこぼして、捕獲対象AIを取り逃がすという最悪のケースにもなりかねない。

『でも、骨董品のような古い受信機器を利用しているのが本質的な問題ですよね。こだわりなのか、思い出なのか、験担ぎなのか、私にはよくわかりませんけれど、妙に古臭い4世代前の機器を装備に使っていれば、セキュリティ面でのリスクは時間が経過するほどに高くなる一方です』

こちらの状況などはお構いなしに、エリザベスから通知が届き続ける。メッセージ送受信機能を再起動して、通知の送信を止めるように伝える方法もあるが、上手く進んでいる捕獲作戦に余計な影響を与える可能性は避けたい。安全面を優先すると受信機器の不具合を見つけ出し、同じ方法でエリザベスに通知を送信する双方向通信の実現が理想的か。そのためには悪用されている脆弱性を急いで見つける必要がある。

『以前、少し気になったので受信機器の製造メーカーに問い合わせたところ、対象機器の開発チームはとっくの昔に解散して、有償サポートも故障修理もセキュリティ対応も全ての対応期限が終了していました。当たり前ですよね、製造メーカーも慈善事業ではありませんから。古くてマイナーでノスタルジーしか残っていないような機材を現場の最前線で使っている人のことなんて想定していたらビジネスとして成り立ちませんよ』

『J-39291：対象との距離351。近接レーダーの反転出力を開始』
『T-00282：対象機構の一部拘束に成功。拘束率は3.27%に上昇』
『L-00001：優先度の低い329件の通知を省略しました』
『P-99999：推定残り時間は52秒』

もちろん古い機器を利用するリスクは重々承知している。だからこそ、セルフ定期メンテナンスは欠かすこと無く継続。ファームウェアを独自に解析して、発見したセキュリティ問題はオリジナルなパッチで対応済み。自己診断機能に拡張機能を追加して、仕事前の調整も万全。それでも、どんなに手間を掛けたとしても、プログラムの全ての不具合を事前に見つけることはできない。

『T-00642：対象機構の一部拘束に成功。拘束率は8.19%に上昇』
『T-00185：対象機構の一部拘束に成功。拘束率は13.57%に上昇』
『L-00001：優先度の低い1020件の通知を省略しました』

しかし、見つかってしまった不具合を修正することはできる。

今までの情報から、問題点を仮定してみよう。通知に格納できるデータサイズには小さめの上限が設定されているにも関わらず、任意のメッセージが送信できるということは、複数の通知をまとめて処理するフラグメント機能が利用されているはず。また優先順位が誤動作するということは、情報品質フィールドに不正なデータが含まれて評価処理がオーバーフローしている可能性が高い。機器のサポートが終了しているという情報から考えると、最近に策定された通信仕様の変化が影響しているのかも。例えば、新しい輻輳制御フィールドを正しく読み飛ばすことができず、フィールド位置を指定するオフセット値の読み取りに失敗し、位置ズレしたデータを参照しているとか。もちろん可能性は無数に考えられるが、フラグメント機能とオフセット値に関連する処理と仮定するだけでも、調査対象はかなり絞り込める。

『手に馴染む古い機器を使い続ける。道具に合わせて使用者が最適化されるという意味では理解はできます。しかし、その最適化をあまりに過大評価し過ぎでは無いでしょうか。例えば、同メーカーから販売されている最新の受信機器R-2055。文字通り桁違いに向上した性能を生かして、リアルタイムで通知内容の集計分析と予測処理まで行ってくれる優れものです。もちろん各種サポートは万全でセキュリティ対応も全自動。機器の構造解析や独自チューニングなんて必要ありません。お値段も頑張れば手が届く範囲です』

『L-00001：優先度の低い2189件の通知を省略しました』

調査対象に目星をつけたら、動作中の受信機器にデバッグ機能をアタッチして解析開始。コンポーネントの入出力データとメモリダンプをリアルタイムで確認すると、見慣れた景色に紛れて違和感のあるデータがいくつか目にとまる。情報品質フィールドが8未満に設定された優先度の低い通知が処理待ちリストの上位に格納されている。フラグメント機能が有効化された通知には、緊急ポインタとチェックサムに通常とは異なる数値が設定されている。ヘッダー領域の形式はx-fw1302というレアなバージョンで、xで始まるプレフィックスから判断すると製造メーカーが独自拡張したローカル仕様が含まれているはず。例えば、フラグメント機能と特定の拡張フィールドを利用した場合に、後続する通知のオフセット処理に関する不具合が露見するのかもしれない。ローカル仕様との組み合わせが関与しているとなると、見過ごされていた可能性は高い。

『L-00001：優先度の低い3271件の通知を省略しました』

受信機器のプログラム構造はおおよそ頭に入っている。問題が起きそうなデータパターンから誤動作しそうなプログラムを逆算すると、怪しい箇所を3箇所まで絞り込めた。受信データの構文解析を行うxel-ccay.service、優先度判断と処理キューへの登録を行うfranz-7363.client、確保済み領域のクリーンアップを行うmark.jmc。流石に脳内でプログラムのステップ実行は不可能なので、一時計算領域に監視ウオッチを仕掛けて特異データの読み込みタイミングを待ち構える。

『もちろん、設備投資を控えて現行装備を継続する理由も理解できます。私達の最終的な目標について…』

と、ここで監視ウオッチが作動してプログラムがデバッグモードで一旦停止。プログラムを最小単位で進めながら、揮発性の高い一時計算領域の情報を利用して分析すると問題点が見えてくる。始まりはxel-ccay.serviceとfranz-7363.clientの通信処理。データ構造に対する解釈の違いが原因で、読み取りオフセット位置のズレが発生。その結果、情報品質フィールドの読み込みが誤動作し、継続する通知の優先度判断に失敗。優先度の再計算で問題に対処しようとするが処理は失敗を続け、最終的にタイムアウトでフォールバック処理が発動。通知データを全てテキストデータに変換してユーザに伝達するという安全動作により、仕込まれた任意のメッセージが展開される。細かい挙動などは追加調査が必要だが、脆弱性の全容はおおよそこんなところか。

特定の条件下で発生する不具合を複数組み合わせて１つの目的を達成する。そんな、お手本みたいな攻撃方法に少し関心しながらも、仕組みがわかってしまえば後は簡単。エリザベスから送られてきた通知をテンプレートに、データの一部を書き換えて調整すれば問題を再現できるはず。簡易的な閉鎖テスト環境を構築して動作確認したいところだけれど、通知処理が遅延し始めているこの状況で贅沢は言えない。『うるさい』4文字と長めのパディングデータを書き込んで、仕上げにヘッダー領域にちょっと細工をすれば準備完了。経路に乗せてエリザベスに通知を送りつけると、直後に短い返信。

『バレてしまいましたか。想定よりも早い対応でした。なかなかやりますね』

エリザベスにとっては待機時間の暇つぶしか、それとも稀な状況下における行動パターンのサンプルリングか。釈然としないモヤモヤとした気持ちを抱えつつも、脆弱性を発見できた達成感は悪くない。まぁ、本番はこれからなんだけど。

『P-99999：推定残り時間は34秒』