iOS Backup Passcode Prompt
Briefly
Security researcher Csaba Fitzl reported a security issue to Apple with iOS/iPadOS backups where an attacker could trigger a backup without a user’s consent to steal their data (CVE-2022-32929 - Bypass iOS backup's TCC protection). Since iOS/iPadOS backups are not encrypted by default and can optionally be stored in a custom location outside of the standard protected macOS TCC location
~/Library/Application Support/MobileSync/Backup
, user data is potentially at risk, even if the risk is low since it requires the device to be initially paired with the computer.To mitigate the issue, Apple has since released iOS versions 16.1 and 15.7.1, introducing a new passcode prompt displayed by iOS on the device when a backup operation is attempted.
The side effect for those using iMazing or the AppleMobileBackup CLI tool to back up their devices automatically is that they must now enter their device passcode before every backup. This can be extremely inconvenient or impractical for reasons detailed below.
We believe a more elegant solution would be to ask the user to enter the device passcode only when backup encryption is disabled for the device.
Context
iOS/iPadOS device and computer pairing
Communication between an iOS or iPadOS device and a computer running macOS or Windows requires the user to enter their device passcode to establish a pairing relationship between the device and computer. This pairing record is effectively certificate private/public keys that reside both on the device and the computer.
On the iOS or iPadOS device, the pairing records are stored in a secure location.
On recent macOS versions, the pairing records are also stored in a secure location /var/db/lockdown
that is not accessible without disabling SIP, or System Integrity Protection.
On Windows, the pairing records are unfortunately not yet stored in a secure location C:\ProgramData\Apple\Lockdown
, but that’s another story.
To pair a device and computer, users need to enter the device's passcode. Once pairing is established, any user or app on the machine can theoretically communicate with the iOS device and access various services running on this device.
iOS backups, encryption and location
Once a device and computer are paired, an important iOS/iPadOS service that enables backups becomes accessible from the computer: BackupAgent. BackupAgent is a daemon in charge of preparing the backup (analyzing the files that need to be backed up from the device), encrypting the backup, and streaming it to the computer. It’s important to note that the computer is not in charge of encrypting the backup, BackupAgent is.
By default, iOS backups are not encrypted. Users must enable backup encryption from Finder on macOS, iTunes on Windows, or third-party apps like iMazing. Enabling backup encryption requires the user to define an encryption password (set from the computer, but stored on the device), then BackupAgent displays a passcode prompt on the device to make sure the user truly has permission to enable encryption.
In other words, by checking if the user knows the device passcode, BackupAgent verifies that the user has ownership of the device. This verification step is important since it proves not only that the user has ownership of the device, it also proves that the user has ownership on the data stored on it, since they are the one who defines the encryption password and only they can decrypt the data.
iMazing is capable of decrypting, browsing, and extracting data from iOS and iPadOS backups, so it is crucial to always enable backup encryption to ensure the data cannot be decrypted without the owner's consent.
The problem is two-fold:
- Backup encryption is by default disabled and not enforced on iOS.
- Once pairing is established between a device and computer, any app or user can trigger a backup from the computer.
Therefore, a user could theoretically pair their device with a computer, and another user or app on the machine could initiate a backup in an attempt to steal data if backup encryption is not enabled.
This is especially true since there are ways to store iOS backups outside of the macOS TCC protected location at ~/Library/Application Support/MobileSync/Backup
. TCC is the Transparency, Consent, and Control system in macOS, an important security layer.
On Windows, the default backup location is not protected at all: C:\Users\<username>\AppData\Roaming\Apple Computer\MobileSync\Backup
.
This scenario is what security report CVE-2022-32929 describes.
iOS/iPadOS 16.1.x and 15.7.1 make automatic local backups awkward
Since iOS and iPadOS versions 16.1 and 15.7.1, released 24 October 2022, Apple introduced a new security measure to mitigate the security issue raised by CVE-2022-32929, requiring users to enter their device passcode every time a local backup is about to start.
Many users prefer to locally back up their devices instead of using iCloud, the reasons for which are numerous and include, but are not limited to:
- Not wanting to be dependent on an Internet connection
- Preserving cellular data
- Privacy
- Cost
For many years, these users have been able to use apps like iMazing or the AppleMobileBackup CLI to automatically backup their devices over their local Wi-Fi network.
While the new security measure Apple introduced is intended to protect user data, it also makes automatic backups less seamless and more disruptive. These obstacles could lead to a reduction in backup frequency, which would actually put user data at risk.
Entering a device's passcode is impossible if the backup occurs overnight, or if devices are locked away charging (a common use case for schools or small businesses).
If you are interacting with the device when an automatic backup is attempted, your use of the device is completely interrupted by the passcode prompt, which can also be disruptive.
In any case, the more frequent your automatic backups, the more awkward backing up your device becomes with this new paradigm. Many iMazing users elect to back up their devices daily, and thus will be prompted 365 times per year for the passcode for each device of theirs that they wish to back up.
Did you kill my automated local backups with @DigiDNA?
— Johannes Obermayr (@j_obermayr) November 12, 2022
"CVE-2022-32929: Csaba Fitzl (@theevilbit) of Offensive Security" in section Backups herehttps://t.co/TkdndT1DBH
Do you have a suggestion how to do my family's automated local backups now?
(iCloud is not an option for us)
Here you go. You are probably right, it seems that this is how Apple fixed the issue at the end. 😳https://t.co/762nRZzo3s
— Csaba Fitzl (@theevilbit) November 14, 2022
A more user-friendly solution
We believe a better approach to this issue would be to prompt the user for a device passcode before every backup only if backup encryption is disabled, considering that:
To enable backup encryption, a user must enter their device passcode while defining the backup encryption password.
It is impossible to disable backup encryption or change the backup encryption password without entering the device passcode and the previous backup encryption password.
The data stored in an encrypted backup can only be read with the encryption password, as defined by the user.
Therefore, this is an effective way to protect user data while also encouraging users to enable backup encryption, which we at DigiDNA have always strongly recommended. iOS/iPadOS device backup encryption is extremely secure when the backup password is adequately strong.
Last words
It is our hope that Apple will be listening to the user community on this subject, as backing up iOS and iPadOS devices locally has become more difficult than it should be.
Sources referenced
- Csaba Fitzl: CVE-2022-32929 - Bypass iOS backup's TCC protection
- Apple: System Integrity Protection
- Apple: Transparency, Consent, and Control
- iMazing: iOS Backup encryption