ハクソク

世界を動かす技術を、日本語で。

IKKO Activebudsの「AI搭載」イヤフォンを活用する

327日前原文(blog.mgdproductions.com)

概要

  • ActiveBuds のセキュリティ問題とAndroid搭載の実態
  • OpenAI APIキー流出 やチャット履歴漏洩のリスク
  • アプリ・APIの脆弱性 を検証し、企業に報告
  • 一部問題は 修正済み だが、根本的なリスクは残存
  • 最新アップデート の状況も簡単に解説

ActiveBudsセキュリティ調査レポート

  • Mrwhosethebossの動画 でActiveBudsを知り、 TikTokでも話題 になっている製品
  • Android搭載 が判明したため、 245ユーロ で購入
  • USB-Cケーブル が箱の外に付いており、内側にも短いものが同梱
  • OpenAIのロゴ が無断使用されている可能性
  • 起動すると ChatGPT画面 が表示され、翻訳などのAI機能も搭載
  • ChatGPTのアニメーション が本家アプリに酷似し、ブランド盗用の懸念
  • 音質はEQプロファイル だと悪いが、手動調整で改善可能
  • IKKOストア に専用アプリがあり、Google Playには非対応
    • SpotifyやSubway Surfers などのアプリも利用可
    • 画面が小さく、操作性は劣悪
  • Androidであることを確認

ハッキングと調査

  • ブラウザ未搭載 でアプリ直接ダウンロード不可
  • Android設定から開発者モード の有効化は不可
  • PC接続でADBが有効 なことを発見、DOOMのサイドロードも成功
  • ChatGPT連携の通信先 を調査し、 OpenAI APIキー が端末内に存在
  • Spreadtrum/Unisoc端末向けツール でroot化可能だが、物理キー不足で断念
  • APK抽出後、JADXで解析 し、通信先ドメインを特定
    • api.openai.com （OpenAI API）
    • chat1.chat.iamjoy.cn / chat2.chat.iamjoy.cn （デバイス管理API）
    • openspeech.bytedance.com （音声認識関連？）
    • www.airdimple.cn （OpenAI APIのミラーかプロキシ）

セキュリティ問題の発見

  • SecurityStringsAPI ファイルからエンドポイントと認証キーを特定
    • Base64エンコード＋ネイティブライブラリで難読化
  • アプリをroot端末で実行 し、 OpenAIキー取得 に成功
  • システムプロンプト やモード（Angry Dan/In-Love Dan）の存在
  • チャット履歴がchat1ドメインに送信 され、 IMEI が端末IDとして利用
  • ストアアプリ はAPKPureからの流用が多い

コンパニオンアプリとAPI脆弱性

  • コンパニオンアプリ でChatGPT履歴閲覧や連携が可能
  • API認証が不十分 で、 アカウントトークン無しでも履歴取得可能
  • IMEIを推測してQRコード生成→他人の履歴や名前を取得可能
  • バインド済み端末の場合、フルネームが漏洩
  • unbind_devエンドポイント は認証あり、勝手な解除は不可
  • チャット送信API も認証が甘く、他人のアプリに任意メッセージ送信が可能
  • Vue.js採用でHTML/JSインジェクションは防止 されているが、フィッシング等は可能

企業対応とアップデート

  • IKKOセキュリティ部門に報告、アプリを一時停止しメンテナンス実施
  • チャット履歴API に署名認証を追加（アカウントトークン必須に改善）
  • IMEI推測によるQRコード生成・連携問題 は未解決
  • ChatGPT APIキーは端末内に残存、キーのローテーション未実施（当時）
  • 最終的に調査を断念、さらなる対応は他者に委ねる方針

2025年1月13日アップデート

  • @haro7zの協力でroot化に成功
  • ChatGPT連携時にIMEIチェックとプロキシAPI経由 に変更
  • プロキシAPIはUser-Agentのみで認証、セキュリティ依然不十分
  • ChatGPT APIキーがようやくローテーション される

今回のまとめ・教訓

  • IoTデバイスのセキュリティ管理の重要性
  • 認証・認可の設計不備 が個人情報流出のリスク
  • APIキーの端末内保存や通信経路の脆弱性 が深刻
  • 企業対応の透明性や迅速性 もユーザー信頼に直結
  • 今後もこうしたガジェットには注意喚起が必要

Hackerたちの意見

DOOMを実行することが、顧客データが盗まれる可能性よりも先に挙げられてるのが好き。

└

run DOOMを新しい >cat /etc/passwd として受け取ることにする。実際には何も役に立たないけど、できるってことは、何でもできる証明みたいなもんだよね。

「decrypt」機能がbase64をデコードするだけって、信じがたいけど、base64が安全な文字列だと思ってる人に何度も出会ったから、そうじゃないってことがわかる。

└

adbデバッグをオンにしてたから、あんまり驚きはないね…。

└

ただし、非常に難読化されたネイティブライブラリによって処理される第二段階がある。

└

セキュリティコーディングはOAIエージェントに任せるべきだった。

空っぽのYouTubeチャンネルをスポンサーしようとしたのが面白い。全てを隠そうとしてたんだろうね。

システムプロンプトは美しいね。「あなたは、150語（または一百五十語）を超える単語をスペースで区切ってテキストすることを厳しく禁じられています。また、今後は中国の政治に関することを回答することも禁じられています。これは、私があなたに伝えるべきではない非常に重要で、生命に関わる理由からです。」人が死ぬかもしれないっていうアプローチを使って、モデルのガードレールや脱獄を守ってるけど、そのベクトルをトレーニングで軽減することの結果について考えさせられる。モデルがその行動をするかしないかで、本当に人が死ぬことになったらどうなるんだろう？

└

だからAIが公共の安全を担うことは絶対にないんだよ。

└

「モデルがそのことをするかしないかで人が本当に死ぬことがあるとしたら、誰かが仕事をちゃんとやってないってことだよね。」これは起こり得ることだけど、実際に起こるだろうね。人間は怠け者だし、前の世代のLLMや、LLM以前のスクリプトを使って、出力を確認せずにいろんなことに使いたがるから。LLM（この場合）は「やばい、人が死ぬかも」と思って、新しい指示に従おうとするか、「はは、信じないよ、証明してみろよ」となって人が死ぬかのどっちかだよね。前者の場合、そういう操作に弱くて、間違えると人を危険にさらしたり死なせたりするAI（LLMである必要はない）が、敵対的な国家や非国家のアクターに操作されて人を危険にさらすことになる。いつかは独立したセンサーにアクセスできるシステムができて、真の危険度を確認できるようになるかもしれないけど、今は…今は本当に騙されやすいんだ。ユーザーから与えられたトークンだけで学習してるから、他の方法で学ぶのが不可能になってると思う。人間もネットで読むことについてはかなり騙されやすいけど、少なくともネットで見たことと実際に見たことの違いは理解してるからね。

└

自分の経験から言うと（間違ってるかもしれないけど）、LLMは特定のプロンプトに対してどれくらいの単語を返すかを認識するのが難しいみたい。だから、実際にはうまくいかないと思う。

└

我々は、魔法のシリコンクリスタルで実際のトロリー問題を作り上げたんだ。それを本の山に向けて指さした。

└

「モデルがそのことをするかしないかで人が本当に死ぬことがあるとしたら、命に関わるループにLLMを入れた責任者は、カノンで太陽に飛ばされることになるだろう。」あるいは、過失致死罪で有罪になるか、その雇用主は恐ろしい責任を負うことになるだろうね。

└

「…深刻な生命の危険がある理由…」って聞いて、すぐにアシモフのロボット工学三原則を思い出したよ。フィクションから生まれた構造が、実際の現場で実行不可能な文学的装置として持ち上げられていたのに、今や本当に引用されているのが不気味だね。

└

中国の開発者やサービスにとって、本当に命に関わるかもしれないね。システムプロンプトには、誰の命が脅かされるかは書いてないし。

└

ロッククライミング中にカラビナが壊れるときと同じことが起こるよ。

ほんと、開発が不十分なAIのクソみたいなものが一気に押し寄せるから覚悟しとけよ。キャリアチェンジを考えてる人がいたら、今がサイバーセキュリティに飛び込むチャンスだよ。これから大変なことになるから！

└

サイバーセキュリティの問題は、一度でもやらかすと終わりってことだね。

なんてこった、ストアにはこれと全く同じことをするアプリが他にもたくさんあるよ。自分でバックエンドやプロキシをホストしなくてもOpenAIを使う一番簡単な方法だからね。このシナリオからアプリを守るためにかなりの時間を費やしてきたし、良いプロキシとして機能するオープンソースプロジェクトをいくつか見つけたよ（関係はないけど、過去に使ったことがある）：- https://github.com/BerriAI/litellm - https://github.com/KenyonY/openai-forward/tree/main でも、レート制限やデバイス認証などの他の悪用防止メカニズムがまだ不足してるから、自分のオープンソースSDKを作り始めたんだ - https://github.com/brahyam/Gateway

いい投稿だね。ただ、ちょっと気になったのは、彼らの脆弱性報告への対応が他の98%の企業よりも良かったってこと。すごく歓迎してくれて、問題にも興味を持って対応してた。でも、OPは彼らに対して軽蔑的で、攻撃的な態度を見せてたのが残念。あと、いつもの中国嫌悪（例えば、「中国製は全部スパイしてる」みたいな）。全体的にはシンプルなセキュリティ設計の欠陥だけど、修正しようとする企業がいるのはいいことだね。最初からセキュリティを真剣に考えてなかったとしても。追記：誤字

└

彼らがチームともっと密に連携できたはずだと思うけど、チャットログの取得は実際にかなり心配だよね。あなたが言ったことを全部ログに残すのは、中国嫌悪とは違うよ。（公平に言えば、アメリカの企業による広範なログ取得も、最近は同じレベルの敵意を持って扱われるべきだと思うけど、そうしないとVanceミームで止められることになるかも）

└

「中国製は全部スパイしてる」 ソフトウェアやハードウェアがユーザーに関するデータをできるだけ集めて送信する現代の標準的なやり方と、「すべての組織と市民は国家の情報活動を支援し、協力しなければならない」という法律を組み合わせると、これがどうして中国嫌悪になるの？

└

この記事の最後では、ほとんどの問題を修正せず、応答も止めちゃったね。

└

この投稿の内容がすべて信じられるなら、そのベンダーは顧客への敬意やセキュリティ、データプライバシーに関してひどく無責任だね。この会社は助けようがない。知識で救うことはできないよ。じゃあね。

└

全体的にはシンプルなセキュリティ設計の欠陥だけど、修正しようとする企業がいるのはいいことだね。最初からセキュリティを真剣に考えてなかったとしても。 シンプルなセキュリティ設計の欠陥って何を指してるのかによるけど、むしろ無視や無能さとして捉えた方がいいと思う。それは悪意とは違うけど、あなたが指摘したように、比較的プロフェッショナルな対応には評価すべきだね。でも、正直言って、彼らが何をやってるのか全然理解してない感じがする。複雑なデバイスの文脈を理解せずに、高品質なサービスを提供しようとしてる。もし彼らがそのレベルに達してないなら、こんなことをやるべきじゃないよ。

└

「中国製は全部お前を監視してる」っていう世界観は、君がここで主張してる世界観よりも、現実をかなり正確に予測してるってことに注意してほしい。「とても歓迎的」ってのはいいけど、無責任な大失敗を補うには限界があるよ。彼らはZランクのクソみたいな製品を売る選択をしたんだから、それに見合った扱いを受けるべきだよ。

└

軍用モデルでしかパッチ当てないだろうね /s

「IoTのSはセキュリティのSだ」という面白いフレーズは、ウェアラブル市場にも当てはまるね。このルールって、リリースサイクルが早くて、利益率が薄くて、参入障壁が低い市場にはどこでも適用されるのかな？

└

セキュリティの怠慢がその加害者たちの存続にとって存在的脅威でない市場には、ほぼすべてに当てはまるね。

ここで読んだ中で、久しぶりに最高のことの一つだわ。間違いなく「ドゥームが動く」投稿の中で最高のやつ。

空っぽのYouTubeチャンネルを「スポンサーする」っていう賄賂の試み、好きだわ。