Artem Azariev, Leiter des Zentrums für die Kompetenz von Ferndienstkanälen der Direktion für Informationstechnologien des ICDHallo Habr!
Mein Name ist Artyom Azariev, ich bin der Teamleiter für das Android-Team der Moskauer Kreditbank und heute möchte ich über Anwendungssicherheit aus Sicht von Debug-Bibliotheken sprechen. Ein paar Jahre war ich freiberuflich tätig, dann war ich 4 Jahre lang in der vollwertigen Entwicklung für ein mobiles Betriebssystem tätig. So kam es, dass ich in den Jahren meiner freiberuflichen Tätigkeit, um meine eigenen Qualifikationen zu verbessern, das Thema Reverse Engineering von Android-Anwendungen ansprach und es allmählich zu meinem Hobby wurde.
Einführung
Es ist kein Geheimnis, dass Android Studio lange Zeit keine Mechanismen für den angemessenen Empfang von Anwendungsdaten vom Gerät vorgestellt hat: den Inhalt der Datenbank, SharedPrefrences, Netzwerkanforderungen. Alle haben gelitten, auch Riesen wie Facebook.
Sie haben der Community eine äußerst nützliche Bibliothek zum Debuggen von Shetho (https://github.com/facebook/stetho) mit einer sehr einfachen Integration in das Projekt in nur wenigen Zeilen zur Verfügung gestellt. Ich werde nicht über die Bibliothek selbst sprechen, wahrscheinlich wissen es viele Leute bereits, aber wen interessiert das schon, sie lesen es selbst.
Die Integration dieser Bibliothek ist wie folgt:
Mit dem Chrome-Browser haben wir Zugriff auf den Inhalt der Datenbanken und auf die auf dem Gerät gespeicherten Einstellungen. Wenn wir das Plug-In für okhttp3 verbinden, dann auch auf den Inhalt von Netzwerkanforderungen.
"Aber hey, wird es auch im Release Build sein?" - Der aufmerksame Entwickler wird sich fragen. Wenden wir uns der Beschreibung der Bibliothek zu - was raten wir dazu?
Das Beispielprojekt zeigt, dass diese Bibliothek nur im Debug-Zweig initialisiert werden muss, indem das Manifest in einer der Build-Optionen überladen wird.
Wir montieren die Release-Assembly mit aktivierter Minifizierung (Flag minifyEnabled). Wir überprüfen den Browser, sehen keine Anwendung zum Debuggen und gehen ruhig in den Ruhezustand.
Die Minimierung ist ein Prozess, der darauf abzielt, die Größe des Quellcodes zu reduzieren, indem unnötige Zeichen entfernt werden, ohne die Funktionalität zu ändern. Das in Android verwendete Proguard-Tool ist auch an der Bereinigung des Projekts von nicht verwendetem Code beteiligt.Hacker
Jedes Reverse Engineering der Anwendung beginnt mit der Untersuchung potenzieller Lesezeichen und Hintertüren, die die Entwickler freundlicherweise für sich selbst hinterlassen haben.
Zunächst dekompilieren wir die Anwendung in Java so weit wie möglich und untersuchen den Paketbaum.
Das süßeste, was in der angegriffenen Anwendung zu finden ist, ist der gute alte Stetho. Die standardmäßig konfigurierte Minifizierung entfernt sie nicht, und im Allgemeinen wird die gesamte Codebasis dieser Bibliothek einfach in einen Produktionsbuild gezogen.
Ich habe viele Anwendungen von ziemlich coolen und großen Unternehmen gesehen, die eine solche Bibliothek seit vielen Jahren in Produktionsgebäuden hinterlassen haben.
Jemand wird fragen: „Und was ist das? Es ist aus. Selbst wenn Sie es aktivieren, versuchen Sie später, diese App zu erstellen. “
Richtig, das Dekompilieren in Java liefert fast nie 100% Arbeitscode. Aber es gibt Smali / Backsmali.
Smali / backsmali ist ein Assembler / Disassembler für das Dex-Format, das von Dalvik, einer Implementierung von Java VM in Android, verwendet wird.
Wenn wir unsere Anwendung zerlegen, werden wir feststellen, dass nichts wirklich enthalten ist.
Nachdem wir jedoch ein paar Zeilen hinzugefügt und den gesamten Code der Bibliothek im Projekt gespeichert haben, können wir ihn ohne besondere Anstrengung wieder einschalten.
Für das okhttp3-Plugin wird die Unterstützung auf die gleiche Weise aktiviert - durch Hinzufügen eines Interceptors zu OkhttpClient.
Nachdem wir die Anwendung zurückgesammelt haben (und es ist einfach, sie von smali aus zu erstellen), sehen wir, dass das Debuggen über stetho wieder verfügbar ist und alle Ihre Daten im lokalen Einstellungs-Repository Ihre gesamte API vollständig vor den Augen schlauer Hacker sind.
Was tun?
Es gibt viele Optionen, um Pakete vom endgültigen Build auszuschließen. Persönlich ziehe ich es vor, einen kleinen Wrapper zu schreiben, um die Stetho-Bibliothek zu initialisieren und ihre verschiedenen Implementierungen gemäß den Assembly-Optionen zu zerlegen.
freigeben
debuggen
Geben Sie außerdem an, dass diese Codebasis nur im Debug-Build benötigt wird.
Kann ausatmen
Abschließend möchte ich die Grundprinzipien ansprechen, die ich bei der Arbeit im Zusammenhang mit der Sicherheit von Android-Anwendungen verwende:
- Minimieren und verschleiern Sie, wenn möglich, alles, was Sie bekommen.
In jedem Fall erschwert dies die Analyse des dekompilierten Codes. Ein zusätzliches Argument für die Erzeugung von grauem Haar auf dem Kopf des Hackers ist das Flag für das Umpacken von Klassen, mit dem die minimierten Klassen in ein Paket verschoben werden. Es wird viele von ihnen geben. - Entdecken Sie Ihre eigenen Anwendungen.
Zumindest eine flüchtige Überprüfung des Baums Ihrer Pakete kann viel über die im Projekt verwendete Struktur, Frameworks und Bibliotheken aussagen. Was dort offensichtlich nicht hingehört, sollte gnadenlos entfernt werden. - Jedes Werkzeug kann Sie früher oder später ins Knie schießen.
Wenn Sie Ihrem Projekt auch aus guten Gründen etwas hinzufügen, denken Sie darüber nach, wie Sie es richtig machen und wie viel Sie überhaupt brauchen.
Ich hoffe, meine Erfahrung wird Ihnen nützlich sein.