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

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

概要

  • 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は特定のプロンプトに対してどれくらいの単語を返すかを認識するのが難しいみたい。だから、実際にはうまくいかないと思う。

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

Hacker Newsで議論の続きを見る