Android-Anwendungen Pentesting

Reading time: 39 minutes

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Grundlagen von Android-Anwendungen

Es wird dringend empfohlen, diese Seite zuerst zu lesen, um die wichtigsten Teile im Zusammenhang mit Android-Sicherheit und die gefährlichsten Komponenten in einer Android-Anwendung zu kennen:

Android Applications Basics

ADB (Android Debug Bridge)

Dies ist das Haupttool, das Sie benötigen, um eine Verbindung zu einem Android-Gerät (emuliert oder physisch) herzustellen.
ADB ermöglicht die Steuerung von Geräten entweder über USB oder Network von einem Computer aus. Dieses Dienstprogramm erlaubt das Kopieren von Dateien in beide Richtungen, die Installation und Deinstallation von Apps, die Ausführung von Shell-Befehlen, das Sichern von Daten, das Lesen von Logs, neben anderen Funktionen.

Schauen Sie sich die folgende Liste der ADB Commands an, um zu lernen, wie man adb verwendet.

Smali

Manchmal ist es interessant, den Anwendungscode zu modifizieren, um auf versteckte Informationen zuzugreifen (vielleicht stark obfuskierte Passwörter oder Flags). Dann kann es sinnvoll sein, das apk zu dekompilieren, den Code zu ändern und es wieder zu rekompilieren.
In diesem Tutorial kannst du lernen, wie man ein APK dekompiliert, Smali-Code modifiziert und das APK mit der neuen Funktionalität rekombiliert. Dies kann als Alternative für mehrere Tests während der dynamischen Analyse sehr nützlich sein, die noch präsentiert werden. Behalte diese Möglichkeit also immer im Hinterkopf.

Weitere interessante Tricks

bash
adb shell pm list packages
com.android.insecurebankv2

adb shell pm path com.android.insecurebankv2
package:/data/app/com.android.insecurebankv2-Jnf8pNgwy3QA_U5f-n_4jQ==/base.apk

adb pull /data/app/com.android.insecurebankv2-Jnf8pNgwy3QA_U5f-n_4jQ==/base.apk
  • Alle splits und base apks mit APKEditor zusammenführen:
bash
mkdir splits
adb shell pm path com.android.insecurebankv2 | cut -d ':' -f 2 | xargs -n1 -i adb pull {} splits
java -jar ../APKEditor.jar m -i splits/ -o merged.apk

# after merging, you will need to align and sign the apk, personally, I like to use the uberapksigner
java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed

Fallstudien & Schwachstellen

Air Keyboard Remote Input Injection

Android Rooting Frameworks Manager Auth Bypass Syscall Hook

Statische Analyse

Zunächst sollten Sie zur Analyse einer APK den Java-Code ansehen mit einem decompiler.
Bitte, lesen Sie hier, um Informationen über verschiedene verfügbare decompiler zu finden.

Suche nach interessanten Informationen

Allein durch das Durchsehen der strings einer APK können Sie nach Passwörtern, URLs (https://github.com/ndelphit/apkurlgrep), API keys, Verschlüsselung, bluetooth uuids, Tokens und allem Interessanten suchen... achten Sie sogar auf Code-Execution Backdoors oder Authentifizierungs-Backdoors (hartkodierte Admin-Zugangsdaten in der App).

Firebase

Achten Sie besonders auf firebase URLs und prüfen Sie, ob diese falsch konfiguriert sind. Mehr Informationen darüber, was Firebase ist und wie es ausgenutzt werden kann finden Sie hier.

Grundlegendes Verständnis der Anwendung - Manifest.xml, strings.xml

Die Untersuchung der Manifest.xml und der strings.xml einer Anwendung kann potenzielle Sicherheitslücken offenbaren. Auf diese Dateien kann man mit Decompilern zugreifen oder indem man die APK-Endung in .zip umändert und sie dann entpackt.

Schwachstellen, die aus der Manifest.xml hervorgehen können, umfassen:

  • Debuggable Applications: Anwendungen, die im Manifest.xml als debuggable (debuggable="true") gesetzt sind, stellen ein Risiko dar, da sie Verbindungen erlauben können, die zu einer Ausnutzung führen. Für ein tieferes Verständnis, wie debuggable Anwendungen ausgenutzt werden können, siehe ein Tutorial zum Auffinden und Ausnutzen debuggable Anwendungen auf einem Gerät.
  • Backup Settings: Das Attribut android:allowBackup="false" sollte explizit für Anwendungen gesetzt werden, die mit sensiblen Informationen umgehen, um unautorisierte Datenbackups via adb zu verhindern, insbesondere wenn USB-Debugging aktiviert ist.
  • Network Security: Benutzerdefinierte Netzwerksicherheitskonfigurationen (android:networkSecurityConfig="@xml/network_security_config") in res/xml/ können Sicherheitsdetails wie Certificate Pins und Einstellungen für HTTP-Verkehr spezifizieren. Ein Beispiel ist das Erlauben von HTTP-Traffic für bestimmte Domains.
  • Exported Activities and Services: Das Auffinden exportierter Activities und Services im Manifest kann Komponenten hervorheben, die missbraucht werden könnten. Weitere Analysen während des dynamischen Testens können aufdecken, wie diese Komponenten ausgenutzt werden.
  • Content Providers and FileProviders: Offengelegte Content Provider könnten unautorisierte Zugriffe oder Modifikationen von Daten erlauben. Die Konfiguration von FileProviders sollte ebenfalls geprüft werden.
  • Broadcast Receivers and URL Schemes: Diese Komponenten könnten für Exploits missbraucht werden, wobei besonderes Augenmerk darauf zu legen ist, wie URL schemes für Eingabeanfälligkeiten gehandhabt werden.
  • SDK Versions: Die Attribute minSdkVersion, targetSDKVersion und maxSdkVersion geben die unterstützten Android-Versionen an und unterstreichen, wie wichtig es ist, keine veralteten, verwundbaren Android-Versionen zu unterstützen.

Aus der strings.xml-Datei können sensible Informationen wie API keys, benutzerdefinierte Schemata und andere Entwicklerhinweise entdeckt werden, was die Notwendigkeit einer sorgfältigen Durchsicht dieser Ressourcen unterstreicht.

Tapjacking

Tapjacking ist ein Angriff, bei dem eine bösartige App gestartet wird und sich über einer Ziel-App positioniert. Sobald sie die Ziel-App sichtbar überdeckt, ist ihre Benutzeroberfläche so gestaltet, dass der Benutzer zur Interaktion verleitet wird, während die Interaktion an die Ziel-App weitergereicht wird.
Effektiv wird der Benutzer geblendet und weiß nicht, dass er Aktionen auf der Ziel-App ausführt.

Mehr Informationen finden Sie in:

Tapjacking

Task Hijacking

Eine activity mit dem launchMode auf singleTask ohne definierte taskAffinity ist anfällig für Task Hijacking. Das bedeutet, dass eine App installiert werden kann und, wenn sie vor der echten App gestartet wird, die Task der echten App kapern könnte (so dass der Benutzer mit der bösartigen App interagiert und denkt, er benutze die echte App).

Mehr Infos in:

Android Task Hijacking

Unsichere Datenspeicherung

Internal Storage

In Android sind Dateien, die im internal storage gespeichert werden, dazu vorgesehen, ausschließlich von der App, die sie erstellt hat, zugänglich zu sein. Diese Sicherheitsmaßnahme wird vom Android-Betriebssystem durchgesetzt und ist für die Sicherheitsanforderungen der meisten Anwendungen in der Regel ausreichend. Entwickler verwenden jedoch manchmal Modi wie MODE_WORLD_READABLE und MODE_WORLD_WRITABLE, um Dateien zwischen verschiedenen Anwendungen zu teilen. Diese Modi schränken jedoch den Zugriff durch andere Anwendungen, einschließlich potenziell bösartiger, nicht ein.

  1. Static Analysis:
  • Stellen Sie sicher, dass die Verwendung von MODE_WORLD_READABLE und MODE_WORLD_WRITABLE sorgfältig geprüft wird. Diese Modi können Dateien unbeabsichtigt oder unautorisiert zugänglich machen.
  1. Dynamic Analysis:
  • Überprüfen Sie die Berechtigungen für von der App erstellte Dateien. Prüfen Sie insbesondere, ob Dateien weltweit lesbar oder beschreibbar gesetzt sind. Dies kann ein erhebliches Sicherheitsrisiko darstellen, da dadurch jede auf dem Gerät installierte App die Dateien lesen oder ändern könnte.

External Storage

Beim Umgang mit Dateien auf external storage, wie SD-Karten, sollten bestimmte Vorsichtsmaßnahmen getroffen werden:

  1. Zugänglichkeit:
  • Dateien auf external storage sind global lesbar und schreibbar. Das bedeutet, jede App oder jeder Benutzer kann auf diese Dateien zugreifen.
  1. Sicherheitsbedenken:
  • Aufgrund der leichten Zugänglichkeit sollte keine sensiblen Informationen auf external storage gespeichert werden.
  • External storage kann entfernt oder von jeder App ausgelesen werden, was es weniger sicher macht.
  1. Umgang mit Daten von External Storage:
  • Führen Sie immer Eingabevalidierung für Daten durch, die von external storage geladen werden. Das ist entscheidend, da die Daten aus einer nicht vertrauenswürdigen Quelle stammen.
  • Das Speichern von ausführbaren Dateien oder Class-Dateien auf external storage zum dynamischen Laden wird dringend abgeraten.
  • Falls Ihre App ausführbare Dateien aus external storage laden muss, stellen Sie sicher, dass diese Dateien signiert und kryptographisch verifiziert sind, bevor sie dynamisch geladen werden. Dieser Schritt ist wichtig, um die Sicherheitsintegrität Ihrer Anwendung zu wahren.

External storage ist unter /storage/emulated/0 , /sdcard , /mnt/sdcard zugänglich

tip

Ab Android 4.4 (API 17) hat die SD-Karte eine Verzeichnisstruktur, die den Zugriff einer App auf das speziell für diese App bestimmte Verzeichnis begrenzt. Dadurch wird verhindert, dass eine bösartige App Lese- oder Schreibzugriff auf die Dateien einer anderen App erlangt.

Sensitive data stored in clear-text

  • Shared preferences: Android erlaubt jeder Anwendung, einfach XML-Dateien im Pfad /data/data/<packagename>/shared_prefs/ zu speichern, und manchmal lassen sich in diesem Ordner sensible Informationen im Klartext finden.
  • Databases: Android erlaubt jeder Anwendung, einfach sqlite-Datenbanken im Pfad /data/data/<packagename>/databases/ zu speichern, und manchmal lassen sich in diesem Ordner sensible Informationen im Klartext finden.

Broken TLS

Accept All Certificates

Aus irgendeinem Grund akzeptieren Entwickler manchmal alle Zertifikate, selbst wenn z. B. der Hostname nicht übereinstimmt, mit Codezeilen wie der folgenden:

java
SSLSocketFactory sf = new cc(trustStore);
sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

Eine gute Möglichkeit, dies zu testen, ist zu versuchen, den Traffic mit einem Proxy wie Burp abzufangen, ohne das Burp CA im Gerät zu authorisieren. Außerdem kann man mit Burp ein Zertifikat für einen anderen Hostnamen erzeugen und verwenden.

Fehlerhafte Kryptographie

Schlechte Schlüsselverwaltungsprozesse

Einige Entwickler speichern sensitive Daten im lokalen Speicher und verschlüsseln sie mit einem im Code hardcodierten/vorhersagbaren Schlüssel. Das sollte nicht gemacht werden, da Reverse-Engineering Angreifern erlauben kann, die vertraulichen Informationen zu extrahieren.

Verwendung unsicherer und/oder veralteter Algorithmen

Entwickler sollten keine deprecated algorithms verwenden, um Authorisation checks durchzuführen, Daten zu store oder zu send. Einige dieser Algorithmen sind: RC4, MD4, MD5, SHA1... Wenn beispielsweise hashes verwendet werden, um Passwörter zu speichern, sollten brute-force-resistente Hashes mit Salt verwendet werden.

Weitere Prüfungen

  • Es wird empfohlen, die APK zu obfuskieren, um die Arbeit des Reverse-Engineerings für Angreifer zu erschweren.
  • Wenn die App sensibel ist (z. B. Bank-Apps), sollte sie eigene Prüfungen durchführen, um zu prüfen, ob das Mobilgerät rooted ist, und entsprechend reagieren.
  • Wenn die App sensibel ist (z. B. Bank-Apps), sollte sie prüfen, ob ein emulator verwendet wird.
  • Wenn die App sensibel ist (z. B. Bank-Apps), sollte sie ihre eigene Integrität vor der Ausführung prüfen, um festzustellen, ob sie verändert wurde.
  • Use APKiD to check which compiler/packer/obfuscator was used to build the APK

React Native Application

Read the following page to learn how to easily access javascript code of React applications:

React Native Application

Xamarin Applications

Read the following page to learn how to easily access C# code of a xamarin applications:

Xamarin Apps

Superpacked Applications

According to this blog post superpacked is a Meta algorithm that compress the content of an application into a single file. The blog talks about the possibility of creating an app that decompress these kind of apps... and a faster way which involves to execute the application and gather the decompressed files from the filesystem.

Automated Static Code Analysis

The tool mariana-trench is capable of finding vulnerabilities by scanning the code of the application. This tool contains a series of known sources (that indicates to the tool the places where the input is controlled by the user), sinks (which indicates to the tool dangerous places where malicious user input could cause damages) and rules. These rules indicates the combination of sources-sinks that indicates a vulnerability.

With this knowledge, mariana-trench will review the code and find possible vulnerabilities on it.

Secrets leaked

An application may contain secrets (API keys, passwords, hidden urls, subdomains...) inside of it that you might be able to discover. You could us a tool such as https://github.com/dwisiswant0/apkleaks

Bypass Biometric Authentication

Bypass Biometric Authentication (Android)

Other interesting functions

  • Code execution: Runtime.exec(), ProcessBuilder(), native code:system()
  • Send SMSs: sendTextMessage, sendMultipartTestMessage
  • Native functions declared as native: public native, System.loadLibrary, System.load
  • Read this to learn how to reverse native functions
  • In-memory native code execution via JNI (downloaded shellcode → mmap/mprotect → call):

In Memory Jni Shellcode Execution

Other tricks

content:// protocol

Dynamische Analyse

Zunächst brauchst du eine Umgebung, in der du die Anwendung und alle benötigten Komponenten (Burp CA cert, Drozer und Frida hauptsächlich) installieren kannst. Daher wird ein rooted device (emuliert oder nicht) dringend empfohlen.

Online Dynamic analysis

You can create a free account in: https://appetize.io/. This platform allows you to upload and execute APKs, so it is useful to see how an apk is behaving.

You can even see the logs of your application in the web and connect through adb.

Thanks to the ADB connection you can use Drozer and Frida inside the emulators.

Local Dynamic Analysis

Using an emulator

  • Android Studio (You can create x86 and arm devices, and according to this latest x86 versions support ARM libraries without needing an slow arm emulator).
  • Learn to set it up in this page:

AVD - Android Virtual Device

  • Genymotion (Free version: Personal Edition, you need to create an account. It's recommend to download the version WITH VirtualBox to avoid potential errors.)
  • Nox (Free, but it doesn't support Frida or Drozer).

tip

Beim Erstellen eines neuen Emulators auf einer beliebigen Plattform gilt: Je größer der Bildschirm, desto langsamer läuft der Emulator. Wähle daher, wenn möglich, kleine Bildschirme.

To install google services (like AppStore) in Genymotion you need to click on the red marked button of the following image:

Also, notice that in the configuration of the Android VM in Genymotion you can select Bridge Network mode (this will be useful if you will be connecting to the Android VM from a different VM with the tools).

Use a physical device

You need to activate the debugging options and it will be cool if you can root it:

  1. Settings.
  2. (FromAndroid 8.0) Select System.
  3. Select About phone.
  4. Press Build number 7 times.
  5. Go back and you will find the Developer options.

Once you have installed the application, the first thing you should do is to try it and investigate what does it do, how does it work and get comfortable with it.
I will suggest to perform this initial dynamic analysis using MobSF dynamic analysis + pidcat, so we will be able to learn how the application works while MobSF captures a lot of interesting data you can review later on.

Magisk/Zygisk quick notes (recommended on Pixel devices)

  • Patch boot.img with the Magisk app and flash via fastboot to get systemless root
  • Enable Zygisk + DenyList for root hiding; consider LSPosed/Shamiko when stronger hiding is required
  • Keep original boot.img to recover from OTA updates; re-patch after each OTA
  • For screen mirroring, use scrcpy on the host

Unintended Data Leakage

Logging

Developers should be cautious of exposing debugging information publicly, as it can lead to sensitive data leaks. The tools pidcat and adb logcat are recommended for monitoring application logs to identify and protect sensitive information. Pidcat is favored for its ease of use and readability.

warning

Note that from later newer than Android 4.0, applications are only able to access their own logs. So applications cannot access other apps logs.
Anyway, it's still recommended to not log sensitive information.

Copy/Paste Buffer Caching

Android's clipboard-based framework enables copy-paste functionality in apps, yet poses a risk as other applications can access the clipboard, potentially exposing sensitive data. It's crucial to disable copy/paste functions for sensitive sections of an application, like credit card details, to prevent data leaks.

Crash Logs

If an application crashes and saves logs, these logs can assist attackers, particularly when the application cannot be reverse-engineered. To mitigate this risk, avoid logging on crashes, and if logs must be transmitted over the network, ensure they are sent via an SSL channel for security.

As pentester, try to take a look to these logs.

Analytics Data Sent To 3rd Parties

Applications often integrate services like Google Adsense, which can inadvertently leak sensitive data due to improper implementation by developers. To identify potential data leaks, it's advisable to intercept the application's traffic and check for any sensitive information being sent to third-party services.

SQLite DBs

Most of the applications will use internal SQLite databases to save information. During the pentest take a look to the databases created, the names of tables and columns and all the data saved because you could find sensitive information (which would be a vulnerability).
Databases should be located in /data/data/the.package.name/databases like /data/data/com.mwr.example.sieve/databases

If the database is saving confidential information and is encrypted but you can find the password inside the application it's still a vulnerability.

Enumerate the tables using .tables and enumerate the columns of the tables doing .schema <table_name>

Drozer (Exploit Activities, Content Providers and Services)

From Drozer Docs: Drozer allows you to assume the role of an Android app and interact with other apps. It can do anything that an installed application can do, such as make use of Android’s Inter-Process Communication (IPC) mechanism and interact with the underlying operating system. .
Drozer is s useful tool to exploit exported activities, exported services and Content Providers as you will learn in the following sections.

Exploiting exported Activities

Read this if you want to refresh what is an Android Activity.
Also remember that the code of an activity starts in the onCreate method.

Authorisation bypass

When an Activity is exported you can invoke its screen from an external app. Therefore, if an activity with sensitive information is exported you could bypass the authentication mechanisms to access it.

Learn how to exploit exported activities with Drozer.

You can also start an exported activity from adb:

  • PackageName is com.example.demo
  • Exported ActivityName is com.example.test.MainActivity
bash
adb shell am start -n com.example.demo/com.example.test.MainActivity

HINWEIS: MobSF wird die Verwendung von singleTask/singleInstance als android:launchMode in einer Activity als bösartig erkennen, aber aufgrund this scheint dies offensichtlich nur auf alten Versionen (API versions < 21) gefährlich zu sein.

tip

Beachte, dass ein Authorisation Bypass nicht immer eine Schwachstelle ist; es hängt davon ab, wie der Bypass funktioniert und welche Informationen offengelegt werden.

Sensitive information leakage

Aktivitäten können auch Ergebnisse zurückgeben. Wenn es dir gelingt, eine exportierte und ungeschützte Activity zu finden, die die Methode setResult aufruft und sensible Informationen zurückgibt, liegt eine sensitive information leakage vor.

Tapjacking

Wenn Tapjacking nicht verhindert wird, könntest du die exportierte Activity missbrauchen, um den Benutzer unerwartete Aktionen durchführen zu lassen. Weitere Informationen zu Tapjacking.

Exploiting Content Providers - Accessing and manipulating sensitive information

Lies das, wenn du auffrischen möchtest, was ein Content Provider ist.
Content Provider werden im Wesentlichen verwendet, um Daten zu teilen. Wenn eine App Content Provider anbietet, könntest du möglicherweise sensible Daten extrahieren. Es ist auch sinnvoll, mögliche SQL injections und Path Traversals zu testen, da diese verwundbar sein könnten.

Erfahre, wie man Content Providers mit Drozer ausnutzt.

Exploiting Services

Lies das, wenn du auffrischen möchtest, was ein Service ist.
Denke daran, dass die Aktionen eines Service in der Methode onStartCommand beginnen.

Ein Service ist im Grunde etwas, das Daten empfangen kann, diese verarbeiten und (oder nicht) eine Antwort zurückgibt. Wenn eine Anwendung also Services exportiert, solltest du den Code prüfen, um zu verstehen, was er tut, und ihn dynamisch testen, um vertrauliche Informationen zu extrahieren, Authentifizierungsmaßnahmen zu umgehen...
Lerne, wie man Services mit Drozer ausnutzt.

Exploiting Broadcast Receivers

Lies das, wenn du auffrischen möchtest, was ein Broadcast Receiver ist.
Denke daran, dass die Aktionen eines Broadcast Receivers in der Methode onReceive beginnen.

Ein Broadcast Receiver wartet auf eine bestimmte Art von Nachricht. Je nachdem, wie der Receiver die Nachricht verarbeitet, kann er verwundbar sein.
Lerne, wie man Broadcast Receivers mit Drozer ausnutzt.

Exploiting Schemes / Deep links

Du kannst manuell nach Deep Links suchen, Tools wie MobSF oder Skripte wie this one verwenden.
Du kannst ein deklariertes scheme mit adb oder einem Browser öffnen:

bash
adb shell am start -a android.intent.action.VIEW -d "scheme://hostname/path?param=value" [your.package.name]

Beachte, dass du den Paketnamen weglassen kannst und das Mobilgerät automatisch die App aufruft, die diesen Link öffnen sollte.

html
<!-- Browser regular link -->
<a href="scheme://hostname/path?param=value">Click me</a>
<!-- fallback in your url you could try the intent url -->
<a href="intent://hostname#Intent;scheme=scheme;package=your.package.name;S.browser_fallback_url=http%3A%2F%2Fwww.example.com;end">with alternative</a>

Ausgeführter Code

Um den Code zu finden, der in der App ausgeführt wird, gehe zur Activity, die vom deeplink aufgerufen wird, und suche die Funktion onNewIntent.

Sensitive info

Jedes Mal, wenn du einen deep link findest, prüfe, dass er keine sensiblen Daten (wie Passwörter) über URL-Parameter empfängt, denn jede andere Anwendung könnte den deep link imitieren und diese Daten stehlen!

Parameters in path

Du musst auch prüfen, ob ein deep link einen Parameter im Pfad der URL verwendet, z. B.: https://api.example.com/v1/users/{username}. In diesem Fall kannst du eine Path Traversal erzwingen, indem du so zugreifst: example://app/users?username=../../unwanted-endpoint%3fparam=value.
Beachte, dass du, wenn du die korrekten Endpunkte in der Anwendung findest, möglicherweise eine Open Redirect (wenn ein Teil des Pfads als Domain genutzt wird), account takeover (wenn du Benutzerdaten ohne CSRF token ändern kannst und der verwundbare Endpoint die richtige Methode verwendet) und jede andere Schwachstelle auslösen kannst. Mehr Info dazu hier.

More examples

Ein interessanter bug bounty report über Links (/.well-known/assetlinks.json).

Transport Layer-Inspektion und Verifikationsfehler

  • Zertifikate werden nicht immer korrekt geprüft von Android-Anwendungen. Es ist üblich, dass diese Anwendungen Warnungen übersehen und self-signed certificates akzeptieren oder in einigen Fällen auf HTTP-Verbindungen zurückfallen.
  • Die Aushandlungen beim SSL/TLS-Handshake sind manchmal schwach und verwenden unsichere cipher suites. Diese Schwachstelle macht die Verbindung anfällig für Man-in-the-middle (MITM)-Angriffe, die es Angreifern erlauben, die Daten zu entschlüsseln.
  • Leakage von privaten Informationen ist ein Risiko, wenn Anwendungen sich über sichere Kanäle authentifizieren, dann aber für andere Transaktionen über nicht-gesicherte Kanäle kommunizieren. Dieser Ansatz schützt sensible Daten, wie session cookies oder Benutzerdetails, nicht vor Abfangversuchen durch böswillige Akteure.

Certificate Verification

Wir konzentrieren uns auf certificate verification. Die Integrität des Serverzertifikats muss verifiziert werden, um die Sicherheit zu erhöhen. Das ist entscheidend, weil unsichere TLS-Konfigurationen und die Übertragung sensibler Daten über unverschlüsselte Kanäle erhebliche Risiken darstellen können. Für detaillierte Schritte zur Verifizierung von Serverzertifikaten und zur Behebung von Schwachstellen bietet diese Ressource umfassende Anleitungen.

SSL Pinning

SSL Pinning ist eine Sicherheitsmaßnahme, bei der die Anwendung das Serverzertifikat mit einer bekannten Kopie vergleicht, die innerhalb der Anwendung gespeichert ist. Diese Methode ist essenziell, um MITM attacks zu verhindern. Die Implementierung von SSL Pinning wird dringend für Anwendungen empfohlen, die mit sensiblen Informationen umgehen.

Traffic Inspection

Um HTTP-Traffic zu inspizieren, ist es notwendig, das Zertifikat des Proxy-Tools zu installieren (z. B. Burp). Ohne dieses installierte Zertifikat ist verschlüsselter Traffic möglicherweise nicht über den Proxy sichtbar. Eine Anleitung zum Installieren eines eigenen CA-Zertifikats findest du hier.

Anwendungen mit Ziel-API-Level 24 und höher erfordern Änderungen an der Network Security Config, damit das CA-Zertifikat des Proxys akzeptiert wird. Dieser Schritt ist entscheidend, um verschlüsselten Traffic zu inspizieren. Anweisungen zum Ändern der Network Security Config findest du in diesem Tutorial.

Wenn Flutter verwendet wird, musst du den Anweisungen auf dieser Seite folgen. Nur das Hinzufügen des Zertifikats zum Store reicht nicht aus, da Flutter eine eigene Liste gültiger CAs verwendet.

Static detection of SSL/TLS pinning

Bevor du Runtime-Bypässe versuchst, mappe schnell, wo Pinning im APK erzwungen wird. Statische Erkennung hilft dir, Hooks/Patches zu planen und dich auf die richtigen Codepfade zu konzentrieren.

Tool: SSLPinDetect

  • Open-source static-analysis utility, das das APK zu Smali dekompiliert (via apktool) und nach kuratierten Regex-Patterns von SSL/TLS pinning Implementierungen scannt.
  • Meldet exakten Dateipfad, Zeilennummer und einen Codeausschnitt für jeden Treffer.
  • Deckt gängige Frameworks und custom code paths ab: OkHttp CertificatePinner, custom javax.net.ssl.X509TrustManager.checkServerTrusted, SSLContext.init with custom TrustManagers/KeyManagers, und Network Security Config XML pins.

Install

  • Prereqs: Python >= 3.8, Java on PATH, apktool
bash
git clone https://github.com/aancw/SSLPinDetect
cd SSLPinDetect
pip install -r requirements.txt

Verwendung

bash
# Basic
python sslpindetect.py -f app.apk -a apktool.jar

# Verbose (timings + per-match path:line + snippet)
python sslpindetect.py -a apktool_2.11.0.jar -f sample/app-release.apk -v

Beispiel-Pattern-Regeln (JSON) Verwende oder erweitere signatures, um proprietäre/benutzerdefinierte pinning-Stile zu erkennen. Du kannst dein eigenes JSON laden und in großem Maßstab scannen.

json
{
"OkHttp Certificate Pinning": [
"Lcom/squareup/okhttp/CertificatePinner;",
"Lokhttp3/CertificatePinner;",
"setCertificatePinner"
],
"TrustManager Override": [
"Ljavax/net/ssl/X509TrustManager;",
"checkServerTrusted"
]
}

Notes and tips

  • Schnelles Scannen großer Apps mittels Multithreading und memory-mapped I/O; vorkompilierte Regex reduziert Overhead/False-Positives.
  • Pattern collection: https://github.com/aancw/smali-sslpin-patterns
  • Typische Erkennungsziele für die weitere Triage:
  • OkHttp: Verwendung von CertificatePinner, setCertificatePinner, okhttp3/okhttp Paketreferenzen
  • Custom TrustManagers: javax.net.ssl.X509TrustManager, Overrides von checkServerTrusted
  • Custom SSL contexts: SSLContext.getInstance + SSLContext.init mit eigenen Managern
  • Deklarative Pins in res/xml network security config und Manifest-Referenzen
  • Nutze die gefundenen Stellen, um Frida-Hooks, statische Patches oder Konfigurationsprüfungen vor dynamischem Testing zu planen.

Umgehung von SSL Pinning

Wenn SSL Pinning implementiert ist, muss es umgangen werden, um HTTPS-Traffic zu inspizieren. Verschiedene Methoden stehen dafür zur Verfügung:

Suche nach typischen Web-Schwachstellen

Es ist wichtig, innerhalb der Anwendung auch nach typischen Web-Schwachstellen zu suchen. Detaillierte Informationen zur Identifikation und Behebung dieser Schwachstellen gehen über den Umfang dieser Zusammenfassung hinaus, werden aber an anderer Stelle ausführlich behandelt.

Frida

Frida ist ein dynamisches Instrumentierungs-Toolkit für Entwickler, Reverse-Engineers und Sicherheitsforscher.
Du kannst laufende Anwendungen zur Laufzeit ansprechen und Methoden hooken, um Verhalten zu ändern, Werte zu verändern, Werte zu extrahieren, anderen Code auszuführen...
Wenn du Android-Anwendungen pentesten möchtest, musst du wissen, wie man Frida verwendet.

Anti-Instrumentation- & SSL pinning Bypass-Workflow

Android Anti Instrumentation And Ssl Pinning Bypass

Speicher auslesen - Fridump

Überprüfe, ob die Anwendung sensible Informationen im Speicher ablegt, die dort nicht sein sollten, z. B. Passwörter oder Mnemonics.

Mit Fridump3 kannst du den Speicher der App dumpen mit:

bash
# With PID
python3 fridump3.py -u <PID>

# With name
frida-ps -Uai
python3 fridump3.py -u "<Name>"

Dies erzeugt ein Speicher-Dump im Ordner ./dump, und dort könntest du mit etwas wie folgendem grep:

bash
strings * | grep -E "^[a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+$"

Sensible Daten im Keystore

Unter Android ist der Keystore der beste Ort, um sensible Daten zu speichern, jedoch ist er bei ausreichenden Rechten weiterhin zugänglich. Da Anwendungen hier häufig sensible Daten im Klartext ablegen, sollten pentests dies als root user überprüfen, da jemand mit physischem Zugriff auf das Gerät diese Daten stehlen könnte.

Selbst wenn eine App Daten im Keystore gespeichert hat, sollten diese verschlüsselt sein.

Um auf die Daten im Keystore zuzugreifen, können Sie dieses Frida script verwenden: https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js

bash
frida -U -f com.example.app -l frida-scripts/tracer-cipher.js

Fingerprint/Biometrics Bypass

Mit dem folgenden Frida-Skript könnte es möglich sein, die von Android-Anwendungen eingesetzte bypass fingerprint authentication zu umgehen, die dazu dient, bestimmte sensible Bereiche zu schützen:

bash
frida --codeshare krapgras/android-biometric-bypass-update-android-11 -U -f <app.package>

Hintergrundbilder

Wenn du eine Anwendung in den Hintergrund legst, speichert Android einen Snapshot der Anwendung, sodass beim Wiederherstellen in den Vordergrund zuerst das Bild geladen wird, bevor die App startet, wodurch es so aussieht, als wäre die App schneller geladen.

Enthält dieser Snapshot jedoch sensible Informationen, könnte jemand mit Zugriff auf den Snapshot diese Informationen stehlen (Hinweis: zum Zugriff ist root erforderlich).

Die Snapshots werden normalerweise gespeichert unter: /data/system_ce/0/snapshots

Android bietet die Möglichkeit, das Erfassen von Screenshots durch Setzen des Layout-Parameters FLAG_SECURE zu verhindern. Wird dieses Flag gesetzt, werden die Fensterinhalte als sicher behandelt, sodass sie nicht in Screenshots erscheinen oder auf nicht-sicheren Displays angezeigt werden können.

bash
getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);

Android Application Analyzer

Dieses Tool kann Ihnen helfen, verschiedene Tools während der dynamischen Analyse zu verwalten: https://github.com/NotSoSecure/android_application_analyzer

Intent Injection

Entwickler erstellen häufig Proxy-Komponenten wie activities, services und broadcast receivers, die diese Intents verarbeiten und an Methoden wie startActivity(...) oder sendBroadcast(...) weitergeben, was riskant sein kann.

Die Gefahr besteht darin, Angreifern zu ermöglichen, nicht-exportierte App-Komponenten auszulösen oder auf sensitive Content Providers zuzugreifen, indem diese Intents fehlgeleitet werden. Ein bemerkenswertes Beispiel ist die WebView-Komponente, die URLs mittels Intent.parseUri(...) in Intent-Objekte umwandelt und diese dann ausführt, was potenziell zu bösartigen Intent injections führen kann.

Essential Takeaways

  • Intent Injection ist ähnlich dem Open Redirect-Problem im Web.
  • Exploits beinhalten das Übergeben von Intent-Objekten als Extras, die umgeleitet werden können, um unsichere Operationen auszuführen.
  • Dadurch können nicht-exportierte Komponenten und Content Providers für Angreifer offenbart werden.
  • Die Umwandlung von URLs in Intent-Objekte durch WebView kann unbeabsichtigte Aktionen ermöglichen.

Android Client-Side Injections und andere

Wahrscheinlich kennen Sie diese Art von Schwachstellen aus dem Web. In Android-Anwendungen müssen Sie bei diesen Schwachstellen besonders vorsichtig sein:

  • SQL Injection: Beim Umgang mit dynamischen Abfragen oder Content-Providers sollten Sie parameterisierte Abfragen verwenden.
  • JavaScript Injection (XSS): Stellen Sie sicher, dass JavaScript- und Plugin-Unterstützung für alle WebViews deaktiviert ist (standardmäßig deaktiviert). Mehr Infos hier.
  • Local File Inclusion: Der Zugriff von WebViews auf das Dateisystem sollte deaktiviert sein (standardmäßig aktiviert) - (webview.getSettings().setAllowFileAccess(false);). Mehr Infos hier.
  • Eternal cookies: In mehreren Fällen wird beim Beenden der Android-Anwendung das Cookie nicht widerrufen oder es kann sogar auf die Festplatte gespeichert werden
  • Secure Flag in cookies

Automatische Analyse

MobSF

Statische Analyse

Schwachstellenbewertung der Anwendung mithilfe eines ansprechenden webbasierten Frontends. Sie können auch eine dynamische Analyse durchführen (aber Sie müssen die Umgebung vorbereiten).

bash
docker pull opensecurity/mobile-security-framework-mobsf
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

Beachte, dass MobSF Android(apk), IOS(ipa) and Windows(apx) applications analysieren kann (Windows-Anwendungen müssen von einem auf einem Windows-Host installierten MobSF analysiert werden).
Auch wenn du eine ZIP Datei mit dem Source-Code einer Android oder einer IOS App erstellst (gehe zum Root-Ordner der Anwendung, wähle alles aus und erstelle eine ZIPfile), kann es diese ebenfalls analysieren.

MobSF ermöglicht außerdem das diff/Compare von Analysen und die Integration von VirusTotal (du musst deinen API-Schlüssel in MobSF/settings.py setzen und es aktivieren: VT_ENABLED = TRUE VT_API_KEY = <Your API key> VT_UPLOAD = TRUE). Du kannst VT_UPLOAD auch auf False setzen, dann wird statt der Datei der hash hochgeladen.

Assisted Dynamic analysis with MobSF

MobSF kann auch bei der dynamischen Analyse von Android sehr hilfreich sein, aber in diesem Fall musst du MobSF und genymotion auf deinem Host installieren (eine VM oder Docker funktioniert nicht). Note: You need to start first a VM in genymotion and then MobSF.\
Der MobSF dynamic analyser kann:

  • Dump application data (URLs, logs, clipboard, screenshots made by you, screenshots made by "Exported Activity Tester", emails, SQLite databases, XML files, and other created files). All of this is done automatically except for the screenshots, you need to press when you want a screenshot or you need to press "Exported Activity Tester" to obtain screenshots of all the exported activities.
  • Capture HTTPS traffic
  • Use Frida to obtain runtime information

Ab Android versions > 5 wird es automatisch Frida starten und globale proxy-Einstellungen setzen, um den Traffic zu capture. Es erfasst nur den Traffic der getesteten Anwendung.

Frida

Standardmäßig verwendet es außerdem einige Frida Scripts, um bypass SSL pinning, root detection und debugger detection zu umgehen und um monitor interesting APIs.
MobSF kann außerdem invoke exported activities, Screenshots davon erstellen und diese für den Report save.

Um das dynamische Testing zu start drücke den grünen Button: "Start Instrumentation". Drücke "Frida Live Logs", um die Logs der Frida-Skripte zu sehen, und "Live API Monitor", um alle Aufrufe an gehookte Methoden, übergebene Argumente und zurückgegebene Werte zu sehen (dies erscheint nach dem Drücken von "Start Instrumentation").
MobSF erlaubt es dir auch, eigene Frida scripts zu laden (um die Ergebnisse deiner Friday scripts an MobSF zu senden, benutze die Funktion send()). Es beinhaltet mehrere vorgefertigte Skripte, die du laden kannst (du kannst weitere in MobSF/DynamicAnalyzer/tools/frida_scripts/others/ hinzufügen), wähle sie einfach aus, drücke "Load" und dann "Start Instrumentation" (du kannst die Logs dieser Skripte in "Frida Live Logs" sehen).

Außerdem gibt es einige zusätzliche Frida-Funktionalitäten:

  • Enumerate Loaded Classes: Gibt alle geladenen Klassen aus
  • Capture Strings: Gibt alle erfassten Strings während der Nutzung der Anwendung aus (sehr viele Ausgaben)
  • Capture String Comparisons: Kann sehr nützlich sein. Es zeigt die beiden verglichenen Strings und ob das Ergebnis True oder False war.
  • Enumerate Class Methods: Gib den Klassennamen an (z. B. "java.io.File") und es werden alle Methoden der Klasse ausgegeben.
  • Search Class Pattern: Suche Klassen nach Pattern
  • Trace Class Methods: Trace eine ganze Klasse (siehe Eingaben und Ausgaben aller Methoden der Klasse). Denk daran, dass MobSF standardmäßig mehrere interessante Android Api-Methoden trace't.

Sobald du das Hilfsmodul ausgewählt hast, das du verwenden möchtest, musst du "Start Intrumentation" drücken und du wirst alle Ausgaben in "Frida Live Logs" sehen.

Shell

MobSF bringt dir außerdem eine Shell mit einigen adb commands, MobSF commands, und gängigen shell commands am unteren Rand der Seite für die dynamische Analyse. Einige interessante Commands:

bash
help
shell ls
activities
exported_activities
services
receivers

HTTP tools

Wenn HTTP-Traffic erfasst wird, können Sie eine unübersichtliche Ansicht des erfassten Traffics über die Schaltfläche "HTTP(S) Traffic" sehen oder eine übersichtlichere Ansicht über die grüne Schaltfläche "Start HTTPTools". Über die zweite Option können Sie die erfassten Requests an Proxies wie Burp oder Owasp ZAP senden.
Um das zu tun: Burp einschalten --> Intercept ausschalten --> in MobSB HTTPTools die Anfrage auswählen --> auf "Send to Fuzzer" drücken --> die Proxy-Adresse auswählen (http://127.0.0.1:8080\).

Sobald Sie die dynamische Analyse mit MobSF abgeschlossen haben, können Sie auf "Start Web API Fuzzer" klicken, um HTTP-Requests zu fuzzen und nach Schwachstellen zu suchen.

tip

Nachdem Sie eine dynamische Analyse mit MobSF durchgeführt haben, können die Proxy-Einstellungen fehlerhaft konfiguriert sein und sich nicht über die GUI zurücksetzen lassen. Sie können die Proxy-Einstellungen wie folgt beheben:

adb shell settings put global http_proxy :0

Assisted Dynamic Analysis with Inspeckage

Sie können das Tool von Inspeckage beziehen.
Dieses Tool verwendet einige Hooks, um Ihnen während einer dynamischen Analyse mitzuteilen, was in der Anwendung passiert.

Yaazhini

Dies ist ein ausgezeichnetes Tool, um statische Analysen mit einer GUI durchzuführen

Qark

Dieses Tool wurde entwickelt, um mehrere security related Android application vulnerabilities zu finden, entweder im source code oder in packaged APKs. Das Tool ist außerdem capable of creating a "Proof-of-Concept" deployable APK und ADB commands, um einige der gefundenen Schwachstellen auszunutzen (Exposed activities, intents, tapjacking...). Wie bei Drozer ist es nicht nötig, das Testgerät zu rooten.

bash
pip3 install --user qark  # --user is only needed if not using a virtualenv
qark --apk path/to/my.apk
qark --java path/to/parent/java/folder
qark --java path/to/specific/java/file.java

ReverseAPK

  • Zeigt alle extrahierten Dateien zur einfachen Referenz an
  • Dekompiliert APK-Dateien automatisch in Java- und Smali-Format
  • Analysiert AndroidManifest.xml auf häufige Schwachstellen und Verhalten
  • Statische Quellcode-Analyse auf häufige Schwachstellen und Verhalten
  • Geräteinformationen
  • und mehr
bash
reverse-apk relative/path/to/APP.apk

SUPER Android Analyzer

SUPER ist eine Kommandozeilenanwendung, die unter Windows, MacOS X und Linux verwendet werden kann und .apk-Dateien auf der Suche nach Schwachstellen analysiert. Dazu dekomprimiert sie APKs und wendet eine Reihe von Regeln an, um diese Schwachstellen zu erkennen.

Alle Regeln sind in der Datei rules.json abgelegt; jedes Unternehmen oder jeder Tester kann eigene Regeln erstellen, um genau das zu analysieren, was benötigt wird.

Lade die neuesten Binärdateien von der download page herunter.

super-analyzer {apk_file}

StaCoAn

StaCoAn ist ein plattformübergreifendes Tool, das Entwicklern, bugbounty hunters und ethical hackers bei der Durchführung von static code analysis an mobilen Anwendungen hilft.

Das Konzept ist, dass Sie Ihre mobile Anwendungsdatei (eine .apk- oder .ipa-Datei) auf die StaCoAn-Anwendung ziehen und ablegen, und sie erstellt einen visuellen und portablen Bericht für Sie. Sie können die Einstellungen und wordlists anpassen, um eine individuelle Erfahrung zu erhalten.

Herunterladen latest release:

./stacoan

AndroBugs

AndroBugs Framework ist ein System zur Analyse von Android-Schwachstellen, das Entwicklern oder hackers hilft, potenzielle Sicherheitslücken in Android-Anwendungen zu finden.\
Windows releases

python androbugs.py -f [APK file]
androbugs.exe -f [APK file]

Androwarn

Androwarn ist ein Tool, dessen Hauptziel es ist, den Benutzer vor potenziell bösartigen Verhaltensweisen einer Android-Anwendung zu warnen.

Die Erkennung erfolgt durch die static analysis des Dalvik bytecode der Anwendung, dargestellt als Smali, mithilfe der androguard Bibliothek.

Dieses Tool sucht nach common behavior of "bad" applications wie: Telephony identifiers exfiltration, Audio/video flow interception, PIM data modification, Arbitrary code execution...

python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3

MARA Framework

MARA ist ein Mobile Application Reverse engineering and Analysis Framework. Es ist ein Tool, das häufig verwendete mobile Application reverse engineering und analysis Tools zusammenführt, um beim Testen mobiler Anwendungen gegen die OWASP mobile security threats zu unterstützen. Ziel ist es, diese Aufgabe für mobile App-Entwickler und Security-Professionals einfacher und benutzerfreundlicher zu machen.

It is able to:

Koodous

Nützlich zur Erkennung von Malware: https://koodous.com/

Obfuskierung/Deobfuskierung von Code

Beachte, dass abhängig vom Service und der Konfiguration, die du zur Obfuskierung des Codes verwendest, Secrets obfuskiert sein können oder nicht.

ProGuard

Aus Wikipedia: ProGuard ist ein Open-Source-Kommandozeilen-Tool, das Java-Code schrumpft, optimiert und obfuskiert. Es kann Bytecode optimieren sowie unbenutzte Anweisungen erkennen und entfernen. ProGuard ist freie Software und wird unter der GNU General Public License, Version 2 verteilt.

ProGuard wird als Teil des Android SDK verteilt und läuft beim Erstellen der Anwendung im Release-Modus.

DexGuard

Eine Schritt-für-Schritt-Anleitung zum Deobfuskieren der APK findest du unter https://blog.lexfo.fr/dexguard.html

(Aus dieser Anleitung) Als wir das letzte Mal nachgesehen haben, war der Betriebsmodus von Dexguard:

  • load a resource as an InputStream;
  • feed the result to a class inheriting from FilterInputStream to decrypt it;
  • do some useless obfuscation to waste a few minutes of time from a reverser;
  • feed the decrypted result to a ZipInputStream to get a DEX file;
  • finally load the resulting DEX as a Resource using the loadDex method.

DeGuard

DeGuard kehrt den Obfuskierungsprozess um, der von Android-Obfuscation-Tools durchgeführt wird. Das ermöglicht zahlreiche Sicherheitsanalysen, einschließlich Code-Inspektion und Vorhersage von Bibliotheken.

Du kannst eine obfuskierte APK auf ihre Plattform hochladen.

[Deobfuscate android App]https://github.com/In3tinct/deobfuscate-android-app

This is a LLM tool to find any potential security vulnerabilities in android apps and deobfuscate android app code. Uses Google's Gemini public API.

Simplify

It is a generic android deobfuscator. Simplify virtually executes an app to understand its behavior and then tries to optimize the code so it behaves identically but is easier for a human to understand. Each optimization type is simple and generic, so it doesn't matter what the specific type of obfuscation is used.

APKiD

APKiD gives you information about how an APK was made. It identifies many compilers, packers, obfuscators, and other weird stuff. It's PEiD for Android.

Handbuch

Read this tutorial to learn some tricks on how to reverse custom obfuscation

Labs

Androl4b

AndroL4b ist eine Android-Security-VM basierend auf ubuntu-mate und enthält eine Sammlung aktueller Frameworks, Tutorials und Labs von verschiedenen Security-Enthusiasten und Forschern für reverse engineering und malware analysis.

Referenzen

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks