Samsung Knox von der US-Regierung für die Klassifizierung genehmigt, aber ist es wirklich sicher?

Table Of Contents

• Samsung Knox validiert und genehmigt für die Klassifizierung der US-Regierung
• Bedeutet das, dass Samsung Knox der sicherste Weg ist, wichtige und persönliche Bilder/Videos/Dokumente zu speichern
• Wie ist Samsung Knox anfällig
• Zusammenfassend weist Ares darauf hin, dass Samsung Knox nicht so sicher ist, wie es dargestellt wird.
• Empfehlung von Ares

Samsung Knox validiert und genehmigt für die Klassifizierung der US-Regierung

Samsung Electronics gab bekannt, dass seine Lösungen von der US-Regierung als die ersten NIAP-validierten mobilen Endgeräte genehmigt wurden, die in der Lage sind, die gesamte Bandbreite klassifizierter Informationen zu verarbeiten. Nach Abschluss von zehn Memoranda of Agreements (MOAs) fügte die Regierung die Galaxy S4, Galaxy S5, Galaxy Note 3, Galaxy Note 4, Galaxy Note 10.1 (2014 Edition), Galaxy Note Edge, Galaxy Alpha, Galaxy Tab S 8.4, Galaxy Tab S 10.5 und den Galaxy IPSEC Virtual Private Network (VPN) Client zur Liste der kommerziellen Lösungen für Klassifizierte (CSfC) Programme hinzu.

Dieser Erfolg ist das direkte Ergebnis von Samsungs erfolgreicher Prüfung und Zertifizierung im Rahmen der Common Criteria Mobile Device Fundamental Protection Profile (MDFPP) und VPN Protection Profile (VPNPP) Programme der US-Regierung. Die aufgeführten Samsung-Geräte sind für die Nutzung mit klassifizierten Regierungsnetzwerken und -daten verfügbar. Alle Geräte und Funktionen beinhalten Sicherheitsmerkmale, die von Samsung KNOX unterstützt werden.

Die eigene Beschreibung von Samsung für seinen Knox-Dienst weist ebenfalls auf dieselben Fakten hin

„KNOX Workspace-Container verbessert die Benutzererfahrung, indem er Sicherheit für Unternehmensdaten bietet, indem er eine sichere Zone im Gerät des Mitarbeiters für Unternehmensanwendungen schafft und Unternehmensdaten sowohl im Ruhezustand als auch in Bewegung verschlüsselt. Der KNOX Workspace-Container bietet den Benutzern eine isolierte und sichere Umgebung innerhalb des mobilen Geräts, komplett mit eigenem Startbildschirm, Launcher, Anwendungen und Widgets für eine einfachere, intuitivere und sichere Bedienung. Anwendungen und Daten innerhalb des Containers sind getrennt.“

Die DISA Approved Products List kann unter: https://www.disa.mil/Services/Network-Services/UCCO gefunden werden.

Bedeutet das, dass Samsung Knox der sicherste Weg ist, wichtige und persönliche Bilder/Videos/Dokumente zu speichern

Mit den fast täglichen Sicherheitsverletzungen und Hacks trägt ein Benutzer ernsthafte Risiken, persönliche Bilder/Dokumente oder Videos online in der Cloud zu speichern. Mit den iCloud-Hacks wurde bewiesen, dass selbst Prominente nicht vor Hacks sicher sind. Die SnapChat-Leaks bewiesen, dass Bilder von 13- bis 17-jährigen Kindern anfällig für solche Leaks waren. Die Dropbox-Leaks bewiesen, dass das Speichern in Dropbox ebenfalls ein relativ hohes Risiko mit sich bringt.

Was tun die Benutzer also mit ihren Bildern und Videos, die in diesen privaten Momenten aufgenommen wurden? Mit der Genehmigung der US-Regierung für die Klassifizierung wurde Samsung Knox zum ersten mobilen Gerät, das als sicher vor Hackern garantiert wurde, nicht weniger als von Big Sam selbst.

Mit unbegrenztem Speicherplatz (bis zu 64 GB) an Bord vieler Samsung-Produkte sind Sie in Bezug auf den Speicherplatz sicher, aber ist Samsung Knox wirklich das Fort Knox für die sichere Speicherung Ihrer privaten Dokumente/Bilder und Videos? Während die US-Regierung das denkt, denkt ein Sicherheitsforscher, Eingestellt von Ares, nicht so.

Tatsächlich hat Ares in seinem Blog demonstriert, warum Samsungs Knox anfällig und ziemlich leicht zu knacken ist.

Wie ist Samsung Knox anfällig

Ares hat in seinem Blog eine vollständige PoC über die Anfälligkeit gegeben, die hier wiedergegeben wird:

Das Samsung-Telefon wird mit zwei vorinstallierten Apps geliefert: Knox und Knox EMM. Knox EMM ist eine cloudbasierte Unternehmensmanagementlösung für mobile Geräte, die nicht Teil dieser Analyse war. Der Fokus lag auf der Knox-App, die den Knox-Container und einen separaten (sicheren) Startbildschirm mit eigenen Apps bereitstellt. Die Einrichtung von Knox ist ziemlich einfach, Sie müssen nur ein Passwort und eine PIN für die Knox-App festlegen. Wenn man sich die Systeminternas ansieht, installiert Knox ziemlich viele Dinge auf Ihrem Telefon. Knox-bezogene Apps 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
Zusätzlich befinden sich alle Apps, die im neuen Knox-Startbildschirm installiert sind, im Standard-App-Installationsordner /data/data/ und haben das Präfix: com.sec.. Alle hier aufzulisten, wäre zu viel. Nach einer typischen Knox-Installation sind 139 Apps und Dienste mit dem Präfix com.sec. installiert. Wenn man etwas tiefer ins System schaut, wird Knox im gesamten System verteilt und speichert Daten an mehreren verschiedenen Orten, zum Beispiel: der verschlüsselte Container selbst wird in /data/.container_ und /data/container/.sdcontainer_1 gespeichert.
Verschiedene Dateien und Datenbanken für Einstellungen werden in /data/system/secure_storage und /data/system/container gespeichert.
Jede Analyse einer mobilen App beginnt mit einer statischen Analyse der Dateien, die die App nach der Einrichtung gespeichert hat. Ein guter Ausgangspunkt für Android-Apps ist der App-Ordner unter /data/data/. Diese Ordner haben typischerweise die Struktur:
com.aPackageName
|- cache
|- databases
|- extracted
|- lib
|- shared_prefs
Insbesondere die Ordner databases und shared_prefs verdienen die erste Aufmerksamkeit. Die ContainerAgent-App von Knox (com.sec.knox.containeragent) hatte einige interessante Dateien gespeichert:
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
Ja, raten Sie mal, was in der pin.xml-Datei geschrieben steht? Die PIN, die wir während der Einrichtung von Knox im Klartext festlegen mussten!


123456789

Jetzt gibt Samsung Knox einem Benutzer maximal 20 Versuche für Benutzername und Passwort.

Die anderen Dateien enthüllten keine weiteren interessanten Dinge. Aber zurück zur pin.xml-Datei. Was ist überhaupt der Zweck der PIN in Knox? Wenn Sie Knox starten möchten, müssen Sie Ihr Passwort angeben, um Zugriff auf die Daten und den Knox-Startbildschirm zu erhalten. Aber es gibt einen kleinen Button unter dem Textfeld mit der Aufschrift „Passwort vergessen?“. Wenn Sie darauf tippen, müssen Sie Ihre PIN angeben. Wenn die PIN korrekt ist, zeigt die Knox-App Ihnen einen kleinen Passwort-Hinweis (das erste und das letzte Zeichen Ihres Passworts!! + die ursprüngliche Länge Ihres Passworts!). Es ist also ziemlich offensichtlich, dass Samsung Knox Ihr Passwort irgendwo auf dem Gerät speichern wird! Wie oben erwähnt, speichert Knox nicht nur Einstellungen in /data/data/, im Ordner /data/system/container gibt es eine Datei namens containerpassword_1.key [sic!] gespeichert. Der Inhalt ist ein verschlüsselter String: 72C9EE6D56CB15916A4CAB01814F978FA1E2689D (ich habe den String aus offensichtlichen Gründen modifiziert ;)).
Also sieht das nach einem AES-verschlüsselten String aus. Jetzt müssen wir die Apps dekompilieren, um einen tieferen Blick darauf zu werfen, wie genau die Verschlüsselung des Passworts funktioniert und woher der Schlüssel für die Verschlüsselung kommt. Samsung verwendet dex-preoptimization, um alle classes.dex-Dateien (der Java-Code wird in einer Datei namens classes.dex gespeichert und diese Datei wird von der Dalvik JVM geparst) in den Knox-APKs zu entfernen, wodurch das Reverse Engineering etwas schwieriger wird. Um die Binärdateien zu erhalten, müssen wir in /system/app/ nach .odex-Dateien suchen (ein odex ist im Grunde eine vorverarbeitete Version der classes.dex einer Anwendung, die bereit für die Ausführung in Dalvik ist). Odex-Dateien können wieder in Smali-Code umgewandelt werden, der dann wieder in eine dex-Datei umgewandelt werden kann. Schließlich kann eine dex-Datei in eine jar-Datei umgewandelt werden, die von jedem Java-Dekompilierer dekompiliert werden kann.
Samsung hat keine Code-Verschleierung verwendet, sondern wirklich versucht, den Code zur Passwortspeicherung innerhalb von Hunderten von Java-Klassen, Vererbung und Proxys zu verstecken. Schließlich wurde in der Knox Store-App der Proxy IDataService implementiert, den alle anderen Apps ständig aufriefen, wenn sie etwas Passwortbezogenes behandelten. Wenn das Passwort gespeichert wird, führt die App Folgendes aus:
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);
}
Schauen wir uns jede Zeile und die entsprechenden Methoden an:
public long getInputForKeyGenerate()
{
return Long.parseLong(SecureKeyLoader.getPartialString(getAndroidID()), 16);
}
private String getAndroidID()
{
return Settings.Secure.getString(this.mContext.getContentResolver(), “android_id”);
}
Also ist der Input für den Schlüssel offensichtlich die eindeutige Android-ID, die jedes Gerät hat. Die 16-Byte-ID, die als Long-Wert geparst wird, wird dann als Argument für die Funktion getKeyForPassword verwendet:
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 verschleiert es immer mehr, um die echte Schlüsselgenerierung zu verstecken. Die Methode getKeyForPassword befindet sich in einer in C geschriebenen Shared Library namens „mealy“. Lassen Sie uns die Bibliothek vom Gerät abrufen und in einen Disassembler wie IDA einfügen:
Die Binärdatei hat einen hardcodierten String namens „out_char“ mit folgendem Wert: eu>q5b0KPlLwyb@#j9?!ehjl(LHukkA(di^S4UXAChr3B`_xf+@h#S&wpfv&# . Wenn man sich den Code ansieht, erhält die Methode getKeyForPassword als Argument den langen Wert von getPartialString(getAndroidID()), der als Variable den out_char-String hält und beide an die Unterroutine „mealymachine“ übergibt. Lassen Sie uns einen Blick auf die Funktion getKeyForPassword und die Unterroutine mealymachine im Pseudocode werfen: function Java_com_sec_knox_store_SecurityManager_SecureKeyLoader_getKeyForPassword { r4 = r0; //partialString androidID als long-Wert r0 = r2; //integer = 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 als long-Wert* *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; } Wenn man sich die Unterroutine ansieht, fügt sie einfach den langen Wert von der Android-ID und den hardcodierten String hinzu. Die Methode getPartialString subtrahiert einen Teil aus der Android-ID. Nur zur Klarstellung: Jede App kann das System nach der Android-ID fragen, indem sie aufruft: Secure.getString(getContext().getContentResolver(),Secure.ANDROID_ID);*

Zusammenfassend weist Ares darauf hin, dass Samsung Knox nicht so sicher ist, wie es dargestellt wird.

Samsung hat wirklich versucht, die Funktionalität zur Generierung des Schlüssels zu verbergen, indem es dem Sicherheitsprinzip der Verschleierung folgt. Am Ende verwendet es einfach die Android-ID zusammen mit einem hardcodierten String und mischt sie für den Verschlüsselungsschlüssel. Ich hätte von einem Produkt, das Knox heißt, einen anderen Ansatz erwartet:

Der Schlüssel sollte aus einer Password-Based Key Derivation Function 2 (PBKDF2) abgeleitet werden, die einen viel stärkeren Schlüssel mit mehr Zufälligkeit erzeugt.
Die Tatsache, dass sie den Schlüssel nur für die Funktionalität des Passwort-Hinweises speichern, gefährdet die Sicherheit dieses Produkts vollständig. Für ein solches Produkt sollte das Passwort niemals auf dem Gerät gespeichert werden. Es gibt keinen Grund dafür, es sei denn, Sie vergessen Ihr Passwort. Aber dann sollten Ihre Daten verloren gehen, andernfalls sind sie nicht sicher, wenn es eine Art von Wiederherstellungsoption gibt.

Empfehlung von Ares

Anstelle von Samsung Knox verwenden Sie die integrierte Android-Verschlüsselungsfunktion und verschlüsseln Sie das gesamte Gerät. Android verwendet eine PBKDF2-Funktion aus dem von Ihnen gewählten Verschlüsselungs-Passwort und speichert es niemals auf dem Gerät. Offensichtlich können Sie niemals auf die Daten zugreifen, wenn Sie Ihr Passwort vergessen, aber das ist der Sinn einer guten Verschlüsselung.

*Ressource: Mobile Security Blog