テクノロジーの急速な進歩は私たちの日常生活に大きな影響を与え、私たちはますますテクノロジーに依存するようになっています。医療分野も例外ではありません。医療関係者は、テクノロジーが正確な情報を提供してくれると信頼し、そのデータに基づき人の人生を左右する意思決定を行います。マカフィーのAdvanced Threat Research(ATR) チームは、セキュリティへの理解と認識を広めるために、こうしたデバイス（機器）についての調査を続けています。
ペースメーカーやインシュリンポンプなど、医療機器の一部はすでにセキュリティ上の問題に関する検証が済んでいます。調査対象を絞るため私たちは医師と話し合い、助言を受けるうちに、私たちは患者のバイタルサイン（生命兆候）の正確さが医療従事者にとっていかに重要かを知りました。ショーン・ノルデック博士は「バイタルサインは臨床方針の決定にあたって欠かせないものです」と説明します。患者の臨床モニターおよび関連システムは、医療従事者に対し、医療方針決定に必要なバイタルサインを得るために欠かせません。今回の調査ではこのシステムを対象としました。
攻撃対象範囲の環境準備
ほとんどの患者監視システムは、臨床モニターと中央監視ステーションの少なくとも2つの基本的なコンポーネントで構成されています。これらのデバイスは、TCP / IPを介して有線または無線でネットワーク接続されています。中央監視ステーションは、複数のベッドサイドモニターで患者のバイタルを収集、一人の医療従事者が複数の患者を経過観察できるようになっています。
eBayを通じて、臨床モニターと、互換性のある中央監視ステーション2点を手ごろな価格で購入しました。臨床モニターは、心拍、酸素レベル、および血圧を監視し、有線と無線の両方のネットワークで患者の情報を蓄積しているようです。中央監視ステーションはWindows XP Embedded上で実行、2つのイーサネットポートを備え、限定的なキオスクモードで起動します。これらデバイスは両方とも2004年頃に生産されていますが、一部の地方の病院では、現在も使用されているデバイスです。
この2つのデバイスは、さまざまな攻撃の対象となる危険があります。中央監視ステーションは、Windows XPを搭載するデスクトップコンピューターと同じように作動するので、セキュリティ コミュニティによる広範囲の調査が行われています。中央監視ステーションで実行されているアプリケーションは古く、脆弱性が発見された場合でも、旧バージョンのOSに縛られていることが多いのです。臨床モニターのファームウェアについての脆弱性は評価することができますが、これはシステム内の2つのデバイスのうちの1つにしか影響を与えず、活用しづらい侵入経路です。このため、2つのデバイス間の通信が攻撃経路として最も関心を引くことになります。というのも、もし通信が侵害された場合、リモート攻撃で両方のデバイスが影響を受ける恐れがあるからです。こうした想定に基づき、今回の調査対象としてまずネットワークに注目しました。ノルデック博士は、中央監視システムに送信された情報がリアルタイムで変更される可能性があることは、医療関係者にとって最も重大な懸念材料だといいます。私たちは調査課題として、「ネットワークを介して送信される患者のバイタルをリアルタイムで修正することは可能か？」という点を追求しました。
環境のセットアップ
どんなデバイスでも脆弱性評価を行う場合、最初に設計されたとおりにデバイスを操作することをお勧めします。臨床モニターは、患者のバイタルサインを経過観察することが役割です。私たちは、テストをするにあたって、こうしたバイタルサインを正確にシミュレートする方法を検討しました。多くのハードウェアシミュレーターが販売されていますが、値段はさまざまです。シミュレートするにあたって最も安価で簡単にできるバイタルサインは心拍でした。eBayで購入した心電図（ECG）のシミュレーターは、100ドル（米国）かかりませんでした。次の図は、テストネットワークを示しています。
試験では、標準スイッチに患者モニター（左）、中央監視ステーション（右）、調査用PC（上）を接続。 調査用PCは、スイッチのモニターポート上に構成され、中央監視機器と臨床モニターの間のトラフィックを傍受。 ECGシミュレーターは臨床モニターに設置した。
調査
設定されたネットワークで実行中のデバイスを監視するために、Wiresharkを利用しました。最初のテストでは、中央監視ステーションだけを起動し、ネットワークトラフィックを観察しました。
上記のスクリーンショットでは、いくつかの基本的な点で注目すべき点が観察されます。まず、中央ステーションがソースと宛先ポート7000で10秒ごとにユーザーデータグラムプロトコル（UDP）ブロードキャストパケットを送信していることがわかります。デバイス名を知らせるペイロード内のクリアテキストのASCIIも表示されます。これらのパケットを数分間収集して観察すると、これが標準的な動作だと見なすことができます。中央ステーションはWindows XP搭載マシン上で実行されているため、アプリケーションで使用されるバイナリを迅速にリバースエンジニアリングすることで、この情報を検証することができます。いくつかのライブラリをInteractive Disassembler Proに入力すれば、シンボルとデバッグ情報が残されていることが明らかになります。わずかなクリーンアップとデコンパイラからの作業によって、次のコードが表示されます。
このループは、一部の医療機器で使用されるプロトコルであるRwhatを送信する関数を呼び出します。また、パケット間で大量の待ち時間を取得するために導かれる関数が表示され、その結果はWindowsのスリープ機能にプラグインされます。このコードブロックは、Wiresharkによって表示された内容を確認し、コミュニケーションが一貫していることが間違いないことを示します。
中央監視ステーションに関する基本的な知識を得たので、次のステップとして患者モニターで同じテストを行いました。中央ステーションの電源を切って患者モニターを起動し、Wiresharkを使用してネットワークトラフィックを監視しました。
10秒間の秒差と患者データのテキスト表示など、患者モニターのブロードキャストパケットに関して同様に観察できます。これらのパケットでは、送信元ポートはインクリメントしますが、宛先ポート7000は中央監視ステーションのものと同様でした。これらのパケットの多くをレビューしたところ、ペイロードのオフセット0x34には、パケットごとに0xA、つまり10ずつ増分するカウンタをもつことがわかりました。患者モニターに潜在的なダメージを与えることなく、コードをレビューするファームウェアをうまく抽出する方法はありません。しかし、中央監視ステーションは、これらのパケットを受信するコードを持つ必要があります。中央ステーションのバイナリを少し掘り下げていくと、患者モニターからブロードキャストパケットを解析するセクションを見つけました。
コードの最初の行は、パケットのペイロードと12バイトを解析しています。Wiresharkのキャプチャでペイロードから12バイトをカウントすると、クリアテキストで患者データの開始が表示されます。次に呼び出される関数はparse_logical_nameで、その2番目のパラメータは送信される文字列の上限です。このフィールドの最も長い文字列は0x20、つまり32バイトです。後続のコードは、この情報が空であるかどうかを処理し、データをlogical_nameフォーマットで保存します。このレビューによって再びWiresharkでリアルタイム表示される内容を確認できます。
それぞれのデバイスについて別々のネットワークトラフィックを確認できたことで、それらがどのように相互作用するかがわかります。ネットワーク設定を使用し、ECGシミュレーターを起動すると、中央監視ステーションと臨床モニターが起動します。
すべてが作動したら、再びWiresharkを使用してトラフィックを調べます。すると新しいパケット群が表示されます。
前述の画面キャプチャでは、IPアドレス126.4.153.150の患者モニターが同じサイズのデータパケットを126.1.1.1の中央監視ステーションに送信していることがわかります。送信元ポートは変更されていません。
これらの基本的なテストを通して、多くのことがわかりました。
・2つの機器は非暗号化UDPによって交信されている
・ペイロードにはカウンタと患者情報が含まれる
・ブロードキャストアドレスでは、機器がお互いのアドレスを事前に知る必要はない
・データが送信されるとき、別個のパケットにはウェーブフォームが含まれる
プロトコル攻撃
これまでの調査の結果、リプレイ攻撃に最適な条件かもしれないことが分かりました。このような攻撃はネットワークを介してリアルタイムでデータを変更するという私たちの目標を満たすものではありませんが、足りない要件についてより多くのヒントを提供するという点で目標を到達するのに役立つかもしれません。
シミュレートされた心拍数のパケットをキャプチャし、PythonのScapyライブラリを使ってキャプチャを再生しようとしました。患者モニターをオフにし、中央監視ステーションが情報を聞ける状態で再生しました。数回にわたり試行しましたが、このテストは失敗しました。この失敗は、このシステムがデバイスに対し、特定のIPアドレスにデータパケットを送信する以上のことを求めていることを示しています。
データパケットに送信されたパケットをより詳細に調べてみました。その結果UDPでパケットを送信しても、2つのデバイスの間で何らかのハンドシェイクがされることがわかりました。次の図は、このハンドシェイクについて説明しています。
吹き出し中、CMSは中央監視システム、PMは臨床モニターを指す。
ハンドシェイク間に起こっていることを確認するため、このハンドシェイクの各フェーズをTCP 3ウェイハンドシェイクのフェーズに関連付けてみます。 （これは単なるアナロジーであり、機器は実際にはTCPの3ウェイハンドシェイクを実行していません）。
中央監視ステーションは、まず、ポート2000へのパケットを臨床モニターに送信します。これは “SYN”パケットと考えることができます。臨床モニターは中央ステーションに応答しますが、この際、最初に要求した送信元ポートに応答することに着目してください。これは、“SYN、ACK”と考えることができます。中央ステーションは最終的な“ACK”を送信し、3ウェイ（または3ステップ）のハンドシェイクを実質的に完了します。このステップの直後に、患者モニターは別のパケットを“SYN”パケットの最初のポートに送信します。中央モニターは、ポート2000の患者モニターに新しい送信元ポートで応答します。直後に、以前の交信で命名された新しい送信元ポート3627に送信されるデータパケットが表示されます。
この試験では、リプレイ攻撃がうまくいかなかった理由を知ることができます。中央ステーションは、着信データに対してどのポートが開いているかを接続ごとに定義しています。リプレイ攻撃を試みるときにこれを考慮する必要があります。以前のScapyスクリプトを修正してハンドシェイクを説明し、リプレイ攻撃を再テストしました。新しいハンドシェイクコードを使用しても、テストは失敗しました。“SYN,ACK”パケットをもう一度見てみると、失敗の理由とおぼしきものがわかりました。
オフセット0x3Dは、これらのパケットの1つが送信されるたびにインクリメントされる必要があるカウンタです。この場合、患者モニターの送信元IPアドレスは0x2Aと0x30のオフセットでペイロードに埋め込まれます。この埋め込みIPアドレスは、再生中にスクリプトが患者モニターのIPになる可能性があるため、この攻撃にはあまり重要ではありませんが、これは後々、重要になってきます。新たに発見されたカウンタを考慮し、インクリメントします。
患者モニターをエミュレート
これらの新しい事実を考慮に入れることによって、リプレイ攻撃が成功するようになります。特定のECGパターンを観察できれば、ネットワーク上の臨床モニターなしで中央監視ステーションに戻ることができます。 したがって、臨床モニターの機能をエミュレートすることができます。次のビデオは、Raspberry Piを使用したエミュレーションです。患者モニターのアイドル機能を模倣したPiを起動した後、Scapyスクリプトをロードするように設定しました。中央モニターが患者のバイタルについての情報を要求すると、Piは毎分の心拍数80の波形をステーションに送ります。これは他のバイタルサインでも同様に機能します。
エミュレーションの影響
リアルタイムの変更という目標にはまだ達していませんが、この種の攻撃が引き出すであろう結果を検討する必要があります。仮に誰かが安定した患者モニターのプラグを引き抜いて、同じ安定したバイタルを報告し続けているデバイスと交換すると、何らかの障害が起きるでしょうか？ おそらくすぐにはありません。しかし、安定した患者が突然不安定になったらどうなるでしょうか？ 中央ステーションは通常、適切な処置を施せる医療関係者に連絡するため、アラームを鳴らします。しかし、もしモニターが交換されていたら、だれが助けを必要としているかわかるでしょうか。患者のモニターは通常、患者の部屋の内外で聞こえるようアラームを鳴らしますが、モニターが交換されてしまえば、アラームも鳴らないのです。
病院では、容体が安定した患者であっても看護師等が定期的にチェックを行うのが通常です。だから、どんなごまかしも長くは続かないでしょうし、無駄かもしれません。もし誰かが患者を誘拐しようとしたら？ 誘拐犯は、意外なほど警戒されないでしょう。
本当の患者モニターからエミュレータに切り替えると、患者の病室から中央監視ステーションへの送信が短時間途切れるショートロスが起きるおそれがあります。これに気づかれて企ては発見されるでしょうか？ 通信のショートロスで気づかれるかどうか、ノルデック博士に聞いたところ、「ECGの一瞬の断絶は、患者が動いたり、服を着替えたりするときにもしばしば起きることで、おそらく気づかれないでしょう。再接続される限り、警告は発せられないでしょう」ということでした。
バイタルをリアルタイムで修正
臨床モニターをエミュレートするのは興味深いものの、リアルタイムの変更を行うという目標は達成できませんでした。 エミュレーションのテスト中にわかったことを生かすことで、リアルタイムのインジェクション攻撃はできるのでしょうか？ この質問に答えるには、まずエミュレーションとリアルタイムのインジェクション攻撃の違いを理解する必要があります。
エミュレーションでは、2つのデバイス間の初期接続、つまりハンドシェイクがどのように発生したかをきちんと理解する必要があります。リアルタイムの変更を考慮する時点で、このハンドシェイクは既に発生しています。しかし、攻撃者はデータパケットがどのポートに送信されているのか、ほかのどのポートがデータストリームに使用されているかを知りません。一方、実際の臨床モニターはオンラインであるため、常に中央監視ステーションにデータを送信します。
これらの要因を満たす方法として、Address Resolution Protocol（ARP）スプーフィングを使うことが考えられます。臨床モニターがARPスプーフィングされている場合、中央監視ステーションではなく攻撃者がデータパケットを受信します。このステップによって、攻撃者はどのポートが使用中であるかを判断でき、臨床モニターのデータが中央監視ステーションに到達するのを阻止することができます。エミュレーションが作動していることがすでにわかっているので、攻撃者は、臨床モニターと偽って代替データを中央ステーションに単に送信すればいいのです。
たとえば、臨床モニターから送信されたオリジナルのパケットを見てみましょう。
臨床モニターは、ペイロードのオフセット 0x71に保存されている患者の心拍数のパケットを送信します。このスクリーンキャプチャされた臨床モニターはIP アドレス 126.4.153.150にあります。攻撃者は、Kali仮想マシンで臨床モニターになりすますことができます。
ARPパケットは、IPアドレス126.1.1.1の中央ステーションが実際にはKali仮想マシンであるMACアドレス00:0c:29:a1:6e:bf,にあることを示しています。Wiresharkは、同じIPアドレスを割り当てられた2つのMACを認識し、ARPスプーフィングをハイライト表示しています。
次に、アドレス126.4.153.153の仮想マシンからの攻撃者は、アドレス126.1.1.1にあって、偽の情報を中央監視ステーションに送信します。この例では、オフセット0x71が0x78つまり120に変更されています（攻撃者は任意の値を選択できますが、以下のデモビデオは警告の度合いを高めるため心拍数を180としています）。偵察段階で発見したペイロードに格納されているIPアドレスも確認してください。これは、このデータがパケットのIPヘッダー上のIPアドレスとは異なるオリジナルの患者モニタードレスから来ていることを示しています。 これで攻撃者が攻撃を成功させるためにIPアドレスを偽装する必要はもうありません。
2つのビデオはこの変更がリアルタイムで行われていることを示しています。
リアルタイム変更の影響
患者の病室のモニターは直接の影響を受けませんが、医療従事者は中央ステーションを利用することで、患者一人一人の病室を回ることなく多くの患者について重要な決定ができるため、リアルタイムの変更が効果的です。もっともらしく疑われにくいような変更であれば、常に検証されるわけではありません。
ノルデック博士はこの攻撃のインパクトについて次のように説明しています。「心拍に関するデータ改ざんは、たとえ断続的なものであったとしても、入院の延長、追加検査、鼓動管理や、もしくは血栓予防のための処方薬による副作用などを招くことがあります。また、病院にとっては資源の浪費になる恐れもあります」。ノルデック博士は、心拍の変化があれば、短期間であっても通常、中央ステーションを監視する看護師や技師は医師に報告します。医師は、心拍のモニターリングのため中央ステーションにプリントアウトして持ってくるよう依頼します。さらに確認のため、心電図などの追加検査を発注します。心電図は断続的な不整脈をとらえることはできないかもしれませんが、断続的不整脈の根本的な原因を明らかにするかもしれません。不整脈が一日中断続的に再発する場合、医師はこの誤ったプリントアウトに基づいて治療決定を下してしまうかもしれません。
米国心臓協会（American Heart Association）、および米国心臓病学会（American College of Cardiology）は、「不整脈」などに対する病院の対処に関するガイドラインを公表しています（下図参照）。
このチャートの最初の決定ポイントでは、患者が血行力学的に安定しているかどうか（血圧が正常か）と問われます。この攻撃は臨床モニターには影響しません。看護師はおそらく正常である患者の血圧を測り直します。「はい」という回答で続く次の決定ポイントは、局所的な心房頻脈の診断です。そして回答がどうであっても患者は必ず投薬を受けます。これがネットワーク攻撃の結果だとしたら、患者が必要としない薬物が投与されたことになり、実害をもたらす可能性があります。
まとめ
マカフィーのATRチームのこの調査は、患者モニターと中央監視ステーションを使って医療ネットワーク上で患者のバイタルサインをリアルタイムでエミュレートし、変更することが可能であることを示しています。この攻撃が実行可能になるためには、攻撃者はデバイスと同じネットワーク上にいなければならず、ネットワーキングプロトコルに関する知識が必要です。患者のデータに加えられた変更は、それが現場で効果的なものになるには、医療関係者を欺けるもっともらしい変更である必要があります。
今回の調査では、臨床モニターは変更しませんでした。しかし、攻撃によって有意の影響があることが実証されました。このような攻撃は、患者への誤った投薬、追加検査、入院延長などの結果を招く可能性があり、そのいずれも不必要な出費を強いることになります。
製品ベンダーと医療機関の両方が、この種の攻撃の脅威を大幅に軽減するための対策を講じることができます。ベンダーは、デバイス間のネットワークトラフィックを暗号化し、認証を追加するとよいのです。これらの2つのステップによって、この種の攻撃の実行を非常に困難にさせることができます。またベンダーは、通常、非常に厳しいネットワークアクセス制御を備えた完全に隔離されたネットワーク上で医療機器を稼働させることを推奨しています。医療機関がこれらの推奨事項に従えば、攻撃者はネットワークに物理的にアクセスしなければならず、攻撃範囲を大幅に減らすことができます。
McAfee ATR チームの目標の1つは、状況が複雑で絶えず進化する中で、幅広い領域における脅威を特定し、明らかにすることです。私たちは、責任ある開示を通じ、より包括的なセキュリティ保護に向けて業界を支援し、奨励することを目指しています。私たちの方針の一環として、今回テストした製品を製造しているベンダーに調査結果を報告しました。引き続き、他のベンダーと協力して製品の安全性を確保していきます。
今回の報告は、医学博士ショーン・ノルデック（Shaun Nordeck）氏に多くの助言をいただきました。 ありがとうございました。
