Identifying a fake login prompt
- A genuine login prompt is modal — you must either press Cancel or OK to proceed past the prompt. A spoof login prompt can be escaped by pressing the Home button.
- A real login prompt does not allow the iCloud username/email address to be edited (the genuine prompt has only one input field). The proof-of-concept code prompts the user to input a username, but more sophisticated/targeted attacks would likely change this behavior.
- The proof-of-concept login prompt repositions when the keyboard is displayed, whereas (genuine) modal prompts do not — the position never changes, as the keyboard is immediately displayed.
- Keyboard locales cannot be changed when the user is prompted for a password.
An issue with Apple’s security practices?
This security vulnerability was reported to Apple in January 2015, but it has remained unfixed in the subsequent versions of iOS — including the developer previews of 8.4 Beta 4 and 9.0 Beta 1 released this week. Six months without a published patch, or any indication of a forthcoming patch is quite bad, especially considering the relative ease of the fix that would not allow the execution of an HTML header.
This issue was submitted using Apple’s Radar bug-reporting interface. Compared to other issue trackers such as Bugzilla — which is used by Mozilla, Red Hat, and for open source software including Eclipse, MediaWiki, GNOME, KDE, and XFCE — Radar is not at all transparent, and it rarely provides any insight into when or if issues will be fixed. Bugs filed in Radar are not visible to anyone other than Apple and the original submitter, which theoretically increases the number of duplicate submissions, leaving developers with the decision of going to the extra effort of reporting a bug or guessing if someone else has done it.
The difficulty of using Radar is also an issue. Various plugins exist to integrate Bugzilla reporting in Eclipse and other IDEs, but no such integration exists in Xcode. This and other problems prompted a petition to be started by frustrated third-party developers requesting changes to make Radar more useful.
Why this is a problem for enterprise users
The ability to use this HTML header to redirect potential victims to arbitrary web pages has potential far-reaching consequences. Phishing attacks are nothing new, but with enterprise deployments of Apple devices — or a BYOD policy in the workplace — the potential for sensitive data to be exfiltrated exists, and a large share of the responsibility for securing devices falls to the vendor.
In a statement to ZDNet, an Apple representative noted that, “We are not aware of any customers affected by this proof of concept,” and the company “[is] working on a fix for an upcoming software update.” Apple’s press team did not respond to an inquiry regarding its acknowledgement of the vulnerability in January and a timeline for delivering a patch.
Vendor responsiveness is crucial for a product to succeed, particularly in the enterprise, where security concerns have reached a new high amid healthy skepticism of vendors following the 2013 surveillance disclosures.
Have you fallen victim to a phishing attack? Or, have you encountered difficulties with the BYOD policy for your organization? Share your experiences in the comments section.
Note: TechRepublic, ZDNet, and Tech Pro Research are CBS Interactive properties.