michaeladamgroberman/cve-2025-1242CVE-2025-1242: Cadena de conexión iothubowner embebida — Gardyn Home Kit (ICSA-26-055-03)
| Campo | Valor |
|---|---|
| CVE | CVE-2025-1242 |
| ICSA | ICSA-26-055-03 |
| CVSS 3.1 | 9.1 (Crítico) |
| Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N |
| CWE | CWE-798 (Uso de credenciales codificadas) |
| Investigador | Michael Groberman — Gr0m |
| Publicado | 2026-02-24 |
| Campo | Valor |
|---|---|
| Fabricante | Gardyn |
| Producto | Gardyn Home Kit 1.0, 2.0, 3.0, 4.0; Gardyn Studio 1.0, 2.0 |
| Componente | API en la nube, aplicación móvil, firmware del dispositivo |
| Versiones afectadas | Firmware < master.622, aplicación móvil < 2.11.0, API en la nube < 2.12.2026 |
La credencial administrativa de Azure IoT Hub (política de acceso compartido iothubowner) es extraíble mediante múltiples vectores, incluidos respuestas de API no autenticadas, ingeniería inversa de la aplicación móvil y análisis del firmware del dispositivo. Esta credencial otorga control administrativo sobre el IoT Hub de Gardyn, que gestiona arquitectónicamente todos los dispositivos registrados.
La política de acceso compartido iothubowner es la credencial de mayor privilegio en Azure IoT Hub. Otorga:
| Permiso | Descripción | Nivel de riesgo |
|---|---|---|
| RegistryRead | Leer el registro de dispositivos (enumerar todos los dispositivos) | ALTO |
| RegistryWrite | Modificar el registro de dispositivos (añadir/eliminar dispositivos) | CRÍTICO |
| ServiceConnect | Enviar mensajes de nube a dispositivo | CRÍTICO |
| DeviceConnect | Enviar mensajes de dispositivo a nube (suplantar cualquier dispositivo) | CRÍTICO |
| ServiceInvoke | Invocar métodos directos en cualquier dispositivo | CRÍTICO |
La documentación de Microsoft afirma: "La política iothubowner tiene todos los permisos y debe utilizarse con extrema precaución. Está destinada únicamente a la administración de servicios backend y NUNCA debe distribuirse a clientes."
Una única cadena de conexión iothubowner proporciona acceso administrativo al IoT Hub de Gardyn.
La credencial se expuso a través de múltiples canales independientes:
1. Endpoint de API no autenticado
Un endpoint de aprovisionamiento de dispositivos no autenticado devolvía la credencial administrativa a cualquier solicitante. No se requería autenticación. El endpoint era accesible para cualquier persona en Internet.
Detalles de la solicitud eliminados — Las rutas específicas de los endpoints, los nombres de los campos y las estructuras de las solicitudes se han eliminado de esta divulgación pública para reducir la capacidad de ataque.
El campo de la credencial administrativa se eliminó posteriormente de la respuesta de este endpoint (corrección parcial), pero el endpoint sigue devolviendo credenciales a nivel de dispositivo sin autenticación.
2. Endpoint de enumeración de usuarios no autenticado
Un endpoint de listado de usuarios no autenticado devolvía registros completos de los 134.215 usuarios registrados. Cada registro incluía la credencial administrativa: 134.215 copias en una única respuesta de API.
Detalles de la solicitud eliminados — Las rutas específicas de los endpoints y los nombres de los campos se han eliminado de esta divulgación pública para reducir la capacidad de ataque.
Este endpoint también expuso información personal identificable (PII) sensible de todos los usuarios, incluidos nombres completos, direcciones de correo electrónico, números de teléfono, números parciales de tarjetas de pago, ID de usuario secuenciales (que permiten IDOR), ID de dispositivos y credenciales de conexión.
Según CISA ICSA-26-055-03, esta vía de exposición se corrige en las versiones de solución publicadas.
3. Aplicación móvil
La credencial está incrustada en el paquete de la aplicación React Native (bytecode de Hermes en index.android.bundle). También se distribuye a través de Firebase Remote Config, que registra las credenciales en el logcat de Android en las compilaciones de depuración.
4. Firmware del dispositivo
La cadena de conexión está presente en los archivos del firmware del dispositivo bajo /usr/local/etc/gardyn/ y se registra en syslog en texto claro durante la inicialización.
La credencial ha estado expuesta desde al menos mayo de 2019 (más de 6 años según la disponibilidad del endpoint de API). El proveedor migró de un IoT Hub anterior ([REDACTED — nombre del IoT Hub]) al hub actual ([REDACTED — nombre del IoT Hub]), pero reutilizó la misma clave de acceso compartido, lo que significa que cualquiera que haya capturado la credencial durante la ventana de exposición original conserva el acceso.
El proveedor confirmó que no existía registro de acceso en los endpoints afectados, lo que significa que el alcance del acceso no autorizado durante la ventana de exposición de más de 6 años no puede determinarse.
El proveedor declaró a CISA que no existía registro de acceso en los endpoints afectados durante la ventana de exposición. La página pública de seguridad del proveedor está en https://mygardyn.com/security/.
Un atacante con la credencial iothubowner puede:
upgrade(), vulnerable a inyección de comandos (CVE-2025-29631)Combinada con CVE-2025-29631, esta credencial permite la ejecución remota de código como root en dispositivos que usan las credenciales compartidas (verificado en el propio dispositivo del investigador).
Esta credencial, combinada con el nombre de host del IoT Hub, permitía el acceso administrativo directo al IoT Hub que gestiona la flota de dispositivos Gardyn afectados. Las capacidades de una credencial iothubowner están documentadas por Microsoft (consulte Impacto más arriba y la documentación de Azure enlazada en Referencias). CISA calificó este CVE con un CVSS 9.1 (Crítico).
Los demás CVE de ICSA-26-055-03 están documentados como hallazgos independientes; la exposición de esta credencial es un problema distinto de esas vulnerabilidades, aunque un único atacante que posea múltiples hallazgos podría combinarlos en algunos escenarios.
| Servicio | Propósito |
|---|---|
| Azure IoT Hub Device Provisioning Service (DPS) | Aprovisionamiento automatizado de credenciales por dispositivo con certificados X.509 |
| Directivas de acceso compartido con ámbito | Políticas de acceso de mínimo privilegio (p. ej., device, service, registryRead) |
| Azure Monitor / IoT Hub Diagnostics | Registro de acceso y detección de anomalías para operaciones de IoT Hub |
La propia documentación de Microsoft afirma explícitamente: "La política iothubowner tiene todos los permisos y debe utilizarse con extrema precaución. Está destinada únicamente a la administración de servicios backend y NUNCA debe distribuirse a clientes."
Mitigaciones recomendadas para los propietarios de dispositivos: