[レポート]開けゴマ!スマートロック開錠の全容 – CODE BLUE 2023 #codeblue_jp
こんにちは、臼田です。
みなさん、セキュリティ対策してますか?(挨拶
今回はCODE BLUE 2023で行われた以下のセッションのレポートです。
開けゴマ!スマートロック開錠の全容
コネクテッド化が進む社会では、スマートな機能を提供する「新しく改良された」デバイスが紹介されることが多いですが、ドアロックも例外ではありません。セキュリティの向上と使いやすさが、こうしたスマートロックの主なセールスポイントです。しかし、最新のスマートロックは、泥棒が少し練習すれば跡形もなく家に侵入できた90年代のものより安全でしょうか?
本発表ではロック内部の電気信号から始まり、Bluetooth Low Engery(BLE)通信、さらには2つのスマートフォンアプリケーションのリバース・エンジニアリング(そのうちの1つは広く使われているソフトウェア開発キット(SDK)を使って開発されたもの)まで、シンプルな方法と低コストな機器で診断しました。
また、複数メーカーの数百万台のデバイスに影響を与える脆弱性を発見するに至った経緯を共有します。そして、決して諦めないことが報われるのです。
Presented by : トーマス・バイゴット - Thomas Bygodt
レポート
- スマートロックのセキュリティについて
- どうやるの?ドアを打ち破る?
- もっとスマートな方法があるよね
- ターゲットの話の前に歴史から
- 最初の鍵は古代エジプトまで遡る
- 木の鍵
- 1851にThe Great Lock Controversy
- 2009年でBLE
- そしてIoTの普及
- しかしデバイスセキュリティは確保しきれていない
- デバイスのリサーチ
- いろんなロックを購入している
- 中国のあるメーカーのシリーズを購入している
- 2021年夏からハードウェアの調査を始めた
- 最初のステップ
- デバイスの中に入る
- スチールだけで保護している
- 穴を開ける
- 新しいプレートでカバーすれば隠せる
- モーターボードはドアの内側にある
- コントローラー
- デバッグポートはリード保護がない
- ハードとメモリを簡単に取得できる
- モーターコントロールも簡単
- コントローラーを置き換えるのはだめだった
- 間のコミュニケーションはなにかおかしい
- バッテリーを入れたときのシグナルを検出
- リクエストは非常にシンプル
- 2つのシンボルがある
- 違うサンプルを取ってきた
- ヘッダがあり、コマンドがある
- checksumとcontrollerIDを推測
- なのでIDを切り替えると動かない
- この構成の何が問題なのか
- 全てが問題
- 全然保護されていない
- 素晴らしいのはバッテリーが切り替えられる
- 2021年冬
- stringsをする
- easyflushへのリンクなども見つかる
- passwordがそのまま使える
- まずcontroll IDを見つける
- IDのinitialize処理
- この機能を置き換えた
- 毎回ファームをアタックごとに変えないといけないけど
- launch_motor_command関数
- 他の通信はどうなっているか
- AESの鍵は半分だけ
- どう使うかが分からなかった
- 何かを隠していると思った
- 2022年春
- 完全に自動化した攻撃を作りたい
- 正規のボードを攻撃カードに変えたい
- 自分のコードに置き換えたい
- 電源を入れ直したら数秒で開けることができた
- 同じメーカーの新しいデバイスを購入した
- 今度は別のアプローチでやってみたい
- 新しいものはread保護がある
- しかし既知のエクスプロイトですぐに抽出できた
- レジスタのアドレスを置き換えて実行
- ヘッダを検索してみた
- 関数を見つけた
- 新しいものにはNFCが搭載されていた
- 電話を持って近づけるだけでいける
- メーカーに連絡してみた
- そうしたら暗号化しているとレスポンスしてきた
- なんのことでしょう?
- 完全に自動化した攻撃を作りたい
- 2023年夏
- BLE SDKを使って一般的な携帯でロックを解除できる
- シンプルにPlaintext BLE communication
- 暗号化されていない
- アプリケーションは暗号化されている
- BLEのスニッフィングは簡単
- 最初のバイトは順序付けしている
- データはおそらくAES CBCで暗号化されている
- これはセキュアではなかった
- より調査するためにアプリを確認した
- 鍵と平文とIVも確認できた
- 同じ鍵が最初のexchangeで使われ、その後は違うものだった
- 暗号鍵の生成が行われている
- 関数はシンプル
- 最初の鍵はloginKeyだjけ
- 次はsrandも使われている
- 重要なのはloginKey
- 6文字のhexでとても短い
- 20分以内に復号できる
- 一度スキャンできればすぐだ
- ベンダーに問い合わせたがうまく行かなかった
- しかし実際にはバグバウンティプログラムを持っていた
- 2023年2月
- より簡素化する
- どうやってコミュニケーションするか
- コマンドとチェックサム
- レスポンスにはもっと情報があった
- srandの情報やデバイスIDなど
- 次のリクエストではuuidとloginkeyとdevidがある
- uuidだけ知らないのでどうやって取得するか
- BLEにアクティベーションすると使える
- loginkeyを利用しているのでブルートフォースが使える
- 諦めなければクラックすることができる
- デモ
- 正常な通信をキャプチャして18秒で実現できた
- そしてアプリにはログが残らなかった
- そしてうまく報告が通って、ベンダーといいやり取りが出来た
- 報奨金も得ることが出来た
- 2023年5月
- 新しいデバイス
- 穴は小さいが緊急用USBがある
- 直接ボードに繋がってないが、緊急用ボードに繋がってる
- BLEを分析
- 緊急モードはリプレイアタックができそう
- シンプルじゃなかった
- Flutterアプリだった
- リバースすることが難しい
- Flutterを使っていないものを調べた
- ver.2.5.7を選んだ
- 難読化されていなかった
- sendOpen関数を見つけた
- openLockから呼ばれる
- c関数は暗号化の関数
- しかしbyteを取ってシフトしている
- 平文を推測するのは簡単
- 2つの攻撃手法
- 暗号化アタック
- リプレイアタック
- いくつかの提言
- ベストプラクティスを踏襲する
- セキュリティリサーチャーに耳を傾けてくれ
- 消費者には解決策はありません
- ロックメーカーのブログをみるといい
感想
スマートロックは直接脅威につながるので気になるところですね。
消費者としてもどういう選択を取るべきかは悩ましいですね。