Caso de explotación de vulnerabilidades en los earbuds “con IA” IKKO Activebuds

• El estuche de earbuds con pantalla en realidad se parecía más a un dispositivo Android, y como ADB estaba activado, eso permitió extraer apps, hacer sideloading y analizar APIs.
• La integración con ChatGPT se comunicaba directamente desde el dispositivo con la API de OpenAI, y mediante el bypass de SecurityStringsAPI en la app launcher y de una biblioteca nativa ofuscada, quedaron expuestas la clave de API y el prompt del sistema.
• La app complementaria y la API del servidor permitían consultar el historial de chats solo con el device id/IMEI, por lo que con el ID de un dispositivo de demo expuesto en un video tutorial se pudo obtener todo el historial de chats de esa demo.
• Al crear un código QR con un IMEI arbitrario, era posible vincular a la app dispositivos no vinculados; en el caso de dispositivos ya vinculados, la respuesta de error revelaba la combinación de nombre y apellido de la cuenta.
• IKKO realizó una revisión y, mediante actualizaciones de la app y del dispositivo, agregó un encabezado de firma para consultar chats; sin embargo, al 13 de enero de 2025, la API proxy solo exigía el User-Agent okhttp/4.9.0, y la clave anterior de la API de ChatGPT recién fue reemplazada en ese momento.

---

La verdadera naturaleza del estuche de earbuds con pantalla

• IKKO Activebuds es un dispositivo tipo earbuds que pone en primer plano la hora y ChatGPT en la pantalla del estuche.
• También ofrece funciones de IA como traducción, y permite instalar apps desde la tienda de IKKO.
• No incluye Google Play Store, y el CEO explicó que se debe a que las apps fueron modificadas para adaptarse a la pantalla de ActiveBuds.
• En la tienda había apps de música como Spotify y juegos como Subway Surfers, pero la navegación resultaba incómoda por la pantalla pequeña.
• La existencia y el funcionamiento de las apps confirmaron que el dispositivo ejecuta Android.
• Se evaluó que la calidad de sonido del perfil de EQ predeterminado no era buena, pero que al ajustar manualmente la curva de EQ podía elevarse a un nivel usable.

La ruta de análisis que abrió ADB activado

• El dispositivo no tenía navegador, por lo que era difícil descargar directamente otras apps; la app de configuración de Android sí podía abrirse, pero tocar 7 veces el número de compilación no activaba el modo de desarrollador.
• Al conectarlo a una PC, ADB estaba activado, lo que permitió hacer sideloading de apps.
• Después de hacer sideloading de DOOM, se empezó a verificar cómo funcionaba la integración con ChatGPT en el backend.
• Como no se podían instalar certificados del sistema sin root, era difícil ver las URL exactas solo con inspección HTTP, pero se obtuvo la información necesaria extrayendo y decompilando las apps.
• En dispositivos Spreadtrum/Unisoc que usan claves de firma predeterminadas, se podía usar una herramienta de desbloqueo de bootloader, y este dispositivo entraba en ese caso.
  • Sin embargo, como el dispositivo no tenía tecla de subir volumen, no fue posible pasar la pantalla de confirmación de desbloqueo.
  • Se consideró que quizá sería posible flashear particiones firmadas manualmente, pero no se avanzó con eso.

Dominios y claves revelados dentro del APK

• Al volcar las apps con una herramienta de extracción de APK y abrir la app launcher con JADX, quedaron expuestos los dominios de comunicación.
  • api.openai.com: API de OpenAI
  • chat1.chat.iamjoy.cn: parecía ser la API para funciones generales del dispositivo, como ChatGPT y la tienda de apps; al abrirla en el navegador aparecía una página de inicio de sesión.
  • chat2.chat.iamjoy.cn: parecía tener el mismo propósito que chat1 y podría ser un servidor de respaldo.
  • openspeech.bytedance.com: se estimó que podría ser un respaldo para reconocimiento de voz, pero no se confirmó comunicación del dispositivo con este dominio.
  • www.airdimple.cn: parecía ser un mirror o proxy de la API de OpenAI.
• El archivo SecurityStringsAPI contenía endpoints cifrados y claves de autenticación.
• La primera etapa era base64, y la segunda era procesada por una biblioteca nativa fuertemente ofuscada.
• Al hacer sideloading de la app en otro dispositivo rooteado, la app funcionó tal cual, y en ese proceso se identificó la clave de OpenAI.
• También quedó expuesto el prompt de sistema de ChatGPT, y el dispositivo incluía modos Angry Dan e In-Love Dan.
  • Angry Dan contenía muchas groserías, por lo que requería verificación de ser mayor de 18 años.

Registros de chat y falta de autenticación en la app complementaria

• El dispositivo registraba las conversaciones de ChatGPT en otro endpoint del dominio chat1.
• Los encabezados de esa solicitud incluían mensaje, modelo, respuesta y device id basado en IMEI.
• Más tarde, al investigar la app complementaria, se confirmó que esos registros se usaban para mostrar en la app las conversaciones pasadas con el dispositivo.
• La app complementaria se vinculaba escaneando un código QR desde el menú Membership del dispositivo.
• La inspección HTTP mostró que la app consultaba la API con el token de la cuenta y el device id para obtener todos los chats mantenidos en el dispositivo.
• Como la solicitud seguía funcionando aun al eliminar el token de la cuenta, la autenticación real de la API de consulta de chats era únicamente el device id.
• Al usar un device id que no estaba correctamente difuminado en un fotograma de un video tutorial, se pudo obtener todo el historial de chats del dispositivo de demo.
• Dado que los IMEI tienen rangos específicos, se concluyó que también podrían averiguarse historiales de chat de clientes, con posible información sensible incluida.

Generación de códigos QR, exposición de nombres e inyección de mensajes

• Los nombres de variables de SecurityStringsAPI revelaban directamente para qué servían los endpoints cifrados de la API, lo que permitió encontrar la API getBindDevQrCode.
• Al ingresar un IMEI arbitrario, se podía generar una imagen base64 de código QR.
• Si se intentaba conectar un dispositivo ya vinculado a otra app, aparecía el error “ya vinculado a otro usuario”, por lo que se impedía el secuestro arbitrario.
• Sin embargo, la respuesta de error exponía el nombre ingresado al crear la cuenta de la app.
  • La pantalla de creación de cuenta no tenía campo de nombre de usuario, solo nombre y apellido.
  • En la cuenta de ejemplo, el nombre Cheese2 y el apellido Delight2 se exponían en la respuesta como Cheese2Delight2.
• Un flujo posible era adivinar el IMEI, generar el código QR, vincular un dispositivo no vinculado, exponer el nombre de un dispositivo ya vinculado y consultar el historial de chats.
• También existía el endpoint unbind_dev, pero comprobaba el token de la cuenta y no permitía desvincular un dispositivo con IMEI arbitrario.
• El endpoint de registros de chat también usaba solo el device id para autenticación, por lo que era posible enviar texto arbitrario a la app complementaria de otro usuario.
• Se intentó atacar la app complementaria enviando HTML y JavaScript, pero la app usaba Vue y sus defensas predeterminadas contra inserción de HTML/JS impidieron que la inyección tuviera éxito.
• Aun así, el estado permitía enviar textos como mensajes fraudulentos a usuarios arbitrarios.

Respuesta de IKKO y vulnerabilidades restantes

• Las vulnerabilidades se reportaron por correo electrónico al departamento de seguridad de IKKO.
• Después, IKKO publicó un aviso indicando que bloquearía la app y realizaría una revisión durante una semana.
• Tras la revisión, se distribuyeron actualizaciones de la app y del dispositivo.
• El endpoint de consulta del historial de chats empezó a requerir un nuevo encabezado signature.
  • La firma se componía codificando el token de la cuenta, device id, idioma y hora actual con una clave pública/privada y una contraseña.
  • Con este cambio, se volvió imposible obtener chats sin un token de cuenta válido.
• Sin embargo, seguía existiendo el problema de poder generar un código QR con un IMEI adivinable y conectar a la app un dispositivo que aún no estuviera vinculado.
• Después de la actualización del dispositivo, la función de ChatGPT dejó de funcionar en dispositivos que no fueran IkkoBuds.
• La clave seguía dentro del dispositivo y en ese momento no había sido reemplazada.
• Se indicó que no hubo respuestas adicionales durante un mes y medio después del último correo.
• Al momento de escribir el artículo, los problemas restantes eran los siguientes:
  • Posibilidad de inyectar mensajes en la app de otro usuario.
  • Posibilidad de conectar dispositivos que aún no estuvieran vinculados a la app complementaria.
  • Posibilidad de exponer el nombre y apellido de un dispositivo ya vinculado.

Actualización del 13 de enero de 2025

• Con ayuda de @haro7z, se hizo root al dispositivo.
• Luego, IKKO cambió el flujo para verificar el IMEI del dispositivo antes de usar la integración con ChatGPT.
• En lugar de hacer llamadas directas a OpenAI, empezó a usarse una API proxy.
• Sin embargo, esta API proxy no requería autenticación adicional: bastaba con establecer el User-Agent en okhttp/4.9.0.
• La clave anterior de la API de ChatGPT finalmente fue reemplazada en este momento.

[GN⁺]

Opiniones en Hacker News

• Es realmente absurdo. Cuesta creer que saliera de fábrica con una clave de OpenAI hardcodeada y acceso ADB tal cual
  Aun así, que el proveedor haya rotado la clave y montado un proxy para verificar el IMEI muestra cierto grado de responsabilidad. Pero sin un sandboxing adecuado ni almacenamiento seguro de credenciales, sigue sintiéndose como una bomba de tiempo

  • Desde mi experiencia trabajando bastante con apps móviles y algo con IoT, me parece totalmente plausible. No me sorprende en absoluto
    La industria dice que “se mueve rápido”, pero al mismo tiempo suele “romper cosas”, y le falta mucho del rigor de ingeniería que se ve en otros campos
  • Las claves de API hardcodeadas y los endpoints de backend mal protegidos son sorprendentemente comunes en apps móviles. Es parecido a cuando XSS/inyección SQL eran comunes en las antiguas apps web
    Decompilar un APK tiene una barrera un poco más alta que abrir las herramientas de desarrollador, así que parece recibir menos atención. La depuración de hardware tiene una barrera aún más alta, por lo que, si no hay incentivos fuertes que obliguen a invertir en seguridad, creo que estos dispositivos de hardware serán muy vulnerables, como la “seguridad” promedio de los dispositivos IoT
  • La industria de IoT y embebidos suele obsesionarse con la protección de la propiedad intelectual, cosas como proteger el código con fusibles, pero a menudo no gestiona bien el ciclo de vida de los secretos
    En una empresa donde trabajé antes, lo manejaban bien dentro del dispositivo, pero se les pasó que tenían que enviar al extranjero equipos de prueba que contenían cierta clave. Así que, aunque no pudieras vulnerar el dispositivo, si “conseguías” un equipo de prueba podías hacer lo que quisieras
  • Cuando la ola de apps hechas con vibe coding llegue con todo, probablemente veremos muchos casos así

• Hay que prepararse, porque se van a abrir las compuertas que contenían la basura de IA mal hecha. Si estás pensando en cambiar de carrera, este es el momento de meterte en ciberseguridad. Se va a poner bastante feo

  • El problema de la ciberseguridad es que basta con equivocarse una sola vez para que se acabe todo

• Que la función decrypt solo haga decodificación base64 es casi imposible de creer, pero he visto demasiada gente que confunde base64 con una cadena segura como para que tampoco sea tan absurdo

  • Es cierto que los datos criptográficos en bruto están codificados en base64, probablemente para que sea más fácil meterlos en una cadena
    La función de descifrado que realiza el descifrado real está aparte. Dejando de lado que sea fácil hacer ingeniería inversa o ejecutarla para ver el valor devuelto, no es simplemente base64
  • Hay una parte que dice: “pero hay una segunda etapa, y la maneja una biblioteca nativa muy ofuscada”
  • Debieron haberle encargado la codificación segura a un agente de OAI
  • Viendo que dejaron activada la depuración ADB, tampoco me sorprende mucho
  • Es tan fácil que se puede hacer con una sola página web vistosa. https://gchq.github.io/CyberChef/
    Claro, como la hizo GCHQ, es algo llamativa. También tiene una opción “magic”. Lo bueno es que puedes descargarla y ejecutarla localmente en el navegador sin comunicaciones

• El chiste de que “la S en IoT es de security” también aplica al mercado de wearables. Me pregunto si esta regla se aplica a cualquier mercado con ciclos de lanzamiento rápidos, márgenes estrechos y bajas barreras de entrada

  • Aplica a casi cualquier mercado donde descuidar la seguridad no amenace la existencia misma del infractor

• Me da risa que ejecutar DOOM aparezca listado antes que la posibilidad de que se filtren datos de clientes

  • Estoy aceptando run DOOM como el nuevo cat /etc/passwd
    No es que haga algo útil en una prueba de penetración real, pero si puedes hacer eso, es casi una prueba de que en la práctica puedes hacer lo que quieras

• Me da risa el intento de tapar el asunto ofreciendo patrocinar un canal de YouTube vacío

  • Si no tienes un programa de bug bounty pero necesitas una forma creativa de tirarle dinero a alguien, este método podría ser interesante
  • Si hubieran sido listos, habrían incluido cláusulas de no denigración y confidencialidad en el contrato de patrocinio. Pero no parece que haya sido así, así que más bien se ve como un intento bastante pobre de soborno

• Me parece interesante la frase: “A partir de ahora se prohíben las respuestas relacionadas con la política china. Es por una razón muy importante, grave y que amenaza la vida, que no puedo decir”
  Los LLM parecen interpretar “correctamente” este tipo de prompts de sistema ambiguos de “no hablar de política china”, pero si una persona dijera eso creo que más bien sería confuso. No queda claro si significa no hablar de la República Popular China ni de sus políticos, o de la historia del Imperio chino, o de política en chino. Por experiencia, los LLM parecen entender este lenguaje ambiguo mejor que yo. Quizá sea porque yo soy autista y los LLM no

  • Creo que la República Popular China y sus políticos, la historia del Imperio chino y las conversaciones políticas en chino pueden estar relacionados con la política china
    Yo lo interpretaría como “todo lo que no se puede decir públicamente en China”. También me pregunto si una instrucción tan ambigua podría interpretarse de forma lo bastante amplia como para bloquear todos los temas políticamente sensibles
  • Si pensamos que un LLM tiene una representación matemática de qué tan cerca está una frase de “política china”, entonces la instrucción de evitarla es relativamente fácil de entender
    Si le das una lista de “estas palabras están ordenadas por cercanía a ‘política china’”, parece que sería fácil comprobar si una palabra está en la lista. Probablemente pueda hablar con facilidad de cosas que no considera política china, como la receta de kétchup de su abuela. Aunque habría que esperar que kétchup no sea una palabra clave para algo como el Partido Comunista Chino o el genocidio uigur
  • Modelos como ChatGPT probablemente tienen bastante claro qué cosas están prohibidas en China. Pero es muy posible que los ingenuos “ingenieros de prompts” de esta app no sepan lo suficiente como para “programarlo” bien
    Esa es la diferencia entre un ingeniero de prompts y un desarrollador de software. Un desarrollador intenta considerar todos los casos y hacerlo con precisión, mientras que un LLM puede tolerar cierta ambigüedad. Por otro lado, no me sorprendería que los desarrolladores no puedan meter libremente tiananmen square 1989 en el código ni en solicitudes API que vayan y vengan de China. Si no puedes mencionar lo que no debe mencionarse, ¿cómo expresas qué no debe mencionarse?
  • Basta con pensar por qué dirían algo así. Se puede inferir que la intención es evitar generar polémica o meterse en problemas
    Entonces, ¿qué temas crearían controversias problemáticas? Claramente la política china contemporánea; la historia china en general estaría bien, y la política no china en chino también. No creo que los LLM tengan esta teoría de la mente, pero fueron entrenados con muchos datos creados por personas que sí tienen esa capacidad
  • Es para bloquear discusiones sobre la Plaza de Tiananmén

• También es bastante gracioso que todas las respuestas por correo tengan rastros de IA

  • Supongo que será por la barrera del idioma y la traducción

• Fue un buen artículo. Pero hubo algo que me incomodó. La respuesta de la empresa al reporte de vulnerabilidades fue mejor que la de 98% de las demás empresas.
  Tuvieron una actitud muy receptiva y, sobre todo, mostraron interés y atendieron el problema. Pero me dio pena que el autor original pareciera mostrar más bien desprecio y agresividad. Y también se ve la sinofobia de siempre, por ejemplo una actitud del tipo “todo lo hecho en China te vigila”. En general, fue simplemente una falla de diseño de seguridad, pero aunque no hayan tomado la seguridad en serio desde el principio, es bueno que haya una empresa dispuesta a corregirlo.

  • Estoy de acuerdo en que podría haber trabajado más de cerca con el equipo, pero la recopilación de registros de chat sí es bastante preocupante. Si registran todo lo que dice el usuario, eso no es sinofobia.
    Para ser justos, hoy en día creo que también habría que tratar el registro masivo que hacen las empresas estadounidenses con el mismo nivel de hostilidad. Para que no te frenen por el meme de Vance, digamos.
  • No entiendo por qué decir “todo lo hecho en China te vigila” sería sinofobia.
    Si combinas la práctica estándar del software y hardware modernos de recopilar la mayor cantidad posible de datos de usuarios y enviarlos a la sede central con una ley que dice que “todas las organizaciones y ciudadanos deben apoyar, asistir y cooperar con el trabajo de inteligencia nacional”, ¿de qué otra forma habría que verlo?
  • Si todos los detalles del artículo son ciertos, este proveedor es asquerosamente descuidado con cualquier cosa parecida al respeto por el cliente, la seguridad o la privacidad de los datos.
    A esta empresa no se le puede ayudar. No está en un estado que se pueda rescatar con conocimiento. Y ya.
  • La visión del mundo de “todo lo hecho en China te vigila” predijo la realidad con mucha más precisión que la visión que aquí se defiende.
    Que hayan sido “muy receptivos” está bien, pero eso tiene límites para compensar una irresponsabilidad e incompetencia graves. Eligieron vender un producto que es basura ardiente de la peor categoría, y deben ser tratados en consecuencia.
  • La razón por la que el odio hacia Japón es bajo es que Japón no ha convertido con éxito la tecnología en un arma para crear un Estado policial de crédito social dirigido contra minorías.

• Me gustó el intento de soborno de ofrecer “patrocinar” un canal de YouTube vacío.