Having played around with an iPad running a jailbreak OS yesterday, I thought it would be useful to explain one possible attack that doesn’t seem to get much coverage.
As I’ve discussed in numerous talks, the data protection feature of iOS (introduced in iOS 4, enabled by setting the NSFileProtectionComplete option on a file or writing data with the NSDataWritingFileProtectionComplete option) only works fully when the user has a passcode lock enabled. The operating system can derive a key to protect the files (indirectly, but that’s another talk) from the passcode, so when the device is locked the files are really inaccessible because the device has no idea what the unlock key is.
This can be seen when you try and access the content via SSH. Of course, the SSH daemon must be installed on a jailbreak operating system, but you don’t need the passcode to jailbreak:
$ ssh -l firstname.lastname@example.org [key/auth exchange...the default password is still 'alpine'] # cd /User/Applications/C393CDBF-1A82-4D7B-A064-D6DFB8CC20DB/Documents # cat UnprotectedFile The flag. You haz it. # cat ProtectedFile cat: Error: Operation not permitted [unlock] # cat ProtectedFile The flag. You haz it.
Now of course you do need physical access to jailbreak, but that doesn’t take particularly long. So here’s a situation that should probably appear in your threat models:
- Attacker retrieves target’s iPad
- Attacker installs jailbreak OS with data-harvesting tools
- Attacker returns iPad to the target
- Target uses iPad
Of course, an attacker who simply tea leafs the target’s iPad can’t perform this attack, and won’t be able to retrieve the files.