Caso 04 — SKRED Messenger

Una clave para
todos los dispositivos.

SKRED es una aplicación de mensajería de código abierto con cifrado de extremo a extremo. Al examinar el código de gestión de claves, encontré una clave de respaldo idéntica en todos los dispositivos. Lo comuniqué a través de BSI CERT-Bund. El fabricante respondió como cabe esperar: con transparencia, explicaciones técnicas concretas y una solución rápida.

Por Abbas Hoseiny· Coordinado a través de BSI CERT-Bund & CERT/CC· Fabricante: SKRED SAS / Twinlife

No todas las vulnerabilidades son dramáticas, ni hace falta un hallazgo espectacular para contar un caso valioso. Este trata de un error concreto en una aplicación de mensajería de código abierto y, sobre todo, de una respuesta que muestra cómo debería funcionar la divulgación coordinada.

Una misma clave para varios teléfonos idénticos la misma clave en todos los dispositivos
Fig. 1 — una clave para todos

SKRED guarda cifradas ciertas configuraciones sensibles en el dispositivo. Normalmente crea una clave propia para cada teléfono en su almacén seguro (Android Keystore). Si ese proceso fallaba —algo conocido en algunos dispositivos antiguos—, entraba en juego una clave de respaldo incorporada al código. Esa clave era idéntica en todas las instalaciones.

Por qué existía. La intención era razonable: seguir protegiendo los datos si fallaba el Keystore del dispositivo. Sin embargo, la clave de respaldo no era propia de cada equipo. Se calculaba de forma determinista a partir de dos valores incluidos en el código; por eso era igual en todas las instalaciones y podía reconstruirse a partir del código fuente público.

Su alcance, sin exageraciones. Se trataba de una ruta de respaldo, no del mecanismo normal de cifrado. Afectaba a configuraciones almacenadas localmente, no al contenido de los mensajes de todos los usuarios. Para aprovecharla hacía falta acceso al propio dispositivo; no era un ataque remoto. Su gravedad se limita a ese escenario local. Es un fallo real, pero de alcance bien delimitado.

La clave de respaldo se guarda y solo sirve para leer datos antiguos ahora: se detiene ante el error la clave de respaldo solo lee datos antiguos
Fig. 2 — cómo lo corrigió el fabricante

En la versión actual, la clave de respaldo ya no se usa para cifrar. Si falla la creación de la clave en el Keystore, la aplicación pasa a un estado de error en vez de seguir con una clave conocida. La clave antigua solo se conserva para descifrar datos ya existentes durante la migración.

La respuesta

Una persona responde — y lo corrige.

Tras recibir el informe remitido por el BSI, el responsable técnico del fabricante respondió personalmente. Contestó punto por punto, con contenido técnico, sin recurrir a una respuesta genérica. Compartió documentación adicional de la arquitectura, señaló el código fuente público y empezó a corregir los problemas de inmediato. Además del cambio en la clave de respaldo, añadió la fijación de certificados que faltaba; ambas correcciones pueden seguirse en el repositorio público.

Lo que me deja este caso

Así debería hacerse.

El valor de la divulgación coordinada no depende de lo espectacular del fallo, sino de lo que ocurre después. SKRED dio un buen ejemplo: código abierto, una persona disponible para responder, diálogo técnico en vez de ponerse a la defensiva y correcciones rápidas y verificables. Que las aplicaciones sean abiertas forma parte de esa misma actitud.

Informe técnico

SKRED Messenger — análisis y corrección

Resumen

SKRED Messenger (SKRED SAS / Twinlife, Francia) es de código abierto en Android e iOS (AGPL). Analicé la aplicación publicada junto con su código fuente. Este informe aborda dos problemas ya corregidos: una clave de respaldo AES incluida en el código de gestión de claves y la ausencia de una configuración de fijación de certificados. Ambos se comunicaron mediante un proceso de divulgación coordinada gestionado por BSI CERT-Bund (y CERT/CC, VU#629507). El fabricante los corrigió y los cambios pueden verificarse en el código público.

Hallazgo 1 · gestión de claves

Clave de respaldo AES determinista, idéntica en todos los dispositivos

Qué ocurría

La capa de gestión de claves (KeyChain) protege configuraciones «seguras» almacenadas localmente con una clave del Android Keystore. Si no podía crearla —un problema conocido en algunos dispositivos o ROM antiguos—, la aplicación recurría a una clave incorporada al código. Esta se calculaba de forma determinista mediante XOR a partir de dos matrices de bytes incluidas en el código, por lo que era igual en todas las instalaciones:

// simplified from the open-source KeyChain implementation
static Key getDefaultSecretKey() {
    int n = Math.min(UUID1.length, UUID2.length);
    byte[] key = new byte[n];
    for (int i = 0; i < n; i++)
        key[i] = (byte) (UUID1[i] ^ UUID2[n - 1 - i]);
    return new SecretKeySpec(key, "AES");   // 128-bit, same on every device
}

Impacto

En un dispositivo cuyo Keystore fallara, las configuraciones «seguras» almacenadas localmente quedaban protegidas con una clave conocida públicamente. Quien tuviera acceso local a ese dispositivo podía descifrar esos datos. Se trata de una ruta de respaldo, no del funcionamiento habitual, y exige acceso local al equipo: no permite un ataque remoto ni expone el contenido de los mensajes de todos los usuarios.

Corrección del fabricante

La clave de respaldo ya no se utiliza para cifrar. Si no puede crearse una clave en el Keystore, la aplicación pasa a un estado de error en vez de cifrar con la clave conocida. La clave antigua solo descifra datos existentes durante la migración; se retiró la compatibilidad con Android 5.0/5.1, principal origen de los fallos del Keystore. Verificado en el código público.

Hallazgo 2 · seguridad de red

Ausencia de fijación de certificados

Qué ocurría

La aplicación se distribuía sin una configuración de seguridad de red. Un certificado instalado en el dispositivo —por ejemplo, en un entorno administrado— podría haber permitido interceptar sus conexiones TLS.

Corrección del fabricante

La aplicación incluye ahora una configuración de seguridad de red que solo confía en los certificados del sistema, desactiva el tráfico sin cifrar y fija un conjunto real de claves para su propio dominio. Se implementó al principio del proceso y lo confirmé en la aplicación publicada.

Sobre la gravedad

Por qué no hay una puntuación alarmista La clave de respaldo solo entraba en juego ante un fallo del Keystore y exigía acceso local al dispositivo; la ausencia de fijación de certificados requería un certificado ajeno instalado en él. Son problemas reales, pero de alcance limitado, y ambos están corregidos. En vez de inflar una puntuación, corresponde describir el escenario con precisión: acceso local al dispositivo, sin ataque remoto.

Coordinación y divulgación


Divulgación coordinada a través de BSI CERT-Bund y CERT/CC. Las correcciones del fabricante pueden seguirse en el código público. Con fines de defensa e investigación.