Common Application Vulnerability with Touch ID

Fingerprint access to Apple devices and applications today is actually standard. It is much more convenient than dialing codes, and also looks safe.

It turns out that it is easy to access almost any application with a Touch ID; all you need to do is to know only the password from blocking (passcode) the device itself from Apple, the Cadmus laboratory reports.

Knowing the passcode, it becomes possible to add a fingerprint to the system, and then use it to log into applications by ignoring their own login codes. And if the password for the device is not set, then the applications are absolutely not protected. At all.

Under such circumstances, it turns out that when using Touch ID, authorization interfaces in applications simply do not play any role. Passcode of 4 or 6 digits gives you the opportunity to get full access to any applications.

The applications that are considered the most secure have been checked, i.e. financial applications, banking, to access remote devices and computers, online stores, password keepers, notebooks, task managers, cloud storages and various others.

How did this happen?

The fact is that since the advent of iOS 7, Touch ID functionality could only be used by Apple itself. In iOS 8, the company opened access to a fairly limited API for developers, which provided information only about whether a known footprint was used or not. This functionality was intended more for confirmation of operations, and not for authorization in applications, but everything was decided differently.

Most developers, evaluating the convenience of new items, quickly implemented the function of entering fingerprints into applications. Although the technology has not yet provided an adequate level of security.

In iOS 9, new features were opened in the API for working with Touch ID and a method appeared to control changes in the composition of prints, but since code samples have already been distributed online, almost all developers continue to ignore these features. Some of them, when discussing vulnerabilities, are still confidently reporting that this is an acceptable risk. Although it is logical that if the passcode is enough to get into the application, then why do we need an authorization screen?

What do developers do?

The fix for this vulnerability was made possible starting with iOS 9.

Follow Apple's recommendations, which are available in the technology description and are listed in the developer documentation . Examples of applications with this type of protection are Sberbank Online or the AppStore.

If you use KeyChain for authorization (which is more organic in the framework of the Apple security model), then, as a rule, it is enough to change just one line of code, or to add a script using the ability to determine the change in the composition of prints.

Fingerprint authorization control in iOS 8

CFErrorRef error = NULL; SecAccessControlRef sacObject = SecAccessControlCreateWithFlags(kCFAllocatorDefault, kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly, kSecAccessControlUserPresence, &error); 

Fingerprint authorization control in iOS 9

 CFErrorRef error = NULL; SecAccessControlRef sacObject = SecAccessControlCreateWithFlags(kCFAllocatorDefault, kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly, kSecAccessControlTouchIDCurrentSet | kSecAccessControlDevicePasscode, &error); 

A special feature is the use of the kSecAccessControlTouchIDCurrentSet attribute, which protects against the use of new fingerprints in iOS.

Epilogue

Surprisingly, security-sensitive applications are moderated when placed in the AppStore.

It also looks strange that information about new iOS security models is not communicated to developers.

However, this type of authorization protection is possible and works since iOS 9.