Question about documentation - iOS fingerprint bypass

[MacJu]

Hello,
I'm currently testing a Cordova plugin which sets access control flags like the following

SecAccessControlRef accessControlRef = SecAccessControlCreateWithFlags( kCFAllocatorDefault, kSecAttrAccessibleWhenUnlockedThisDeviceOnly, kSecAccessControlUserPresence, &accessControlError);

From my understanding and after research, the kSecAccessControlUserPresence flag is equivalent to specifying kSecAccessControlBiometryAny, kSecAccessControlOr, and kSecAccessControlDevicePasscode.

https://developer.apple.com/documentation/security/secaccesscontrolcreateflags/ksecaccesscontroluserpresence

The materials stored in the Keychain or filesystem are protected with protection classes (such as kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly and kSecAttrAccessibleWhenUnlockedThisDeviceOnly), and the SecAccessControlCreateFlags is set either with kSecAccessControlDevicePasscode (for passcodes), kSecAccessControlUserPresence (passcode or touchid), kSecAccessControlTouchIDAny (Touch ID) or kSecAccessControlTouchIDCurrentSet (Touch ID: but current fingerprints only).

So based on the statement in the wiki

What should be clear now is that this 'bypass' is purely a local bypass for when a target application calls evaluatePolicy and a failed response is received. This 'bypass' will not work in cases where keychain items are protected with access control flags such as kSecAccessControlTouchIDAny or kSecAccessControlTouchIDCurrentSet.

https://github.com/sensepost/objection/wiki/Understanding-the-TouchID-Bypass

The plugin sets the correct flags which should protect against the bypass, but it is currently not the case.
What I can't understand now is how can these flags protect against Objection's bypass when it returns a True to whatever the [LAContext evaluatePolicy:localizedReason:reply:] replies.

Thanks.

[leonjza]

Hey,

There are few things I think may need some clarifying, so let me try to explain to the best of my knowledge. Bear with me if you already know the theory, but I hope it helps explain better in the end!

The first thing to talk about I think is the differences in usages of something like *SecAccessControlRef() and [LAContext evaluatePolicy:localizedReason:reply:]. The former, as you know, is purely for configuration of the Access Control applicable to a keychain entry. Set it to something like kSecAccessControlBiometryAny, then a valid set of biometrics (either TouchID or FaceID) must be presented before the key is released from the Secure Enclave to decrypt the keychain entry itself. Setting it to something like kSecAccessControlBiometryCurrentSet instead means that if the enrolled set of biometrics changes, the key is no longer retrievable from the Secure Enclave, and by virtue invalidates any keychain entries too. I am not 100% familiar with the behavior of kSecAccessControlUserPresence, but I suspect you will be prompted for your current passcode (if TouchID is not available) to release the required key from the Secure Enclave (something I can test and feedback on later). Nonetheless, to see these protections in action, having keychain items available that were set with these attributes will result in the keychain dumper module triggering prompts on the device for whichever authentication mechanism is needed (TouchID / FaceID) as the dumper enumerates them. This specific scenario is not bypassable (even on jailbroken devices).

Now the second method speaks specifically about local authentication. It is possible for developers to use local authentication to protect parts of their application, triggering prompts based on either a LAPolicyDeviceOwnerAuthenticationWithBiometrics or LAPolicyDeviceOwnerAuthentication policy before performing an action. In this case, an Obj-C block exists within the target application that is reachable with Frida can be manipulated. Typically, when [LAContext evaluatePolicy:localizedReason:reply:] is called, as the reply block is invoked, the operating systems' response is what is manipulated, meaning that whatever the condition for success is, will be the code path taken. An important note to make here is that [LAContext evaluatePolicy:localizedReason:reply:] is not used to access keychain items directly, however the success condition for the reply block may have logic that in itself may retrieve items from the keychain (which is an insecure implementation if the expectation is that this sufficiently protects a keychain item with biometrics).

In summary, [LAContext evaluatePolicy:localizedReason:reply:] is just a way to prompt a user to enter the devices passcode or present a valid set of biometrics, which is bypassable as we can intercept the operating systems response to the application for that. Whatever the success condition for a correct authentication scenario is, is not directly relevant to the bypass, other than the fact that it forces that specific code path. As for keychain entries, those are handled outside of a target application (and in reality isolated within the Secure Enclave) and therefore can not be manipulated other than by providing the correct authentication needed.

My suggestion would be to double check the logic within the reply block for your target application and see what its up to there.

Hope this helps clear things up a bit!

[MacJu]

Hello,
Thanks for the really good explanation.
In the time I asked the question, I did not have access to the full source-code, only the plugin.
It seems like when they were creating the keychain key, they did not call the correct function which actually sets the flags.

I believekSecAccessControlUserPresence protects the keychain as good as kSecAccessControlBiometry*or kSecAccessControlTouchID*, but have not got the updated code yet.

Thanks again!

[poldenais]

HI there,
I have a question on this. If I was able to use Objection to bypass Biometrics authentication thats being implemented on a iOS application, is that an issue for Development?

[leonjza]

@poldenais You will need to threat model your particular case. Some more information is available here.