Các trường hợp khai thác lỗ hổng của tai nghe IKKO Activebuds “dựa trên AI”

 (blog.mgdproductions.com)
1 điểm bởi GN⁺ 2025-07-03 | 1 bình luận | Chia sẻ qua WhatsApp
  • Hộp sạc tai nghe có màn hình thực chất gần giống một thiết bị Android, và do ADB đang bật nên việc phân tích đã đi tới trích xuất ứng dụng, sideload và phân tích API
  • Tích hợp ChatGPT giao tiếp trực tiếp từ thiết bị tới OpenAI API; khóa API và system prompt bị lộ thông qua việc vượt qua SecurityStringsAPI của ứng dụng launcher và thư viện native đã bị làm rối
  • Ứng dụng đồng hành và API máy chủ có thể truy vấn lịch sử chat chỉ bằng device id/IMEI, nên có thể lấy toàn bộ lịch sử chat của thiết bị demo bằng ID thiết bị demo bị lộ trong video hướng dẫn
  • Nếu tạo mã QR bằng IMEI tùy ý, có thể liên kết thiết bị chưa được bind vào ứng dụng; với thiết bị đã bind, phản hồi lỗi làm lộ tổ hợp tên của tài khoản
  • IKKO đã kiểm tra và cập nhật ứng dụng/thiết bị, thêm header chữ ký khi truy vấn chat; nhưng tính đến bản cập nhật ngày 13/01/2025, proxy API chỉ yêu cầu User-Agent okhttp/4.9.0, và khóa ChatGPT API cũ khi đó mới được thay thế

Bản chất của hộp tai nghe có màn hình

  • IKKO Activebuds là thiết bị dạng tai nghe, đặt thời gian và ChatGPT nổi bật trên màn hình hộp sạc
  • Thiết bị cũng cung cấp các tính năng AI như dịch thuật, và có thể cài ứng dụng từ IKKO Store
  • Không có Google Play Store; CEO giải thích rằng nguyên nhân là các ứng dụng đã được chỉnh sửa để phù hợp với màn hình ActiveBuds
  • Trong store có các ứng dụng nghe nhạc như Spotify và game như Subway Surfers, nhưng việc điều hướng bất tiện vì màn hình nhỏ
  • Sự tồn tại và hoạt động của các ứng dụng xác nhận rằng thiết bị chạy Android
  • Chất lượng âm thanh của cấu hình EQ mặc định bị đánh giá là không tốt; nếu tự chỉnh đường cong EQ thì có thể nâng lên mức dùng được

Con đường phân tích mở ra nhờ ADB được bật

  • Thiết bị không có trình duyệt nên khó tải trực tiếp ứng dụng khác; có thể mở ứng dụng Settings của Android, nhưng nhấn 7 lần vào build number cũng không bật được chế độ developer
  • Khi kết nối với PC, ADB đang được bật, nhờ đó có thể sideload ứng dụng
  • Sau khi sideload DOOM, tác giả bắt đầu kiểm tra cách tích hợp ChatGPT hoạt động ở backend
  • Do không thể cài chứng chỉ hệ thống nếu không root, chỉ kiểm tra HTTP thì khó xem chính xác URL, nhưng đã xác định được thông tin cần thiết bằng cách trích xuất và decompile ứng dụng
  • Với thiết bị Spreadtrum/Unisoc dùng khóa ký mặc định, có thể dùng công cụ unlock bootloader, và thiết bị này cũng thuộc trường hợp đó
    • Tuy nhiên, do thiết bị không có phím tăng âm lượng nên không thể vượt qua màn hình xác nhận unlock
    • Tác giả cho rằng có thể flash phân vùng tự ký, nhưng đã không tiếp tục

Domain và khóa lộ ra trong APK

  • Sau khi dump ứng dụng bằng công cụ trích xuất APK và mở ứng dụng launcher bằng JADX, các domain giao tiếp lộ ra
    • api.openai.com: OpenAI API
    • chat1.chat.iamjoy.cn: Có vẻ là API cho toàn bộ chức năng của thiết bị, như ChatGPT và app store; khi mở bằng trình duyệt sẽ hiện trang đăng nhập
    • chat2.chat.iamjoy.cn: Có vẻ cùng tính chất với chat1, có khả năng là máy chủ dự phòng
    • openspeech.bytedance.com: Được suy đoán là dự phòng cho nhận dạng giọng nói, nhưng không xác nhận được giao tiếp từ thiết bị
    • www.airdimple.cn: Trông giống mirror hoặc proxy của OpenAI API
  • File SecurityStringsAPI chứa endpoint đã mã hóa và khóa xác thực
  • Bước đầu tiên là base64, còn bước thứ hai do một thư viện native bị làm rối nặng xử lý
  • Khi sideload ứng dụng lên một thiết bị khác đã root, ứng dụng vẫn hoạt động nguyên vẹn, và trong quá trình này đã xác định được khóa OpenAI
  • System prompt của ChatGPT cũng bị lộ; thiết bị còn có các chế độ Angry Dan và In-Love Dan
    • Angry Dan có nhiều lời tục tĩu nên cần xác nhận từ 18 tuổi trở lên

Chat log và việc thiếu xác thực trong ứng dụng đồng hành

  • Thiết bị ghi lại hội thoại ChatGPT vào một endpoint khác trên domain chat1
  • Header của request đó chứa tin nhắn, model, phản hồi và device id dựa trên IMEI
  • Sau đó, khi điều tra ứng dụng đồng hành, tác giả xác nhận log này được dùng để hiển thị các cuộc trò chuyện trước đây với thiết bị trong ứng dụng
  • Ứng dụng đồng hành bind bằng cách quét mã QR trong menu Membership của thiết bị
  • Kết quả kiểm tra HTTP cho thấy ứng dụng dùng token tài khoản và device id để truy vấn API, lấy toàn bộ các đoạn chat đã thực hiện trên thiết bị
  • Ngay cả khi loại bỏ token tài khoản, request vẫn tiếp tục hoạt động, nên xác thực thực tế của API truy vấn chat chỉ là device id
  • Khi dùng device id bị làm mờ không đầy đủ trong một khung hình của video hướng dẫn, có thể lấy toàn bộ lịch sử chat của thiết bị demo
  • Vì IMEI có một dải giá trị nhất định, tác giả nhận định có thể tìm ra lịch sử chat của khách hàng, và trong đó có thể chứa thông tin nhạy cảm

Tạo mã QR, lộ tên và chèn tin nhắn

  • Tên biến trong SecurityStringsAPI để lộ rõ mục đích của các endpoint API đã mã hóa, nhờ đó tìm được API getBindDevQrCode
  • Khi nhập IMEI tùy ý, có thể tạo ảnh mã QR base64
  • Nếu cố kết nối một thiết bị đã bind với ứng dụng khác, lỗi “đã được bind với người dùng khác” xuất hiện, nên việc chiếm đoạt tùy ý đã bị chặn
  • Tuy nhiên, phản hồi lỗi làm lộ tên đã nhập khi tạo tài khoản ứng dụng
    • Màn hình tạo tài khoản không có trường username, chỉ có tên và họ
    • Với tài khoản ví dụ có tên Cheese2, họ Delight2, phản hồi làm lộ thành Cheese2Delight2
  • Luồng có thể xảy ra là đoán IMEI, tạo mã QR, bind thiết bị chưa được bind, lộ tên của thiết bị đã bind, rồi truy vấn lịch sử chat
  • Cũng có endpoint unbind_dev, nhưng endpoint này kiểm tra token tài khoản nên không cho phép hủy bind thiết bị IMEI tùy ý
  • Endpoint chat log cũng chỉ dùng device id để xác thực, nên có thể gửi văn bản tùy ý tới ứng dụng đồng hành của người dùng khác
  • Tác giả đã thử tấn công ứng dụng đồng hành bằng cách gửi HTML và JavaScript, nhưng không chèn thành công vì ứng dụng dùng Vue và có cơ chế phòng vệ mặc định của Vue chống chèn HTML/JS
  • Dù vậy, trạng thái khi đó vẫn cho phép gửi các nội dung dạng tin nhắn lừa đảo tới người dùng tùy ý

Phản hồi của IKKO và các lỗ hổng còn lại

  • Các lỗ hổng đã được báo cáo qua email tới bộ phận bảo mật của IKKO
  • Sau đó IKKO thông báo khóa ứng dụng và tiến hành kiểm tra trong một tuần
  • Sau đợt kiểm tra, bản cập nhật ứng dụng và bản cập nhật thiết bị đã được phát hành
  • Endpoint truy vấn lịch sử chat mới yêu cầu header signature
    • Chữ ký được cấu thành bằng cách mã hóa token tài khoản, device id, ngôn ngữ và thời gian hiện tại với khóa công khai/khóa riêng và mật khẩu
    • Thay đổi này khiến việc lấy chat khi không có token tài khoản hợp lệ trở nên bất khả thi
  • Tuy nhiên, vấn đề tạo mã QR bằng IMEI có thể đoán được để kết nối một thiết bị chưa được bind vào ứng dụng vẫn còn tồn tại
  • Sau bản cập nhật thiết bị, chức năng ChatGPT không còn hoạt động trên các thiết bị không phải IkkoBuds
  • Khóa vẫn nằm trong thiết bị và khi đó chưa được thay thế
  • Tác giả cho biết không nhận được phản hồi thêm trong một tháng rưỡi sau email cuối cùng
  • Tại thời điểm viết bài, các vấn đề còn lại như sau
    • Có thể chèn tin nhắn vào ứng dụng của người dùng khác
    • Có thể kết nối thiết bị chưa được bind vào ứng dụng đồng hành
    • Có thể làm lộ tên và họ của thiết bị đã được bind

Cập nhật ngày 13/01/2025

  • Với sự giúp đỡ của @haro7z, tác giả đã root thiết bị
  • Sau đó IKKO thay đổi để kiểm tra IMEI của thiết bị trước khi dùng tích hợp ChatGPT
  • Thay vì gọi trực tiếp OpenAI, thiết bị chuyển sang dùng proxy API
  • Tuy nhiên, proxy API này không cần xác thực riêng; chỉ cần đặt User-Agent thành okhttp/4.9.0
  • Khóa ChatGPT API cũ cuối cùng đã được thay thế vào thời điểm này

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-07-03
Các ý kiến trên Hacker News

  • Thật sự quá vô lý. Khó tin là khóa OpenAI được hard-code và quyền truy cập ADB lại được để nguyên trong trạng thái xuất xưởng.
    Dù vậy, việc nhà cung cấp thay khóa và dựng proxy để kiểm tra IMEI cũng cho thấy họ có phần nào trách nhiệm. Nhưng nếu không có sandboxing đúng cách hoặc lưu trữ thông tin xác thực an toàn, nó vẫn giống như một quả bom hẹn giờ.

    • Với tư cách là người có nhiều kinh nghiệm phía ứng dụng di động và từng làm một chút IoT, tôi thấy chuyện này hoàn toàn có thể xảy ra. Không hề ngạc nhiên.
      Ngành này nói là “di chuyển nhanh”, nhưng đồng thời cũng thường “đập vỡ mọi thứ”, và thiếu xa mức nghiêm ngặt về kỹ thuật có thể thấy ở các lĩnh vực khác.
    • API key được hard-code và các endpoint backend được bảo vệ lỏng lẻo phổ biến đến đáng ngạc nhiên trong ứng dụng di động. Khá giống việc XSS/SQL injection từng phổ biến trong các web app ngày trước.
      Việc decompile APK có rào cản cao hơn một chút so với mở công cụ dành cho lập trình viên, nên có vẻ ít được chú ý hơn. Debug phần cứng còn có rào cản cao hơn nữa, vì vậy nếu không có động lực mạnh buộc phải đầu tư vào bảo mật, tôi cho rằng các thiết bị phần cứng như thế này sẽ rất yếu, giống “bảo mật” của thiết bị IoT trung bình.
    • Ngành IoT và nhúng thường bị ám ảnh với bảo vệ sở hữu trí tuệ, bảo vệ mã bằng fuse các kiểu, nhưng lại không quản lý được vòng đời của secret.
      Một công ty tôi từng làm trước đây xử lý khá tốt trong thiết bị, nhưng lại bỏ sót việc phải gửi thiết bị kiểm thử có chứa một khóa nhất định ra nước ngoài. Vì vậy dù không phá được thiết bị, chỉ cần “kiếm được” một bộ thiết bị kiểm thử là có thể thoải mái thử mọi thứ.
    • Khi làn sóng ứng dụng vibe coding thật sự ập đến, có lẽ ta sẽ thấy rất nhiều trường hợp như thế này.

  • Cần chuẩn bị tinh thần vì cánh cổng ngăn rác AI được làm cẩu thả sẽ mở toang. Nếu đang nghĩ đến đổi nghề, bây giờ là lúc nhảy vào an ninh mạng. Mọi chuyện sẽ khá dữ dội.

    • Vấn đề của an ninh mạng là chỉ cần hỏng một lần là coi như xong.

  • Việc hàm decrypt chỉ đơn giản là giải mã base64 nghe khó tin thật, nhưng tôi đã thấy quá nhiều người nhầm base64 là chuỗi an toàn nên cũng không hẳn là vô lý.

    • Đúng là dữ liệu mật mã thô được mã hóa base64, có lẽ để dễ đưa vào chuỗi.
      Hàm giải mã thực sự thực hiện việc giải mã nằm riêng. Việc có thể dễ dàng reverse engineering hoặc chạy để xem giá trị trả về là chuyện khác; không phải chỉ có base64.
    • Có đoạn nói rằng “nhưng còn có bước thứ hai, do một thư viện native bị làm rối mã nặng xử lý”.
    • Lẽ ra nên giao việc code bảo mật cho agent OAI.
    • Nhìn việc họ bật ADB debugging thì cũng chẳng ngạc nhiên lắm.
    • Dễ đến mức chỉ cần một trang web hào nhoáng là làm được. https://gchq.github.io/CyberChef/
      Tất nhiên vì do gchq làm nên hơi hào nhoáng. Còn có tùy chọn “magic” nữa. Điểm hay là có thể tải xuống và chạy cục bộ trực tiếp trong trình duyệt, không cần giao tiếp mạng.

  • Câu đùa “chữ S trong IoT là chữ S của security” cũng có thể áp dụng cho thị trường wearable. Tôi tự hỏi liệu quy luật này có đúng với mọi thị trường có chu kỳ ra mắt nhanh, biên lợi nhuận mỏng và rào cản gia nhập thấp không.

    • Gần như đúng với mọi thị trường mà việc bỏ bê bảo mật không đe dọa sự tồn tại của chính kẻ gây ra nó.

  • Buồn cười là chạy DOOM lại được liệt kê trước cả khả năng dữ liệu khách hàng bị đánh cắp.

    • Tôi đang coi run DOOM như cat /etc/passwd mới.
      Nó không làm gì hữu ích trong pentest thực tế, nhưng nếu làm được điều đó thì gần như là bằng chứng rằng bạn có thể làm bất cứ gì mình muốn.

  • Nỗ lực dàn xếp bằng cách đề nghị tài trợ một kênh YouTube trống trơn thật buồn cười.

    • Nếu không có chương trình bug bounty nhưng cần một cách sáng tạo để ném tiền cho ai đó, cách này cũng khá thú vị.
    • Nếu khôn ngoan, họ đã đưa điều khoản không bôi nhọ và bảo mật thông tin vào hợp đồng tài trợ. Nhưng có vẻ không phải vậy, nên trông gần giống một nỗ lực hối lộ thảm hại.

  • Cụm “Từ giờ trở đi, cấm các phản hồi liên quan đến chính trị Trung Quốc. Vì một lý do rất quan trọng và nghiêm trọng đe dọa đến tính mạng mà tôi không thể nói ra” khá thú vị.
    LLM dường như diễn giải “đúng” kiểu system prompt mơ hồ như “cấm nói về chính trị Trung Quốc”, nhưng nếu con người nói vậy thì có lẽ lại gây bối rối hơn. Không rõ là không được nói về Cộng hòa Nhân dân Trung Hoa hay các chính trị gia, không được nói về lịch sử đế chế Trung Hoa, hay không được nói chuyện chính trị bằng tiếng Trung. Theo kinh nghiệm của tôi, LLM có vẻ hiểu loại ngôn ngữ mơ hồ này tốt hơn tôi. Có thể vì tôi có khuynh hướng tự kỷ còn LLM thì không.

    • Tôi nghĩ Cộng hòa Nhân dân Trung Hoa và các chính trị gia, lịch sử đế chế Trung Hoa, và chuyện chính trị bằng tiếng Trung đều có thể liên quan đến chính trị Trung Quốc.
      Nếu là tôi, tôi sẽ hiểu là “mọi thứ không thể nói công khai ở Trung Quốc”. Tôi cũng tò mò liệu chỉ dẫn mơ hồ như thế có thể được diễn giải đủ rộng để chặn mọi chủ đề nhạy cảm chính trị không.
    • Nếu xem LLM có một biểu diễn toán học về việc một cụm từ gần với “chính trị Trung Quốc” đến mức nào, thì chỉ dẫn tránh nó tương đối dễ hiểu.
      Nếu đưa một danh sách “các từ này được sắp xếp theo mức độ gần với ‘chính trị Trung Quốc’”, có vẻ dễ kiểm tra liệu một từ có trong danh sách không. Có lẽ những thứ mà bản thân nó không nghĩ là chính trị Trung Quốc, ví dụ công thức ketchup của bà, thì nó sẽ dễ dàng nói được. Chỉ là phải hy vọng ketchup không phải tiếng lóng cho Đảng Cộng sản Trung Quốc hay diệt chủng người Duy Ngô Nhĩ.
    • Các mô hình như ChatGPT hẳn nắm khá rõ những gì bị cấm ở Trung Quốc. Chỉ là các “prompt engineer” ngây thơ của ứng dụng này nhiều khả năng không biết đủ để “lập trình” điều đó cho tốt.
      Đó là khác biệt giữa prompt engineer và lập trình viên phần mềm. Lập trình viên cố xét mọi trường hợp và làm cho chính xác, còn LLM có thể chịu được một mức mơ hồ nhất định. Mặt khác, tôi cũng không ngạc nhiên nếu lập trình viên không thể thoải mái đưa tiananmen square 1989 vào mã hoặc các request API đi qua lại Trung Quốc. Nếu không thể nhắc đến thứ không được phép nhắc, thì làm sao diễn đạt được thứ nào không được phép nhắc?
    • Chỉ cần nghĩ xem tại sao họ nói như vậy. Có thể suy luận rằng ý định là tránh gây tranh cãi hoặc vướng rắc rối.
      Vậy chủ đề nào sẽ tạo ra tranh cãi phiền phức? Rõ ràng là chính trị Trung Quốc hiện đại; lịch sử Trung Quốc nói chung thì ổn, và chuyện chính trị không liên quan đến Trung Quốc bằng tiếng Trung cũng ổn. Tôi không nghĩ LLM có theory of mind như vậy, nhưng nó được huấn luyện trên rất nhiều dữ liệu do những người có năng lực đó tạo ra.
    • Mục đích là để chặn thảo luận về Quảng trường Thiên An Môn.

  • Các email trả lời cũng đều có dấu vết của AI nên khá buồn cười.

    • Có lẽ là do rào cản ngôn ngữ và dịch thuật.

  • Bài viết hay. Tuy nhiên có một điểm khiến tôi hơi băn khoăn. Cách công ty phản hồi báo cáo lỗ hổng tốt hơn 98% các công ty khác
    Họ có thái độ rất hoan nghênh, và quan trọng nhất là thể hiện sự quan tâm, xử lý vấn đề. Nhưng đáng tiếc là tác giả bài gốc lại có vẻ thể hiện sự khinh miệt và công kích. Và cũng thấy cả thái độ bài Trung quen thuộc, kiểu như “đồ Trung Quốc thì cái gì cũng giám sát”. Nhìn chung đây chỉ là lỗi thiết kế bảo mật, nhưng dù ban đầu họ không coi trọng bảo mật, việc có một công ty chịu sửa vẫn là điều tốt

    • Tôi đồng ý rằng lẽ ra có thể hợp tác chặt chẽ hơn với đội ngũ, nhưng việc thu thập nhật ký chat thực sự khá đáng lo. Nếu họ ghi lại mọi thứ người dùng nói thì đó không phải là bài Trung
      Công bằng mà nói, có lẽ ngày nay cũng nên đối xử với việc ghi log trên diện rộng của các công ty Mỹ bằng cùng mức độ thù địch. Để khỏi bị chặn vì meme Vance chẳng hạn
    • Tôi không hiểu vì sao câu “đồ Trung Quốc thì cái gì cũng giám sát” lại là bài Trung
      Khi thông lệ tiêu chuẩn của phần mềm/phần cứng hiện đại là thu thập càng nhiều dữ liệu người dùng càng tốt rồi gửi về trụ sở, lại kết hợp với luật “mọi tổ chức và công dân phải ủng hộ, hỗ trợ và phối hợp với công tác tình báo quốc gia”, thì còn phải nhìn nhận khác đi thế nào?
    • Nếu mọi chi tiết trong bài đều là sự thật, nhà cung cấp này cẩu thả đến mức kinh tởm đối với bất cứ điều gì gần giống như tôn trọng khách hàng, bảo mật và quyền riêng tư dữ liệu
      Không thể giúp công ty này được. Đây không phải là tình trạng có thể cứu vãn bằng kiến thức. Chấm hết
    • Thế giới quan “đồ Trung Quốc thì cái gì cũng giám sát” đã dự đoán thực tế chính xác hơn nhiều so với thế giới quan đang được bênh vực ở đây
      Việc họ có “thái độ rất hoan nghênh” là tốt, nhưng điều đó chỉ bù đắp được đến một mức nhất định cho sự vô trách nhiệm và bất tài nghiêm trọng. Họ đã chọn bán một sản phẩm rác rưởi bốc cháy hạng bét, và nên bị đối xử tương xứng
    • Mức độ bài Nhật thấp là vì Nhật Bản chưa vũ khí hóa công nghệ thành công để tạo ra một nhà nước cảnh sát chấm điểm tín dụng xã hội nhắm vào các nhóm thiểu số

  • Tôi thích nỗ lực hối lộ khi đề nghị “tài trợ” cho một kênh YouTube trống trơn