2018年は、消費者向けオンラインショッピングの継続的な成長トレンドがさらに記録を更新した年でした。技術と利便性の向上、コストと納期の低減により、オンラインショッピングはより日常的な消費者行動になりました。
オンラインショッピングの成長に伴い宅急便の配達数が増加していますが、同時に配達荷物の盗難も増えています。とっさに、YouTuberのマーク・ローバー氏（Mark Rober）の「ラメパウダー爆弾」を再生産しようという衝動に駆られたのですが、そこはぐっとこらえ、代わってBoxLock(BoxLock ファームウェア:94.50 又はそれ以前)と呼ばれる革新的な製品を調べてみることにしました。BoxLockはスマート南京錠です。自宅の玄関先に設置した配達物収容コンテナを保護するために装着します。解錠するには、モバイルアプリケーション（AndroidまたはiPhone）や配達荷物をスキャンする内蔵のバーコードスキャナーを使用し配達予定の荷物か確認して開くことができます。荷物の配送担当者はBoxLockを解錠してコンテナを開け、配達荷物を入れて施錠し、泥棒が手出しできないようにします。家主は、専用のアプリをインストールした携帯電話を使って解錠し、大事な荷物を取り出すことができます。
私はハードウェアの研究者として、BoxLockを入手し分解して内部を調べてみました。
デバイスを分解してメインPCBを取り出したところで、複数の興味深いピンが目に入りました。主にUARTとJTAGの接続に使われています。WiFiモジュールの下部に5本のピンがあり、UARTに間違いないと思われたのですが、ロジックアナライザーを介して起動しても通信しているようには見えませんでした。
BoxLockは、CPU、RAM、ROM、およびフラッシュメモリを1つにまとめたSOC（システム オン チップ）を使っています。ところが、不思議なのは、フラッシュチップがもう1つあったことです。私が使っているExodus Intelligence（エクソダス インテリジェンス）のハードウェアインターフェイスボードでSPIフラッシュチップに接続し、コンテンツをダンプしました。
フラッシュチップには何も入っていませんでした。私の推測が正しいとすれば、このフラッシュチップは配達荷物のバーコードを記憶するためのものでしょう。もちろんフラッシュをダンプするために使ったソフトウェアである私のフラッシュメモリに問題がある可能性もあります。というのも、私のフラッシュメモリは初期設定ではサポートされておらず、正確なフラッシュチップ（FT25H04S）をサポートするよう自分でコンパイルしなければならなかったからです。それでも考えられる理由はそれだけです。
フラッシュチップからの収穫は何もありませんでしたが、最大の目的はSOCを調べることでした。プロセス制御基板（PCB）の裏側を見ると、タグ接続用の接続ポートが2つあります。SOC（上の画像の57番ピンと58番ピン）上にはSWD（シリアル ワイヤー デバッグ）ピンがあり、できるだけゆっくりと慎重に小さなタグ接続用の接続への回路を追っていきました。
私はJTAG分析をそれほどしたことがないので、実験用にラボで所有しているAdafruit Feather M0を持ってきました。FeatherはBoxLockとまったく同じSOCとWiFiチップを使っているからです。Adafruit Featherには、SWDピンからSOCへの接続方法に関する優れたドキュメンテーションがあります。Atmel Studio設定を使用して情報をATSAMD21のSOCから読み込んだところ、それぞれのヒューズの機能とAdafruit Featherからフラッシュ全体をダンプする方法が出てきました。
Atmel Studioからは、有効な「セキュリティビット」をデバイスが持っているかどうかもわかります。設定すると、すべての外部プログラミングおよびデバッグインターフェースを無効にするため、メモリの抽出と分析が非常に困難になります。セキュリティビットが設定されると、チップを完全に消去しない限り、ビットを回避したりクリアしたりすることはできません。
Adafruit Featherの効果を実感した後、BoxLockをSegger JLinkに接続してAtmel Studioをロードしました。 Segger JLinkはJTAGとSWDに使用できるデバッグデバイスです。驚いたことに、開発者はセキュリティビットを設定していました。IoTデバイスでは見過ごされがちな機能ですが、脆弱性を見つけるという目的には障害だったので、他の場所に目を向けました。
しばらく細かく観察すると、より大きなタグ接続ポートがBLE（Bluetooth低出力）モジュールに由来することを突き止めました。BLEモジュールにはフルSOCがあり、これはこれで調べてみたいのですが、その前にまずは調査すべき2つの経路があります。BLEとWiFiネットワークトラフィックです。
BLEはBluetoothとは異なります。BLEデバイス間の通信は暗号化することで保護され、その堅牢性は使用されるペアリングモードによるもので、BLEはいくつかの異なるペアリングモードを可能にします。最も安全性の低い「Just Works」ペアリングモードは、BoxLockが使用しているものです。このモードではどんなデバイスでも接続でき、普通のBluetooth接続で特有のピンペアリングは必要ありません。これは、BLEデバイスが知らぬ間に傍受されたり、MITM（Man in The Middle、中間者）攻撃を受けやすいということを意味します。
BoxLockはカスタムGATTコマンドを使用していたので、「不明な」UUIDに関する詳細情報が見つかるかどうかを確認するためにAndroid APKを逆アセンブルすることにしました。Android APKを逆アセンブルするために「dex2jar」と呼ばれるツールを使用し、コードをきれいにするためにJSBeautifyを介してJavaScriptコードを走らせました。
次に、UUIDとキーワード「GATT」の検索を行うと、GATTサービスの全リストと関連事項を見つけることができました。
私が最も関心を持ったのは、ロック解除GATTコマンドが送信されていた場所に「Command Service」と表示されていたことです。試しに、NRF Connectアプリケーションを使用して、属性値「2」を指定してGATTの「sendOpenSignal」コマンドを送信しました。
それはとても簡単で、なんと、BoxLockのロックが解除されたのです！
驚きです。私がGATTコマンドの送信に使った電話は、それまでBoxLockに接続したことがなく、BoxLockアプリケーションもインストールされていませんでしたが、それでもBoxLockのロックを解除することができました。（脆弱なアプリケーションのバージョンはv1.25以下）
他のGATT UUIDの探索を続けると、WiFi SSID、アクセストークン、ユーザーのメールアドレス、およびクライアントIDをデバイスから直接読み取ることができました。これらの同じ値を任意に書き込むこともできました。
BoxLockのロック解除に必要な識別子は、アクセストークン、ユーザーの電子メールアドレス、およびクライアントIDです。これらが存在しない場合、デバイスはクラウドAPI経由で認証されず、ロックが解除されません。
すべてのフィールドを読み書き可能な状態に関して最も顕著な問題は、私がデバイス上で正常に再現することができたことです。最終的にはいかなる認証も回避し、BoxLockは解錠されてしまうのです。
私の実験では、これらの値には期限切れにならず、BoxLockからバッテリーでも外さない限り、デバイスが認証に必要な認証情報をクリアできません。もっともBoxLockバッテリーが「技術的に」言って取り外されることなど決して想定していません。私が実験できたのは、ロックを物理的に分解したため（かなりの労力がかかりましたが）です。
BoxLockのロックを解除することはできたものの、もう1つ別の一般的な攻撃経路を探索したいと思いました。デバイスとインターネット間のネットワークトラフィックを分析してみると、ファームウェアの更新は別として、デバイスからクラウドへのトラフィックはHTTPSで適切に保護されており、有用な情報を見つけるのは容易ではないとすぐに気付きました。
BoxLockが現時点でどの程度利用されているのか推定できる材料はないため、仮に悪意のあるグループがこの問題を発見した場合、その潜在的な影響がどのくらいの範囲に及ぶ可能性があるかについてはコメントはできません。攻撃経路の1つの制約は、約30～40フィートの距離から通信するBLEが必要になるということです。しかし、配達荷物を盗もうとしている人にとっては、克服が困難なハードルとは言えないでしょう。ロック解除攻撃は非常に迅速かつ簡単に完了することができ、Bluetooth機能があるスマートフォン1つあれば事足りるのです。悪用の容易さとスピードが、犯罪者にとって魅力的なターゲットになる恐れがあるのです。
このベンダーについて非常に肯定的なフィードバックをしたいと思います。脆弱性の開示はどの企業にとっても扱いづらい困難な問題に違いありません。しかし、BoxLock社はとても対応が早く、一緒に仕事がしやすく、McAfee ATRチームが提供する価値をすぐに認めました。私たちの目的は、悪意のある攻撃者が発見する前に脆弱性を排除し、セキュリティ問題を業界に明らかにすることでセキュリティの全体的な底上げを図ることです。BoxLockは、いま取り組んでいるこのプロセスをまさに体現しています。この脆弱性を発見した翌日にBoxLockは会議を招集して私たちと調査結果について議論し、そこで私たちは緩和計画を提案しました。BoxLockチームは計BoxLockファームウェアだけでなくモバイルアプリケーションにもパッチを適用する画を立てました。1週間以内に彼らはこの脆弱性に対するパッチを作成し、モバイルアプリを更新して、パッチ適用のファームウェアバージョンへの必要な更新を強制的に実施しました。ファームウェアとアプリのアップデートをテストし、脆弱なファームウェアで使用した後にアプリケーションが資格情報を正しくクリアすることを確認しました。また、モバイルアプリの操作がなくても資格情報をクリアする新しいファームウェアをテストしました。
IoTセキュリティは、消費者にとって決定的な要素となっています。脆弱性の開示プロセスは、ベンダー、メーカー、セキュリティコミュニティー、および消費者間の協力を促すには効果的な方法です。ベンダーが製品開発サイクルの早い段階でセキュリティを最優先に取り組むことを願っています。効果的なエンドツーエンドのコミュニケーションプロセスを提供してくれたBoxLockに感謝するとともに、この重大な欠陥はすぐに根絶されたことを喜んで報告いたします。このブログに関する質問やコメントがあればぜひお寄せください。
※本ページの内容は、2019年2月25日（CET）更新の以下のMcAfee Blogの内容です。
原文：What’s in the Box?
著者：Sam Quinn