Was wird geprüft?

Im Sicherheitsgutachten für Sicherheit in Apps (LiGSA) führen wir zwei Kernanalysen durch, um anschließend unser Liasoft Siegel für Sicherheit zu vergeben.

Statische Analyse

In der statischen Analyse werden viele Faktoren auf Sicherheitsmängel untersucht. Bei dieser Analyse wird zunächst mit einer Übersicht begonnen. Das heißt es wird Ihre Anwendung nach benutzten Frameworks und Libraries untersucht.

Untersuchung des Archivs und der Verzeichnisstruktur

Hier ermitteln wir die ersten Informationen über Ihre Anwendung. Wir erstellen eine Liste der zu analysierenden Binaries, dekompillierbaren Dateien und gleichen Dritthersteller Libraries mit unseren Datenbanken ab und ermitteln alle Frameworks die auf dem ersten Blick verwendet werden. Mit den hier gewonnen Informationen wird der nächste Schritt der Analyse eingeleitet.

Managed Ressourcen sammeln und vorbereiten.

Als ‚managed‘ Ressource bezeichnen wir Code der über eine Runtime geladen wird. Das kann Bytecode oder interpretierbarer Code sein. Sämtlichen Code dekompillieren wir automatisch um die nachfolgende Analyse durchzuführen. Das heißt im Konkrekten, dass wir alle Java Dateien, .NET Assemblies, Javascript Dateien uvm. dekompillieren und deobfuscaten. Diese Schritte passieren automatisch. Aktuell unterstützen wir an dieser Stelle über 50 verschiedene Frameworks und Technologien und es werden beinahe wöchentlich mehr.

Binaries sammeln und vorbereiten.

Im Anschluss ermitteln wir alle nativen Binaries (C, C++, Objective-C) also Executables und Shared Libraries die in Ihrer Anwendung integriert sind.

Analysis

Nach sammeln der Metadaten und analysierbaren Dateien startet eine tiefgehende Analyse. Wir haben eine gezielte Checkliste und einen Workflow dem wir nachgehen. Es sollte verständlich sein, dass wir hier nicht den internen Arbeitsfluss dokumentieren. Dennoch möchten wir eine kurze Übersicht einiger Punkte geben nach denen gesucht wird:

  • Metadaten
  • Import/Export Tables?
  • Segmente die ungewöhnlich sind (Packer).
  • Gibt es verschlüsselte Strings? Wie leicht sind diese zu dekodieren?
  • Anti-Debugging checks?
  • Syscalls?
  • RTTI Information vorhanden?
  • Protobuf (mit Metadaten) vorhanden?
  • Script Engine vorhanden die Metadaten exportiert?
  • Sind Zertifikate eingebunden?
  • Wird Code zur Laufzeit modifiziert? (PAGES)
  • Gibt es eine Control Flow Obfuscation?
  • Gibt es Stack Spilling?
  • Wird eine Shell mit User-Input aufgerufen?
  • Gibt es bekannte Verschlüsselungs-Libraries?
  • Debug-Informationen?
  • Welche Libraries werden verwendet?
  • Binaries/Android only: Werden interne Java APIs verwendet?
  • .NET: Ist der gesamte Programmcode wiederherstellbar?
  • .NET: Gibt es einen Schutz gegen IL Patching?

Mit den gewonnen Informationen haben wir aus Sicht des Reverse-Engineerings sehr viele Metadaten und eine große Wissensdatenbank über die internas Ihrer Anwendung. Aus unserer Erfahrung können wir mit diesen Informationen ein Angriffsszenario planen.

Laufzeitanalyse

In der Laufzeitanalyse greifen wir Ihre Anwendung gezielt an. Das heißt (sofern notwendig) hebeln wir sämtliche Sicherheitsfunktionen wie Anti-Debugging, SSL Certificate Pinning oder Verschlüsselungen aus und versuchen in irgendeiner Form die Anwendung anzugreifen. Das hängt natürlich sehr stark vom Nutzen Ihrer Anwendung ab und ist in jedem Fall unterschiedlich.

Angriffsszenarien während der Laufzeitanalyse

  • Können wir noch mehr Metadaten zur Laufzeit extrahieren? (Datenbanken, Script-Registrierungen, etc.)
  • Können wir einen MITM Angriff machen um auf Ihre APIs zuzugreifen?
  • Können wir sogar eine vermeintlich sichere Verbindung ohne großen Aufwand komplett nachimplementieren?
  • Verarbeitet Ihre Anwendung oder Ihr Backend fehlerhafte Daten richtig?
  • Sind Daten-Leaks von Ihrem Backend oder sogar von Benutzerdaten möglich?
  • Können wir uns in irgendeiner Form des Angriffs einen Vorteil erschaffen, den ein normaler Benutzer nicht erreichen kann?