search

tweaselORG / meta

(Currently) only used for the issue tracker.
2 stars 0 forks source link

Security considerations for automated analyses of iOS apps #47

Closed baltpeter closed 3 weeks ago

baltpeter commented 3 weeks ago

We will need to allow users to essentially run arbitrary apps on our physical analysis iPhone. Since our options for the analysis environment on iOS are very limited, we will for the most part need to rely on iOS's built-in security features. But of course, we do first need to research whether these are sufficient.

(cf. https://github.com/tweaselORG/meta/issues/48 for Android, and https://github.com/tweaselORG/meta/issues/49 for the whole platform)

baltpeter commented 3 weeks ago

Since we are running on a physical device, we don't have the option to reset the whole device after each analysed app. Thus, the main question that we need to answer is: Can we be sure that there are no traces anymore of an app after we uninstall it[^traces]?

[^traces]: By no traces I only mean things that would affect subsequent analyses. If the app for example saves a few photos in the gallery and these are persisted after the uninstall, that's fine.

baltpeter commented 3 weeks ago

All iOS apps do indeed run in a sandbox:

All third-party apps are “sandboxed,” so they are restricted from accessing files stored by other apps or from making changes to the device. Sandboxing is designed to prevent apps from gathering or modifying information stored by other apps. Each app has a unique home directory for its files, which is randomly assigned when the app is installed. If a third-party app needs to access information other than its own, it does so only by using services explicitly provided by iOS and iPadOS.

System files and resources are also shielded from the users’ apps. Most iOS and iPadOS system files and resources run as the nonprivileged user “mobile,” as do all third-party apps. The entire operating system partition is mounted as read-only. […]

More details on what that actually means in practice: https://0xn3va.gitbook.io/cheat-sheets/ios-application/overview/app-sandbox#protections

The first two are most important for us:

  • […] The application sees its own bundle container /var/containers/Bundle/Application// as the root, similar to the chroot(2) system call. […]
  • Inability to access any other process on the system, even if that process is owned by the same UID. The application sees itself as the only process executing on the system.

More details on the bundle containers: https://medium.com/techiepedia/demystifying-ios-ipados-sandbox-with-swift-code-8c9222d19380

The sandbox mechanism has been in place for a long time, I've found docs going back to at least 2011.

baltpeter commented 3 weeks ago

After a bit of jailbreaking fun, I was able to confirm that the bundle container is indeed deleted when the app is installed.

I installed the Babbel app. Filza told me that Babbel's app container was /var/mobile/Containers/Data/Application/6462BB19-A235-47DF-94DB-C22FDAC721A5:

image

After uninstalling, that directory didn't exist anymore:

image

And after installing again, Babbel got a fresh app container, this time in /var/mobile/Containers/Data/Application/E8FA17EA-0383-4FFD-B32D-2CB160D0C569.

For reference, here's what that folder contains:

image

baltpeter commented 3 weeks ago

I also wanted to check how research on this subject deals with these security questions. There have been various papers (including a whole bunch that I have been involved in myself :D) that analysed hundreds or thousands of iOS apps automatically on real devices, which is of course very similar to our use case.

This is the research I considered:

None of them even mention any security concerns. Even the efforts I was not involved in used a very similar setup to the one we're using. With that, I'm reasonably confident that we can rely on iOS's sandbox.

baltpeter commented 3 weeks ago

Two additional mitigations, which should make it even harder to exploit our platform: