iOS Basics
Last updated
Last updated
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
In iOS gibt es einen Unterschied in den Privilegien zwischen den benutzerzugänglichen Anwendungen und den Kernprozessen des Systems. Anwendungen laufen unter der mobile Benutzeridentität, während die entscheidenden Systemprozesse als root arbeiten. Diese Trennung wird durch einen Sandbox-Mechanismus verstärkt, der strenge Einschränkungen dafür auferlegt, welche Aktionen Anwendungen durchführen können. Zum Beispiel, selbst wenn Anwendungen dieselbe Benutzeridentität teilen, ist es ihnen untersagt, auf die Daten anderer Anwendungen zuzugreifen oder diese zu ändern.
Anwendungen werden in einem bestimmten Verzeichnis (private/var/mobile/Applications/{random ID}) installiert und haben eingeschränkten Lesezugriff auf bestimmte Systembereiche und Funktionen, wie SMS und Telefonanrufe. Der Zugriff auf geschützte Bereiche löst eine Pop-up-Anfrage zur Benutzererlaubnis aus.
iOS bietet Entwicklern die Data Protection APIs, die auf dem Secure Enclave Processor (SEP) basieren — einem speziellen Co-Prozessor für kryptografische Operationen und Schlüsselmanagement. Der SEP gewährleistet die Integrität des Datenschutzes über einen einzigartigen, gerätespezifischen Schlüssel, die Geräte-UID, die darin eingebettet ist.
Bei der Dateierstellung wird ein einzigartiger 256-Bit-AES-Verschlüsselungsschlüssel generiert, der den Inhalt der Datei verschlüsselt. Dieser Verschlüsselungsschlüssel wird zusammen mit einer Klassen-ID verschlüsselt, indem ein Klassenschlüssel verwendet und in den Metadaten der Datei gespeichert wird. Das Entschlüsseln einer Datei erfordert die Verwendung des Schlüssels des Systems, um auf die Metadaten zuzugreifen, die Klassen-ID abzurufen und dann den einzigartigen Verschlüsselungsschlüssel der Datei zu entschlüsseln.
iOS definiert vier Schutzklassen für die Datensicherheit, die bestimmen, wann und wie auf Daten zugegriffen werden kann:
Vollständiger Schutz (NSFileProtectionComplete): Daten sind unzugänglich, bis das Gerät mit dem Benutzerpasswort entsperrt wird.
Geschützt, es sei denn, es ist geöffnet (NSFileProtectionCompleteUnlessOpen): Ermöglicht den Dateizugriff, selbst wenn das Gerät gesperrt ist, vorausgesetzt, die Datei wurde geöffnet, als das Gerät entsperrt war.
Geschützt bis zur ersten Benutzerauthentifizierung (NSFileProtectionCompleteUntilFirstUserAuthentication): Daten sind nach der ersten Benutzerentsperrung nach dem Booten zugänglich und bleiben auch dann zugänglich, wenn das Gerät erneut gesperrt wird.
Kein Schutz (NSFileProtectionNone): Daten sind nur durch die Geräte-UID geschützt, was ein schnelles Löschen von Daten aus der Ferne ermöglicht.
Die Verschlüsselung aller Klassen, mit Ausnahme von NSFileProtectionNone, erfolgt mit einem Schlüssel, der sowohl aus der Geräte-UID als auch aus dem Benutzerpasswort abgeleitet wird, was sicherstellt, dass die Entschlüsselung nur auf dem Gerät mit dem richtigen Passwort möglich ist. Ab iOS 7 ist die Standard-Schutzklasse "Geschützt bis zur ersten Benutzerauthentifizierung".
Entwickler können FileDP verwenden, ein Tool zur Überprüfung der Datenschutzklasse von Dateien auf einem iPhone.
In iOS dient ein Schlüsselbund als sicheres verschlüsseltes Container zum Speichern von sensiblen Informationen, die nur von der Anwendung, die sie gespeichert hat, oder von ausdrücklich autorisierten Anwendungen zugänglich sind. Diese Verschlüsselung wird durch ein einzigartiges Passwort, das von iOS generiert wird, verstärkt, das selbst mit AES verschlüsselt ist. Dieser Verschlüsselungsprozess nutzt eine PBKDF2-Funktion, die den Benutzer-Passcode mit einem Salt kombiniert, das aus der UID des Geräts abgeleitet ist, einem Bestandteil, auf den nur der Secure Enclave-Chip zugreifen kann. Folglich bleiben die Inhalte des Schlüsselbunds selbst dann unzugänglich, wenn der Benutzer-Passcode bekannt ist, auf jedem anderen Gerät als dem, auf dem sie ursprünglich verschlüsselt wurden.
Verwaltung und Zugriff auf die Schlüsselbunddaten werden vom securityd-Daemon verwaltet, basierend auf spezifischen App-Berechtigungen wie Keychain-access-groups und application-identifier.
Die Schlüsselbund-API, die in der Dokumentation zu den Schlüsselbunddiensten von Apple detailliert beschrieben ist, bietet wesentliche Funktionen für das Management der sicheren Speicherung:
SecItemAdd: Fügt ein neues Element zum Schlüsselbund hinzu.
SecItemUpdate: Aktualisiert ein vorhandenes Element im Schlüsselbund.
SecItemCopyMatching: Ruft ein Element aus dem Schlüsselbund ab.
SecItemDelete: Entfernt ein Element aus dem Schlüsselbund.
Das Brute-Forcing des Schlüsselbund-Passworts umfasst entweder den direkten Angriff auf den verschlüsselten Schlüssel oder den Versuch, den Passcode auf dem Gerät selbst zu erraten, was erheblich durch die Durchsetzung einer Verzögerung zwischen fehlgeschlagenen Versuchen durch die Secure Enclave erschwert wird.
Die Datenschutzniveaus für Schlüsselbund-Elemente werden mit dem Attribut kSecAttrAccessible während der Erstellung oder Aktualisierung des Elements festgelegt. Diese Niveaus, wie von Apple angegeben, bestimmen, wann und wie Schlüsselbund-Elemente zugänglich sind:
kSecAttrAccessibleAlways: Jederzeit zugänglich, unabhängig vom Gerätesperrstatus.
kSecAttrAccessibleAlwaysThisDeviceOnly: Immer zugänglich, aber nicht in Backups enthalten.
kSecAttrAccessibleAfterFirstUnlock: Zugänglich nach dem ersten Entsperren nach einem Neustart.
kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly: Dasselbe wie oben, aber nicht übertragbar auf neue Geräte.
kSecAttrAccessibleWhenUnlocked: Nur zugänglich, wenn das Gerät entsperrt ist.
kSecAttrAccessibleWhenUnlockedThisDeviceOnly: Zugänglich, wenn entsperrt, nicht in Backups enthalten.
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly: Erfordert den Gerätepincode, nicht in Backups enthalten.
AccessControlFlags verfeinern die Zugriffsarten weiter und ermöglichen biometrische Authentifizierung oder die Verwendung eines Passcodes.
Auf jailbroken Geräten sind die Schutzmaßnahmen des Schlüsselbunds kompromittiert, was ein erhebliches Sicherheitsrisiko darstellt.
Im Gegensatz zu app-spezifischen Daten, die bei der Deinstallation der App gelöscht werden, persistieren Schlüsselbunddaten auf dem Gerät. Diese Eigenschaft könnte es neuen Besitzern eines gebrauchten Geräts ermöglichen, auf die Anwendungsdaten des vorherigen Besitzers zuzugreifen, indem sie einfach die Apps neu installieren. Entwicklern wird geraten, proaktiv die Schlüsselbunddaten bei der Installation der App oder beim Abmelden zu löschen, um dieses Risiko zu mindern. Hier ist ein Swift-Codebeispiel, das zeigt, wie man die Schlüsselbunddaten beim ersten Start der App löscht:
Im Bereich der App-Entwicklung spielt Sandboxing eine entscheidende Rolle bei der Verbesserung der Sicherheit. Dieser Prozess stellt sicher, dass jede App in ihrem eigenen einzigartigen Home-Verzeichnis arbeitet, wodurch verhindert wird, dass sie auf Systemdateien oder Daten anderer Apps zugreift. Die Durchsetzung dieser Einschränkungen erfolgt durch Sandbox-Richtlinien, die Teil des Trusted BSD (MAC) Mandatory Access Control Framework sind.
Entwickler haben die Möglichkeit, bestimmte Funktionen oder Berechtigungen für ihre Apps zu konfigurieren, wie z.B. Datenschutz oder Keychain-Sharing. Diese Berechtigungen werden sofort nach der Installation der App angewendet. Dennoch muss die App für den Zugriff auf bestimmte geschützte Ressourcen die ausdrückliche Zustimmung des Benutzers zum Zeitpunkt des ersten Versuchs einholen. Dies wird durch die Verwendung von Zweck-Strings oder Nutzungsbeschreibungs-Strings erreicht, die den Benutzern in einer Berechtigungsanfrage angezeigt werden.
Für diejenigen mit Zugang zum Quellcode kann die Überprüfung der Berechtigungen, die in der Info.plist-Datei enthalten sind, wie folgt erfolgen:
Öffnen Sie das Projekt in Xcode.
Suchen und öffnen Sie die Info.plist-Datei.
Suchen Sie nach Schlüsseln, die mit "Privacy -" beginnen, mit der Option, rohe Schlüssel/Werte zur Klarheit anzuzeigen.
Beim Umgang mit einer IPA-Datei können die folgenden Schritte befolgt werden:
Entpacken Sie die IPA.
Suchen Sie die Info.plist-Datei innerhalb von Payload/<appname>.app/.
Konvertieren Sie die Datei bei Bedarf in das XML-Format, um eine einfachere Inspektion zu ermöglichen.
Zum Beispiel könnten die Zweck-Strings in der Info.plist-Datei so aussehen:
Die Info.plist-Datei einer App gibt Gerätefähigkeiten an, die dem App Store helfen, Apps nach Gerätekompatibilität zu filtern. Diese sind unter dem UIRequiredDeviceCapabilities-Schlüssel definiert. Zum Beispiel:
Dieses Beispiel zeigt, dass die App mit dem armv7-Befehlssatz kompatibel ist. Entwickler können auch Funktionen wie nfc angeben, um sicherzustellen, dass ihre App nur auf Geräten verfügbar ist, die NFC unterstützen.
Berechtigungen sind ein weiterer kritischer Aspekt der iOS-App-Entwicklung und dienen als Schlüssel-Wert-Paare, die Apps die Erlaubnis erteilen, bestimmte Operationen über Laufzeitprüfungen hinaus durchzuführen. Zum Beispiel beinhaltet das Aktivieren von Datenschutz in einer App das Hinzufügen einer spezifischen Berechtigung im Xcode-Projekt, die dann in der Berechtigungsdatei der App oder der eingebetteten mobilen Bereitstellungsdatei für IPAs reflektiert wird.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
