概要 背景の確認 輸液ポンプとは 既存のセキュリティ対策状況プロジェクトの動機システムの説明 SpaceComの機能とソフトウェアコンポーネントクリティカルな攻撃シナリオの詳細 攻撃の目的 初期アクセス 特権の昇格 クロッシングシステム 重要なデータを理解する ファイナルアタックチェーン 攻撃の前提条件影響 Demo輸液ポンプのハッキングに関する独自の考慮事項 TUBE_HEADVOLUMEを変更した理由 病院での手術と過剰注入薬の結果よくある落とし穴 パッチ適用にかかるコスト セキュリティではなく安全のための設計 すべてが信頼のもとに CANがWi-Fiに接続される状況 技術的負債結論CVEの詳細 CVE：CVE-2021-33882 CVE：CVE-2021-33883 CVE：CVE-2021-33884 CVE：CVE-2021-33885 CVE：CVE-2021-33886
概要
企業と消費者に、よりセキュリティ上の問題のない安全な製品を提供するという継続的な目標の一環として、McAfee Enterpriseの Advanced Threat Research（ATR）チームは、最近、成人および小児の医療施設で使用されるB.Braun社の医療機器「Infusomat Space Large Volume Pump」と「SpaceStation」を調査しました。この調査は、医療サイバーセキュリティ分野の信頼できるリーダーであるCulinda社の支援を受けて行われました。このパートナーシップによる調査の結果、これまでに報告されていない医療システムの次の5つの脆弱性が発見されました。
1.CVE-2021-33886–外部制御フォーマット文字列の使用（CVSS 8.1）2.CVE-2021-33885–データの信頼性の検証が不十分（CVSS 9.7）3.CVE-2021-33882–重要な機能の認証の欠損（CVSS 8.2）4.CVE-2021-33883–機密情報のクリアテキスト送信（CVSS 7.1）5.CVE-2021-33884-危険なタイプのファイルの無制限のアップロード（CVSS 5.4）
同時に、これらの脆弱性は、悪意のある攻撃者がポンプのスタンバイモード中にポンプの構成を変更するために使用する可能性があり、その結果、次の使用時に予期しない量の薬剤が患者に配信されます。すべて認証なしで行われます。
マカフィーの脆弱性開示ポリシーに従って、2021年1月11日にB.ブラウンに最初の調査結果を報告しました。その後まもなく、開示レポートで概説した緩和策の採用に取り組んでいる間、彼らは応答し、ATRとの継続的な対話を開始しました。
このホワイトペーパーは、医療業界が直面する固有の課題に対処するとともに、最も重要な攻撃チェーンの概要と技術的な詳細を紹介することを目的としています。概要については、こちらの概要ブログをご覧ください。
背景の確認
製品評価の最も重要な部分は、テスト対象の製品の目的と機能をしっかりと理解することです。これがなければ、研究が意味のない結果を生み出す可能性は否めません。したがって、この調査では、まず、輸液ポンプについて、およびどのようなセキュリティ対策がされているかについて確認しました。
輸液ポンプとは
信頼できるリソースを使用して基本から始める– fda.govは、「輸液ポンプは、栄養素や薬などの液体を制御された量で患者の体内に供給する医療機器です」と述べています。FDAはさらに、それらは通常「レートと期間をプログラムする訓練を受けたユーザー」によって使用されると説明しています。輸液ポンプは、家庭環境で単一の静脈内（IV）薬剤を投与する単純なものから、ICU設定で同時に複数の薬剤を投与する複雑なものまであります。1960年代から2000年まで、輸液ポンプは主にいくつかの電子機器が組み込まれた電気機械装置でしたが、技術の進歩に伴い、より優れた安全メカニズムとそれらをプログラムする可能性を備えた「よりスマートな」装置を提供し、情報セキュリティの課題への扉をゆっくりと開きました。私たちが検討することを選択した特定の製品であるInfusomat® Space® Large Volume Pump（図1）について参照すると、このポンプは医療環境専用であり、家庭ユーザー向けには設計されていないことがわかります。注入ポンプは主に、手動注入を実行する必要性を排除するために存在します。これには、 1分あたりの滴数への用量変換と、時間のかかる信頼性の低い速度を設定するための滴の視覚的なカウントが必要です。毎年世界中で2億回以上の点滴が行われていると推定されており、2020年の米国での点滴ポンプの売上高は135億ドルでした。明らかに、輸液ポンプは医療の世界でその地位を確立しています。
図1：B.Braun Infusomat ポンプ
既存のセキュリティ対策状況
輸液ポンプは医療分野の非常に大きな部分を占めており、いくつかの異なるタイプがあるため、私たちのチームがそれらのセキュリティについて最初に問い合わせるわけではないと予想するのは合理的です。予想通り、何年にもわたって注入ポンプに関する多くの異なる研究プロジェクトがありました。おそらく最も有名な研究は、2018年にBilly RiosとJohnathan ButtsによってBlackhatで発表されました。彼らの研究の輸液ポンプ部分は、メドトロニックインスリンポンプに焦点を当てていました。彼らは、クリアテキストトラフィックとリプレイ攻撃を発行する機能により、患者に追加のインスリンを遠隔投与できることを発見しました。さらに早い段階で、2015年にHospira Symbiq Infusion Pumpに関する研究が発表され、認証が必要でしたが、「予期しない操作」によって薬物ライブラリファイルを変更し、投与量制限を引き上げることが可能であることが示されました。
もちろん、私たちの目的のために、最も重要な質問が残っています–今回の特定のデバイスで実行された以前の研究はありますか？当初、答えはノーでした。しかし、私たちの研究プロジェクトの間に、ドイツ当局の支援の下、自国で製造または使用されている、ネットワーク接続された医療機器のセキュリティを調査するための非常に大規模な研究であるManiMedがリリースされました。これには、B.Braun社のInfusomat ポンプで行われた研究が含まれていました。これは、ネットワークに接続された多くのデバイスをカバーする素晴らしい調査研究で、この調査を参照し、必要に応じてこのドキュメントの調査結果について説明します。さらに、この調査の機能強化を調査し、以前は不可能と呼ばれていた新しい攻撃を示します。
プロジェクトの動機
先に背景のセクションを検討すると、この分野で実行されるべき重要な研究がまだたくさんあることが明らかになります。輸液ポンプは、医療機器の分野で目立って継続的に開発されている分野であり、これまでの研究は表面的なものでした。潜在的な重大な影響と医療機器のセキュリティの状態により、以前の多くのプロジェクトでは、セキュリティの問題や懸念を見つけるために深く掘り下げる必要はありませんでした。輸液ポンプ業界には、公に研究されていない多くのデバイスがあり、また調査されたとしてもそれらの多くは情報セキュリティコミュニティから大まかな分析を受けただけです。これらの理由から、最大の輸液ポンプベンダーの1つであるB.Braunを詳しく調べることにしました。特に、世界中で使用されているデバイスの1つに焦点を当てて、これまでにない深さで分析します。このポンプのあらゆる側面に取り組み、基本的な疑問を確認したいと考えました。現実的なシナリオとして、既存のセキュリティの脆弱性を利用し、悪意のある攻撃者がこの製品を利用する人々の生活に影響を与える可能性があるのか、という疑問です。
システムの説明
この研究プロジェクトでは、システムは3つの主要コンポーネントで構成されていました。B.BraunInfusomat大容量ポンプモデル871305U（実際の輸液ポンプ）、SpaceStationモデル8713142U（最大4つのポンプを保持するドッキングステーション）、およびSpaceComバージョンと呼ばれるソフトウェアコンポーネントです。 012U000050。これらのモデルとB.Braun Infusomatシステムに対応するソフトウェアは、2017年にリリースされました。家庭用電化製品などの業界では、これは廃止されたと見なされるため、研究との関連性は低くなります。しかし、前述のように、医療分野ではそうではありません。古いデバイスはまだ広く使用されており、おそらく元々はセキュリティをあまり重視せずに開発されたものであるため、それらを調査することの重要性が増しています。デューデリジェンスについては、
SpaceComは組み込みLinuxシステムであり、スマートバッテリーパック内またはSpaceStation内からポンプ上で実行できます。ただし、ポンプがSpaceStationに接続されると、ポンプのSpaceComは無効になります。これが最も一般的な使用例であることがわかったため、SpaceStationに接続されたポンプを使用してほとんどの調査を実行しました。SpaceStationが危険にさらされた場合、一度に複数のポンプに影響を与える可能性があります。SpaceComは、システムの外部通信モジュールとして機能し、ポンプがどこから実行されているかに関係なく、ポンプの内部操作から分離されています。
SpaceStationに接続されているポンプを1つのシステムと見なすと、3つの異なるチップセットで実行される3つの別個のオペレーティングシステムがあります。SpaceStationで実行されているSpaceComは、PowerPCチップセット上でLinuxの標準バージョンを実行します。SpaceStationのWIFIモジュールは、ARMチップセット上でLinuxの標準バージョンも実行し、PCIバスを介してSpaceComと通信します。最後に、ポンプはM32Cマイクロコントローラー上で独自のカスタムリアルタイムオペレーティングシステム（RTOS）とファームウェアを実行します。M32Cマイクロコントローラーを監視するために追加のマイクロコントローラーが使用されますが、これは私たちの研究の範囲を超えています。このモジュール式で分離された設計により、Spacecom通信モジュールとポンプにはデータ交換用の専用パスが必要です。これは、SpaceStation全体で共有されるCANバスを介して解決され、ポンプとアクセサリが相互に通信できるようになります。これは、SpaceComと宇宙ステーションにドッキングされているポンプが交換のために依存しているものです。以下のアーキテクチャ図は、ドッキングステーションにポンプが存在する場合のシステムレイアウトと設計を示すのに役立ちます。
図2：システムアーキテクチャ
SpaceComの機能とソフトウェアコンポーネント
SpaceComには、より大きなB.ブラウンと医療施設のエコシステムの多くの機能をサポートするためのさまざまな適切なソフトウェアとアプリケーションが含まれています。私たちのチームは、それぞれを非常に詳細に分析することに時間を費やしました。ただし、このホワイトペーパーでは、冒頭の要約で言及されている最も重要な調査結果にとって重要な主要コンポーネントについてのみ触れます。
SpaceComの重要な機能は、ポンプに保存されている薬物ライブラリとポンプ構成を更新できることです。薬剤ライブラリには、病棟や部門、デフォルトの濃度で事前設定された薬剤のリスト、選択時に画面に印刷される情報メッセージ、さらに重要なことに、投薬ミスを防ぐためのソフト制限とハード制限などの情報が含まれています。スマート注入ポンプの最大のセールスポイントの1つは、薬剤の誤った投与を防ぐ能力です。これは、薬剤ライブラリの制限によって部分的に実行されます。ドラッグライブラリが軽減するのに役立つもう1つのリスクは、ヒューマンエラーです。最も一般的な投与量と注入長をポンプに事前にプログラムすることにより、手動注入療法に関連する、レート計算、および前述のドロップカウントに関連するエラーを排除します。
ポンプRTOSには、操作中に使用される1500を超えるキーと値のペアのデータベースが含まれています。このデータは、現在のコンポーネントに関するステータス、バッテリー寿命、モーター速度、アラーム、およびチューブのキャリブレーションに使用される値からすべてで構成されます。そのため、このデータは、ポンプの動作のコンテキストでは非常に機密性が高いと見なされ、ユーザーと直接対話することを意図したものではなく、ユーザーに提示されることもありません。キーのサブセットは、認定技術者が専用のサービスソフトウェアを介して間接的に変更できます。
SpaceComのポンプで薬物ライブラリとポンプ構成の両方を操作するために、PCSと呼ばれる適切なバイナリが使用されます。PCSバイナリは、canonバイナリを使用してCANバスとインターフェイスし、提供されたドラッグライブラリまたはポンプ構成に基づいて値の読み取りと書き込みの両方を行うコマンドをポンプのシステムに送信します。このタスクを実行するための主なインターフェイスは、適切なTCPネットワークプロトコルを介したもので、デフォルトではポート1500を介して送信されます。このプロトコルは認証も暗号化もされておらず、調査と攻撃ではこれらの弱点に大きく依存していました。さらに、これにより、上記の概要で述べたように、CVE-2021-33882およびCVE-2021-33883が提出されました。
クリティカルな攻撃シナリオの詳細
攻撃の目的
悪意のある攻撃者の目的は何でしょうか。現実的に言えば、ほとんどの攻撃は金銭的な動機であることが証明されています。これを輸液ポンプに変換すると、問題は次のようになります。医療関係者は、ためらうことなく、多額の費用を支払うのでしょうか。最近の出来事を見ると、2021年5月、コロニアルパイプライン社はハッカーに440万ドルを支払い、ランサムウェア攻撃から石油パイプラインを再び稼働させました。
医療現場への攻撃の増加については、FBIが「Ryuk」ランサムウェアを使用したサイバー攻撃が2018年と2019年の21か月間に6,100万ドルを得たと推定しています。攻撃は現在、2020年10月28日から始まる一例で患者に危害を加える可能性を示しています。バーモント大学ヘルスネットワークは、複数の米国の医療に対するより大規模な協調攻撃の一部であり、その結果、電子医療記録システムが数週間完全に失われました。ランサムウェアベースの攻撃の結果、アクティブな化学療法患者の75％が拒否され、救急車の経路が変更され、検査と治療が遅れました。IVポンプが人間の生活を直接サポートしている場合があることを考えると、攻撃者が実際の患者への脅威を利用して「身代金」の金額を要求する可能性があることを示唆するのは簡単です。したがって、これを達成するには、攻撃者はポンプの動作を制御する必要があります。
上述のようにポンプの設計を検討するとき、このタスクは口で言うほど簡単ではありません。ネットワークコンポーネント（SpaceCom）の従来の「ルート取得」は効果がないことがわかります。ポンプ自体に変更を加えるには、攻撃者はネットワークに接続されていないポンプのRTOSと対話する必要があります。このセクションでは、報告された5つのCVEを使用してこの目標を達成する方法の概要を説明します。
初期アクセス
SpaceComでルートアクセスを取得しても、最終的な目標を達成するために必要なすべてが提供されるわけではありませんが、それでも最初のステップです。システムの偵察と列挙中に、https：// {ipaddress} / rpcでリッスンしているリモートインターフェイスを発見しました。このインターフェースは、「json-dbus-bridge」と呼ばれる一般的なオープンソースサービスに接続されていました。GitHubで説明されているように、このサービスは「D-Busへのアクセスを提供するfast-cgiアプリケーションです。JSON-RPC呼び出しを受け入れ、これらをD-Bus呼び出しに変換します。応答はすべてJSONに変換され、クライアントに送信されます。」D-Busサブシステムへの外部アクセスにより、通常の外部ネットワークとは異なるレベルのセキュリティを持つ内部通信へのアクセスが提供される可能性があるため、これは私たちの興味をそそりました。
あらゆる種類の脆弱性の調査、製品のセキュリティ評価、または評価を行う場合、サードパーティコンポーネントの既存の問題を検索することを忘れないことが重要です。2017年にリリースされたソフトウェアに取り組んでいるため、これはさらに重要です。json-dbus-bridgeのGitHubページを精査しているときに、2015年にパッチが適用されたフォーマット文字列の脆弱性に気付きました。もちろん、バージョンかどうかをテストする必要がありました。私たちが遭遇した既存の脆弱性がありました。
図3：フォーマット文字列の脆弱性テスト
図3のテストでは、フォーマットスティングの脆弱性の存在が確認されました。このフォーマット文字列の脆弱性は2015年にjson-dbus-bridgeコードで公に発見されましたが、更新はB. Braunのソフトウェアに含まれていなかったため、ベンダー固有のゼロデイ脆弱性開示の条件を満たすものでした。これはCVE-2021-33886として提出され、B。ブラウンに最初に報告された発見でした。次の数週間で、この脆弱性を利用し、実用的なエクスプロイトを作成して、デバイスへのwwwユーザーレベルのシェルアクセスを取得することができました。パッチが適用されていないデバイスに影響を与える可能性があるため、エクスプロイトの正確な技術的詳細は含まれていません。
特権の昇格
ユーザーアクセスが最初のステップですが、CANバスと対話して実際のポンプと通信するには、ルートアクセスが必要になります。 特権昇格の適切なターゲットでよく知られているプロセスは、setuidビットが有効になっているrootが所有するバイナリを見つけることです。すぐに使えるものが見つかりませんでした。ただし、Webインターフェイスには、少数のファイルを含むフォルダーをタール化し、ユーザー指定のパスワードを使用してAESで暗号化することに依存する設定をバックアップおよびエクスポートするオプションがあります。その後、バックアップアーカイブをダウンロードして、後で設定を復元できます。このバックアップを復元する場合、rootは解凍を実行するユーザーです提供されたtarファイルからファイルのパーミッションが保持されるようにします。したがって、アーカイブを改ざんできる場合は、特権昇格シナリオを作成できる可能性があります。
これを有利に使用するには、rootが所有するバックアップアーカイブに「setuid」ビットが設定されたバイナリを埋め込んで、特権を昇格させる必要があります。皮肉なことに、設定のインポート/エクスポートを担当するコードは、すでにほとんどの作業を行っています。ファイルシステムにある「configExport」バイナリは、setuid / setgidを呼び出す（および入力をサニタイズする）ラッパーであり、スクリプト「/configExport/configExport.sh」でexecveを呼び出します。16進エディターを使用して、「configExport」バイナリが実行しているスクリプトを変更し、「configExport.sh」を攻撃者が制御するスクリプトに置き換えると同時に、入力のサニタイズにパッチを適用できます。代わりに、絶対に独自のバイナリをコンパイルすることもできますが、このアプローチにより、PPCクロスコンパイルの楽しみを数時間節約できます。
攻撃チェーンのこのコンポーネントを処理している間、ManiMedプロジェクトに取り組んでいる研究者は、B。Braunと協力して、この発見を含むレポートをB.BraunのWebサイトにCVE-2020-16238として公開しました。レポートのセクション4.6.2.2で説明されているように、「認証された任意のファイルアップロードの脆弱性と、検証されていないシンボリックリンクおよびローカル特権の昇格により、攻撃者はrootユーザーとしてコマンドを実行できます。」ManiMedの研究者も、この脆弱性を発見し、責任ある開示を実践したことを称賛します。
クロッシングシステム
ルートアクセスが取得されると、実際の作業が始まります。課題は、SpaceCom通信モジュールのルートアクセスでポンプRTOSの変更にどのように影響するかということです。一般的なアプローチの1つは、システム内でのコード実行につながるポンプのRTOSの脆弱性を引き続き探すことです。この方法は、ブラックボックステスト中に多くの課題を提起し、限られた数のテストデバイスに損傷を与える可能性があります。
過去のプロジェクトで活用したもう1つのアプローチは、デバイスの標準機能を乗っ取って攻撃を促進することです。これはより管理しやすくなりますが、最初にデバイスがどのように機能し、望ましい結果が得られるかを深く理解する必要があります。これは、デバイスの多層防御もテストし、実施されているセキュリティ対策によっては非常に困難であることが判明する可能性があります。私たちの場合、これは、ポンプとSpaceComの間の通信を取り巻くエリアがどの程度保護されているかという問題を強制します。
上記のシステムの説明のセクションで述べたように、PCSバイナリは、薬物ライブラリの更新とポンプ構成の更新という2つの重要な操作のためにポンプのシステムと通信する役割を果たします。これらは、攻撃者が関心を持つ可能性が高い重要な機能です。特にルートアクセスが与えられた場合、攻撃者がこれらの主要な操作と対話するために取ることができるいくつかの異なるアプローチがあります。さまざまな代替案を考慮して、SpaceComのルートアクセスを利用してPCSのメモリにコードを挿入し、既存の関数とオブジェクトを使用してポンプの内部システムと通信することを選択しました。
選択したパスでは、この通信を容易にするために使用されるデータ構造と機能を深く理解する必要がありました。重要なのは、オブジェクトやデータを最初から不必要に作成する必要をなくすために、低レベルの関数を利用しながら、必要なデータを変更または挿入できる、より大きな操作呼び出しスタック内の最適な場所を見つけることです。この点を説明するために、PCSのメモリ空間内からポンプの電源を切るための簡単な信号を送信するかどうかを検討してください。SpaceComからポンプのRTOSに送信されるすべてのデータがCANメッセージを介して行われるという事実は、ルートアクセスを使用して、CANバス上でCANメッセージを直接送信できることを意味します。基盤となるプロトコルはB.Braunによって設計されており、リバースエンジニアリングする必要があるため、これには、CANメッセージ構造の広範な知識と内訳が必要になります。可能ですが、特にCANのデータフレームフィールドに厳密な仕様がない場合、それは非常に困難です。PCS内には、このメッセージを作成するコールチェーンがあります。コールチェーンの非常に低い機能を挿入して利用する場合、CANメッセージを送信するtrySend関数（図4を参照）では、そのすべての引数と使用するデータ形式を理解する必要があります。基本的に以前と同じ問題が発生します。
図4：trySend関数
確認が必要と思われた操作を実行する関数を呼び出しスタックで上位に表示し、デバイスのスイッチをオフにすると、代わりに、残りの呼び出しチェーンに手間のかかる作業を任せることができます。以下の図5には、この目的のためだけの関数があり、1つのパラメーターを渡すだけでよいことに注意してください。
図5：switchOffDevice
この概念を活用して、APIと同様の方法でPCS内の関数を使用して、ポンプのデータベースへの読み取りおよび書き込み操作を実行し、変更を強制することができます。
重要なデータを理解する
ドラッグライブラリやポンプ構成などのデータを送受信する場合は、最初にデータの形式、データの処理方法、および考慮する必要のあるセキュリティ対策を理解する必要があります。私たちのチームは、薬物ライブラリとポンプ構成データの両方を逆にすることに長い時間を費やしました。ポンプ構成の一部は、キャリブレーションおよび使い捨てデータと呼ばれます。どちらも攻撃チェーンを通じて変更できます。ただし、このペーパーでは、キャリブレーションデータと使い捨てデータの2つのうちのより重要なものに触れます。
キャリブレーションと使い捨てデータは通常、SpaceComにあるファイルの形式で表示されます。より詳細なレベルでは、これらは、ポンプのデータベースに対して読み取りまたは書き込みを行うことを目的としたキーと値のペアのコレクションです。各ファイルは、ポンプフラッシュ上に存在するデータの大きな塊にすることもできます。このblob内の各キーの物理的な場所は、ポンプにハードコードされており、PCSにハードコードされている場合もあります。この表現は、キーペアではなくデータのブロブを操作するさまざまなCRCの計算に関連しています。これらのチェックサムは、データの整合性を確保するために重要なデータとともにポンプのインフラストラクチャ全体で頻繁に使用されます。これは、データが誤って変更または破損されないようにすることで、患者の安全を確保するためのものです。図6は、SpaceComのファイルに含まれている使い捨てデータの例を示しています。
図6：使い捨てデータ
使い捨てデータファイル内の変数名とポンプファームウェアの関連コードを見ると、上の図に示すように、チューブの「ヘッドボリューム」を指定する1つのキーと値のペアが見つかりました。徹底的な分析の結果、「ヘッドボリューム」は、サイクルごとに患者に投与される薬剤の量を決定するパラメータであると判断しました。この値を変更すると、潜在的に有害である可能性があると判断しました。この分析については、以下の「輸液ポンプのハッキングに関する独自の考慮事項」のセクションで詳しく説明します。
ターゲットのキーと値のペアを念頭に置いて、次のステップはCRCの計算方法を理解することです。システムは常にデータの整合性をチェックしているため、攻撃者が値を変更したい場合は、変更されたデータを検証するCRCも変更する必要があります。リバースエンジニアリングにより、CRCはCRC16のカスタム実装であり、初期値は0xFFFFであり、ハードコードされた多項式テーブルに依存していると判断しました。このアルゴリズムを抽出し、カスタムpythonスクリプトを記述して、使い捨てデータに必要なCRCを計算することができました。
重要な運用データの基本的な理解とCRCを計算する機能により、API方式でPCSバイナリを活用して、このデータを変更するコマンドをポンプに送信できます。これは、薬物ライブラリとポンプ構成データの両方に当てはまります。CRCは整合性チェックには最適ですが、データの送信元のセキュリティや信頼レベルは提供されません。この出自の確認の欠如が、CVE-2021-33885の提出につながった理由です。
ファイナルアタックチェーン
攻撃チェーンを確認すると、認証や承認なしでデバイスへのユーザーレベルのアクセスを取得できます。次に、特権をエスカレートしてルート化し、PCSバイナリの既存の機能を
PCSバイナリのプロプライエタリプロトコルは認証されていないため、攻撃者が仕事をさらに簡単にするために変更できる特定の構成オプションがあります。これらの構成オプションの1つは、どのサーバーが操作データの受信を「信頼」されているか（薬剤ライブラリーなど）をポンプに指示します。攻撃者はSpaceComにコマンドを送信して、現在の信頼できるサーバー構成をクリアし、攻撃者が制御するサーバーに書き換えることができます。上記のフォーマット文字列と特権昇格パスを利用する場合、これはこの攻撃には必要ありません。ただし、代替方法を提供し、攻撃プロセスを簡素化します。
最後に、ポンプの構成または薬剤情報が変更された場合、ポンプには音声と視覚による通知があります。もう一度、現実的な攻撃の精神で、悪意のある攻撃者は可能な限りステルスになりたいと思うでしょう。これを実現するには、これらの通知をクリアする方法を決定する価値がありました。このプロセスは、変更が完了した後にポンプを再起動するのと同じくらい簡単であることがわかりました。再起動操作は数秒で実行されるため、この手法を使用することで、エンドユーザーへのすべてのアラートがすばやくクリアされました。完全な攻撃プロセスは、次の図に概説されています。
図7：完全な攻撃チェーン
攻撃の前提条件
この攻撃チェーンは、重要なポンプデータを変更するための完全な方法を提供しますが、この攻撃が成功するために必要な条件を認識することが重要です。これらのポンプは、ローカル内部ネットワークにネットワーク接続されるように設計されています。したがって、通常の動作条件下では、攻撃者はローカルネットワークにアクセスする方法を見つける必要があります。この攻撃はインターネット経由で発生する可能性がありますか？技術的に言えば、そうです。ただし、ポンプが直接インターネットに接続されている設定が表示される可能性はほとんどありません。
ローカルネットワーク上にあることに加えて、ポンプには、ポンプの動作中に変更が発生しないようにするための保護手段があります。調査中に発見したことから、ポンプが積極的に薬剤を投与している場合、ライブラリまたは構成データを変更するためのCANバス上の要求はすべて無視されます。これは、注入の合間にポンプがアイドル状態またはスタンバイモードの場合にのみ攻撃が成功する可能性があることを意味します。
影響
この攻撃の前提条件は最小限であり、全体的な脅威を軽減するには十分ではありません。今日の世界では、攻撃者がローカルネットワークにアクセスするための、文書化され利用されているさまざまな方法があります。また、病院や医療施設は一般に、参入障壁がほとんどまたはまったくない公共の場所であると考えると、悪意のある人が気づかれずにネットワークにアクセスする方法を簡単に確認できます。ポンプはまた、常に積極的に調停を行っているわけではありません。最も忙しい病院でさえ、患者間のダウンタイムやポンプが単に使用されていない時間帯があります。
ポンプの使い捨てデータと構成データを変更する機能により、攻撃者が影響を与えることを選択できる可能性が幅広くあります。攻撃者は、単にデバイスを使用できない状態にしたり、画面に任意のメッセージを書き込んだりする可能性があります。使い捨てデータ、特に「 TUBE_HEADVOLUME_A」というラベルの付いたキーと値のペアに焦点を当てることを選択しました。これは、それが最大の影響を示し、患者に害をもたらすと判断したためです。以下のビデオでは、最初に通常の操作でポンプが表示されます。システムが意図したとおりに機能することを示した後、上記で説明した攻撃チェーンを使用してリモートで構成を変更し、薬剤を投与する際のポンプへの影響を示します。
Demo
輸液ポンプのハッキングに関する独自の考慮事項
このプロジェクトの興味深い特徴は、その影響と結果が本質的に物理的な世界に基づいていることです。一般的なソフトウェアハッキングがrootアクセスまたはカーネル特権を取得する機能で終わる場合、このプロジェクトでは、医療スタッフによるデバイスの使用方法と、それが患者の安全にどのように影響するかが結果に重要です。次のいくつかのセクションでは、この傘下にあるプロジェクトのさまざまな側面に焦点を当てます。
TUBE_HEADVOLUMEを変更した理由
前に説明したように、私たちの攻撃は、ポンプを使用して薬剤を送達する方法を管理する使い捨てデータの変更に依存しています。しかし、なぜ、どのようにしてこれを調査することにしたのでしょうか。安全のために構築されているポンプの興味深い副作用は、CANバスから受信する入力と出力のほとんどが範囲外のアクセスに対して広範囲にチェックされることです。すでにSpaceComを侵害している攻撃者の観点からは、これは通常、メモリ破損のバグの主な標的になります。M32Cアーキテクチャのファジングとエミュレートは、先行作業の点でコストがかかるため、代わりに、抵抗が最も少ないパスを探し始め、安全な設計で死角を探しました。
私たちの場合、誤動作や異常を示すものが画面に表示されることなく、投与される薬剤の量に影響を与えることができるようにしたかったのです。当初の計画では、デバイスの薬剤ライブラリを改ざんする予定でしたが、変更できるデータが画面に表示されるため、医療スタッフが処方された薬剤とレートを注文の前後で確認するため、懸念が生じる可能性があります。注入を開始します。これは攻撃者にとって理想的ではないため、調査を続けました。変更できる他のファイルは、キャリブレーションデータと使い捨てデータでした。これらのファイルは、内部パラメーターを記述しているので興味深いものです。校正用のものはデバイス自体の物理的パラメータを指定し、使い捨て用のものはポンプを通過するチューブに関する詳細用です。精密工具に精通している人なら誰でも、適切な校正がいかに重要かを知っています。キャリブレーションがオフの場合、不適切な操作または結果につながります。運用の観点からはこれは理にかなっていますが、攻撃者の観点からは、これは私たちが考えていた攻撃の請求に適合する可能性が高いです。内部値を変更して、ポンプが適切な量の薬剤を調剤していると見なすようにします。
ディスポーザブルファイル内の変数名とポンプファームウェアの関連コードを見ると、チューブの「ヘッドボリューム」を指定するものが見つかりました。私たちの理解では、ポンプがポンピングするたびに、IVチューブが圧縮され、それによって少量の薬剤が患者に向かって押し出されます。全体として、この体積を支配する多くの物理的パラメータ（チューブの内径、圧縮領域の長さ、チューブが圧縮されている量など）がありますが、最終的には、これらすべての値が合計されたように見えました。 1つの変数で。この値を半分に減らすと、ポンプは実際の量の半分を押していると信じるようになり、したがって、それを供給するために2倍の速さでポンプを送る必要があります。私たちは仮説を試しましたが、そうすることで、ポンプがすべてが正常であると想定している間に、投与される薬剤の量が2倍になりました。
病院での手術と過剰注入薬の結果
内部構成を変更するとデバイスに何が起こるかがわかったので、これが現実の世界でどのように機能するかを検討できます。前述のように、医療スタッフはこれらのデバイスを使用する際に細心の注意を払い、番号が医師の指示と一致するようにする必要があります。 米国では、メディケア・メディケイドサービスセンター（CMS）と米国臨床腫瘍学会の両方で、血液や化学療法などの高リスクまたは危険な注入を伴う標準的な診療が必要です。この基準では、適切に訓練された2人の人（通常は看護師）が必要です。1人は薬剤を注入し、もう1人は投与前に順序と構成を確認します。国際的に見ると、アイルランドの病院でも同じプロトコルが使用されていることがわかりました。詳細への注意と、各値を再確認する要件が正しいことを確認します。ただし、スウェーデンの病院でのスマートポンプシステムの採用について説明している別の文書は、看護師がポンプのデフォルト設定を間違えた場合、無効な薬剤プロトコルに従う可能性があるという懸念（p.47）を示唆しています。これらの文書は逸話的ですが、全体的な感覚は強力なチェックが行われているということです。圧力がかかっている場合や複数回の注入がある場合は、間違いを犯す可能性があります。これは、スマートポンプで防ぐ必要があります。
当社の業界パートナーの1つであるShaun Nordeck, M.D.は、レベル1外傷センターのインターベンショナルラジオロジー研修医であり、以前は陸軍衛生兵および連合医療専門家を務めていました。医療分野で20年以上の経験を持っています。ドクター Nordeckは次のように述べています。「ICUなどの高圧環境では、これらの重要でしばしば医学的に複雑な患者が頻繁に調整される複数の注入を行うため、注入エラーのリスクが高くなる可能性があります。ただし、エラーはICUに限定されるものではなく、入院病棟や外来患者の設定でも同じように簡単に発生する可能性があります。基本的に、変数（患者の複雑さや鋭敏さ、投薬の数、比率の変更、看護師と患者の比率など）が増えるたびに、エラーのリスクが高まります。」
安全性の尺度として、注入速度を確認するために滴の数を視覚的に数えることができることを覚えておくことが重要です（それを自動的に行うオプションのモジュールさえあります）。ただし、パラメータによっては、速度のわずかな変化（たとえば、半分または2倍）はすぐには明らかではないかもしれませんが、それでも有害である可能性があります。ノルデック博士はさらに、「人の高血糖またはナトリウムレベルをあまりにも早く修正するのと同じくらい日常的なことは、脳を腫れさせたり神経を損傷したりして、永続的な障害や死に至る可能性がある」と述べました。FDAのMAUDEデータベースは、医療機器に関連する有害事象を追跡し、現場で実際に発生した問題の種類を確認するために使用できます。特定の薬は特に強力であり、その場合、それらが送達される速度が重要です。この場合、意図した速度の4倍の鎮静過剰は、事件が発生してから数時間後に患者を死に至らしめました。必要な薬が適切な量で患者に届かないため、投薬不足も問題になる可能性があります。これらの例は、正しい量の薬剤を供給しないポンプが現場で発生し、数時間気づかれずにいる可能性があり、怪我や死亡につながる可能性があることを強調しています。
よくある落とし穴
ここで少し戻って、輸液ポンプのエコシステムを見ているときに明らかになったいくつかの一般的な欠点について考えてみましょう。これらの問題は、ブランドや製品に固有のものではなく、医療分野全体で見られる可能性があると考えています。これは、何年にもわたって、この業種が悪意のある攻撃者とサイバーセキュリティ業界の両方から限られた量の注目しか受けていないためです。サイバー脅威の割合が増加し、プライベートネットワークに新しいスマートデバイスが絶えず追加されているため、新しい攻撃対象領域が露呈しており、多くのシステムの強化は、遅れているシステムにとっては手に負えない成果に変わる可能性があります。スマート医療機器のライフサイクルが遅いということは、セキュリティのベストプラクティスと緩和策が現場で採用され展開されるまでに時間がかかることを意味します。これを知っていると、医療機関に役立つ可能性があります。
パッチ適用にかかるコスト
ハードウェアとソフトウェアの両方の消費者向け製品は、多くの場合、医療業界の対応製品よりも機敏です。パーソナルコンピュータ上のWebブラウザまたはオペレーティングシステムは、定期的に提供されるパッチがリリースされた直後に自動更新されます。これは、患者の安全に直接関連することが多い医療機器では根本的に異なり、したがって、更新を適用する前に、より厳密な検査プロセスを経る必要があります。これにより、更新中にデバイスを固定し、フォローアップテストと再キャリブレーションを実行する必要が生じることがよくあります。多くの場合、医療施設が製品を更新することは非常に費用がかかり、困難であり、その結果、数年前のファームウェアを備えたデバイスが展開されます。このため、「テーブルステークス」のセキュリティ対策が完全に採用されることはありません。
セキュリティではなく安全のための設計
ポンプの一般的なアーキテクチャを見ると、安全性を念頭に置いて設計されていることは明らかです。たとえば、メイン処理はアプリケーションプロセッサに依存していますが、他のコンポーネントと一緒にセンサー出力を監視することで予期しないことが発生しないようにする制御プロセッサも備えています。すべてがCRCチェックされ、メモリの破損にフラグが立てられ、すべての範囲が境界チェックされます。これらすべては、設計がハードウェアとソフトウェアの障害、データが誤ってネットワーク上で破損したこと、および安全性の優先度が高いフラッシュモジュールの劣化を軽減することを目的としていたことを示唆しています。
ただし、設計プロセスでは悪意の防止にはあまり注意が払われていなかったようです。安全性とセキュリティの違いが少しぼやけている場合があります。障害のあるハードウェアによる偶発的なメモリの破損や範囲外のアクセスを防ぐことも、悪用を困難にしますが、攻撃者は常にこれらの緩和策を回避しようとします。同じように、偶然に発生する可能性が非常に低い論理バグは、攻撃者にとって「王国への鍵」である可能性があります。内部監査と攻撃的なセキュリティ演習は、攻撃者の考え方を浮き彫りにし、意図的な脅威から保護するために既存のセーフガードを強化する方法として貴重な洞察をもたらすことができます。
すべてが信頼のもとに
ポンプとその通信モジュールが通信とファイル処理をどのように処理するかを見ると、重要なファイルは署名されておらず（CVE-2021-33885）、ほとんどのデータ交換はプレーンテキストで行われ（CVE-2021-33883）、使用されている独自のプロトコルの認証（CVE-2021-33882）が全体的に不足していることがわかりました。ユーザー向けシステムにはパスワードで保護された領域がいくつかありますが、舞台裏の内部システムにはそれほど多くはありません。これは、Webサイトのログインページが「明白な」必要性であり、FTPおよびSSHの適切な認証メカニズムを備えている一方で、よりカスタマイズされた用途で設計されたアドホックプロトコルはそれほど明白ではないためである可能性があります。進化する状況とそれに関連する脅威の評価もあります。権限のない人が構成ファイル（キャリブレーションデータ、ドラッグライブラリなど）を改ざんするリスクは、専用のソフトウェアとデバイスへの物理的なアクセスも必要な場合はかなり低くなります。ただし、デバイスが突然ネットワークに接続されると、攻撃対象領域が拡張され、元の想定が更新されない場合があります。多層防御は、いずれにせよ、重要なファイルは簡単に改ざんされてはなりません。ただし、セキュリティと機能には正当な妥協が伴い、組み込みデバイスに関しては、限られたリソースと使いやすさも考慮に入れる必要があります。
CANがWi-Fiに接続される状況
当初、CANバスは、メンテナンスに使用されるサービスPCなどの信頼できるコンポーネント間の通信、またはSpaceComが組み込まれていない古いモデルの宇宙ステーション内の複数のデバイスの接続用に予約されていました。後者はオプションのモジュールとして提供されます。宇宙ステーションに接続して、外部接続を提供することができます。したがって、CANバスは、信頼できるコンポーネント間の「内部」通信に使用され、外部モジュールであるSpaceComは、ネットワークを介したデータレポート用に追加できます。その後の10年間で、テクノロジーは改善され、すべてが統合されるまで小型化されたため、バッテリーモジュールでもWi-fi接続とSpaceCom機能を提供できるようになりました。これにより、新しい可能性が開かれました。組み込みのSpaceComモジュールを使用するなど、サービスを提供するPCと同様の機能を提供します。ユーザーの観点からは操作が簡素化されるので優れていますが、セキュリティの観点からは、「信頼できる」内部ネットワークが突然、ワイヤレスでアクセスできる外部ネットワークにブリッジされる状況が発生しました。Wi-Fi接続されたLinuxデバイスが同じ機能を提供し始めたとき、物理的にアクセスできる少数の専用デバイスだけが特権操作を実行できるという許容可能なリスクであったかもしれないものは、はるかに疑わしいものになりました。
この種の問題は、インターネットやその他の信頼できないネットワークに突然接続された、信頼できる物理ネットワークへの依存から発展したほぼすべての業界が直面しています。スマート接続デバイスは両刃の剣です。システム間の柔軟性と相乗効果が向上するのと同じように、全体的に検討する必要のある緊急のセキュリティ問題につながる可能性もあります。
技術的負債
カスタムプロトコルやアドホックシステムを開発する場合、技術的負債が発生するのは当然です。これは、デバイスのライフサイクルが何年もあり、パッチやアップグレードの展開が複雑で費用がかかる場合にさらに当てはまり、サポートする顧客ベースが異質で、ハードウェアのリビジョンが複数になります。これにより、よりあいまいな機能が何年も見られず、所有権が失われたり機能しなくなったりする可能性があります。この例は、json-dbusモジュールに影響を与えるフォーマット文字列の脆弱性です。その使用法はあいまいであり、何年も前にオープンソースプロジェクトから分岐しました。元のリポジトリは、セキュリティバグであるが、そのようにフラグが立てられていなかったバグを修正しました。おそらく、フォークされた時点で、コードはその目的を果たし、その後再訪されることはなく、セキュリティバグに気付かなかったようです。カスタム設計されたプロトコルとファイル形式についても同じことが言えます。 「レガシー」展開を壊すことを避けながら、ベストセキュリティプラクティスの改善に合わせてそれらを進化させることは難しいかもしれません。このシナリオでは、緩和策が進むべき道かもしれません。システムが分離されていることを確認し、不要な機能を無効にして、それらの特権とアクセスを必要なものに制限することができます。システムの将来を保証することは難しい課題です。どちらかといえば、システムの機能と依存するコンポーネントの透明性と、定期的な監査（コードソースレビューまたはブラックボックス監査）を組み合わせることで、コンポーネントが長年のベストプラクティスに照らしてチェックされていない場所に陥るのを防ぐことができます。
結論
これで、2人の上級研究者が、遠隔地の攻撃者に医療機器が乗っ取られるという生命を脅かすリスクを示すのにかなりの時間を要した研究プロジェクトが終了しました。当面、ランサムウェア攻撃は医療部門で脅威となる可能性が高くなりますが、最終的にはこれらのネットワークはこのタイプの攻撃に対して強化され、悪意のある攻撃者は他のより低い成果を探します。医療機器の寿命とその更新を取り巻く困難さを考えると、明日の脅威に備えて今すぐ計画を開始することが重要です。この研究が、長い間盲点であった領域に気づきをもたらすのに役立つことを願っています。
ノルデック博士は、この研究の重要性を次のように述べています。「エンドユーザーが検出することなく、患者に有害な可能性のある方法で医療機器を操作する機能は、デバイスを効果的に武器化し、ハリウッドがこれまでに考案したものが実際起こる可能性があることをマカフィーのATRチームは確認しました。デバイスメーカーは、組み込みのセーフガードによって証明されるように、安全でセキュアな製品の製造を明確に目指しています。しかし、デバイスが身代金攻撃に屈したり、危害を加えたりする可能性のある欠陥が存在する可能性があります。したがって、製造業者はセキュリティの専門家と協力して製品を独自にテストし、潜在的な脅威を検出して修正し、それによって患者の安全とデバイスのセキュリティを維持する必要があります。」
定期的なセキュリティ監査を実行し、医療専門家がデバイスを最新の状態に保つのを容易にし、これが不可能な場合に確実な緩和策を提供することは、すべての医療ベンダーの優先事項のリストに含まれるべきです。医療専門家、政策立案者、さらには一般の人々も、医療ベンダーに説明責任を負わせ、販売するデバイスのリスクプロファイルを明確に示し、デバイスを安全に保つためのより良い方法を要求する必要があります。この考え方とセキュリティへの全体的なアプローチがあっても、事前に決定できない欠陥が常に存在することを認識しています。このような場合、ベンダーは業界のパートナーを奨励し、さらには探し、責任ある開示を受け入れ、研究者、利害関係者、顧客と幅広くコミュニケーションをとる必要があります。
セキュリティ研究の観点からは、デバイスが全体的なシステムレベルでどのように機能するか、各コンポーネントがどのように相互作用するか、どのコンポーネントと通信できるかなどを理解することが重要です。メーカーにとっては、行間を読むことが重要です。何かが設計ドキュメントや仕様に含まれていない可能性がありますが、他の設計決定の副作用として緊急プロパティが発生する場合があります。
私たちのような攻撃的なプロジェクトは、実際には構造的な弱点を強調し、リスクを指摘することを目的としています。現在、これらの懸念に対処するために防御的な作業が必要です。たとえば、メーカーは、より安価で強力なマイクロコントローラーを活用して、適切な認証メカニズムを実装する必要があります。ただし、デバイスを最新の状態に保つことに関して、病院が直面する課題を調査して対処することはさらに重要です。これは、ベンダーからの技術的ソリューションと、安全な慣行を促進し、古いソフトウェアを備えた重要なデバイスに関連する潜在的なリスクについての認識を高めるためのアドボカシーの両方として提供される必要があります。FDAは、2018年にCyberMed Safety（Expert）Analysis Board（CYMSAB）で先導しようとしましたが、これまでのところほとんど進展がありません。ドイツのBSIがManiMedプロジェクトで行った作業も、非常に心強いものです。これは、多くの可能性と注意が必要なサイバーセキュリティの分野であると考えており、情報セキュリティ業界がこの重要なセクターを常により安全にするためにこの課題に取り組むことを楽しみにしています。
McAfee Advanced Threat Researchチームの目標の1つは、今日の複雑で絶えず進化する状況における幅広い脅威を特定して明らかにすることです。マカフィーの脆弱性公開ポリシーに従い、マカフィーのATRチームは、B.Braunチームに直接通知し、協力しました。このパートナーシップにより、ベンダーはこのブログで詳しく説明されている脆弱性の効果的な軽減に向けて取り組んでいます。B.Braun Infusomatデバイスを使用している企業は、パッチポリシーとテスト戦略に沿ってできるだけ早く更新することを強くお勧めします。
CVEの詳細
CVE：CVE-2021-33882
CVSSv3評価：6.8 / 8.2
CVSS String: AV:N/AC:H/PR:N/UI:N/ S:C/C:N/I:H/A:N/CR:H/IR:H/AR:M/MAV:A
CVEの説明：012U000062より前のBBraun SpaceCom2の重要な機能の脆弱性に対する認証がないため、リモートの攻撃者は、独自のネットワークコマンドの認証がないため、不明なソースからデバイスを再構成できます。
CVE：CVE-2021-33883
CVSSv3評価：5.9 / 7.1
CVSS String: AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N/CR:H/IR:H/AR:M/MAV:A
CVEの説明：012U000062より前のBBraun SpaceCom2の機密情報のクリアテキスト送信の脆弱性により、リモートの攻撃者はネットワークトラフィックをスヌーピングして機密情報を取得できます。公開されたデータには、ポンプの内部構成の重要な値が含まれています。
CVE：CVE-2021-33884
CVSSv3評価：7.3 / 5.8
CVSS文字列：AV：N/AC：L/PR：N/UI：N/S：U/C：L/I：L/A：L/CR：M/IR：M/AR：L/MAV：A
CVEの説明：012U000062より前のBBraun SpaceCom2に危険なタイプのファイルを無制限にアップロードすると、リモートの攻撃者がWebページAPIを介してデバイスの/ tmpディレクトリにファイルをアップロードできます。これにより、重要なファイルが上書きされる可能性があります。
CVE：CVE-2021-33885
CVSSv3評価：10.0 / 9.7
CVSS String: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N/CR:H/IR:H/AR:M/MAV:A
CVEの説明：012U000062より前のBBraun SpaceCom2のデータ信頼性の脆弱性の検証が不十分であるため、認証されていないリモートの攻撃者が、正しいデータの代わりに使用される悪意のあるデータをデバイスに送信できます。これにより、重要なデータセットに暗号化署名がないために実行されます
CVE：CVE-2021-33886
CVSSv3評価：8.1 / 7.7
CVSS String: AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N/RL:O/RC:C
CVEの説明：012U000062より前のBBraun SpaceCom2の入力脆弱性の不適切なサニタイズにより、認証されていないリモートの攻撃者が、生の外部文字列をprintfステートメントに直接渡すことでユーザーレベルのコマンドラインアクセスを取得できます。攻撃者は、デバイスと同じネットワーク上にいる必要があります。
※本ページの内容は2021年8月24日22時 （日本時間）更新の以下のMcAfee Enterprise Blogの内容です。
原文：McAfee Enterprise ATR uncovers vulnerabilities in globally used B. Braun Infusion Pump著者：Douglas McKee and Philippe Laulheret
