Unpatched iOS Mail bug allows spoof login prompts

James Sanders
Updated

This article, Unpatched iOS Mail bug allows spoof login prompts, originally appeared on TechRepublic.com.

 Image: iStock/weerapatkiatdumrong

Prague-based security researcher Jan Souček discovered a vulnerability in the Mail app in iOS 8.1.2 in January 2015, in which the HTML header <meta http-equiv=refresh> is executed instead of being ignored, allowing the contents of the email to be replaced with an arbitrary web page. JavaScript is (correctly) disabled for this context, though a spoof login prompt can be displayed to the user as in the proof-of-concept released this week by Souček, allowing passwords to be harvested using a combination of PHP, HTML, and CSS.

Identifying a fake login prompt

Although the proof-of-concept login prompt is a moderately convincing lookalike, and it uses cookies to determine if the user has already entered credentials in order to avoid suspicion, it isn't possible to completely replicate the behavior of a genuine login prompt due to the lack of API access. Various subtle behaviors give it away as not being genuine, and should be kept in mind to avoid the potential of having your account information stolen by attackers.

  • 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.

Final thoughts

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.

Also see

Note: TechRepublic, ZDNet, and Tech Pro Research are CBS Interactive properties.