Awesome Open Source
Awesome Open Source

SecureApp

Demo-Applikation fr Android fr Pentester, Entwickler und jeden, der Interesse an Application-Security hat!


Die SecureApp ist auf Basis meiner Bachelorarbeit entstanden. In dieser wurden die wichtigsten Techniken zur Vermeidung von Sicherheitslcken in modernen Android-Apps untersucht und voneinander abgegrenzt.

Die Applikation beinhaltet technische Lsungen zu bestimmten Sicherheitslcken, bezogen auf die OWASP Mobile Top10 Risks.


Download der APK

https://github.com/MaHo1194/secure_app/releases/tag/v1.0

Backend

Der Quellcode des Backends kann hier eingesehen werden:

https://awesomeopensource.com/project/MaHo1194/secure_app_backend


Installation

Am besten lsst sich die SecureApp auf einem Android-Emulator ausfhren, beispielsweise Genymotion: https://www.genymotion.com/


Anleitung zum Testen der einzelnen Schwachstellen

Lokale Datenspeicherung

Die SecureApp impelementiert die lokale Datenspeicherung, in Form der EncryptedSharedPreferences und einer SQLite-Datenbank, welche mit Hilfe von SQL-Cipher verschlsselt wird.

EncryptedSharedPreferences

Die Speicherung in den EncryptedSharedPreferences lsst sich testen, indem im Eingabefenster ein beliebiger String bergeben wird. Dieser wird hier gespeichert: /data/data/shared_prefs/encrypted_shared_prefs.xml. Der String ist nicht im Klartext vorhanden, sondern wurde mit dem AES256-Algorithmus verschlsselt. Zur Kontrolle wird der String im unteren Fenster ausgegeben.

Um die Datei zu ffnen, muss in der ADB-Shell folgender Befehl abgesetzt werden:

adb pull /data/data/com.example.secure_app/shared_prefs/encrypted_shared_prefs.xml <Zielpfad>

Anschlieend kann die XML-Datei beispielsweise mit Notepad++ geffnet werden.


Verschlsselte SQLite-Datenbank

Bei der Erstbenutzung muss ein Passwort ausgewhlt werden. Dieses wird lokal in den EncryptedSharedPreferneces gespeichert. Anschlieend kann die Datenbank geffnet werden. Diese Datenbank ermglicht das Speichern von E-Mail-Adressen. Nachdem ein Passwort gesetzt und die Datenbank verlassen wurde, kann mit dem Passwort die Datenbank erneut geffnet werden.

Um die Verschlsselung der Datenbank zu testen, muss in der ADB-Shell folgender Befehl abgesetzt werden:

adb pull /data/data/databases/com.example.secure_app/encrypted_database.db <Zielpfad>

Anschlieend kann die Datenbank mit dem DB-Browser und dem Passwort geffnet werden.


Verschlsselte Backend-Kommunikation

Das Backend stellt einen ffentlichen API-Endpunkt zur Verfgung, welcher die aktuelle Serverzeit bermittelt. Die Verschlsselung geschieht hier ber TLSv1.3. Einsehbar ist das ganze zum einen ber die Burp-Suite oder auch Wireshark. Die Daten werden verschlsselt bertragen.

Zum Testen mit Wireshark, den Filter auf

ip.addr == 193.174.71.211

setzen. Dies ist die IP-Adresse des Backends. Anschlieend eine Anfrage an das Backend senden.

Danach ist in Wireshark eine Verschlsselte Verbindung sichtbar.


Authentifizierung mit JWT

Neben dem ffentlichen API-Endpunkt, stellt das Backend auch einen privaten API-Endpunkt zur Verfgung. Dieser wird mit Hilfe von JSON Web Tokens abgesichert. Um das ganze zu testen, kann sich in der SecureApp registriert werden. Nach erfolgreicher Registrierung und erfolgreichem Login, kann nachfolgend auf den privaten API-Endpunkt zugegriffen werden und eine Hello World-Message sollte erscheinen.

Wird kein AccessToken im Header mitgeliefert, erscheint folgender Error.

Die SecureApp erhlt seinen AccessToken von Auth0.com. Bevor die API aufgerufen werden kann, muss in der Applikation die bergabe des Authorization Headers gewhrleistet sein. Genutzt wird Volley. Dies geschieht wie folgt:

public Map<String, String> getHeaders() throws AuthFailureError {
  Map<String, String> headerMap = new HashMap<String, String>();
  headerMap.put("Content-Type", "application/json");
  headerMap.put("Authorization", "Bearer " + ACCESS_TOKEN);
  return headerMap;
 }

Client Side Injection / SQLite-Injection

Neben der verschlsselten Datenbank, besitzt die SecureApp eine weitere Datenbank, welche speziell zum Testen von SQLite-Injections implementiert wurde. Diese ist unverschlsselt, damit trotz SQLi-Gegenmanahmen die Datenbank eingesehen werden kann. Als Payloads knnen beispielsweise Folgende verwendet werden:

    - admin' or '1'='1
    - a'or'1'='1

Der Insert-Into-Befehl wurde wie folgt implementiert:

String SQL = "INSERT INTO sqliuser(user, password, phone_number) VALUES (?, ?, ?)";
mDB = openOrCreateDatabase("sqli", MODE_PRIVATE, null);
mDB.execSQL("DROP TABLE IF EXISTS sqliuser;");
mDB.execSQL("CREATE TABLE IF NOT EXISTS sqliuser(user VARCHAR, password VARCHAR, phone_number VARCHAR);");

SQLiteStatement statement = mDB.compileStatement(SQL);
statement.bindString(1, "admin");
statement.bindString(2, "passwd123");
statement.bindString(3, "0123456789");
statement.executeInsert();

Der Select-Befehl so:

String SQL = "select * from sqliuser where user = ?";

Cursor cursor = mDB.rawQuery(SQL, new String[]{srchtxt.getText().toString()});
StringBuilder strb = new StringBuilder("");

Dadurch werden Eingaben in das Suchfeld direkt als Parameter geparst.


Get A Weekly Email With Trending Projects For These Topics
No Spam. Unsubscribe easily at any time.
Java (710,532
Kotlin (60,055
Android (41,173
Related Projects