Denken Sie wie ein Bedrohungsakteur: Eine Serie

Motivation hinter dieser Serie

Die ersten Schritte in die Anwendungssicherheit können entmutigend sein. Es gibt unzählige Blogs zur Cybersicherheit und Dutzende von Open-Source- und kostenlosen Angriffstools. Es gibt jedoch nur sehr wenige Informationen, die dabei helfen, die wichtigen Teile aufzuschlüsseln, die eine echte Bedrohung für Anwendungsentwickler darstellen. Ein Großteil der vorhandenen Informationen besteht aus Forschungsergebnissen oder Proof of Concepts.

Diese Serie befasst sich mit den größten Bedrohungen, erklärt, wie man die Angriffe auf die Anwendungen reproduzieren kann, bietet die Grundlagen, die ein Penetrationstester beim Testen Ihrer Anwendung verwendet, und gibt Empfehlungen zum Schutz vor den größten Bedrohungen. Um die besten Methoden zum Stoppen von Bedrohungsakteuren zu erlernen, muss man zunächst ihr Verhalten und ihre Ziele verstehen. Diese Serie konzentriert sich auf die Anwendungssicherheit von iOS. Alle Betriebssysteme haben ähnliche Bedrohungen und Angriffsvektoren. Dennoch hat iOS einzigartige Eigenschaften, da es eine restriktive Anwendungs-Sandbox hat und der Quellcode der Hardware und des Betriebssystems stärker gesperrt ist als bei vielen anderen Systemen. Dieser erste Artikel gibt einen Überblick über die Hintergründe der Einzigartigkeit der Anwendungssicherheit von iOS und befasst sich mit iOS-IPA-Dateiformaten, Anwendungssignierung und Anwendungs-Sideloading, die grundlegende Elemente sind, um den in späteren Teilen dieser Serie beschriebenen Angriffen zu begegnen.

Motive der Bedrohungsakteure

Bedrohungsakteure können eine Reihe von Motiven haben, eine Anwendung anzugreifen. Sie könnten einfach nur darüber bloggen und Informationen verbreiten wollen ;). Bedrohungsakteure könnten es tun, um zu zeigen, dass sie es können. Im Allgemeinen haben Bedrohungsakteure das Ziel, sich selbst finanziell zu bereichern oder ihren Zielen finanziell zu schaden. Als Ausgangspunkt möchte ein Bedrohungsakteur möglicherweise sensible Algorithmen, Kommunikationsprotokolle, APIs oder Geschäftslogiken zurückentwickeln und verstehen, um die Logik in seinen Anwendungen neu zu implementieren. Dieser Prozess kann jedoch schnell dazu führen, dass die DRM- oder Lizenzmechanismen umgangen werden, was möglicherweise zu einer kostenlosen Verteilung der Anwendung führt. Die Grundlagen von Reverse Engineering, Codeänderung und Anwendungsanalyse sind für diese Angriffe dieselben. Die Angriffe verstehenund den Bedrohungsakteuren führt zu einer besseren Verteidigung gegen sie.

Unterschied zwischen Desktop und Mobilgerät Application Security

Jede Plattform und jedes Betriebssystem bietet unterschiedliche Angriffsmethoden. Desktop-Betriebssysteme wie Windows, Linux und Mac bieten auf Betriebssystemebene die geringste Sicherheit. Dadurch können Angriffstools entwickelt oder Anwendungen geändert werden, um die geringere Sicherheit auszunutzen. Anwendungen, die auf mobilen Betriebssystemen wie iOS und Android laufen, haben in der Regel eine eingeschränktere Sandbox als typische Desktop-Anwendungen. Nur weil das Betriebssystem über integrierte Sicherheitsfunktionen verfügt, bedeutet dies jedoch nicht, dass die darauf laufenden Anwendungen immer geschützt sind. safe. Es gibt immer noch Angriffe auf Anwendungen, die auf jedem Betriebssystem laufen.

Sehen wir uns an, was iOS für Bedrohungsakteure anders macht:

  1. iOS bietet Benutzern überhaupt keinen Root- oder Administratorzugriff. Desktop-Betriebssysteme ermöglichen Benutzern jedoch, ihre Berechtigungen zu erhöhen.
  2. Viele Angriffstools müssen auf demselben Gerät ausgeführt werden wie die angegriffene Software. Das Erstellen und Ausführen von Angriffstools auf mobilen Zielen kann schwieriger sein.
  3. Angriffstools gegen iOS werden häufig auf einem gekoppelten Desktop ausgeführt und nicht auf dem iOS-Gerät selbst, was ihre Verwendung und Entwicklung erschwert.
  4. Apple erschwert aktiv die Erlangung erweiterter Berechtigungen. Apple behebt Sicherheitslücken, die zu Jailbreaks führen, und hat Jailbreaks im Laufe der Zeit abgeschwächt und eingeschränkt. Siehe Unser Blog für eine detailliertere Historie. Das Android-Betriebssystem bietet für die meisten Geräte standardmäßig keine Root-Berechtigungen, aber es ist für einen Bedrohungsakteur weniger schwierig, Berechtigungen zu eskalieren.
  5. Unter iOS gibt es weniger Debugging-Funktionen für die Softwareentwicklung. Die Entwicklung erfolgt hauptsächlich in Xcode oder mithilfe von Xcode-Build-Tools im Hintergrund. Die meisten Debugging-Tools sind an Xcode gebunden und verfügen nur über eingeschränkte Funktionen für bereits kompilierte Anwendungen.
  6. iOS-Geräte verfügen standardmäßig weder über SSH noch über eine direkte Terminalverbindung.
  7. Endbenutzer aktualisieren iOS-Geräte schnell mit sich schnell ändernden Betriebssystemen, Hardware und Anwendungen, einschließlich Sicherheitspatches. Dies macht Angriffstools und Malware kaputt und zwingt Bedrohungsakteure zu höheren Wartungskosten.
  8. iOS-Geräte sind teurer, erfordern Apple-Entwicklerkonten und verfügen aus Kostengründen über eingeschränkte Simulator- oder Emulatorfunktionen.

Binäre iOS-Verpackung

iOS IPA-Dateien sind in einem Zip-Format komprimiert, das alles enthält, was zum Ausführen der Anwendung erforderlich ist. IPA-Dateien können einfach entpackt werden, um auf die Binärdateien der App zuzugreifen. Dies ist der erste Schritt zum Reverse Engineering der Anwendung durch statische Analyse. Das folgende Beispiel befasst sich mit der Anwendung Job Dispatcher, die in späteren Teilen dieser Serie als Beispielanwendung angegriffen wird. Die Anwendung ist verfügbar unter https://github.com/digitalai-opensource/job-dispatcher.

% entpacken Job\ Dispatcher.ipa Archiv: Job Dispatcher.ipa Erstellen: Payload/ Erstellen: Payload/Job Dispatcher.app/ Erstellen: Payload/Job Dispatcher.app/_CodeSignature/ Aufblasen: Payload/Job Dispatcher.app/_CodeSignature/CodeResources Aufblasen: Payload/Job Dispatcher.app/AppIcon60x60@2x.png Aufblasen: Payload/Job Dispatcher.app/Assets.car Aufblasen: Payload/Job Dispatcher.app/AppIcon76x76@2x~ipad.png Aufblasen: Payload/Job Dispatcher.app/Job Dispatcher Aufblasen: Payload/Job Dispatcher.app/embedded.mobileprovision Aufblasen: Payload/Job Dispatcher.app/Info.plist Aufblasen: Payload/Job Dispatcher.app/PkgInfo

Dies ist eine kleine Anwendung, und große Anwendungen enthalten viele Binärcodedateien und zahlreiche Assets, Frameworks und andere Anwendungsinhalte. Diese Anwendung enthält nur eine einzige ausführbare Binärdatei mit dem gleichen Namen wie die IPA der obersten Ebene „Job Dispatcher“. Mit dem Befehl „file“ können wir überprüfen, ob es sich um eine ausführbare Datei handelt.

% Datei Job\ Dispatcher Job Dispatcher: Mach-O 64-Bit ausführbare Datei arm64

Mach-O ist das von Apple-Betriebssystemen verwendete Binärdateiformat und alle aktuellen iOS-Geräte verwenden ARM64-CPUs.

Wir haben jetzt Zugriff auf die Datei, die wir in zukünftigen Teilen dieser Serie zurückentwickeln und ändern möchten. Wenn wir mit dem Angriff auf die Anwendung fertig sind, können wir den gesamten Inhalt zippen und die ZIP-Datei wieder in eine IPA-Datei umbenennen, um die IPA-Datei zu erstellen. Wenn die Dateien geändert werden, müssen wir die Anwendung ordnungsgemäß neu signieren oder seitlich laden, um sie zu installieren.

Signieren geänderter iOS-Anwendungen

Das Signieren von Anwendungen für iOS erfolgt normalerweise über die Xcode-GUI beim Erstellen einer Anwendung oder über das Befehlszeilentool Codesign bei Verwendung der Befehlszeile. Diese Tools unterliegen Einschränkungen beim erneuten Signieren einer Anwendung nach der Änderung kompilierter und signierter Binärdateien, was der typische Anwendungsfall für einen Bedrohungsakteur ist. Um eine geänderte Anwendung erneut zu signieren, kann ein Tool wie iOS App Signer rekursiv alle Dateien in einem IPA durchgehen und sie alle erneut signieren. Dieser Ansatz erfordert ein Apple-Entwicklerkonto, und Xcode gibt einen Fehler aus, wenn eine Anwendung installiert wird, die mit einem anderen Zertifikat auf einem inaktivierten Gerät erneut signiert wurde. Beachten Sie, dass zum Angreifen von iOS-Anwendungen häufig das Herunterladen und Ausführen potenziell gefährlicher Codes erforderlich ist. Caveat Emptor!

Sideloading modifizierter iOS-Anwendungen

Ein alternativer Ansatz zum erneuten Signieren und Installieren geänderter Anwendungen ist die Verwendung eines Sideloading-Tools. Sideloading umgeht Sicherheitsbeschränkungen beim erneuten Signieren von Anwendungen und kann verwendet werden, um Einschränkungen bei unterstützten Geräten und iOS-Versionen zu umgehen. Ein leistungsstarkes Tool zum Sideloading von iOS-Anwendungen ist Sideloadly. Seien Sie vorsichtig beim Herunterladen und Installieren vorgefertigter Anwendungen, bei denen Sie den Quellcode nicht überprüfen können.

Denken Sie wie ein Bedrohungsakteur. Miniaturansicht

wegnehmen

Wenn Sie Bedrohungsakteure und ihre Angriffsmethoden verstehen, können Sie sicherere Anwendungen erstellen. In den nächsten Monaten werden hier eine Reihe von Artikeln erscheinen, die verschiedene Angriffsmethoden beschreiben. In vielen Fällen bauen die Angriffe aufeinander auf. Bedrohungsakteure müssen beispielsweise Jailbreak ihres Geräts bevor sie Frida in vollem Umfang installieren und ausführen können. Bedrohungsakteure müssen außerdem Anwendungen neu starten oder sideloaden, um Änderungen zu testen. Der erste anstößige Artikel (in Kürze verfügbar!) zeigt, wie man eine Beispielanwendung ändert, um eine Authentifizierungsfunktion zu umgehen.

 

Klicken Sie auf werden auf dieser Seite erläutert für eine kostenlose Bedrohungsbewertung Ihrer App.

Auch interessant