ルート権限なしでBluetoothデバイスをAppleのAirTagに変身させる方法とは？
引用元：https://news.ycombinator.com/item?id=43196207
ざっくりまとめると、Apple製デバイスは特定の形式のBLE広告を受信して、失くしたデバイスを示す”Find My”ネットワークに参加するんだ。失くしたデバイスの広告は公開鍵の一部を含んでて、その鍵の全体は広告本体に収まらないからアドレスフィールドに押し込まれてるっぽい。正確には224ビットの公開鍵から46ビットだけがアドレスフィールドに入ってる。誰でも”失くしたデバイス”の広告を作れるんだけど、アドレスフィールドを完全にコントロールする必要があるんだ。BLE広告のヘッダーにはアドレスの種類が表示されるけど、失くしたデバイス広告は”Random Static”として扱われるべきなのに、Appleはどんなアドレスタイプでも広告を受け入れることがわかったんだ。これを利用して、既存のホストアダプタのBLEアドレスに合った公開鍵を生成できる。ホストアダプタのBLEアドレスは一般にユーザー権限じゃ変えられない。計算は重いけど、大部分がメーカーコードで形成されてるからプリコムputed（レインボーテーブル）もできる。
ちょっと待って、どうやって公開鍵から秘密鍵を生成してるの？それって難しいはずじゃない？大きな塊の鍵（秘密鍵か公開鍵？）がメーカーコードって本当なの？それはおかしい。
＞ちょっと待って、どうやって公開鍵から秘密鍵を生成してるの？
彼らは生成してないよ。犠牲者のBLEアドレスと一致する公開鍵ペアを生成してるんだ。Find Myネットワークは、攻撃者の秘密鍵で暗号化されたビーコンをこのアドレスから受け入れて、iCloudに格納する。そして攻撃者はその46ビットのプレフィックスでそれを取り戻せるんだ。
Appleがこれをどう修正したか分からないけど、パッチで何を変えたんだろう？このままじゃ今のAirtagネットワークをシャットダウンしないと無理じゃない？
Findersにパッチを当てたんだろう、多分これを修正したんだろうね：＞失くしたデバイス広告は”Random Static”として扱われるべきなのに、Appleの”Find My”リスナーはどんなアドレスタイプでも広告を受け取ることがわかってる。
犠牲者のBLEアドレスって、あの人が以前スキャンしてAirtagを設定したターゲットデバイスのこと？
違うよ。高額な計算を経た公開鍵の最初の46ビットが犠牲者のBLEアドレスと一致するんだ。AppleのFind Myシステムは（または以前は）送信される公開鍵が製造または登録されたことを確認してなかったから、iCloudアカウントを持つ誰でもApple Find Myのハッシュテーブルに問い合わせて、近くの電話から生成された観測された位置が含まれている観測された暗号payloadを取得できたんだ。もし犠牲者のデバイスでrootがあれば、高額な計算ステップが不要になるから好きな公開鍵/秘密鍵ペアを取って、犠牲者のBluetoothハードウェアを再プログラムしてそれを放送することができるんだ。
分かった、攻撃パターンは二つあって、一つはターゲットデバイスのBluetoothを置き換える方法、もう一つは自分の秘密鍵を使って、一致する公開鍵プレフィックスを探してビーコンを設置する方法だよね？それとも理解できてないのかな？
最初から、犠牲者デバイスをBluetoothビーコンに設定できるのはroot権限を持ってる時だけだった。ただ犠牲者のBluetoothアドレスを変更して、AirtagをクローンしてFindMyビーコンを放送することで、攻撃することができた。今回の攻撃の新しい点は、root権限なしで行えることだよ。犠牲者の固定Bluetoothアドレスを観察して、一致するFindMyビーコンを作れるんだ。FindMyビーコンは基本的に、受信者が位置データを暗号化するために使う公開鍵だから、ビーコンを作成するのは犠牲者のBluetoothアドレスと一致する公開鍵/秘密鍵ペアを見つけるだけ。それにビーコンを放送するのは権限が低くて済むから、さらに広く悪用される可能性があるんだ（高額な事前計算ステップを除いて）。
違うよ、犠牲者のMACを見つけて、そのデバイスから放送するためのペイロードを生成するんだ。それによって、デバイスはAppleのデバイスにとって本物のAirtagとして見える。そうするとAppleが位置レポートをアップロードして、攻撃者がそれをダウンロードすることになるんだ。本物のAirtagは関係ない。
公開鍵の生成をランダムな秘密鍵を使ってブルートフォースしてるみたいだね。正確な秘密鍵は関係ないし、生成された公開鍵の全長も重要ではない。ただ最初の46ビットだけが重要だから、その部分に合致する公開鍵を見つけるためのブルートフォース検索が可能なんだ。
なるほど。2^46は約70兆だから、計算的には全然可能だね。つまり、データベースに70兆の秘密鍵／公開鍵を生成するためにGPUが必要なだけってことだ。悪くないな。
レインボーテーブルを使ってるんだ。
一度生成すればいいんだ。
キーのペアを事前生成してるみたいだね。トロイの木馬がMACアドレスをサーバーに送信し、サーバーが事前計算したキーのストックから公開鍵を見つけるってわけ。
NYCやLA、ロンドンのAndroidユーザーがメッシュネットワークの「仮想エアタグ」を作って、街中を巡るiPhoneを追いかけることはできないかな。私もAndroidに切り替えて参加したいな（実はもうAndroidだけど、オペSecがバレちゃうな、ハハ！）。
記事から面白い点は、これは単なる一般的な脱獄やBLEプロトコル間の対抗的相互運用ではないってこと。誰かのデバイスをエアタグに変えて、その位置を追跡できるんだ。＞それに、Apple Security Teamからの迅速な対応と承認に感謝します。Appleは最近、iOS 18.2やその他のOSのバージョンで脆弱性を修正しました。でも、まだ未パッチのiPhoneやApple Watchが近くにある限り、この攻撃は有効なんだ。1.5BものiPhoneが早くアップデートするのを望むだけなんて、かなりまずい脆弱性だよ。まだiOS 17や16のままの人もいるし、全員が共謀者になってる。私の州がセキュリティ研究に参加しているのを見るのは嬉しいけどね。
他の人のデバイスをエアタグに変えて、その位置を追跡することができるってことだね。ただし、あなたのコードをそのデバイス上で実行させないといけないけど。
いや、上のコメントの要約を読んでみて。
実際にそうだよ。追跡されるデバイスは、BLEで存在を広告するためのコードを実行できるように、何らかの方法で攻撃される必要があるんだ。FTAの「Architecture of nRootTag」：＞（1）トロイの木馬コードは追跡されるコンピュータ上で実行される。
すごく面白いけど、ターゲットデバイスにコードがあるなら、なんでFindMy経由で位置情報を送るの？外部サーバーと通信してプリコンピュートしたキーを取ってるなら、もっと簡単に位置を共有できると思う。でもターゲットデバイスにGPSがない場合、FindMyが他の方法より近い場所を特定できるかもね。 GPSがないのが理由の一つだね。もう一つはネットワーク接続がなくても追跡できること。でも、ネット接続が切れてる状態で、近くにiPhoneがある状況はあまりないかも。例えば飛行機の中とかね。 iOSのパッチはトロイの木馬によるハイジャックを防ぐためじゃなくて、iOSデバイス同士がFindMyメッセージを放送するのを止めるためのものだよ。 ハッキングされたコンピュータの居場所を特定する良い方法だね。世界中に感染させるランサムウェア作者には役立つかも。Appleの位置情報スキャンデバイスのネットワークを悪用してるだけで、新しいことじゃない。アクティブなBluetoothスタックなしでデバイスを追跡できるなら、FindMyネットワークを利用してGPSなしで位置を特定できるかも。近くにAppleユーザーがいれば、電池も節約できるかもしれない。 このエクスプロイトはBLEパケットを送信するものがデバイスに必要なんだ。そんなに大きな問題じゃないよ。優れたPRチームだね。他のサイトはFmFを壊したみたいに報道してるけど、すでにデバイスがパワーを奪われてる時点で問題じゃないんだ。 広告SDKが広告を出すアプリの中で、許可なしでユーザーを地理特定するようになるのは時間の問題だね。既に位置情報の許可を持ってるアプリにとって、あまり気付かれないと思う。 ＞”広告SDKが広告を出すアプリの中で、許可なしでユーザーを地理特定するようになるのは時間の問題だ” ＞”Bluetoothの許可が必要だから、普通のフラッシュライトや天気アプリには怪しまれるだろうね” ＞”Bluetoothの許可が必要だから、普通のフラッシュライトや天気アプリには怪しまれるだろうね” iOSでは動かないよ。アプリはiOSでローカルのMACアドレスを取得できないから、プライバシーの理由だね。全ての選択肢を試すのも電力の理由で早々に制限かかるよ。 256^3のプリセットを事前計算する必要はないんじゃない？これらのキーはプライベートやセキュアにする意図はないし、MACアドレスだけが違えば再利用しても問題ないと思う。16777216の組み合わせなんて、最近はそんなに多くないし、6コアで3.5GHzのCPUを使えば、1000命令で確認する間に4〜5秒で全通りのブルートフォースができそう。 問題は事前計算じゃなく、MACアドレスが分からないとすべてをブロードキャストしなきゃならないってことだ。iOSはそんなに多くのブロードキャストを許可しないんだよ。 MACアドレスは必要なくて、iPhoneが特定のBLE広告パケットをブロードキャストすればいいんだ。Core Bluetooth APIを使えば簡単だけど、アプリを作ったり、SDKを改造したりする必要がある。アプリがフォアグラウンドで動いてるときだけBLEビーコとして動けるけどね。 元の情報を読んでみて。自分のMACアドレスを知っている（もしくは推測する）必要があるんだ、それがキーの一部になるから。 そうそう、MACアドレスがわかれば攻撃は現実的になる。ただ、MACアドレスがわからないと検索空間が広すぎて、膨大な時間がかかる。攻撃にはユーザーがアプリをダウンロードして、偽のBLEをブロードキャストしないといけない。他のデバイスがそのMACを拾って教えてくれる必要もあるけどね。 目標次第で全く問題ないよ。 そうだね。コード実行やインターネット接続、Bluetoothの権限が必要だし、もし被害者のデバイスにGPSがあれば、この攻撃は無意味になるよ。 攻撃ってのは分かるけど、自分の非AppleのBluetoothデバイスにこれが使えたらすごく便利だよな。 これ、１ヶ月前に投稿されたやつなんだよね： https://news.ycombinator.com/item?id=42835772 これって https://github.com/seemoo-lab/openhaystack とどう違うの？編集：皇冥のない状態で動作するみたいだし、この発見がopenhaystackを改善できるかな？ この話はOpenHaystackにはあまり影響ないね。要するに、MACアドレスを変えずにFindMyのBLEメッセージをブートフォースで送れるってことだけで、根本的にはそういう仕様なんだ。自分のデバイスをAirTagにしたいなら、ルート権限でMACアドレスを変えた方が早いよ。 カスタムBluetoothファームウェアをインストールする必要がないってことで。 ただ、そこから図をそのままコピーしたってわけさ。 Appleがこの問題をどう扱うか気になるな。善意でオープンにするのか、予想外の使い方が多すぎてネットワークを閉じる方向に行くのか。自分のAppleデバイスがこれを探してAppleと情報共有してるのがどれだけデータに加算されるかも気になる。 最近のアップデートで修正されたけど、更新してないデバイスはまだたくさん残るだろうね。サーバー側での修正は無理なんだ。 こういう脆弱性への対策は、AirTag特有のパケットタイプに受け入れを絞る感じかな？ OpenHaystackは長い間あったけど、実はあまり気にしてないようだね。 この脆弱性、デバイスにルートアクセスが必要ってことだよね。それなら自分のノートPCで失くしたビーコンを発信できて、タダで盗難追跡できるってこと！？ iPhoneがFind Myネットワークに参加しないようにしたいなら、iCloudをオフにすることでBLE広告の共有が無効になるって理解してるよ。 Find My Phoneをオフにするだけでも同じだと思うよ。 この脆弱性の修正が、自分の好きなBLEデバイスをFindMyネットワークで使う能力を奪う可能性ある？ その能力は奪わないよ。 建設的な意見として、GPUのセクションは意味がない感じがするから、削除するか、もっと論文の内容を補足してほしいな。 いいね！Chipoloのトラッカー持ってるけど、AirTagに比べて追跡がイマイチ。この方法でAppleのネットワーク経由で追跡できるようになるかな？ カスタムファームウェアをフラッシュできればね。安いデバイスのファームウェア作成も色々な試みがされてるから、簡単かも。 Samy Kamkarの本からそのまんまみたいだね。 オープンソースのハードウェア/ソフトウェアに対応したAirTagsや仮想AirTagsの可能性が開けたかもね？ AppleがAirTagのiCloud送信された紛失通知メッセージにアクセスできるなんて知らなかった。 AirTagに関連付けられた秘密鍵が必要だよ。 …と、SMS認証された電話番号があるApple Accountもね。リクエストすることで、AppleがそのAirTagに興味のあるApple Accountを知ることになる。FindMyの匿名性の主張は、実際に物を失くして探そうとする時には消えちゃうよ。ネットワークを問い合わせない限り匿名っていうのはね。 実際のAirtagsは、鍵を1日ごとにローテーションしてるんだって（紛失モードの時ね）。Appleはその鍵を予測できないから、理論的にはx、y、zデバイスから報告されたタグを探してるって分かるけど、実際の位置情報は暗号化されてる。 これ、システムをフラッドさせるのに悪用できるんじゃないの？ ＞ この研究は、米国国立科学財団（NSF）の助成金CNS-2304720、CNS-2310322、CNS-2309550、CNS-2309477によって部分的に支援を受けた 人々はまだこの脆弱性を見つけ続けるだろうね。減るとは思うけど、アメリカ国内からはますます少なくなるし、公に詳細を発表する人も減ると思う。 直感的には、こういう脆弱性開示がもう既に見つかっている人たちによって行われることが多い気がする。そういう脆弱性を積極的に示すプログラムがあるから、国家的な情報機関のインチキが大半になる一方で、組織犯罪やテロリストには行き渡らないでいるのかな。将来の問題がこういうプログラムによって防げたとは言えないから、社会のインフラを守る意味でも大事だと思うよ。 面白いな。Appleがタグに対してブロードキャストアドレスが有効かどうかを確認してない隙をついてるみたいだね。BLEのブロードキャストは、暗号化の一部をメッセージアドレスに入れて、その後はペイロードに入れてる。これを使って”普通の” BLEアドレスを使って鍵を逆向きに解読してる。 ＞ ただの”普通の”BLEアドレスを使って鍵を逆向きに解読してるんだ。 Appleは鍵の素材として会社IDを使ったの？ 違うよ。もう一度論文を読んでみて、特に図3を見て。 ビッグテックのエンドツーエンド暗号化はどうなったんだ？私の推測だけど、これは意図的なバックドアが発見されたんじゃないかな。 エンドツーエンド暗号化はされてるけど、攻撃者が両端をコントロールできちゃうって感じ。バックドアはないよ。もっとコメントを表示（1）
Bluetoothの許可が必要だから、普通のフラッシュライトや天気アプリには怪しまれるだろうね。＞”既に位置情報の許可を持ってるアプリにとって、あまり気付かれないと思う”
アプリがすでに位置情報の許可を持っているなら、なんでこの攻撃をする必要があるの？ユーザーの位置を直接取得できるのに。
家族のスマホから消さなきゃいけないアプリを見てると、それは問題にならないと思うよ。＞”アプリがすでに位置情報の許可を持っているなら、なんでこの攻撃をする必要があるの？”
位置情報APIにアクセスするとインジケーターが表示されるけど、BLE APIにアクセスしてもそうはならないと思う。
みんな気にしないと思うけど。もっとコメントを表示（2）
もっとコメントを表示（3）
いい時代だったね。
すごく賢いね！BLEの規格はメッセージのサイズに制限があるから、Appleはメッセージの一部をアドレスに使ってる。でも、BLEチップの公開アドレスには”会社ID”っていう24ビットがあって、その情報は公にされているから、いくつかの公開/秘密鍵ペアを事前に計算できる。
