Samsung Knox approvato dal governo degli Stati Uniti per uso classificato, ma è davvero sicuro?

Table Of Contents

• Samsung Knox convalidato e approvato per uso classificato dal governo degli Stati Uniti
• Significa che Samsung Knox è il modo più sicuro per memorizzare immagini / video / documenti importanti e personali
• Come è vulnerabile Samsung Knox
• In conclusione Ares sottolinea che Samsung Knox non è sicuro come viene descritto.
• Raccomandazione di Ares

Samsung Knox convalidato e approvato per uso classificato dal governo degli Stati Uniti

Samsung Electronics ha annunciato che le sue soluzioni sono state approvate dal governo degli Stati Uniti come i primi dispositivi mobili di consumo convalidati NIAP in grado di gestire l’intera gamma di informazioni classificate. Dopo aver completato dieci Memorandum di Intesa (MOA), il governo ha aggiunto il Galaxy S4, Galaxy S5, Galaxy Note 3, Galaxy Note 4, Galaxy Note 10.1 (Edizione 2014), Galaxy Note Edge, Galaxy Alpha, Galaxy Tab S 8.4, Galaxy Tab S 10.5 e il Galaxy IPSEC Virtual Private Network (VPN) Client all’elenco dei componenti del Programma Commercial Solutions for Classified (CSfC).

Questo risultato è il diretto risultato dei test e della certificazione di successo di Samsung sotto i programmi di protezione fondamentale per dispositivi mobili Common Criteria (MDFPP) e VPN Protection Profile (VPNPP) del governo degli Stati Uniti. I dispositivi Samsung elencati sono disponibili per l’uso con reti e dati governativi classificati. Tutti i dispositivi e le capacità incorporano funzionalità di sicurezza alimentate da Samsung KNOX.

La descrizione di Samsung del suo servizio Knox sottolinea anche gli stessi fatti

“Il contenitore KNOX Workspace migliora l’esperienza dell’utente, fornendo sicurezza per i dati aziendali creando una zona sicura nel dispositivo dell’impiegato per le applicazioni aziendali e crittografando i dati aziendali sia a riposo che in movimento. Il contenitore KNOX Workspace fornisce agli utenti un ambiente isolato e sicuro all’interno del dispositivo mobile, completo di una propria schermata iniziale, launcher, applicazioni e widget per un’operazione più semplice, intuitiva e sicura. Le applicazioni e i dati all’interno del contenitore sono separati.”

L’elenco dei prodotti approvati DISA può essere trovato su: https://www.disa.mil/Services/Network-Services/UCCO.

Significa che Samsung Knox è il modo più sicuro per memorizzare immagini / video / documenti importanti e personali

Con le violazioni e gli attacchi che si verificano quasi ogni giorno, un utente affronta seri rischi nel salvare immagini / documenti o video personali online nel cloud. Con gli hack di iCloud è stato dimostrato che anche le celebrità non sono al sicuro dagli attacchi. Le perdite di SnapChat hanno dimostrato che le immagini di ragazzi di età compresa tra 13 e 17 anni erano vulnerabili a tali perdite. Le perdite di Dropbox hanno dimostrato che salvare su Dropbox comporta anche un rischio relativamente alto.

Quindi cosa fanno gli utenti con le loro immagini e video catturati in quei momenti privati? Con l’approvazione del governo degli Stati Uniti per uso classificato, Samsung Knox è diventato il primo dispositivo mobile garantito come sicuro dagli hacker, non meno che dal Grande Sam stesso.

Con una capacità di archiviazione illimitata (fino a 64 GB) a bordo di molti dei prodotti Samsung, sei al sicuro per quanto riguarda lo spazio, ma è davvero Samsung Knox il Fort Knox per memorizzare i tuoi documenti / immagini e video privati in modo sicuro? Mentre il governo degli Stati Uniti lo pensa, un ricercatore di sicurezza, Eingestellt da Ares, non la pensa così.

Infatti Ares ha dimostrato sul suo blog perché Samsung Knox è vulnerabile e anche piuttosto facilmente.

Come è vulnerabile Samsung Knox

Ares ha fornito un PoC completo sulla vulnerabilità sul suo blog, che è riprodotto qui:

Il telefono Samsung viene fornito preinstallato con due app: Knox e Knox EMM. Knox EMM è una soluzione di gestione basata su cloud per dispositivi mobili che non faceva parte di questa analisi. L’attenzione è stata posta sull’app Knox, che fornisce il contenitore Knox e una schermata iniziale separata (sicura) con proprie app. La configurazione per Knox è piuttosto semplice, devi solo impostare una password e un pin per l’app Knox. Guardando gli interni del sistema, Knox installa un sacco di cose sul tuo telefono. App correlate a Knox in /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 Inoltre, tutte le app installate nella nuova schermata iniziale di Knox si trovano nella cartella di installazione standard delle app /data/data/ e hanno il prefisso: com.sec.. Elencarle tutte qui sarebbe troppo. Dopo un tipico installazione di Knox ci sono 139 app e servizi installati con il prefisso com.sec.* Guardando un po’ più a fondo nel sistema, Knox è distribuito in tutto il sistema e memorizza dati in un paio di posizioni diverse, ad esempio: il contenitore crittografato stesso sarà memorizzato in /data/.container_ e/data/container/.sdcontainer_1. Diversi file e database per le impostazioni sono memorizzati in /data/system/secure_storage e /data/system/container. Ogni analisi di un’app mobile inizia con un’analisi statica dei file che l’app ha memorizzato dopo la configurazione. Un buon punto di partenza per le app Android è la cartella dell’app sotto /data/data/. Queste cartelle hanno tipicamente la struttura: com.aPackageName |- cache |- databases |- extracted |- lib |- shared_prefs In particolare, le cartelle databases e shared_prefs sono quelle che meritano la prima attenzione. L’app ContainerAgent di Knox (com.sec.knox.containeragent) aveva alcuni file interessanti memorizzati: 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ì, indovina cosa è scritto nel file pin.xml? Il pin che abbiamo dovuto impostare durante la configurazione di Knox in chiaro! Ora Samsung Knox dà all’utente un massimo di 20 tentativi per nome utente e password.*

**

Gli altri file non hanno rivelato altre cose interessanti. Ma torniamo al file pin.xml. Qual è lo scopo del pin in Knox? Se stai per avviare Knox devi fornire la tua password per accedere ai dati e alla schermata iniziale di Knox. Ma c’è un piccolo pulsante sotto il campo di testo chiamato “Password dimenticata?”. Toccandolo, devi fornire il tuo pin. Se il PIN è corretto, l’app Knox ti mostrerà un piccolo suggerimento per la password (il primo e l’ultimo carattere della tua password!! + la lunghezza originale della tua password!). Quindi ora è abbastanza ovvio che Samsung Knox andrà a memorizzare la tua password da qualche parte sul dispositivo! Come accennato in precedenza, Knox non memorizza solo impostazioni in /data/data/, nella cartella /data/system/container c’è un file chiamato containerpassword_1.key [sic!] memorizzato. Il contenuto è una stringa crittografata: 72C9EE6D56CB15916A4CAB01814F978FA1E2689D (ho modificato la stringa per ovvi motivi ;)). Quindi sembra una stringa crittografata AES. Ora dobbiamo decompilare le app per dare un’occhiata più da vicino a come funziona esattamente la crittografia della password e da dove proviene la chiave per la crittografia. Samsung utilizza la dex-preottimizzazione per rimuovere tutti i file classes.dex (il codice java è memorizzato in un file chiamato classes.dex e questo file viene analizzato dalla Dalvik JVM) negli apk di Knox, rendendo così l’ingegneria inversa un po’ più difficile. Per ottenere i binari dobbiamo guardare in /system/app/ e trovare i file .odex (un odex è fondamentalmente una versione pre-elaborata delle classi.dex di un’applicazione che è pronta per l’esecuzione per Dalvik). I file odex possono essere convertiti di nuovo in codice smali, che può poi essere convertito di nuovo in un file dex. Infine, un file dex può essere convertito in un file jar, che può essere decompilato da qualsiasi decompilatore Java. Samsung non ha fatto uso di offuscamento del codice, ma ha davvero cercato di nascondere il codice di memorizzazione della password all’interno di centinaia di classi java, ereditarietà e proxy. Infine, nell’app Knox Store è stato implementato il proxy IDataService che tutte le altre app chiamavano costantemente quando gestivano qualcosa relativo alla password. Quindi, quando si salva la password, l’app fa quanto segue:
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);
}
Esaminiamo ogni riga e i metodi corrispondenti:
public long getInputForKeyGenerate()
{
return Long.parseLong(SecureKeyLoader.getPartialString(getAndroidID()), 16);
}
private String getAndroidID()
{
return Settings.Secure.getString(this.mContext.getContentResolver(), “android_id”);
}
Quindi, l’input per la chiave è ovviamente l’ID Android unico che ogni dispositivo ha. L’ID a 16 byte analizzato come valore Long viene quindi utilizzato come argomento per la funzione 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 sta offuscando sempre di più per nascondere la vera generazione della chiave. Il metodo getKeyForPassword è collocato in una libreria condivisa scritta in C chiamata “mealy”. Prendiamo la libreria dal dispositivo e mettiamola in un disassemblatore come IDA:
Il binario ha una stringa hardcoded chiamata “out_char” con il seguente valore: eu>q5b0KPlLwyb@#j9?!ehjl(LHukkA(di^S4UXAChr3B`_xf+@h#S&wpfv&# . Guardando il codice, il metodo getKeyForPassword riceve come argomento il valore long di getPartialString(getAndroidID()), tenendo come variabile la stringa out_char e passa entrambi a una subroutine ‘mealymachine’. Diamo un’occhiata alla funzione getKeyForPassword e alla subroutine mealymachine in pseudo codice: function Java_com_sec_knox_store_SecurityManager_SecureKeyLoader_getKeyForPassword { r4 = r0; //partialString androidID come valore long r0 = r2; //intero = 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 come valore long* *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; } Guardando la subroutine, aggiunge semplicemente il valore long dell’ID Android e la stringa hardcoded. Il metodo getPartialString sottrae una parte dall’ID Android. Solo per chiarire: ogni app può chiedere al sistema per l’ID Android chiamando: Secure.getString(getContext().getContentResolver(),Secure.ANDROID_ID);*

In conclusione Ares sottolinea che Samsung Knox non è sicuro come viene descritto.

Samsung ha davvero cercato di nascondere la funzionalità per generare la chiave, seguendo la regola della sicurezza per oscurità. Alla fine utilizza semplicemente l’ID Android insieme a una stringa hardcoded e li mescola per la chiave di crittografia. Mi sarei aspettato da un prodotto chiamato Knox un approccio diverso:

La chiave dovrebbe essere derivata da una Password-Based Key Derivation Function 2(PBKDF2) che genera una chiave molto più forte con maggiore casualità.
Il fatto che stiano persistendo la chiave solo per la funzionalità di suggerimento della password compromette completamente la sicurezza di quel prodotto. Per un prodotto del genere, la password non dovrebbe mai essere memorizzata sul dispositivo. Non c’è bisogno, solo se dimentichi la tua password. Ma allora i tuoi dati dovrebbero andare persi, altrimenti non sono al sicuro se c’è qualche tipo di opzione di recupero.

Raccomandazione di Ares

Invece di Samsung Knox, utilizza la funzione di crittografia integrata di Android e crittografa l’intero dispositivo. Android utilizza una funzione PBKDF2 dalla password di crittografia che scegli e non la memorizza mai sul dispositivo. Ovviamente non puoi mai accedere ai dati se dimentichi la tua password, ma questo è il punto di una buona crittografia.

*Risorsa: Mobile Security Blog