Apple iOS Vuln via Mail

ZecOps announced a collection of iOS vulnerabilities associated with the iOS Mail app that enables hostile agents to run arbitrary code and to delete messages since at least since iOS 6…
So far, this has been described as a set of Out-Of-Bounds write and Heap-Overflow vulnerabilities that are being used against targeted high value endpoints. My interpretation of their detailed write-up is that this qualifies as a remote, anonymous, arbitrary code execution vulnerability. As such, even if it must be targeted and even if it may not be an ‘easy‘ attack, because global financial services organizations are targeted by some amount of determined adversaries, we need to take it seriously.

Apple responded by rejecting the idea that this represented an elevated risk for consumers because their security architecture was not violated and they found no evidence of impact to their customers — while engineering a fix that will be rolled out soon. Is it time to factor this elevated risk behavior (reject-but-fix) into our threat models?

The ZecOps headline was:

“The attack’s scope consists of sending a specially crafted email to a victim’s mailbox enabling it to trigger the vulnerability in the context of iOS MobileMail application on iOS 12 or maild on iOS 13. Based on ZecOps Research and Threat Intelligence, we surmise with high confidence that these vulnerabilities – in particular, the remote heap overflow – are widely exploited in the wild in targeted attacks by an advanced threat operator(s).”

For global financial services enterprises, the presence of hundreds of billions, even trillions of dollars in one or another digital form seems to make this risk rise to the level of relevance. This is especially true because of the effectiveness of Apple’s marketing techniques across broad categories of roles expected to populate our organizations — i.e., our staff and leaders often use Apple devices.

On one front “Apple’s product security and the engineering team delivered a beta patch (to ZecOps) to block these vulnerabilities from further abuse once deployed to GA.”

On another front Apple also publicly rejected the ZecOps claims about finding evidence of the exploit being used saying “are insufficient to bypass iPhone and iPad security protections, and we have found no evidence they were used against customers.” If I read this assertion carefully and in the context of potential future legal action or sales headwinds, it does not inspire confidence that the vulnerabilities were not real-and-exploitable-as-described — only that Apple rejects some narrowly-crafted subset of ZecOps’ announcement/analysis and that they still stand behind the effectiveness of some subset of the iOS architecture.

Apple’s full statement:

“Apple takes all reports of security threats seriously. We have thoroughly investigated the researcher’s report and, based on the information provided, have concluded these issues do not pose an immediate risk to our users. The researcher identified three issues in Mail, but alone they are insufficient to bypass iPhone and iPad security protections, and we have found no evidence they were used against customers. These potential issues will be addressed in a software update soon. We value our collaboration with security researchers to help keep our users safe and will be crediting the researcher for their assistance.”

The Apple echo-chamber kicked in to support the rejection in its most comprehensive and positive interpretation…

ZecOps’ summary of their findings includes (quoted):

• The vulnerability allows remote code execution capabilities and enables an attacker to remotely infect a device by sending emails that consume significant amount of memory
• The vulnerability does not necessarily require a large email – a regular email which is able to consume enough RAM would be sufficient. There are many ways to achieve such resource exhaustion including RTF, multi-part, and other methods
• Both vulnerabilities were triggered in-the-wild
• The vulnerability can be triggered before the entire email is downloaded, hence the email content won’t necessarily remain on the device
• We are not dismissing the possibility that attackers may have deleted remaining emails following a successful attack
• Vulnerability trigger on iOS 13: Unassisted (/zero-click) attacks on iOS 13 when Mail application is opened in the background
• Vulnerability trigger on iOS 12: The attack requires a click on the email. The attack will be triggered before rendering the content. The user won’t notice anything anomalous in the email itself
• Unassisted attacks on iOS 12 can be triggered (aka zero click) if the attacker controls the mail server
• The vulnerabilities exist at least since iOS 6 – (issue date: September 2012) – when iPhone 5 was released
• The earliest triggers we have observed in the wild were on iOS 11.2.2 in January 2018

Like any large-scale software vendor, Apple fixes a lot of bugs and flaws. I am not highlighting that as an issue.  A certain amount of bugs & flaws are expected in large scale development efforts.  I think that it is important to keep in mind that iOS devices are regularly found in use in safety and critical infrastructure operations, increasing the importance of managing the software lifecycle in ways that minimize the number, scope and nature of bugs & flaws that make it into production.

Apple has a history of enthusiastically rejecting the announcement of some interesting and elevated risk vulnerabilities using narrowly crafted language that would be likely to stand up to legal challenge while concurrently rolling out fixes — which often seems like a pretty overt admission of a given vulnerability.
This behavior leaves me thinking that Apple has created a corporate culture that is impacting their ability to do effective threat modeling.  From the outside, it increasingly appears that Apple’s iOS trust boundaries are expected to match the corporation’s marketing expressions of their control architecture — ‘the happy path‘ where formal iOS isolation boundaries matter only in ways that are defined in public to consumers and that other I/O channels are defined-out of what matters… If I am even a little correct, that cultural characteristic needs to be recognized and incorporated into our risk management practices.

Given the scale of their profits, Apple has tremendous resources that could be devoted to attack surface definition, threat modeling, and operational verification of their assumptions about the same. Many types of OOB Write and Heap-Overflow bugs are good targets for discovery by fuzz testing as well. Until recently I would have assumed that by this point in iOS & iPhone/iPad maturation, Apple had automation in place to routinely, regularly & thoroughly fuzz obvious attack vectors like inbound email message flow in a variety of different ways and at great depth.

This pattern of behavior has been exhibited long enough and consistently enough that it seems material for global financial services enterprises. So many of our corporations support doing large amounts of our business operations on iDevices. I think that we need to begin to factor this elevated risk behavior into our threat models. What do you think?

REFERENCES:
“You’ve Got (0-click) Mail!” By SecOps Research Team, 04-20-2020
https://blog.zecops.com/vulnerabilities/youve-got-0-click-mail/

“Apple’s built-in iPhone mail app is vulnerable to hackers, research says.” By Reed Albergotti, 2020-04-23
https://www.washingtonpost.com/technology/2020/04/23/apple-hack-mail-iphone/

“Apple downplays iOS Mail app security flaw, says ‘no evidence’ of exploits — ‘These potential issues will be addressed in a software update soon’” By Jon Porter, 2020-04-24 https://www.theverge.com/2020/4/24/21234163/apple-ios-ipados-mail-app-security-flaw-statement-no-evidence-exploit

All Attack Vectors Remain Relevant

ESET Cybersecurity researchers from said yesterday that they have disabled parts of the “VictoryGate” botnet command & control infrastructure.  It had been directing the activity of a malware botnet of at least 35,000 compromised Windows systems.  The hostile agents were using the Windows endpoints to mine Monero cryptocurrency since May 2019.  Most of the exploited endpoints are located in Latin America, with Peru accounting for 90% of them.  These hosts were owned by both public and private sectors organizations, including financial institutions.

ESET researchers confirmed that USB drives were the main or only malware attack and propagation vector.

“The victim receives a USB drive that at some point was connected to an infected machine. It seemingly has all the files with the same names and icons that it contained originally. Because of this, the contents will look almost identical at first glance” …”When an unsuspecting user “opens” (i.e. executes) one of these files, an AutoIt script will open both the file that was intended, in addition to the initial module, both hidden by VictoryGate in a hidden directory”…

Replication through Removable Media has been an initial access path for attackers for as long as there has been removable media.

Financial services enterprises need to remain vigilant in their efforts to police their entire attack surface — including the boring, routine portions like USBs & USB port usage.

I think that the detailed ESET write-up is worth a read if you have any responsibility for attack surface management, or if you have a role in incident response.

REFERENCES:

“Following ESET’s discovery, a Monero mining botnet is disrupted.” By Alan Warburton, 23 Apr 2020. https://www.welivesecurity.com/2020/04/23/eset-discovery-monero-mining-botnet-disrupted/

Twitter Reduces Privacy Options

The Electronic Frontier Foundation (EFF) provided some context for the recent change in Twitter privacy options.  I think that it is an excellent read and recommend it to anyone involved in Financial Services security — especially those involved in mobile application architecture, design, and implementation.

Their conclusion:

Users in Europe retain some level of control over their personal data in that they get to decide whether advertisers on Twitter can harvest user’s device identifiers. All other Twitter users have lost that right.

The more broadly-available are user’s device identifiers — especially in the context of their behaviors (how they use their devices) — the greater are the risks associated with resisting a range of attacks.  We already have a difficult time identifying customers, vendors, contractors, the people we work with, and leaders throughout our organizations.  We depend on all kinds of queues (formal and informal) for making trust decisions.  As the pool of data available to hostile agents (because if it is gathered it will be sold and/or leaked) grows along every relevant dimension, the more difficult it is for us to find information that only the intended/expected individual would know or would have.

Defending against competent social engineering is already a great challenge — and behaviors like Twitter’s* will make it more difficult.

Note: Twitter is hardly alone in its attraction to the revenue that this type of data sales brings in…

REFERENCE:

https://www.eff.org/deeplinks/2020/04/twitter-removes-privacy-option-and-shows-why-we-need-strong-privacy-laws