Files.app Symbolic Link Following

Ron Masas
4 minute read
Content
1. Airdrop2. Attack Setup3. The Bug4. The Attack5. Practical Attack
Timeline

In this post, I'm going to go over how a simple symbolic link could have been used to extract the entire /private/var/mobile/Containers/ folder. This folder contains, among other things, iOS applications data, usually in the form of an unencrypted database. FYI, this is true for many "End-to-end" encrypted messeaging apps like WhatsApp, Telegram, and Facebook Messenger.

Additionally, it contains the "./Shared/AppGroup/[UUID]/File Provider Storage" folder, which is where the "Files" app stores your local files also known as "On My iPhone". And finally, the "Mobile Documents" folder which is the device local copy of iCloud Drive, applications backups, etc.

The research for this bug was bitter sweet, while writing up my report iOS 15 was released, limiting the impact of the bug to "File Provider Storage" and "Mobile Documents" folders. This issue was addressed in the security content of iOS 15.4

Airdrop

Airdrop was first introduced in Mac OS X Lion and iOS 7. AirDrop can be used to share and receive photos, documents, links, and more with other Apple devices that are nearby.

The Bug

The Files Application on iOS does not sufficiently account for when a given file is a symbolic link that resolves to a target outside of the intended control sphere. This allows an attacker to cause the app to operate on unauthorized files.

For one, entire sensitive folders like /private/var/mobile/Containers/ could have been extracted using Airdrop by simply sharing a symlink.

One attack scenario is physical extraction from an unlocked device. Let's say you asked your target for his phone to "call your mom". Once you have the unlocked phone at hand, you download a symlink that points to the information you want to steal and share it with your device using Airdrop.

If you like to reproduce my findings on an iOS device running iOS 14.8.1 and below, do the following:

  1. Create a symbolic link to /private/var/mobile/Containers/ (Other directories may also work, this folder was the highest impact directory I was able to find)
mkdir /tmp/foo
ln -s /private/var/mobile/Containers/ /tmp/foo/share_containers
zip --symlinks -r foo.zip /tmp/foo
  1. Get foo.zip to your iOS device - I did it using Airdrop
  2. Extract foo.zip by tapping on the foo.zip file, and navigate to the foo folder.
  3. Open the share_containers file and click on the share icon at the top right corner.
  4. Share the file using Airdrop.

Sharing may take some time depending on the amount of data you have on your phone. For best results, keep both devices "awake" while the folder is sent.

As I said in the beginning, I wasn't quick enough to report this bug, it was patched on iOS 15. I think the CVE for it was CVE-2021-30855. However, I found that relative symbolic links still work when targeting the "File Provider Storage" and "Mobile Documents" folders. I also found I could store and share symbolic links using iCloud Drive, which makes the attack much more reliable.

Attack Setup

First, we need to create our symlink. In this example, we are going to target the iCloud Drive, so traversing back 2 directories should land us at the iCloud root directory AKA "Mobile Documents".

ln -s ../../ contarct.pdf

In your iCloud Drive, create a new folder and copy "contarct.pdf" into it. Right click on the folder and choose Share > Share Folder

In the Share Folder dialog, set "Who can access" to "Anyone with a link" and click on the share button.

Right click on the folder again, and choose Share > Copy Link.

You should now have a shareable link to a folder with the symlink we just created.

The Attack

All that left for us to do now is share the link with our target, and ask him to send us the contarct.pdf file. If he does, we will gain access to his iCloud Drive files.

When the user sends the contarct.pdf he is actually sharing ../../ which is the "Mobile Documents" folder. Since the user is trying to share a folder, it will be zipped before it sent, in this example via WhatsApp.

The attacker can now download and extract the file to get a full copy of the user iCloud Drive and application backups.

Practical Attack

Since I'm using a test phone, my iCloud Drive is pretty empty. When testing on my own account, I had to wait a few minutes for my phone to generate the zip and a few more just to send it.

A more practical attack would be targeting specific folders within the "File Provider Storage" and "Mobile Documents" folders. Something like the Chrome downloads folder for example.

Conclusion

Symlinks are extremely powerful when hunting for bugs. In my previous post I've used one to bypass the macOS Gatekeeper. Please don't forget to update iOS and iPadOS to 15.4 and macOS Monterey to 12.3.

Timeline