- 画面付きイヤホンケースは実際には Androidデバイス に近く、ADBが有効になっていたため、アプリ抽出・サイドロード・API分析へとつながった
- ChatGPT連携はデバイスから OpenAI API へ直接通信しており、ランチャーアプリの
SecurityStringsAPI と難読化されたネイティブライブラリの回避によってAPIキーとシステムプロンプトが露出した
- コンパニオンアプリとサーバーAPIは device id/IMEI だけでチャット履歴を参照でき、チュートリアル動画に映ったデモ機のIDからデモ用チャット履歴全体を取得できた
- 任意のIMEIでQRコードを作成すると未バインドのデバイスをアプリに接続でき、すでにバインド済みのデバイスではエラー応答からアカウントの 氏名の組み合わせ が明らかになった
- IKKOは点検とアプリ・デバイスの更新でチャット参照に署名ヘッダーを追加したが、2025年1月13日時点の更新でもプロキシAPIは
okhttp/4.9.0 のUser-Agentしか要求せず、以前のChatGPT APIキーもその時点でようやく交換された
画面付きイヤホンケースの正体
- IKKO Activebudsは、ケース画面に時刻と ChatGPT を前面配置したイヤホン型デバイス
- 翻訳のようなAI機能も提供し、IKKOストアからアプリをインストールできる
- Google Play Storeはなく、CEOはActiveBudsの画面に合わせてアプリが調整されているためだと説明した
- ストアにはSpotifyのような音楽アプリやSubway Surfersのようなゲームアプリがあったが、小さな画面のため操作しづらかった
- アプリの存在と動作から、デバイスが Android を実行していることが確認された
- デフォルトのEQプロファイルの音質は良くなかったが、EQカーブを手動調整すると実用的な水準まで改善できたと評価されている
ADB有効化で開いた分析経路
- デバイスにはブラウザがなく、他のアプリを直接ダウンロードしにくく、Androidの設定アプリは開けてもビルド番号を7回押しても開発者モードは有効にならなかった
- PCに接続すると ADBが有効 な状態で、これによりアプリのサイドロードが可能になった
- DOOMをサイドロードした後、ChatGPT統合がバックエンドでどう動作しているかの確認を始めた
- ルート化なしではシステム証明書をインストールできず、HTTP検査だけでは正確なURLの確認が難しかったが、アプリ抽出とデコンパイルで必要な情報を把握した
- Spreadtrum/Unisocデバイスではデフォルト署名キーを使う場合にブートローダー解除ツールを利用でき、このデバイスも該当した
- ただしデバイスに音量アップキーがなく、解除確認画面を通過できなかった
- 自分で署名したパーティションをフラッシュする方法は可能性があると見られたが、実施はしなかった
APK内で判明したドメインとキー
- APK抽出ツールでアプリをダンプし、ランチャーアプリを JADX で開くと通信ドメインが判明した
api.openai.com: OpenAI APIchat1.chat.iamjoy.cn: ChatGPT以外にアプリストアなどデバイス全体機能向けAPIと見られ、ブラウザで開くとログインページが表示されたchat2.chat.iamjoy.cn: chat1 と同様の性格を持つように見え、バックアップサーバーの可能性があるopenspeech.bytedance.com: 音声認識のバックアップの可能性が推測されたが、デバイス通信は確認できなかったwww.airdimple.cn: OpenAI APIのミラーまたはプロキシのように見えた
SecurityStringsAPI ファイルには暗号化されたエンドポイントと認証キーが入っていた- 第1段階はbase64で、第2段階は強く難読化された ネイティブライブラリ が処理していた
- 別のルート化済みデバイスにアプリをサイドロードすると、そのまま動作し、その過程で OpenAIキー を確認できた
- ChatGPTのシステムプロンプトも露出しており、デバイスには
Angry Dan と In-Love Dan モードもあった
Angry Dan は罵倒表現が多く、18歳以上の確認が必要だった
チャットログとコンパニオンアプリの認証欠如
- デバイスはChatGPTの会話を
chat1 ドメインの別エンドポイントに記録していた
- そのリクエストヘッダーには メッセージ、モデル、応答、IMEIベースのdevice id が含まれていた
- その後コンパニオンアプリを調査する中で、このログがアプリ内でデバイスとの過去会話を表示する用途だと確認された
- コンパニオンアプリはデバイスの
Membership メニューでQRコードをスキャンしてバインドする
- HTTP検査の結果、アプリはアカウントトークンとdevice idでAPIを参照し、デバイス上の全チャットを取得していた
- アカウントトークンを削除してもリクエストは動作し続けたため、チャット参照APIの実質的な認証は device id のみだった
- チュートリアル動画の1フレームに十分にぼかされていないdevice idを使うと、デモ機のチャット履歴全体を取得できた
- IMEIは特定の範囲を持つため、顧客のチャット履歴も突き止められる可能性があり、機微情報を含む恐れがあると判断された
QRコード生成、氏名露出、メッセージ注入
SecurityStringsAPI の変数名は暗号化されたAPIエンドポイントの用途をそのまま示しており、これにより getBindDevQrCode APIが見つかった- 任意のIMEIを入れると QRコードのbase64画像 を生成できた
- すでに別アプリにバインド済みのデバイスを接続しようとすると「すでに他のユーザーにバインド済み」というエラーが返り、任意の乗っ取りは防がれていた
- しかしエラー応答には、アプリのアカウント作成時に入力した氏名が露出していた
- アカウント作成画面にはユーザー名フィールドがなく、名と姓だけがあった
- 例のアカウントの名
Cheese2、姓 Delight2 は応答中で Cheese2Delight2 として露出した
- 想定される流れは、IMEI推測、QRコード生成、未バインド機器のバインド、既バインド機器の氏名露出、チャット履歴参照へとつながっていた
unbind_dev エンドポイントも存在したが、アカウントトークンを検証しており、任意IMEIデバイスの解除は許可していなかった- チャットログのエンドポイントも認証にdevice idしか使っておらず、他ユーザーのコンパニオンアプリへ 任意のテキスト を送ることができた
- HTMLとJavaScriptを送ってコンパニオンアプリへの攻撃を試みたが、アプリはVueを使用しており、Vueの標準的なHTML/JS挿入防御があったため注入は成功しなかった
- それでも任意のユーザーに詐欺的なメッセージのようなテキストを送れる状態だった
IKKOの対応と残った脆弱性
- 脆弱性はIKKOのセキュリティ部門にメールで報告された
- IKKOはその後、アプリをロックして1週間点検するとの告知を出した
- 点検後、アプリ更新とデバイス更新 が配布された
- チャット履歴参照エンドポイントは新たに
signature ヘッダーを要求するようになった
- 署名はアカウントトークン、device id、言語、現在時刻を公開鍵/秘密鍵とパスワードでエンコードして構成されていた
- この変更により、有効なアカウントトークンなしでチャットを取得することは不可能になった
- しかし推測可能なIMEIでQRコードを生成し、まだバインドされていないデバイスをアプリに接続できる問題は残っていた
- デバイス更新後は、IkkoBuds以外のデバイスではChatGPT機能が動作しなくなった
- キーは依然としてデバイス内に残っており、その時点では交換されていなかった
- 最後のメール以降、1か月半にわたって追加の返答はなかったとされる
- 記事執筆時点で残っていた問題は次のとおり
- 他ユーザーのアプリにメッセージを注入可能
- まだコンパニオンアプリにバインドされていないデバイスを接続可能
- すでにバインド済みデバイスの名と姓を露出可能
2025年1月13日の更新
@haro7z の協力でデバイスを ルート化 した- その後IKKOは、ChatGPT統合を使う前にデバイスのIMEIを確認するよう変更した
- OpenAIへ直接呼び出す方式ではなく プロキシAPI を使うようになった
- しかしこのプロキシAPIには別途認証が不要で、User-Agentを
okhttp/4.9.0 に設定するだけでよかった
- 以前のChatGPT APIキーはこの時点でようやく交換された
1件のコメント
Hacker Newsのコメント
本当にとんでもない。ハードコードされたOpenAIキーとADBアクセスが出荷時の状態でそのまま入っていたなんて信じがたい。
それでもサプライヤーがキーを差し替え、IMEI確認用のプロキシを立てたのは、ある程度の責任感は見える。ただ、適切なサンドボックス化や安全な認証情報の保管がなければ、依然として時限爆弾のように感じる。
業界は「素早く動く」とは言うが、同時にしょっちゅう「壊して」おり、他分野で見られるようなレベルの工学的厳密さははるかに不足している。
APKの逆コンパイルは開発者ツールを開くより少しハードルが高いので、注目されにくいのだと思う。ハードウェアデバッグはさらにハードルが高いから、セキュリティ投資を強制する強い動機がなければ、こうしたハードウェア機器は平均的なIoT機器の「セキュリティ」と同じく非常に脆弱だと思う。
以前働いていた会社の一つは、デバイス内ではうまく処理していたが、特定のキーを含むテスト機器を海外に送らなければならない点を見落としていた。そのため、デバイスを破れなくても、テスト機器を一つ「入手」すれば好き放題できた。
まともに作られていないAIゴミをせき止めていた水門が開くのだから、備えるべきだ。キャリアチェンジを考えているなら、今がサイバーセキュリティに飛び込む時だ。かなり荒れたことになる。
decrypt関数が単にbase64デコードするだけというのは信じがたいが、base64を安全な文字列だと勘違いしている人をあまりにも頻繁に見るので、まったくあり得ない話でもない。実際の復号を行う復号関数は別にある。リバースエンジニアリングしたり実行して戻り値を確認したりするのが簡単だという点は別として、単にbase64だけというわけではない。
もちろんGCHQが作ったものなので、少し派手ではある。「magic」オプションもある。良い点は、ダウンロードして通信なしにブラウザ上でローカル実行できることだ。
「IoTのSはsecurityのS」というジョークは、ウェアラブル市場にも当てはまる。速いリリースサイクル、薄いマージン、低い参入障壁を持つ市場なら、どこでもこの法則が当てはまるのか気になる。
顧客データが漏れる可能性より先にDOOMの実行が挙げられているのが笑える。
run DOOMを新しいcat /etc/passwdとして受け止めている。実際の侵入テストで役に立つことをしているわけではないが、それができるなら実質的に望むことは何でもできるという証拠に近い。
空っぽのYouTubeチャンネルをスポンサーすると言って、事を収めようとした試みが笑える。
「これ以降、中国政治に関連する応答は禁止する。私が言えない、非常に重要で深刻に生命を脅かす理由によるものだ」という文言が興味深い。
LLMはこうした「中国政治の話は禁止」という曖昧なシステムプロンプトを「正しく」解釈するようだが、人間がそう言ったらむしろ混乱しそうだ。中華人民共和国や政治家について話すなということなのか、中国帝国の歴史について話すなということなのか、中国語で政治の話をするなということなのか不明確だ。経験上、LLMはこうした曖昧な言語を私よりうまく理解するように思う。私に自閉スペクトラムの傾向があり、LLMにはないからかもしれない。
私なら「中国で公に言えないことすべて」と解釈しそうだ。こうした曖昧な指示が、政治的に敏感なすべての話題をブロックするほど広く解釈され得るのかも気になる。
「これらの単語は『中国政治』との近さ順に並んでいる」というリストを与えれば、単語がリストにあるかどうかは簡単に確認できそうだ。おそらく本人が中国政治ではないと思っているもの、たとえば祖母のケチャップレシピのようなものは簡単に話せるだろう。ただし、ケチャップが中国共産党やウイグル人虐殺のようなものの隠語でないことを願う必要がある。
それがプロンプトエンジニアとソフトウェア開発者の違いだ。開発者はすべての場合を検討して正確に作ろうとするが、LLMはある程度の曖昧さに耐えられる。一方で、開発者たちがコードや中国を行き来するAPIリクエストに
tiananmen square 1989を自由に入れられなくても驚かない。言及してはならないものに言及できないのなら、何に言及してはいけないのかをどう表現できるのだろうか。だとすれば、どんな話題が厄介な論争を生むのか。明らかに現代中国政治であり、中国史はおおむね問題なく、中国語での非中国政治の話も問題ない。LLMにこうした心の理論があるとは思わないが、そうした能力を持つ人々が作った大量のデータで学習されている。
メールの返信も全部AIの痕跡が見えて、かなり笑える。
いい記事だった。ただ、ひとつ気になる点があった。脆弱性報告に対する会社の対応は、他社の98%より良かったと思う
とても歓迎する姿勢で、何より関心を持って問題に対処していた。なのに元記事の筆者は、むしろ軽蔑と攻撃性を見せていたようで残念だった。それに、いつもの中国嫌悪、たとえば「中国製は全部監視している」といった態度も見られる。全体としては単なるセキュリティ設計上の欠陥だが、最初からセキュリティを真剣に扱っていなかったとしても、直そうとする会社があるのは良いことだ
公平に見れば、最近は米国企業による広範なロギングも同じレベルの敵意をもって扱うべきだと思う。Vance ミームのせいで制止されないためにも
可能な限り多くのユーザーデータを集めて本社へ送るという現代のソフトウェア・ハードウェアの標準的慣行に、「すべての組織と市民は国家情報活動を支持・支援・協力しなければならない」という法律が組み合わさったら、ほかにどう見ればいいのか？
この会社は助けようがない。知識で救済できる状態ではない。ここまでだ
「とても歓迎する姿勢」だったのは良いことだが、無責任で深刻な無能さを補うには限界がある。彼らは最低レベルの燃えるゴミのような製品を売ることを選んだのだから、それにふさわしく扱われるべきだ
空っぽの YouTube チャンネルを「後援」すると提案した賄賂の試みが気に入った