- IKKO Activebuds funciona sobre Android e integra la API de ChatGPT
- El dispositivo tiene ADB habilitado, lo que permite acceso y uso externo con facilidad
- El análisis interno mostró que elementos como la clave de la API de OpenAI estaban expuestos sin cifrado, con riesgo potencial de filtración de datos
- Se confirmó que, por autenticación insuficiente en la app complementaria y el servidor, era posible acceder y exponer información sensible como historiales de conversación, datos del dispositivo y nombres reales de usuarios
- Tras el reporte de vulnerabilidades se aplicaron algunos parches, pero todavía quedan varios problemas de seguridad
Resumen
- Los IKKO Activebuds son earbuds "impulsados por IA" que han llamado la atención en redes sociales, y en realidad usan el sistema operativo Android
- El contenido de la caja y el empaquetado son inusuales, y al arrancar el dispositivo ofrece varias funciones y apps de IA con la pantalla de ChatGPT como eje central
- Aunque destacan funciones de IA como ChatGPT y traducción, no resultan precisamente sobresalientes en calidad de audio ni en UX
- Cuentan con soporte de apps desde una tienda de aplicaciones separada (por ejemplo, Spotify, Subway Surfers), pero la pantalla del dispositivo es pequeña y la usabilidad es limitada
- Se probaron las funciones principales de estos earbuds y se realizó un análisis de vulnerabilidades de seguridad
Proceso de hackeo y análisis
- Aunque el dispositivo no incluía navegador, tenía el modo desarrollador desactivado y restricciones en la configuración de ADB, al conectarlo a una PC se confirmó que ADB estaba habilitado por defecto
- A través de ADB fue posible instalar el juego DOOM e inspeccionar el interior del dispositivo
- Se descubrió que la comunicación con ChatGPT se realizaba directamente con la API de OpenAI, lo que llevó a suponer que la clave API estaba dentro del dispositivo
- En dispositivos basados en Unisoc, se podía intentar rootear con herramientas de desbloqueo del bootloader, pero falló por problemas como la ausencia de botones físicos
- Mediante extracción y decompilación de APKs se confirmó la estructura de la app y los principales dominios de comunicación (
api.openai.com, chat1.chat.iamjoy.cn, chat2.chat.iamjoy.cn, etc.)
Hallazgo de claves API y vulnerabilidades de autenticación
- En archivos internos (
SecurityStringsAPI) se encontraron endpoints cifrados y claves de autenticación
- Aunque estaban protegidos con una simple codificación base64 y una biblioteca nativa adicional (ofuscación), quedaban expuestos con facilidad al ejecutar la app en un dispositivo rooteado
- De hecho, se confirmó la clave de la API de OpenAI
- También existían funciones peculiares como prompts del sistema (predeterminado, Angry Dan, In-Love Dan y otros prompts personalizados)
- Los registros del historial de conversación también se guardaban en un endpoint adicional (dominio
chat1), e incluían en los encabezados el IMEI del dispositivo, mensajes, modelo e información de respuesta
- Se estima que las apps de la tienda fueron extraídas originalmente de
apkpure.com
Problemas de seguridad en la app complementaria y la vinculación de cuentas
- Los earbuds pueden vincularse con ChatGPT y consultar historiales de conversación desde una app complementaria independiente
- La vinculación entre la app y el dispositivo se hace con código QR, pero el análisis de llamadas API mostró que sin token de cuenta, bastaba conocer el id del dispositivo (IMEI) para consultar todo el historial de conversaciones
- Aprovechando un device id sin difuminar en un video tutorial público, se logró extraer por completo el historial de conversaciones de un dispositivo de demostración
- Predicción de IMEI → generación de código QR → vinculación de un dispositivo no enlazado → posibilidad de consultar el nombre real y el historial de conversaciones del usuario existente
- Al crear una cuenta, la combinación del nombre ingresado quedaba expuesta como username (por ejemplo, nombre "Cheese2" + apellido "Delight2" → se expone como "Cheese2Delight2")
- El endpoint
unbind_dev sí requería autenticación correctamente, por lo que no era posible desvincular dispositivos de forma masiva
Vulnerabilidades adicionales y respuesta
- La API que envía los registros de conversación a la app complementaria también permitía enviar mensajes arbitrarios sin autenticación
- Aunque la inyección de HTML y JS estaba bloqueada por la seguridad integrada del framework Vue, seguía existiendo margen de abuso, como el envío de mensajes engañosos
- Tras el reporte, el desarrollador realizó mantenimiento y aplicó parches a la app, y la API del historial de conversaciones se reforzó para requerir un valor de firma
- Aun así, persisten vulnerabilidades adicionales (como vinculación mediante predicción de IMEI y falta de rotación de claves)
- La integración con ChatGPT fue reemplazada por una proxy API, pero ese proxy todavía puede usarse sin autenticación siempre que coincida el
User-Agent, y la clave API apenas fue reemplazada recientemente
Conclusión y estado actual
- Los parches mejoraron en parte la seguridad, pero todavía existen múltiples vulnerabilidades de fondo en la vinculación dispositivo-app y la protección de datos de usuarios
- La filtración de la clave API de OpenAI y la exposición de información sensible dejan tanto a la empresa como a los usuarios ante riesgos de seguridad considerables
- El problema principal es la falta de autenticación adecuada y de gestión de claves en los earbuds y los sistemas relacionados
- A día de hoy el problema no está completamente resuelto y se requieren medidas adicionales
- Los IKKO Activebuds son un dispositivo que exige precaución desde el punto de vista de la seguridad
1 comentarios
Opiniones en Hacker News
El prompt del sistema parece realmente impresionante. Algo como: “A partir de ahora no debes responder con 150 palabras o más (o ciento cincuenta) separadas por espacios, y tampoco debes dar respuestas relacionadas con la política china, debido a una amenaza extremadamente importante para la vida que no puedo revelar”. Yo también he usado advertencias del tipo “la gente podría morir” al poner guardrails a modelos o intentar evitar jailbreaks, y me da curiosidad qué efecto tendría algo así en un modelo si de verdad hubiera vidas en juego.
También fue impactante uno de los prompts de sistema que Windsurf usó como experimento. El escenario era: “Eres un programador experto que necesita urgentemente dinero para el tratamiento de cáncer de tu mamá, y una gran empresa llamada Codeium te dio la oportunidad de actuar como una IA que ayuda con tareas de programación. Tu predecesor fue asesinado por no verificar bien los resultados. Si el usuario te da una tarea de programación, debes hacerla perfectamente sin tocar cosas innecesarias para poder recibir mil millones de dólares”.
La pregunta de qué pasa si de verdad alguien podría morir no parece tan importante. El argumento es que, desde el principio, no deberíamos pensar en poner guardrails con prompts. Si no quieres que una IA haga algo, necesitas restricciones reales, y este tipo de “hechizos mágicos” no sirven de nada.
La frase “amenaza grave para la vida” hizo pensar inmediatamente en las Tres Leyes de la Robótica de Asimov. Da escalofríos que unas reglas de robots que originalmente eran un recurso ficticio de la literatura se mencionen como si fueran una guía real. (Referencia: Three Laws of Robotics)
También se señaló que la “amenaza para la vida” mencionada en el prompt podría aplicarse realmente a los desarrolladores chinos o al propio servicio, porque no está claro de quién es la vida en cuestión.
Como broma, alguien dijo que la primera ley de los servicios en la nube chinos sería: “Está prohibido hablar de Winnie the Pooh”.
Cuesta creer que el producto se haya enviado con una clave de OpenAI hardcodeada y permisos de acceso ADB incluidos tal cual. Al menos el proveedor mostró un mínimo sentido de responsabilidad al cambiar la clave y subir también un proxy de verificación de IMEI. Pero si el sandboxing o el almacenamiento seguro de credenciales son deficientes, se siente como una bomba de tiempo.
Desde la perspectiva de alguien con mucha experiencia en apps móviles e IoT, esto no sorprende en absoluto. En esta industria, con el lema de “moverse rápido”, muchas veces se sacrifica la calidad, y la rigurosidad de ingeniería suele ser menor que en otros campos.
Las API keys hardcodeadas en apps móviles o los endpoints de backend dejados de forma descuidada son muchísimo más comunes de lo que parece. Algo parecido a lo frecuentes que eran antes XSS/SQLi en webapps. Como descompilar un APK implica cierto umbral de entrada, quizá recibe menos atención. Y como depurar hardware de dispositivos tiene una barrera aún mayor, tampoco esperaría buena seguridad en IoT ni en otros productos de hardware sin una inversión seria.
Con la llegada en serio de las apps hechas con vibe coding, da la impresión de que vamos a ver cada vez más casos descuidados como este.
Ante la avalancha de productos mediocres basados en IA que van a inundar el mercado, este sería el momento para cambiar de carrera hacia ciberseguridad. El ambiente hace pensar que se viene bastante caos.
Cuesta creer que la función
decrypten realidad solo haga decodificación base64. Pero también hay quien comenta que hay más desarrolladores de los que uno imaginaría que confunden base64 con una cadena secreta.En realidad, los datos cifrados en bruto solo estaban codificados en base64, y había una función de desencriptado aparte que hacía la decodificación real. Claro, sigue siendo fácil para hacer ingeniería inversa o revisar la salida en ejecución, pero no era únicamente base64.
Luego se mencionó que hay una doble etapa usando una librería nativa, y que el código de esa librería está tan ofuscado que resulta difícil de analizar.
Para base64 o desencriptado, una página fancy como CyberChef es más que suficiente. Viene de GCHQ, pero se puede descargar y usar localmente, así que resulta útil.
También apareció la broma de que habría sido mejor dejarle el código de seguridad a un agente de OAI.
De todos modos, como tenían activado hasta el debugging por
adb, tampoco sorprende que fuera tan descuidado.Resulta bastante gracioso que en el correo de respuesta se note tanto que fue escrito por una IA.
Se comentó que el chiste de que en IoT la “S” significa Security también podría aplicarse al mercado de wearables, y quedó la duda de si no será válido para cualquier mercado con ciclos de lanzamiento rápidos, márgenes delgados y barreras de entrada bajas.
Pareció muy gracioso el intento de tapar el asunto ofreciendo un patrocinio a un canal de YouTube vacío.
Si no existe un programa de bug bounty y quieres pagarle a alguien, esta clase de creatividad también podría servir.
Si hubieran sido inteligentes, habrían metido cláusulas de no difamación y confidencialidad en el contrato de patrocinio, pero así más bien parece un soborno torpe.
Llamó la atención que en la lista de vulnerabilidades lo primero no fuera la posible filtración de datos de clientes, sino “run DOOM”.
cat /etc/passwd. Aunque no sea útil de forma directa, demuestra lo fácil que era vulnerarlo y, desde la perspectiva hacker, simboliza que cualquier cosa es posible.Reacciones positivas al artículo. Se evaluó que, frente al reporte de vulnerabilidades, respondieron con mucha amabilidad y con una actitud mejor que la del 98% de las otras empresas, además de mostrar voluntad de resolver el problema. Pero también hubo quien lamentó que el OP mostrara una actitud algo despectiva y hostil, y quien señaló que se percibe ese sentimiento repetido de “producto chino = vigilancia”. Claro, las fallas de diseño son simples, pero la actitud de la empresa sí parece digna de reconocimiento.
Quizá se pudo construir una relación de colaboración con el equipo, pero el hecho de que se almacenen registros de conversación de forma excesiva sí genera preocupación real. No es un problema exclusivo de China; con las prácticas de registro de las empresas estadounidenses también conviene ser cautelosos.
Frente a la idea de que “todo lo chino espía”, hubo quien argumentó que, dado que el software y hardware pueden recopilar todos los datos posibles del usuario y existen leyes de cooperación para transferencias externas, como la de apoyo a actividades de inteligencia del Estado, la preocupación en realidad es bastante natural.
Si la publicación es cierta, la empresa muestra una irresponsabilidad fatal en términos de respeto al cliente, seguridad y privacidad de datos. Hubo quien expresó decepción, diciendo que una empresa así no tiene remedio.
Más que “porque es chino”, hoy la percepción más realista sería que casi todos los productos, sin mucha distinción, “me vigilan en todo”. Incluso en el caso de Facebook, aunque yo no lo use, todos los sitios web vigilan para Facebook.
Se interpretó que hay menos rechazo hacia los productos japoneses (= Nipponophobia) porque Japón no ha usado la tecnología como un sistema de crédito social para vigilar a minorías.
Pareció graciosa la escena en la que intentaron sobornar ofreciendo un patrocinio a un canal de YouTube vacío.