Samsung Knox aprovado pelo governo dos EUA para uso classificado, mas é realmente seguro?

Table Of Contents

• Samsung Knox Validado e Aprovado Para Uso Classificado do Governo dos EUA
• Isso significa que o Samsung Knox é a maneira mais segura de armazenar imagens / vídeos / documentos importantes e pessoais?
• Como o Samsung Knox é vulnerável
• Em conclusão, Ares aponta que o Samsung Knox não é tão seguro quanto se afirma.
• Recomendação de Ares

Samsung Knox Validado e Aprovado Para Uso Classificado do Governo dos EUA

Samsung Electronics anunciou que suas soluções foram aprovadas pelo governo dos Estados Unidos como os primeiros dispositivos móveis de consumo validados pelo NIAP para lidar com toda a gama de informações classificadas. Após a conclusão de dez Memorandos de Acordo (MOAs), o governo adicionou o Galaxy S4, Galaxy S5, Galaxy Note 3, Galaxy Note 4, Galaxy Note 10.1 (Edição de 2014), Galaxy Note Edge, Galaxy Alpha, Galaxy Tab S 8.4, Galaxy Tab S 10.5 e o Cliente de Rede Privada Virtual (VPN) Galaxy IPSEC à Lista de Componentes do Programa de Soluções Comerciais para Classificados (CSfC).

Essa conquista é o resultado direto dos testes e certificações bem-sucedidos da Samsung sob os programas de Perfil de Proteção Fundamental de Dispositivos Móveis (MDFPP) e Perfil de Proteção VPN (VPNPP) do governo dos EUA. Os dispositivos Samsung listados estão disponíveis para uso com redes e dados governamentais classificados. Todos os dispositivos e capacidades incorporam recursos de segurança alimentados pelo Samsung KNOX.

A própria descrição da Samsung sobre seu serviço Knox também aponta para os mesmos fatos

“O contêiner KNOX Workspace melhora a experiência do usuário, proporcionando segurança para dados empresariais ao criar uma zona segura no dispositivo do funcionário para aplicativos corporativos, e criptografando dados empresariais tanto em repouso quanto em movimento. O contêiner KNOX Workspace fornece aos usuários um ambiente isolado e seguro dentro do dispositivo móvel, completo com sua própria tela inicial, lançador, aplicativos e widgets para operação mais fácil, intuitiva e segura. Aplicativos e dados dentro do contêiner são separados.”

A Lista de Produtos Aprovados pela DISA pode ser encontrada em: https://www.disa.mil/Services/Network-Services/UCCO.

Isso significa que o Samsung Knox é a maneira mais segura de armazenar imagens / vídeos / documentos importantes e pessoais?

Com as violações e hacks ocorrendo quase todos os dias, um usuário enfrenta sérios riscos ao salvar imagens / documentos ou vídeos pessoais online nas nuvens. Com os Hacks do iCloud, foi provado que até mesmo celebridades não estão seguras de hacking. Os vazamentos do SnapChat provaram que imagens de crianças de 13 a 17 anos eram propensas a serem vulneráveis a tais vazamentos. Os vazamentos do Dropbox provaram que salvar no Dropbox também envolve um risco relativamente alto.

Então, o que os usuários fazem com suas imagens e vídeos tirados nesses momentos privados? Com a aprovação do governo dos EUA para uso classificado, o Samsung Knox se tornou o primeiro dispositivo móvel a ser garantido como seguro contra hackers, nada menos que pelo próprio Big Sam.

Com capacidade de armazenamento ilimitado (até 64GB) a bordo de muitos dos produtos Samsung, você está seguro na opção de espaço, mas o Samsung Knox é realmente o Fort Knox de armazenar seus documentos / imagens e vídeos privados de forma segura? Enquanto o governo dos EUA pensa que sim, um pesquisador de segurança, Einstellt von Ares, não pensa assim.

Na verdade, Ares demonstrou em seu blog por que o Knox da Samsung é vulnerável e de forma bastante fácil também.

Como o Samsung Knox é vulnerável

Ares forneceu um PoC completo sobre a vulnerabilidade em seu blog, que é reproduzido aqui :

O telefone Samsung vem pré-instalado com dois aplicativos: Knox e Knox EMM. O Knox EMM é uma solução de gerenciamento em nuvem baseada em empresa para dispositivos móveis que não fazia parte desta análise. O foco foi definido no aplicativo Knox, que fornece o Contêiner Knox e uma tela inicial (segura) separada com seus próprios aplicativos. A configuração do Knox é bastante fácil, você só precisa definir uma senha e um PIN para o aplicativo Knox. Olhando para os internos do sistema, o Knox instala muitas coisas no seu telefone. Aplicativos relacionados ao Knox em /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 Além disso, todos os aplicativos que estão instalados na nova tela inicial do Knox estão localizados na pasta de instalação de aplicativos padrão /data/data/ e vêm com o prefixo: com.sec.. Listar todos eles aqui seria demais. Após uma instalação típica do Knox, há 139 aplicativos e serviços instalados com o prefixo com.sec.* Olhando um pouco mais fundo no sistema, o Knox é distribuído por todo o sistema e armazena dados em alguns locais diferentes, por exemplo: o contêiner criptografado em si será armazenado em /data/.container_ e/data/container/.sdcontainer_1. Diferentes arquivos e bancos de dados para configurações são armazenados em /data/system/secure_storage e /data/system/container. Cada análise de um aplicativo móvel começa com uma análise estática dos arquivos que o aplicativo armazenou após a configuração. Um bom ponto de partida para aplicativos Android é a pasta do aplicativo em /data/data/. Essas pastas geralmente têm a estrutura: com.aPackageName |- cache |- databases |- extracted |- lib |- shared_prefs Especialmente as pastas databases e shared_prefs são as que merecem a primeira atenção. O aplicativo ContainerAgent do Knox (com.sec.knox.containeragent) tinha alguns arquivos interessantes armazenados: 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 Sim, adivinha o que está escrito no arquivo pin.xml? O PIN que tivemos que definir durante a configuração do Knox em texto claro! Agora o Samsung Knox dá ao usuário um máximo de 20 tentativas para nome de usuário e senha.*

Os outros arquivos não revelaram outras coisas interessantes. Mas voltando ao arquivo pin.xml. Qual é o propósito do PIN no Knox, afinal? Se você vai iniciar o Knox, precisa fornecer sua senha para acessar os dados e a tela inicial do Knox. Mas há um pequeno botão sob o campo de texto chamado “Senha esquecida?”. Ao tocá-lo, você deve fornecer seu PIN. Se o PIN estiver correto, o aplicativo Knox mostrará uma pequena dica de senha (o primeiro e o último caractere da sua senha!! + o comprimento original da sua senha!). Então agora é bastante óbvio que o Samsung Knox vai armazenar sua senha em algum lugar no dispositivo! Como mencionado acima, o Knox não está apenas armazenando configurações em /data/data/, na pasta /data/system/container há um arquivo chamado containerpassword_1.key [sic!] armazenado. O conteúdo é uma string criptografada: 72C9EE6D56CB15916A4CAB01814F978FA1E2689D (modifiquei a string por razões óbvias ;)). Então isso parece uma string criptografada em AES. Agora precisamos descompilar os aplicativos para ter uma visão mais profunda de como exatamente a criptografia da senha funciona e de onde vem a chave para a criptografia. A Samsung faz uso da dex-preoptimization para remover todos os arquivos classes.dex (o código java é armazenado em um arquivo chamado classes.dex e este arquivo é analisado pela JVM Dalvik) nos apks do Knox, tornando assim a engenharia reversa um pouco mais difícil. Para obter os binários, precisamos olhar em /system/app/ e encontrar arquivos .odex (um odex é basicamente uma versão pré-processada das classes.dex de um aplicativo que está pronta para execução no Dalvik). Arquivos odex podem ser convertidos de volta em código smali, que então pode ser convertido de volta em um arquivo dex. Finalmente, um arquivo dex pode ser convertido em um arquivo jar, que pode ser descompilado por qualquer Descompilador Java. A Samsung não fez uso de ofuscação de código, mas realmente tentou esconder o código de armazenamento da senha dentro de centenas de classes java, heranças e proxies. Finalmente, no aplicativo Knox Store, o proxy IDataService foi implementado, que todos os outros aplicativos estavam chamando constantemente ao lidar com algo relacionado à senha. Então, ao salvar a senha, o aplicativo faz o seguinte:
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);
}
Vamos dar uma olhada em cada linha e nos métodos correspondentes:
public long getInputForKeyGenerate()
{
return Long.parseLong(SecureKeyLoader.getPartialString(getAndroidID()), 16);
}
private String getAndroidID()
{
return Settings.Secure.getString(this.mContext.getContentResolver(), “android_id”);
}
Então, a entrada para a chave é obviamente o ID Android único que cada dispositivo possui. O ID de 16 bytes analisado como valor Long é então usado como argumento para a função 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, a Samsung está ofuscando cada vez mais para esconder a verdadeira geração da chave. O método getKeyForPassword está colocado em uma biblioteca compartilhada escrita em C chamada “mealy”. Vamos pegar a biblioteca do dispositivo e colocá-la em um desassemblador como IDA:
O binário tem uma string hardcoded chamada “out_char” com o seguinte valor: eu>q5b0KPlLwyb@#j9?!ehjl(LHukkA(di^S4UXAChr3B`_xf+@h#S&wpfv&# . Ao olhar para o código, o método getKeyForPassword recebe como argumento o valor longo de getPartialString(getAndroidID()), segurando como variável a string out_char e passa ambas para a sub-rotina ‘mealymachine’. Vamos dar uma olhada na função getKeyForPassword e na sub-rotina mealymachine em pseudocódigo: function Java_com_sec_knox_store_SecurityManager_SecureKeyLoader_getKeyForPassword { r4 = r0; //partialString androidID como valor longo r0 = r2; //inteiro = 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 longo* *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; } Ao olhar para a sub-rotina, ela apenas adiciona o valor longo do ID Android e a string hardcoded. O método getPartialString subtrai uma parte do ID Android. Apenas para esclarecimento: cada aplicativo pode pedir ao sistema pelo ID Android chamando: Secure.getString(getContext().getContentResolver(),Secure.ANDROID_ID);*

Em conclusão, Ares aponta que o Samsung Knox não é tão seguro quanto se afirma.

A Samsung realmente tentou esconder a funcionalidade de gerar a chave, seguindo a regra de segurança pela obscuridade. No final, ela apenas usa o ID Android junto com uma string hardcoded e mistura-os para a chave de criptografia. Eu esperaria de um produto chamado Knox uma abordagem diferente:
A chave deveria ser derivada de uma Função de Derivação de Chave Baseada em Senha 2 (PBKDF2) que gera uma chave muito mais forte com mais aleatoriedade.
O fato de que eles estão persistindo a chave apenas para a funcionalidade de dica de senha compromete completamente a segurança desse produto. Para um produto desse tipo, a senha nunca deveria ser armazenada no dispositivo. Não há necessidade disso, apenas se você esquecer sua senha. Mas então seus dados deveriam ser perdidos, caso contrário, eles não estão seguros se houver algum tipo de opção de recuperação.

Recomendação de Ares

Em vez do Samsung Knox, use a função de criptografia embutida do Android e criptografe todo o dispositivo. O Android usa uma função PBKDF2 a partir da senha de criptografia que você escolhe e nunca persiste isso no dispositivo. Obviamente, você nunca pode acessar os dados se esquecer sua senha, mas esse é o ponto de uma boa criptografia.

*Recurso: Mobile Security Blog