Wie verbreitet ist Code-Verschleierung in beliebten Android-Apps?

Ob es nun darum geht, geistiges Eigentum zu stehlen, Zugriff auf sensible Nutzerdaten zu erlangen oder auf nahezu alles auf einem Backend-Server zuzugreifen – viele gezielte Angriffe beginnen mit dem Reverse Engineering von Teilen clientseitiger Anwendungen, um deren Struktur zu verstehen und Schwachstellen zu identifizieren. Selbst wenn der Angriff letztendlich im Backend erfolgt, liefert die Analyse der Client-Seite oft entscheidende Informationen über deren APIs und Authentifizierungsmechanismen.

Aus diesem Grund sind wir der Ansicht, dass Codehärtung Dies ist für jede App, die originelle Algorithmen verwendet oder mit sensiblen Daten arbeitet, nicht verhandelbar..

Im Jahr 2023 definierte OWASP die zweite Version ihrer Mobil Application Security Verifizierungsstandard (MASVS)Es dient als Leitfaden für App-Entwickler, die ihre mobilen Apps absichern wollen, sowie für Sicherheitstester, die Schwachstellen darin finden möchten. Es bietet außerdem Application Security Produktanbieter wie Digital.ai Ein Rahmenwerk, um über die heutige Landschaft der Anwendungssicherheit nachzudenken. OWASP MASVS-RESILIENCE Die Bedienelemente passen perfekt dazu Digital.ai (und zuvor Arxan) beschäftigt sich mit Codehärtung und Manipulationsschutz:

• MASVS-RESILIENCE-1Die App überprüft die Integrität der Plattform.
• MASVS-RESILIENCE-2Die App verfügt über Manipulationsschutzmechanismen.
• MASVS-RESILIENCE-3Die App implementiert antistatische Analysemechanismen.
• MASVS-RESILIENCE-4Die App implementiert Techniken der Antidynamikanalyse.

Während die Gewährleistung der Integrität der Plattform, der Schutz vor Manipulation und die Verhinderung dynamischer Analysen oft wirkungsvoller sind, sind sie, wenn sie ohne antistatische Analyse implementiert werden, anfällig dafür, dass fortgeschrittene Angreifer sie leicht erkennen und neutralisieren können.

Vor diesem Hintergrund wollen wir zunächst untersuchen, wie verbreitet die Implementierung folgender Funktionen in heutigen Apps ist: MASVS-RESILIENCE-3 Kontrolle. Dazu haben wir 40 der beliebtesten kostenlosen Apps im Google Play Store überprüft und nach eindeutigen Anzeichen für Code-Verschleierung gesucht.

Was wir gefunden haben

Um unsere Ergebnisse vollständig zu verstehen, müssen wir zunächst unsere Methodik beschreiben. Bytecodebasierte Sprachen wie Java und Kotlin behalten oft Klassen- und Methodennamen bei. Selbst wenn der Code verschleiert ist, können diese Bezeichner Reverse Engineers genügend Hinweise liefern, um die Architektur der Anwendung zu verstehen und einen Angriff zu entwickeln. Die Umbenennung, auch Namensverschleierung genannt, entfernt diese identifizierenden Informationen aus dem Code. Da das Vorhandensein von Umbenennungen (d. h. das Fehlen lesbarer Bezeichner) sehr visuell und leicht erkennbar ist, haben wir dies als Kriterium für diese Analyse verwendet.

Nach der Dekompilierung der Ziel-Apps haben wir sie anhand der Umbenennungshäufigkeit in 3 Kategorien eingeteilt:

• Keine UmbenennungNichts in der App wurde umbenannt, was auf nicht vorhandene oder schwache Sicherheitsvorkehrungen hindeutet.
• Lokale UmbenennungNur einige wenige Teile der App wurden umbenannt, was auf die Verwendung einer Runtime Application Self-Protection (RASP)-Bibliothek für Sicherheitszwecke oder auf eine Konfiguration mit geringem Aufwand hindeuten könnte.
• Globale UmbenennungDer Großteil des Codes wurde umbenannt, was auf den Einsatz einer umfassenden Sicherheitslösung und einer durchdachten Konfiguration hinweist.

Von den ausgewählten Apps waren 37 % völlig ungeschützt, bei 28 % wurden nur wenige Klassen umbenannt, und bei den restlichen 35 % wurde die Umbenennung in den meisten Klassen vorgenommen.

Hierbei ist zu beachten, dass die Umbenennung einzelner Komponenten (28 % der analysierten Apps) diese Bereiche sogar hervorheben kann, da sie die sensibelsten Logiken oder Sicherheitskontrollen für Angreifer sichtbar macht, die diese dann gezielt angreifen und entfernen können. Im Gegensatz dazu verschleiert eine einheitlichere Umbenennung des gesamten Quellcodes (35 % der analysierten Apps) diese Hinweise und erschwert die Identifizierung wertvoller Ziele erheblich. Dies macht die Dekonstruktion des geschützten Codes deutlich schwieriger und verlängert die Zeit für das Reverse Engineering der App erheblich (die wichtigste und zugleich knappste Ressource des Angreifers). In vielen Fällen reicht allein diese erhöhte Komplexität aus, um weitere Angriffe abzuschrecken.

Diese Ergebnisse zeigen, dass sich ein beträchtlicher Teil der App-Entwickler zumindest einige Gedanken über die Sicherheit ihrer Apps macht, aber mindestens ein Drittel der Apps, die im Fokus stehen, kommen immer noch mit Code auf den Markt, der leicht überprüft, modifiziert und neu verpackt werden kann.

Was bedeutet das?

Dies ist von Bedeutung, da ungeschützte oder nur schwach geschützte Apps deutlich leichter Ziel für Reverse Engineering und Manipulationen sind. Bei den meisten Apps bedeutet dies die Preisgabe von geistigem Eigentum, die Offenlegung von API-Schlüsseln oder die Preisgabe von Geschäftslogik, die Angreifer ausnutzen können. Bei Spielen öffnet dies Tür und Tor für Cheating, Modifizierung oder geklonte Versionen, was sich direkt auf Umsatz und Markenintegrität auswirkt. Die aktuelle Verteilung zeigt, dass zwar einige Teams die Sicherheit ernst nehmen, viele aber immer noch große Teile ihres Quellcodes ungeschützt lassen.

Es ist klar: Grundlegender clientseitiger Schutz ist selbst bei vielbeachteten Anwendungen noch kein allgemeiner Standard, und es besteht ein dringender Bedarf an mehr Einheitlichkeit und Sensibilisierung. Der nächste Beitrag dieser Reihe beleuchtet genauer, wie viel schwieriger die Analyse einer gut gesicherten Anwendung im Vergleich zu einer völlig ungeschützten oder nur oberflächlich implementierten Anwendung ist.