目次
エグゼクティブサマリー
McAfee Advanced Threat Research（ATR）チームは、より安全な製品を開発者が事業や個人に提供するのをサポートするため、ソフトウェアとハードウェア双方のセキュリティ問題の発見に取り組んでいます。セキュリティ研究者として、ターゲットに目を向ける前に留意する点は、調査範囲をどうすべきかということです。実は、特にネットワークスタックや OSレイヤーなど十分に吟味されたテクノロジーについては有効であるとの前提で、ターゲットに固有のアプリケーションレイヤーやソフトウェアに注意を向けることがよくあります。アプローチが包括的なものであるかどうかは、重要ではないこともあります。今回のプロジェクトでも、Android OS自体をバイパスし、Pelotonのコードと実装に重点を置いて行うことにしました。調査の途中で、Pelotonを脆弱にしているAndroid Verified Boot（AVB）プロセスの欠陥を発見しました。これは当初は調査の対象外でした。
詳しくない方のために説明すると、Pelotonは米国で大人気のハイエンドのエクササイズ機器と最先端のテクノロジーを組み合わせたブランドです。同社の製品には、フィットネスマシンのコンポーネントと連動する大型タブレットが装備されており、インターネット経由で仮想トレーニングクラスに参加することもできます。この豪華な外観の「中身」は、標準のAndroidタブレットであり、エクササイズ機器に対するこのハイテクなアプローチは注目を集めました。しかしバイラル・マーケティングでの不運な事件以外にも、Pelotonは最近、自社製品のプライバシーとセキュリティに対する懸念がクローズアップされています。そこで、それを確かめるためにPeloton Bike+を購入しました。
バックアップを試みる
通常新しいプロジェクトを開始する際に最初にしようとすることの1つは、まずリカバリが必要になった場合に使用できるバックアップまたはシステムダンプを取る方法を見つけることです。Pelotonのような高額な出費を伴うプロジェクトの場合はなおさらです。私たちの調査手法のすべてがデバイスを新品同様の状態に保つわけではありません（でなければ一流のハッカーとはいえません）。ターゲットとなるデバイスが工場出荷時の設定に復元する機能をセーフティネットとして装備させるのが私たちの狙いです。
私たちは、カスタム化されたPelotonだけがアプリケーションレイヤーで実行されている状態の通常のAndroidデバイスを使用しているため、Androidスマートフォンのバックアップに使用されるプロセスの多くはPelotonでも機能します。Android カスタムROMシーンでは、ユーザーがそれぞれ重要なパーティションのすべてのフラッシュダンプを取得し、後でそれらを復元する方法を提供するカスタムリカバリイメージを使用するのが一般的です。このようなコミュニティでは、これらの手順を実行するために、まずデバイスのロック解除を行う必要があることは言うまでもありません。Android OSでは、ユーザーがこれらの重要なパーティションをフラッシュすることができますが、通常、攻撃者が「現在」実行中のシステムにアクセスできないようにする制限が設けられています。攻撃者がルートキットをインストールする目的でAndroid デバイスを入手したとしても、いくつかの面倒な手順を踏む必要があります。最初に攻撃者がとる必要のあるステップは「開発者向けオプション」メニュー内のユーザーモード設定である「OEMロック解除」を有効にすることです。ブートローダーに物理的にアクセスしても、この設定がされていない限り、攻撃者はAndroidデバイスを「ロック解除」できません。このオプションは通常、ユーザーのパスワード、PIN、またはスマートフォンの生体認証ロックによって保護され、攻撃者が簡単にアクセスできないようになっています。2つ目の有効なセキュリティ対策は、「OEMロック解除」設定がオンになっている場合でも、最初にロック解除を実行するコマンドをブートローダーに送ると、アプリケーション、ファイル、パスワードなどを含むAndroidデバイス上のすべてのデータが消去されます。これにより、攻撃者が何の疑いも持たない被害者の Android デバイスにアクセスできたとしても、すべてのデータを削除せずにルートキットをインストールしたり、既存のカーネルを変更したりすることはできません。それにより、個人データが攻撃者の手に渡ることが阻止され、デバイスが改ざんされたことが明らかになります。
アプリがAndroid内のデバイスのロック解除ステータスのクエリを発行する複数の方法があるため、今回の調査では、Pelotonのロックを解除することは控えました。私たちが行いたかったことは、発見されたあらゆる脆弱性の原因が、ロック解除によってデバイスが異なる動作をしたためではないことを確認することでした。調査で生じたこうした齟齬は通常、2 つのターゲットデバイスを使用し、1つはコントロールとして、もう1つはテストデバイスとすることで特定します。残念ながら、私たちが使用できるPelotonは1つしかありませんでした。もう 1 つの問題は、Pelotonのハードウェアはあまり一般的ではなく、 Team Win Recovery Project（TWRP）など、前述したようなカスタムリカバリイメージの開発者は、すべてのデバイス用のイメージを作成するのではなく、最も一般的なものだけを作成することです。したがって、バックアップ簡単にとる方法には、デバイスのロックを解除するだけでなく、独自のカスタムリカバリイメージを作成することが必要です。
そこで、私たちは判断を迫られることになりました。ブートローダーのロックを解除してデバイスをルート化すると、フラッシュメモリブロックデバイス （フラッシュパーティションへのローインターフェイス）への内部的なアクセスが可能となり、必要に応じてバックアップの作成と復元ができるようになります。ただし、前述のように、これにより、バイクが「改ざんされた」状態になったことがすぐに分かってしまいます。もう1つの方法として、バイクの無線（OTA）アップデートの1つをキャプチャしてバックアップとして使用することも考えられますが、実際にOTAイメージを手動でフラッシュするには、デバイスを「ロック解除」する必要があります。どちらのオプションも理想的とは言えなかったため、他のソリューションを探し続けました。
Android Verified Boot プロセス
セキュアブートがWindows PCのOSを適切に起動するためのセキュリティメカニズムを提供しているのと同じように、AndroidはAndroid Verified Boot（AVB）と呼ばれる起動プロセスを制御する手段を実装しています。Androidの資料によると、AVBは「使用前に、起動時にAndroidバージョンの一部であるすべての実行可能コードとデータを暗号論的な観点から検証する必要があります。これには、ブートパーティションからロードされたカーネル、dtboパーティションからロードされたデバイスツリー、システムパーティション、ベンダーパーティションなどが含まれます」とあります。
Peloton Bike+は、デフォルトでは「Verity Mode」がtrueに、「Device Unlocked」および「Device Critical Unlocked」がfalseに設定された状態で出荷されます。これは、変更されたブートイメージのロードを防ぎ、デバイスの改ざんを判断する方法を提供するのが目的です。図1にあるように、この情報は、Pelotonのfastboot oem device-infoを実行することで検証されました。
Androidブートプロセスは簡略化して次のようにビジュアル化すると、明確になります。
変更されたコードが図2のいずれかの段階で見つかった場合はブートプロセスを中止するか、デバイスのロックが解除されている場合はイメージが検証されていないことをユーザーに警告し、ブートを中止するオプションを提供します。
今回のプロジェクトの範囲について、Androidブートプロセスを調査対象に含めないことにしました。そして、PelotonがAndroid提供のセキュリティ対策を使用しようとしたことを確認し、その上でバックアップが可能かどうかを再び熟考しました。
Pelotonを含む新しいAndroid製品の更新方法では、Androidのシームレスシステムアップデート （A/B）を使用します。この更新方法では「recovery」パーティションが不要になるため、カスタマイズされたリカバリを行いたいユーザーは、提供されたイメージをダウンロードして起動するfastboot bootコマンドを使用する必要があります。これは一時的なブートで、「ラッシュ」、つまりデバイスのフラッシュパーティションを「フラッシュ」、つまり変更せず、再起動時に以前のブートイメージに戻ります。このオプションを使用すると変更されたコードを実行されるため、デバイスがロック解除の状態でのみ使用でき、ロックされたデバイスで試行すると、「デバイスのロックを解除して、このコマンドを有効にしてください」というエラーメッセージが表示されます。
これは、優れたセキュリティ実装です。なぜなら、PCのライブUSBから起動するプロセスと非常によく似ていて、このコマンドが常に許可されていれば、ルートユーザーとしてログインして、基盤となるシステムとコンポーネントを完全に制御できるためです。
変更されたコードの起動
ここでは運がよかったか、あまり考えていなかったことが奏功しました。デバイスのロック解除をためらい、バックアップを作成したいと思って、何が起こるかを確認するためだけに、一般的なTWRPリカバリイメージを起動しようとしました。このイメージは最終的に黒い画面になりました。リカバリイメージはそれぞれ、ディスプレイやタッチデジタイザーなどデバイス固有のハードウェア用の正しいドライバーを備えた小さなカーネルが必要なため、これは想定されていました。ところが、想定外だったのは、fastboot bootコマンドを通り抜けることでした。カスタムリカバリを実行することはできませんでしたが、1 つのことがわかりました。システムは、カスタムイメージを起動しようとする前に、デバイスがロック解除されていることを確認していなかったのです。通常、このコマンドは「ロックされた」デバイスでは拒否され、前述のように fastbootコマンドでエラーが発生します。
また、変更されたイメージを起動したにもかかわらず、内部ヒューズが焼損していなかったことがわかったことも重要です。これらのヒューズは、OEMのロック解除プロセス中に焼損することが多く、それによってデバイスが異なる「信頼のルート」のインストールを許可していないかどうかを特定できます。このようなヒューズの焼損は永久的な動作であり、焼損したヒューズは、デバイスが改ざんされたことを示すケースであることがよくあります。図3に示すようにError! Reference source not found.、「Secure Boot」のヒューズはまだ存在し、デバイスはロックされたブートローダーを報告していました。
OTAイメージの取得
この発見は予期せぬもので、最終的にデバイスのバックアップを取り、Pelotonを「改ざんされていない」状態にしておくことができる欠陥を偶然見つけてしまったようなものでした。カスタムイメージは「ロックされた」ブートローダーでも起動できることがわかったため、私たちは有効なブートイメージを収集する方法の検討に入りました。この対象になるのが、正常なブートを容易にする適正なカーネルドライバーです。OTAアップデートURL をつなぎ合わせて、Pelotonから直接更新パッケージをダウンロードできれば、変更可能なブートイメージが含まれている可能性があります。ブートイメージを変更する機能があれば、ブロックされたデバイスのルートとアクセスが可能になります。
ADBデバッグを有効にしただけでも、デバイスからPeloton固有のアプリケーションをプルできました。図4にあるように、すべてのPeloton APKをリストアップし、OTAパスを取得するのに役立つものを探しました。
OTAServiceという名前が見込みがあると思ったので、APKをプルダウンし、JADXを使用してリバースエンジニアリングを開始しました。いくつか手順を踏んだ結果、図5にあるように、アプリがOTAアップデート用のダウンロードURL文字列をどのように構築しているかを確認することができ、beginDownload()にパスされていることを突き止めました。
また、beginDownload（）の呼び出しの1つ手前で見られたような、多数のAndroidログ呼び出しがあることを確認したため、図6にあるように、Androidの組み込みlogcatコマンドを使用して、「OTA」出力をgrepしました。そうして、OTAアップデートに使用された S3バケットと、OTAConfig.jsonというタイトルのファイルマニフェストを見つけることができました。
OTAService.apkとログから取得した情報を組み合わせることで、図7に示すように、OTAイメージマニフェストファイルへのフルパスと各OTA zipファイルの名前をつなぎ合わせることができました。
次のステップは、OTAアップデートのコンテンツを抽出して、Pelotonハードウェアの特定のカーネルドライバーを含むすべての有効なboot.imgファイルを取得することでした。Pelotonはシームレスな更新を容易にするAndroidのA/Bパーティションを使用しているため、更新パッケージは「payload.bin」形式で保存されました。Androidペイロードダンパーツールを使用して、binファイルに含まれるすべてのイメージを抽出することができました。
ブートイメージの変更
boot.img が抽出されたら、デバイスでルートアクセスを取得できるように初期カーネルを変更することが必要でした。これを実現するにはさまざまな方法がありますが、私たちはシンプルに進めるため、 Magiskインストーラーを使用してboot.imgファイルに「su」バイナリを含めるようにパッチを当てることにしました。boot.imgにパッチを適用すると、 fastboot bootコマンドを再び使用できますが、今回はパッチを適用した boot.imgファイルをパスします。PelotonのVerified Bootプロセスが、変更されたブートイメージが改ざんされたものだと識別できなかったため、OSはパッチを適用したboot.imgファイルを使用して通常通りに起動しました。このプロセスが完了した後、Peloton Bike+は、目視検査では「通常」の状態と区別できず、このプロセスでは、Peltonが不正侵害されたことをユーザーに知らせる成果物を示す結果にはなりませんでした。しかし、見た目はだまされている可能性があり、実際にはAndroid OSがルート化されているため、図88図8にあるように、「su」コマンドを使用してルート化され、UID=0でアクションを実行できます。
影響のシナリオ
先ほど示したように、Android Verified Bootをバイパスできることで、物理的にアクセス可能な攻撃者によってAndroid OSが侵害される可能性があります。このような攻撃経路の最悪のシナリオには、変更されたイメージでPelotonを起動した悪意のあるエージェントが、昇格された権限を取得し、それらの権限を利用してリバースシェルを確立することが含まれます。その結果、攻撃者は遠隔からバイクへの無制限のルートアクセスを得ることになります。攻撃者は変更されたイメージを起動するためにデバイスのロックを解除する必要がないため、デバイス上で達成したアクセスの痕跡をとどめることはありません。この種の攻撃は、サプライチェーンプロセスを介して効果的に実行される可能性があります。悪意のある攻撃者は、建設から倉庫、配送までのあらゆる段階で製品に不正な変更を加え、エンドユーザーに気づかれることなく知Androidタブレットにバックドアをインストールできる可能性があります。別のシナリオとしては、攻撃者がジムやフィットネスルームに設置されているこれらのデバイスの1つに近寄って同じ攻撃を実行し、後で使用するためデバイスのルートアクセスを取得する可能性もあるでしょう。攻撃者は下の図9のPelobuddyインタラクティブマップを参考に、攻撃しようとする公共のバイクに狙いをつけるおそれもあります。
攻撃者がルートを取得すると、ルートキット方式でOSを変更することで永続的に居座ることが可能となり、攻撃者にとってはこの手順を繰り返す手間が省けます。もう1つのリスクは、攻撃者がシステムを変更して中間者攻撃を行い、SSLピン留め解除と呼ばれる手法を使用して、SSL暗号化トラフィックを含むすべてのネットワークトラフィックを傍受する可能性があることです。これには、内部暗号化機能への呼び出しをフックするためのroot権限が必要です。この方法でネットワークトラフィックを傍受して復号化すると、ユーザーの個人データの侵害につながるおそれがあります。最後になりますが、Peloton Bike+にはカメラとマイクも搭載されています。Androidタブレットでルート許可を使用してリモートアクセスできることで、攻撃者はこれらのデバイスを監視できるようになります。以下のビデオでデモの確認が可能です。
Disclosure Timeline and Patch
開示のタイムラインとパッチ
欠陥の単純さと深刻さを考慮して、引き続きリモートの脆弱性についてのデバイスの監査を継続しながら、Pelotonに開示することにしました。2021年3月2日に、詳細を網羅した開示情報を送信しました。その直後にPelotonはこの問題を確認し、その後、修正用のソフトウェアバージョン「PTX14A-290」をリリースしました。パッチが適用されたイメージでは、ユーザービルドで「boot」コマンドを使用できなくなり、脆弱性が完全に低減されました。Pelotonの脆弱性開示プロセスはスムーズで、同社のチームはすべての伝達事項をすぐに理解し、迅速に対応しました。
私たちはPeloton Bike+の調査を続けています。今後、更新情報がある際には、マカフィーのATRブログでお伝えします。
※本ページの内容は2021年6月2日（US時間）更新の以下のMcAfee Blogの内容です。
原文：A New Program for Your Peloton – Whether You Like It or Not
著者：Sam Quinn and Mark Bereza