iOS Credential Leakage

Now that iOS 5 has released and Apple CLAIMS to have fixed the issue, I believe its time for a full disclosure...

What Users/Enterprises MUST know:

I had reported a security vulnerability with iOS 4 implementation to Apple in OCT 2011. This vulnerability allows an attacker with physical possession of an iOS device or an attacker with the ability to remotely jailbreak a device to retrieve the victims EXCHANGE/Account (email or exchange account) credentials (username + password) in clear text.

Hence, if an iOS 4 device is lost/unwillingly jailbroken, immediate steps MUST be taken to ensure that the users credentials are RESET or account locked. Remote administration options like Remote Wipe/Lock/Locate are not effective as an attacker can easily bypass or block remote administration options.

This issue has been partially addressed and fixed by Apple in iOS 5. New changes in iOS 5 ensures that the credentials on an iOS device remain secure if a device is lost/stolen. However, the risk of leakage is NOT COMPLETELY fixed and is explained in detail below.

REFER section CURRENT THREAT for more information and remediation/mitigation strategies.


Current Status:

Apple claims to have fixed the issue in iOS 5 with the introduction of 2 new protection classes:
  • NSFileProtectionCompleteUntilFirstUserAuthentication (class C, CLAS=3)
  • NSFileProtectionCompleteUnlessOpen (class B, CLAS=2)

However, through these changes, Apple has ONLY succeeded in protecting consumers from credential leakage from an attacker with physical access to a device. For example, these changes prevents at an attacker with access to a lost/stolen device from retrieving the clear text credentials unless the device is unlocked ONCE (just once...) by the end-user. The RISK of credential leakage is still at large (under certain circumstances) and is explained below in section CURRENT THREAT.

The new protection classes limits the ability of MAIL APP on iOS to decrypt credentials in keychain until the end-user unlocks the device ONCE after a reboot. Though these changes fix ONE of the attack vectors, the new iOS 5 changes have weakened the security posture of the system and has actually made it easier for attackers leveraging remote and targeted attacks to obtain credentials from iOS devices (explained in technical details section).

SOGETI Labs has a good explanation of these new protection classes here, though the actual reason behind the change and mail app implementation was unknown or not explained in their blog.

CURRENT THREAT:
  • If the end-user finds/gets back a lost/misplaced device and unlocks the device, the attacker can still leverage this vulnerability to retrieve clear text credentials
  • If an attacker has physical access to an iOS device (for a short time) and can jailbreak the device and slip it back without being noticed by end user, the attacker can remotely retrieve credentials
  • Targeted attacks and remote exploits (using pdf's or image files) can still retrieve clear-text credentials from the device. This could be a good target for APT's and targeted attacks (like Aurora or RSA...) as a point of entry into corporate networks
  • iOS 5 removed SOP implementation in keychain, which was used in iOS 4 for protecting credentials and potential SSL stripping attacks. Makes attack easier for remote/targeted attacks
  • Onus is on users and MDM vendors to detect device compromise and accidental/targeted jailbreaks
Recommendation:
  • Upgrade to iOS 5 (this only fixes one aspect of this attack)
  • DO NOT UNLOCK an iOS device if a device was retrieved after a lost/stolen scenario. Ensure that the device is WIPED before reusing
  • Enhance jailbreak detection capabilities on iOS devices to detect unwilling/remote jailbreaks
  • Block user account and reset password if device is lost or unwillingly jailbroken
Technical Details:

As part of this vulnerability, an attacker with ability to jailbreak a device (physical access or remote) can modify the system behavior to forward exchange credentials to an attackers server.

iOS 4:
In iOS 4, an attacker had to manipulate the Single-Origin-Policy protection for account credentials in "inet" table of keychain and modify the system DNS behavior to retrieve the clear text credentials. By doing so, the attacker can manipulate the iOS system and force the system to decrypt the credentials stored in the keychain and forward the same to a server owned and controlled by the attacker.

iOS 5:
In iOS 4, this was a multi step attack and required a skilled attackers observation (though the attack is technically simple). With changes in iOS 5, Apple changed keychain implementation and got rid off SOP protection feature. The reasons for removing SOP is still unknown at this point. However, by doing so iOS no longer validates which server , protocol or port has access to stored credentials. This essentially allows an attacker to directly manipulate the system behavior to send clear text credentials to an attackers server without any constraints or restrictions. The attacker only have to change ONE configuration file owned and accessed by system user "mobile", to be able to perform this attack.

PS: Obvious technical explanations with held in public interest. Contact me if you have a legitimate reason to learn further about the same.

Comments

Popular posts from this blog

Problems with Equifax Breach Disclosure

Potential DoS Vulnerability with Android System

Why does my Android App READ SMS?