or the False Sense of Security of Dropbox’s Passcode Protection Since the release of iOS 8, the Touch ID fingerprint sensor can now also be used in third-party apps. The Local Authentication framework provides an API via which users can conveniently deploy their biometric fingerprint to authenticate themselves in both apps from the App Store and enterprise apps. In the medium term, we anticipate that more and more apps will switch to the fingerprint method of user authentication.
A comparison before and after iOS 8 was released As part of one of our recent research projects, we evaluated how malicious third-party apps could affect user privacy, despite the various security controls and the solid security architecture of the iOS platform. Therefore, we reviewed the iOS app sandbox model for weaknesses – and, indeed, made some finds. Some of these defects, which Markus Troßbach and I disclosed to Apple a while back, have been addressed with yesterday’s release of iOS 8 (CVE-2014-4361, CVE-2014-4362).
A few weeks ago, I noticed that email attachments within the iOS 7 MobileMail.app are not protected by Apple’s data protection mechanisms. Clearly, this is contrary to Apple’s claims that data protection “provides an additional layer of protection for (..) email messages attachments”. I verified this issue by restoring an iPhone 4 (GSM) device to the most recent iOS versions (7.1 and 7.1.1) and setting up an IMAP email account1, which provided me with some test emails and attachments.
When Apps Get Out of (Privacy) Control Slow but steady, the everlasting trade-off between usability and security appears to reach a considerable peak within the mobile app ecosystem. Since “ease of use” has been one of the key drivers for designing mobile apps in the recent past, it’s about time to pause for a moment and to rethink whether our strong expectations towards app usability may have gone too far. To demonstrate how our strong usability expectations are going to intensify the mobile privacy crisis, this blog entry describes one of my latest cases in which I noticed an app that automagically retrieves a user’s login credentials from its backend.
Behind the Scenes of iPIN Lite – A Secure PIN & Password Safe Within one of my recent research projects on mobile application security, I reviewed some password managers for iOS devices from the Apple App Store. The primary goal of this study was to demonstrate the diverse possibilities of iOS runtime injection and how our new tool Snoop-it eases down security assessments of iOS applications. Note: Snoop-it is a tool to assist dynamic analysis and blackbox security assessments of iOS applications by retrofitting existing apps with debugging and runtime tracing capabilities.
Last week we published a study on the security of mobile hotspots. We found out, that Apple iOS generates weak default passwords, when an iPhone is used as mobile hotspot. This case serves as a perfect example, why it is always a good advice to replace initial default passwords by user-defined strong and secure passwords. Abstract Passwords have to be secure and usable at the same time, a trade-off that is long known.
A common approach to implement access control within iOS apps is to display a lock screen and ask the user to enter a PIN. When the correct PIN is entered, the lock screen fades out and the main view of the application appears. By manipulating the iOS runtime it is often possible to circumvent such measures. Let’s take SpringBoard1 as an example. The following cycript example demonstrates iOS runtime injection to bypass the iPhone/iPad passcode lock: First of all it’s necessary to replace the method “isPasswordProtected”.