Samsung Knox aprobado por el Gobierno de EE. UU. para uso clasificado, ¿pero es realmente seguro?

Table Of Contents

• Samsung Knox validado y aprobado para uso clasificado del Gobierno de EE. UU.
• ¿Significa eso que Samsung Knox es la forma más segura de almacenar imágenes / videos / documentos importantes y personales?
• ¿Cómo es vulnerable Samsung Knox?
• En conclusión, Ares señala que Samsung Knox no es tan seguro como se indica.
• Recomendación de Ares

Samsung Knox validado y aprobado para uso clasificado del Gobierno de EE. UU.

Samsung Electronics anunció que sus soluciones han sido aprobadas por el gobierno de los Estados Unidos como los primeros dispositivos móviles de consumo validados por NIAP para manejar toda la gama de información clasificada. Después de completar diez Memorandos de Acuerdo (MOAs), el gobierno agregó el Galaxy S4, Galaxy S5, Galaxy Note 3, Galaxy Note 4, Galaxy Note 10.1 (Edición 2014), Galaxy Note Edge, Galaxy Alpha, Galaxy Tab S 8.4, Galaxy Tab S 10.5 y el Cliente de Red Privada Virtual (VPN) Galaxy IPSEC a la Lista de Componentes del Programa de Soluciones Comerciales para Clasificados (CSfC).

Este logro es el resultado directo de las pruebas y certificaciones exitosas de Samsung bajo el Perfil de Protección Fundamental de Dispositivos Móviles (MDFPP) y el Perfil de Protección VPN (VPNPP) del gobierno de EE. UU. Los dispositivos Samsung enumerados están disponibles para su uso con redes y datos clasificados del gobierno. Todos los dispositivos y capacidades incorporan características de seguridad impulsadas por Samsung KNOX.

La propia descripción de Samsung de su servicio Knox también señala los mismos hechos

“El contenedor KNOX Workspace mejora la experiencia del usuario, proporcionando seguridad para los datos empresariales al crear una zona segura en el dispositivo del empleado para aplicaciones corporativas, y encriptando los datos empresariales tanto en reposo como en movimiento. El contenedor KNOX Workspace proporciona a los usuarios un entorno aislado y seguro dentro del dispositivo móvil, completo con su propia pantalla de inicio, lanzador, aplicaciones y widgets para una operación más fácil, intuitiva y segura. Las aplicaciones y los datos dentro del contenedor están separados.”

La Lista de Productos Aprobados por DISA se puede encontrar en: https://www.disa.mil/Services/Network-Services/UCCO.

¿Significa eso que Samsung Knox es la forma más segura de almacenar imágenes / videos / documentos importantes y personales?

Con las brechas y hackeos que ocurren casi todos los días, un usuario enfrenta serios riesgos al guardar imágenes/documentos o videos personales en línea en la nube. Con los hackeos de iCloud se demostró que incluso las celebridades no están a salvo de los hackeos. Las filtraciones de SnapChat demostraron que las imágenes de niños de 13 a 17 años eran propensas a ser vulnerables a tales filtraciones. Las filtraciones de Dropbox demostraron que guardar en Dropbox también conlleva un riesgo relativamente alto.

Entonces, ¿qué hacen los usuarios con sus imágenes y videos tomados en esos momentos privados? Con la aprobación del Gobierno de EE. UU. para uso clasificado, Samsung Knox se convirtió en el primer dispositivo móvil garantizado como seguro contra hackers, nada menos que por el propio Big Sam.

Con capacidad de almacenamiento ilimitado (hasta 64GB) a bordo de muchos de los productos Samsung, estás seguro en la opción de espacio, pero ¿es realmente Samsung Knox el Fort Knox de almacenar tus documentos/imágenes y videos privados de manera segura? Mientras que el Gobierno de EE. UU. así lo piensa, un investigador de seguridad, Einstellt von Ares, no lo cree.

De hecho, Ares ha demostrado en su blog por qué el Knox de Samsung es vulnerable y bastante fácilmente también.

¿Cómo es vulnerable Samsung Knox?

Ares ha dado un PoC completo sobre la vulnerabilidad en su blog, que se reproduce aquí:

El teléfono Samsung viene preinstalado con dos aplicaciones: Knox y Knox EMM. Knox EMM es una solución de gestión basada en la nube para dispositivos móviles que no formó parte de este análisis. El enfoque se centró en la aplicación Knox, que proporciona el Contenedor Knox y una pantalla de inicio (segura) separada con sus propias aplicaciones. La configuración para Knox es bastante fácil, solo tienes que establecer una contraseña y un pin para la aplicación Knox. Al observar los internos del sistema, Knox instala bastante cosas en tu teléfono. Aplicaciones relacionadas con Knox en /data/data/: com.samsung.klmsagent com.samsung.knoxemm.mdm com.sec.knox.app.container com.sec.knox.containeragent com.sec.knox.eventsmanager com.sec.knox.seandroid com.sec.knox.store Además, todas las aplicaciones que se instalan en la nueva pantalla de inicio de Knox se encuentran en la carpeta de instalación de aplicaciones estándar /data/data/ y vienen con el prefijo: com.sec.. Listar todas aquí sería demasiado. Después de una instalación típica de Knox, hay 139 aplicaciones y servicios instalados con el prefijo com.sec.* Mirando un poco más profundo en el sistema, Knox se distribuye a través de todo el sistema y almacena datos en un par de ubicaciones diferentes, por ejemplo: el contenedor encriptado en sí se almacenará en /data/.container_ y /data/container/.sdcontainer_1. Diferentes archivos y bases de datos para configuraciones se almacenan en /data/system/secure_storage y /data/system/container. Cada análisis de una aplicación móvil comienza con un análisis estático de los archivos que la aplicación almacenó después de la configuración. Un buen punto de partida para las aplicaciones de Android es la carpeta de la aplicación bajo /data/data/. Estas carpetas típicamente tienen la estructura: com.aPackageName |- cache |- databases |- extracted |- lib |- shared_prefs Especialmente las carpetas databases y shared_prefs son las que merecen la primera atención. La aplicación ContainerAgent de Knox (com.sec.knox.containeragent) tenía algunos archivos interesantes almacenados: Activation.xml ContainerActivator.xml ContainerType.xml CreateSettings.xml DB_BRIDGE_INIT_SYNC.xml DB_BRIDGE_ISCHNDUOS.xml DB_BRIDGE_ONCHANGE_CONTACTS.xml DB_BRIDGE_ONCHANGE_EVENT.xml KLMSLicenseStatus.xml Pref.xml PrivacyPolicy.xml bno.xml com.sec.knox.containeragent_preferences.xml pin.xml Sí, adivina qué está escrito en el archivo pin.xml? ¡El pin que tuvimos que establecer durante la configuración de Knox en texto claro! Ahora Samsung Knox le da al usuario un máximo de 20 intentos para el nombre de usuario y la contraseña.*

Los otros archivos no revelaron otras cosas interesantes. Pero volviendo al archivo pin.xml. ¿Cuál es el propósito del pin en Knox de todos modos? Si vas a iniciar Knox, debes proporcionar tu contraseña para acceder a los datos y a la pantalla de inicio de Knox. Pero hay un pequeño botón debajo del campo de texto llamado “¿Contraseña olvidada?”. Al tocarlo, debes proporcionar tu pin. Si el PIN es correcto, la aplicación Knox te mostrará una pequeña pista de contraseña (¡el primer y el último carácter de tu contraseña!! + la longitud original de tu contraseña!). Así que ahora es bastante obvio que Samsung Knox va a almacenar tu contraseña en algún lugar del dispositivo. Como se mencionó anteriormente, Knox no solo almacena configuraciones en /data/data/, en la carpeta /data/system/container hay un archivo llamado containerpassword_1.key [sic!] almacenado. El contenido es una cadena encriptada: 72C9EE6D56CB15916A4CAB01814F978FA1E2689D (modifiqué la cadena por razones obvias ;)). Así que esto parece una cadena encriptada con AES. Ahora tenemos que descompilar las aplicaciones para tener una mirada más profunda sobre cómo funciona exactamente la encriptación de la contraseña y de dónde proviene la clave para la encriptación. Samsung hace uso de la dex-preoptimización para eliminar todos los archivos classes.dex (el código java se almacena en un archivo llamado classes.dex y este archivo es analizado por la JVM de Dalvik) en los apks de Knox, haciendo que la ingeniería inversa sea un poco más difícil. Para obtener los binarios, tenemos que mirar en /system/app/ y encontrar archivos .odex (un odex es básicamente una versión preprocesada de las clases.dex de una aplicación que está lista para la ejecución en Dalvik). Los archivos odex pueden ser convertidos de nuevo en código smali, que luego puede ser convertido de nuevo en un archivo dex. Finalmente, un archivo dex puede ser convertido en un archivo jar, que puede ser descompilado por cualquier Descompilador de Java. Samsung no hizo uso de ofuscación de código, pero realmente intentó ocultar el código de almacenamiento de contraseñas dentro de cientos de clases java, herencias y proxies. Finalmente, en la aplicación Knox Store se implementó el proxy IDataService que todas las demás aplicaciones estaban llamando constantemente al manejar algo relacionado con contraseñas. Así que al guardar la contraseña, la aplicación hace lo siguiente:
public boolean setData(String paramAnonymousString) {
this.keyGenInput = DataService.this.mPasswordUtil.getInputForKeyGenerate();
String str = SecureKeyLoader.getKeyForPassword(this.keyGenInput, this.bit_size);
return DataService.this.mEncryptDecrypt.encryptAndSave(paramAnonymousString, str);
}
Veamos cada línea y los métodos correspondientes:
public long getInputForKeyGenerate()
{
return Long.parseLong(SecureKeyLoader.getPartialString(getAndroidID()), 16);
}
private String getAndroidID()
{
return Settings.Secure.getString(this.mContext.getContentResolver(), “android_id”);
}
Así que la entrada para la clave es obviamente el ID de Android único que tiene cada dispositivo. El ID de 16 bytes analizado como valor Long se utiliza luego como argumento para la función getKeyForPassword:
public class SecureKeyLoader
{
static
{
System.loadLibrary(“mealy”);
}
public static native String getKeyForPassword(long paramLong, int paramInt);
public static native String getPartialString(String paramString);
} Ok, Samsung está ofuscando cada vez más para ocultar la verdadera generación de claves. El método getKeyForPassword está colocado en una biblioteca compartida escrita en C llamada “mealy”. Vamos a tomar la biblioteca del dispositivo y ponerla en un desensamblador como IDA:
El binario tiene una cadena codificada llamada “out_char” con el siguiente valor: eu>q5b0KPlLwyb@#j9?!ehjl(LHukkA(di^S4UXAChr3B`_xf+@h#S&wpfv&# . Al observar el código, el método getKeyForPassword recibe como argumento el valor largo de getPartialString(getAndroidID()), manteniendo como variable la cadena out_char y pasa ambas a la subrutina ‘mealymachine’. Veamos la función getKeyForPassword y la subrutina mealymachine en pseudocódigo: function Java_com_sec_knox_store_SecurityManager_SecureKeyLoader_getKeyForPassword { r4 = r0; //partialString androidID como valor largo r0 = r2; //entero = 16 r0 = mealymachine(r0, var_8, next, “eu>q5b0KPlLwyb@#j9?!ehjl(LHukkA(di^S4UXAChr3B_xf+@h*#S&wpfv&#”, STK29);* *r3 = *r4;* *r2 = *(r3 + 0x29c);* *r0 = (r2)(r4, r0, r2, r3);* *return r0;* *}* *function mealymachine {* *r6 = r0; //partialString androidID como valor largo* *r5 = r1; //var_8* *r7 = r2; //next* *r8 = r3; //eu>q5b0KPlLwyb@*#j9?!*ehjl(LHukkA(di^S4UXAChr3B_xf+@h#S&wpfv&#
if (r1 <= 0x64) {
r4 = 0x0;
memset@PLT(0x2144, 0x0, 0x64);
r1 = r4;
do {
if (r4 >= r5) {
break;
}
r0 = r6 & 0x1;
r6 = r6 >> 0x1;
(int8_t )(r4 + 0x2144) = (int8_t )(r0 + r8 + r1); //AndroidID + eu>q5b0KPlLwyb@#j9?!ehjl(LHukkA(di^S4UXAChr3B`_xf+@h#S&wpfv&# + var_8 r4 = r4 + 0x1; r1 = (r0 0x4 + r7 + r1); } while (true); r0 = 0x2144;* (int8_t )(r0 + (r5 & !r5)) = 0x0;
return r0;
}
else {
r0 = 0x0;
return r0;
} return r0; } Al observar la subrutina, simplemente suma el valor largo del ID de Android y la cadena codificada. El método getPartialString resta una parte del ID de Android. Solo para aclarar: cada aplicación puede pedir al sistema el ID de Android llamando: Secure.getString(getContext().getContentResolver(),Secure.ANDROID_ID);*

En conclusión, Ares señala que Samsung Knox no es tan seguro como se indica.

Samsung realmente intentó ocultar la funcionalidad para generar la clave, siguiendo la regla de seguridad por oscuridad. Al final, solo utiliza el ID de Android junto con una cadena codificada y los mezcla para la clave de encriptación. Esperaría de un producto llamado Knox un enfoque diferente:
La clave debería derivarse de una Función de Derivación de Clave Basada en Contraseña 2 (PBKDF2) que genera una clave mucho más fuerte con más aleatoriedad.
El hecho de que estén persistiendo la clave solo para la funcionalidad de pista de contraseña compromete completamente la seguridad de ese producto. Para tal producto, la contraseña nunca debería almacenarse en el dispositivo. No hay necesidad de ello, solo si olvidas tu contraseña. Pero entonces tus datos deberían perderse, de lo contrario no están seguros si hay algún tipo de opción de recuperación.

Recomendación de Ares

En lugar de Samsung Knox, utiliza la función de encriptación integrada de Android y encripta todo el dispositivo. Android utiliza una función PBKDF2 a partir de la contraseña de encriptación que elijas y nunca la persiste en el dispositivo. Obviamente, nunca podrás acceder a los datos si olvidas tu contraseña, pero ese es el punto de una buena encriptación.

*Recurso: Mobile Security Blog