Updates

We published another writeup: https://blog.zecops.com/vulnerabilities/seeing-maildemons-technique-triggers-and-a-bounty/

The vulnerability affected even the first iPhone (aka iPhone 1 / iPhone 2G) on iOS 3.1.3.

First in-the-wild trigger to this vulnerability happened on October 2010.

As you can see in the new writeup, this vulnerability is exploitable and we encourage to release a patch as soon as possible.

We launched a bounty program for attacks related to MailDemon

The IOCs & FAQ were updated.

Impact & Key Details (TL;DR) :

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

FAQ

This post is the first part of a series – See post number 2

Hear the news first Only essential content

New vulnerabilities & announcements

News from ZecOps Research Team We won’t spam, pinky swear 🤞 Follow @ZecOps Leave this field empty if you're human:

were you targeted by this vulnerability? Check Now

Multiple Vulnerabilities in MobileMail/Maild

Introduction

Following a routine iOS Digital Forensics and Incident Response (DFIR) investigation, ZecOps found a number of suspicious events that affecting the default Mail application on iOS dating as far back as Jan 2018. ZecOps analyzed these events and discovered an exploitable vulnerability affecting Apple’s iPhones and iPads. ZecOps detected multiple triggers in the wild to this vulnerability on enterprise users, VIPs, and MSSPs, over a prolonged period of time.

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

The suspected targets included:

Individuals from a Fortune 500 organization in North America

An executive from a carrier in Japan

A VIP from Germany

MSSPs from Saudi Arabia and Israel

A Journalist in Europe

Suspected: An executive from a Swiss enterprise

Few of the suspicious events even included strings commonly used by hackers (e.g. 414141…4141) – see FAQ. After verifying that it wasn’t a red-team exercise, we validated that these strings were provided by the email-sender. Noteworthy, although the data confirms that the exploit emails were received and processed by victims’ iOS devices, corresponding emails that should have been received and stored on the mail-server were missing. Therefore, we infer that these emails may have been deleted intentionally as part of attack’s operational security cleanup measures.

We believe that these attacks are correlative with at least one nation-state threat operator or a nation-state that purchased the exploit from a third-party researcher in a Proof of Concept (POC) grade and used ‘as-is’ or with minor modifications (hence the 4141..41 strings).

While ZecOps refrain from attributing these attacks to a specific threat actor, we are aware that at least one ‘hackers-for-hire’ organization is selling exploits using vulnerabilities that leverage email addresses as a main identifier.

We advise to update as soon as an iOS update is available.

Exploitation timeline

We are aware of multiple triggers in the wild that happened starting from Jan 2018, on iOS 11.2.2. It is likely that the same threat operators are actively abusing these vulnerabilities presently. It is possible that the attacker(s) were using this vulnerability even earlier. We have seen similarities between some of the suspected victims during triggers to these vulnerabilities.



Affected versions:

All tested iOS versions are vulnerable including iOS 13.4.1.

Based on our data, these bugs were actively triggered on iOS 11.2.2 and potentially earlier.

iOS 6 and above are vulnerable. iOS 6 was released in 2012. Versions prior to iOS 6 might be vulnerable too but we haven’t checked earlier versions. At the time of iOS 6 release, iPhone 5 was in the market.

ZecOps Customers & Partners

ZecOps Gluon iOS DFIR customers can detect attacks leveraging MobileMail/maild vulnerabilities.

Thank you

Before we dive deeper, we would like to thank Apple’s product security and the engineering team that delivered a beta patch to block these vulnerabilities from further abuse once deployed to GA.

Vulnerability Details

ZecOps found that the implementation of MFMutableData in the MIME library lacks error checking for system call ftruncate() which leads to the Out-Of-Bounds write. We also found a way to trigger the OOB-Write without waiting for the failure of the system call ftruncate . In addition, we found a heap-overflow that can be triggered remotely.

We are aware of remote triggers of both vulnerabilities in the wild.

Both the OOB Write bug, and the Heap-Overflow bug, occurred due to the same problem: not handling the return value of the system calls correctly.

The remote bug can be triggered while processing the downloaded email, in such scenario, the email won’t get fully downloaded to the device as a result.

Affected Library: /System/Library/PrivateFrameworks/MIME.framework/MIME

Vulnerable function: -[MFMutableData appendBytes:length:]

Abnormal behavior once the vulnerabilities are exploited

Besides a temporary slowdown of mobile mail application, users should not observe any other anomalous behavior. Following an exploit attempt (both successful / unsuccessful) on iOS 12 – users may notice a sudden crash of the Mail application.

On iOS13, besides a temporary slowdown, it would not be noticeable. Failed attacks would not be noticeable on iOS 13 if another attack is carried afterwards and deletes the email.

In failed attacks, the emails that would be sent by the attacker would show the message: “This message has no content.”.. As seen in the following picture below:

Crash Forensics Analysis

Part of the a crash (out of multiple crashes) experienced by the user, is as follows.

The crashed instruction was stnp x8, x9, [x3] , meaning that the value of x8 and x9 has been written into x3 and crashed due to accessing an invalid address 0x000000013aa1c000 which was stored in x3 .

Thread 3 Crashed: 0 libsystem_platform.dylib 0x000000019e671d88 _platform_memmove +88 0x19e671d84 b.ls 0x00008da8 0x19e671d88 stnp x8, x9, [x3] 0x19e671d8c stnp x10, x11, [x3, #16] 0x19e671d90 add x3, x3, 0x20 0x19e671d94 ldnp x8, x9, [x1] 1 MIME 0x00000001b034c4d8 -[MFMutableData appendBytes:length:] + 356 2 Message 0x00000001b0b379c8 -[MFDAMessageContentConsumer consumeData:length:format:mailMessage:] + 808

Registers: x0: 0x000000013aa1b05a x5: 0x0000000000000006 x1: 0x0000000102f0cfc6 x6: 0x0000000000000000 x2: 0x0000000000004a01 x7: 0x0000000000000000 x3: 0x000000013aa1c000 x8: 0x3661614331732f0a x4: 0x000000000000004b x9: 0x48575239734c314a

In order to find out why the process crashed, we need to take a look at the implementation of MFMutableData .

The below call tree is taken from the crash log experienced only by a selected number of devices.

-[MFDAMessageContentConsumer consumeData:length:format:mailMessage:] | +-- -[MFMutableData appendData:] | +-- -[MFMutableData appendBytes:length:] | +-- memmove()

By analyzing the MIME library, the pseudo code of -[MFMutableData appendBytes:length:] as follows:

-(void)appendBytes:(const void*)bytes length:(uint64_t)len{ //... uint64_t new_length = old_length + len; [self setLength:new_length]; if (!self->flush){ self->flush = true; } //... memmove(dest, bytes, len); }

The following call stack was executed before the crash happened:

-[MFDAMessageContentConsumer consumeData:length:format:mailMessage:] | +-- -[MFMutableData appendData:] | +-- -[MFMutableData appendBytes:length:] | +-- -[MFMutableData setLength:] | +-- -[MFMutableData _flushToDisk:capacity:] | +-- ftruncate()

A file is used to store the actual data if the data size reaches the threshold, when the data changes, the content and the size of the mapped file should be changed accordingly. The system-call ftruncate() is called inside -[MFMutableData _flushToDisk:capacity:] to adjust the size of the mapped file.

Following is the pseudo code of -[MFMutableData _flushToDisk:capacity:]

- (void)_flushToDisk:(uint64_t)length capacity:(uint64_t)capacity;{ boolean_t flush; //... if (self->path){ boolean_t flush = self->flush; //<-line [a] }else{ //... flush = true; } if(flush){ //<-line [b] //... ftruncate(self->path, capacity); //... self->flush = false; } }

The man page of ftruncate specifies:

ftruncate() and truncate() cause the file named by path, or referenced by fildes, to be truncated (or extended) to length bytes in size. If the file size exceeds length, any extra data is discarded. If the file size is smaller than length, the file is extended and filled with zeros to the indicated length. The ftruncate() form requires the file to be open for writing. RETURN VALUES A value of 0 is returned if the call succeeds. If the call fails a -1 is returned, and the global variable errno specifies the error.

According to the man page: “If the call fails a -1 is returned, and the global variable errno specifies the error.” which means under certain conditions, this system call would fail to truncate the file and return an error code.

However, upon failure of the ftruncate system call , _flushToDisk continues anyway, which means the mapped file size is not extended and the execution finally reaches the memmove() in the appendBytes() function, causing the mmap file an out-of-bound (OOB) write.

Finding another trigger

We know that the crash was due to a failure ftruncate() system call, does it mean we can’t do anything but to wait for the system call to fail?

Let’s take another look at the -[MFMutableData _flushToDisk:capacity:] function.

- (void)_flushToDisk:(uint64_t)length capacity:(uint64_t)capacity;{ boolean_t flush; //... if (self->path){ boolean_t flush = self->flush; //<-line [a] }else{ //... flush = true; } if(flush){ //<-line [b] //... ftruncate(self->path, capacity); //... self->flush = false; } }

As you can see in line [b], it checks whether the flush flag is true before calling ftruncate() . This means if we can set the flush flag to false at line [a], the ftruncate() won’t be executed at all.

If someone calls -[MFMutableData setLength:](set flush to 0) , before calling -[MFMutableData appendData:], ftruncate() won’t be executed due to flush==0) and there will be a similar result.

The following backtrace is a demonstration of a local POC. Combining this OOB Write with an additional vulnerability and/or methods to control the memory layout, this vulnerability could be triggered remotely – for example by controlling the selectors (as we have observed in other DFIR events as well as in Google Project Zero blog post).

Thread 0 Crashed: 0 libsystem_platform.dylib 0x00000001cc442d98 _platform_memmove + 88 0x1cc442d8c stnp x14, x15, [x0, #16] 0x1cc442d90 subs x2, x2, 0x40 0x1cc442d94 b.ls 0x00008db8 // 0x00000001cc44bf30 0x1cc442d98 stnp x8, x9, [x3] 0x1cc442d9c stnp x10, x11, [x3, #16] 0x1cc442da0 add x3, x3, 0x20 0x1cc442da4 ldnp x8, x9, [x1] 1 MIME 0x00000001ddbf0518 -[MFMutableData appendBytes:length:] + 352 0x1ddbf050c mov x1, x20 0x1ddbf0510 mov x2, x19 0x1ddbf0514 bl 0x000498f4 // 0x00000001ddc39e08 0x1ddbf0518 ldp x29, x30, [sp, #80] 0x1ddbf051c ldp x20, x19, [sp, #64] 0x1ddbf0520 ldp x22, x21, [sp, #48] 0x1ddbf0524 ldp x24, x23, [sp, #32]

Although this is indeed a vulnerability that should be patched, we suspect that it was triggered by accident while the attackers were trying to exploit the following vulnerability.

2nd Vulnerability: Remote Heap Overflow in MFMutable

We continued our investigation to the remotely triggered events that were suspicious and determined that there is another vulnerability in the same area

The backtrace can be seen as following:

-[MFDAMessageContentConsumer consumeData:length:format:mailMessage:] | +-- -[MFMutableData appendData:] | +-- -[MFMutableData appendBytes:length:] | +-- -[MFMutableData _mapMutableData]

While analyzing the code flow, we determined the following:

The function [MFDAMessageContentConsumer consumeData:length:format:mailMessage:] gets called when downloading an email in raw MIME form, and also will get called multiple times until the email is downloaded in Exchange mode. It will create a new NSMutableData object, and call appendData : for any new streaming data that belongs to the same email/MIME message. For other protocols like IMAP it uses -[MFConnection readLineIntoData:] instead but the logic and vulnerability are the same.

gets called when downloading an email in raw MIME form, and also will get called multiple times until the email is downloaded in Exchange mode. It will create a new object, and call for any new streaming data that belongs to the same email/MIME message. For other protocols like IMAP it uses instead but the logic and vulnerability are the same. NSMutableData sets a threshold of 0x200000 bytes , if the data is bigger than 0x200000 bytes , it will write the data into a file, and then use the mmap systemcall to map the file into the device memory. The threshold size of 0x200000 can be easily excessed, so every time new data needs to append, the file will be re-mmap’ed, and the file size as well as the mmap size getting bigger and bigger.

sets a threshold of , if the data is bigger than , it will write the data into a file, and then use the systemcall to map the file into the device memory. The threshold size of 0x200000 can be easily excessed, so every time new data needs to append, the file will be re-mmap’ed, and the file size as well as the mmap size getting bigger and bigger. Remapping is done inside -[MFMutableData _mapMutableData:] , the vulnerability is inside this function.

Pseudocode of the vulnerable function as below:

-[MFMutableData _mapMutableData:] calls function MFMutableData__mapMutableData___block_invoke when the mmap system call fails

-[MFMutableData _mapMutableData:] { //... result = mmap(0LL, v8, v9, 2, v6, 0LL); if (result == -1){ //... result = (void *)MFMutableData__mapMutableData___block_invoke(&v21); } //... }

The pseudo code of MFMutableData__mapMutableData___block_invoke is as follows, it allocates a size 8 heap memory then replaces the data->bytes pointer with the allocated memory.

void MFMutableData__mapMutableData___block_invoke(__int64 data) { __int64 result; // x0 data->vm = 0; data->length = 0; data->capacity = 8; // Reset MFMutableData capacity to 8 result = calloc(data->capacity, 1); // Allocate a new piece of memory, size of 8 data->bytes = result; // replace the mapping memory pointer, which overwrites the -1 in case of mmap failure. return result; }

After the execution of -[MFMutableData _mapMutableData:] , the process continues execution of -[MFMutableData appendBytes:length:] , causing a heap overflow when copying data to the allocated memory.

-[MFMutableData appendBytes:length:] { int length = [self length]; //... bytes = self->bytes; if(!bytes){ bytes = [self _mapMutableData]; //Might be a data pointer of a size 8 heap } copy_dst = bytes + length; //... platform_memmove(copy_dst, append_bytes, append_length); // It used append_length to copy the memory, causing an OOB writing in a small heap }

append_length is the length of a chunk of data from the streaming. Since MALLOC_NANO is a very predictable memory region, it is possible to exploit this vulnerability.

An attacker doesn’t need to drain every last bit of the memory to cause mmap to fail, as mmap requires a continuous memory region.

Reproduction

According to the man page of mmap, the mmap would fail when MAP_ANON was specified and insufficient memory was available .

The goal is to cause mmap to fail, ideally, a big enough email is going to make it happen inevitably. However, we believe that the vulnerabilities can be triggered in using other tricks that can exhaust the resources. Such tricks can be achieved through multi-part, RTF, and other formats – more on that later.

Another important factor that can affect exploitability, is the hardware specs:

iPhone 6 has 1GB

iPhone 7 has 2GB

iPhone X has 3GB

Older devices have smaller physical RAM, and smaller virtual memory space, hence it is not necessary to drain every last bit of RAM in order to trigger this bug, mmap will fail when it cannot find a continuous memory of given size in the available virtual memory space.

We have determined that MacOS is not vulnerable to both vulnerabilities.

In iOS 12, it is easier to trigger the vulnerability because the data streaming is done within the same process, as the default mail application (MobileMail), it deals with much more resources, which eats up allocation of virtual memory space, especially the UI rendering, whereas in iOS 13, MobileMail pass data streaming to a background process namely maild . It concentrates its resources in parsing the e-mails, which reduces the risk of virtual memory space accidentally running out.

Remote Reproduction / POC

Since MobileMail/maild didn’t explicitly set the max limit for email size, it is possible to set up a custom email server and send an email that has several GB of plain text. iOS MIME/Message library chunks data into an average of roughly 0x100000 bytes while streaming data, so failing to download the entire email is totally fine.

Please note that this is just one example of how to trigger this vulnerability. Attackers do not need to send such email in-order to trigger this vulnerability, and other tricks with multi-part, RTF, or other formats may accomplish the same objective with a standard size email.

Indicators of Compromise

# Type of indicator Purpose IOC 1 String in raw email Part of the malicious email sent AAAAAAAA AND AAAAATEy AND EA\r

AABI AND "$\x0e\xce\xa0\xd4\xc7\xcb\x08" AND T8hlGOo9 AND OKl2N\r

C (updated) 3 String in raw email Part of the malicious email sent 3r0TRZfh AND AAAAAAAAAAAAAAAA AND \x0041\x0041\x0041\x0041 (unicode AAAA) (updated) 4 String in raw email Part of the malicious email sent

/s1Caa6 AND J1Ls9RWH 5 String in raw email Part of the malicious email sent ://44449 6 String in raw email Part of the malicious email sent ://84371 7 String in raw email Part of the malicious email sent ://87756 8 String in raw email Part of the malicious email sent ://94654

Patch

Apple patched both vulnerabilities in iOS 13.4.5 beta, as can be seen in the following screenshot below:

To mitigate these issues – you can use the latest beta available. If using a beta version is not possible, consider disabling Mail application and use Outlook, Edison Mail, or Gmail that are not vulnerable.

Disclosure timeline

February 19th 2020 – Suspected events reported to the Vendor under ZecOps responsible disclosure policy which allows immediate release for in-the-wild triggers

Ongoing communication between the affected vendor & ZecOps

March 23rd – ZecOps sent to the affected vendor a POC reproduction of the OOB Write vulnerability

March 25th – ZecOps shared a local POC for the OOB Write

March 31st – ZecOps confirmed a second vulnerability exists in the same area and the ability of a remote trigger (Remote Heap Overflow) – both vulnerabilities were triggered in the wild

March 31st – ZecOps shared a POC with the affected vendor for the remote heap-overflow vulnerability

the affected vendor for the remote heap-overflow vulnerability April 7th – ZecOps shared a custom Mail Server to trigger the 0-click heap overflow vulnerability on iOS 13.4 / 13.4.1 easily by simply adding the username & password to Mail and downloading the emails

April 15/16th – Vendor patches both vulnerabilities in the publicly available beta

April 20th – We re-analyzed historical data and found additional evidence of triggers in the wild on VIPs and targeted personas. We sent an email notifying the vendor that we will have to release this threat advisory imminently in order to enable organizations to safeguard themselves as attacker(s) will likely increase their activity significantly now that it’s patched in the beta

April 22nd – Public disclosure

FAQ

Q: Was the first and/or the second vulnerability exploited in the wild?

A: The suspected emails triggered code paths of both vulnerabilities in the wild, however, we think the first vulnerability (OOB Write) was triggered accidentally, and the main goal was to trigger the second vulnerability (Remote Heap Overflow).

We have seen multiple triggers on the same users across multiple continents. We examined the suspicious strings & root-cause (such as the 414141…41 events and mostly other events): We confirmed that this code path do not get randomly triggered. We confirmed the registers values did not originate by the targeted software or by the operating system. We confirmed it was not a red team exercise / POC tests. We confirmed that the controlled pointers containing 414141…41, as well as other controlled memory, were part of the data sent via email to the victim’s device. We verified that the bugs were remotely exploitable & reproduced the trigger. We saw similarities between the patterns used against at least a couple of the victims sent by the same attacker. Where possible, we confirmed that the allocation size was intentional. Lastly, we verified that the suspicious emails were received and processed by the device – according to the stack trace and it should have been on the device / mail server. Where possible, together with the victims, we verified that the emails were deleted.

Based on the above, together with other information, we surmise that these vulnerabilities were actively exploited in the wild.

Q: Does an attacker have to trigger the first vulnerability first in order to trigger the second one?

A: No. An attacker would likely target the second vulnerability.

Q: Why are you disclosing these bugs before a full patch is available?

A: It’s important to understand the following:

These bugs alone cannot cause harm to iOS users – since the attackers would require an additional infoleak bug & a kernel bug afterwards for full control over the targeted device.

Both bugs were already disclosed during the publicly available beta update. The attackers are already aware that the golden opportunity with MobileMail/maild is almost over and they will likely use the time until a patch is available to attack as many devices as possible.

With very limited data we were able to see that at least six organizations were impacted by this vulnerability – and the potential abuse of this vulnerability is enormous. We are confident that a patch must be provided for such issues with public triggers ASAP.

It is our obligation to the public, our customers, partners, and iOS users globally to disclose these issues so people who are interested can protect themselves by applying the beta patch, or stop to use Mail and temporarily switch to alternatives that are not vulnerable to these bugs.

We hope that with making this information public it will help to promote a faster patch.



Q: Can both vulnerabilities be triggered remotely?

A; The remote heap overflow has been proven to be possible to trigger remotely without any user-interaction (aka ‘0-click’) on iOS13. The OOB write can be triggered remotely with an additional vulnerability that allows to call an arbitrary selector, just like the one published by Google Project Zero here:

https://i.blackhat.com/USA-19/Wednesday/us-19-Silvanovich-Look-No-Hands-The-Remote-Interactionless-Attack-Surface-Of-The-iPhone.pdf – since we saw in the wild trigger for the first vulnerability, it is possible, although we think it was done by mistake (see above).

Q: Do end users require to perform any action for the exploitation to succeed?

A: On iOS 13 – no. On iOS 12 – it requires the victim to click on an email.

If an attacker controls the mail server, the attack can be performed without any clicks on iOS 12 too.

Q: Since when iOS is vulnerable to these bugs?



A: iOS is vulnerable to these bugs at least since iOS 6 (Sept’ 2012). We haven’t checked earlier versions.

Q: What can you do to mitigate the vulnerability:

A: The newly released beta update of 13.4.5 contains a patch for these vulnerabilities. If you cannot patch to this version instead of using Mail application consider to use other mail applications until a GA patch is available.

Q: Does an attacker need to send a very large email (e.g. 1-3gb) to trigger the vulnerability?

A: No. Attackers may use tricks in multi-part / RTF, etc in order to consume the memory in a similar way without sending a large email.

Q: Does the vulnerability require additional information to succeed?

A: Yes, an attacker would need to leak an address from the memory in order to bypass ASLR. We did not focus on this vulnerability in our research.

Q: What does the vulnerability allow:

A: The vulnerability allows to run remote code in the context of MobileMail (iOS 12) or maild (iOS 13). Successful exploitation of this vulnerability would allow the attacker to leak, modify, and delete emails. Additional kernel vulnerability would provide full device access – we suspect that these attackers had another vulnerability. It is currently under investigation.

Q: Would end users notice any abnormal behavior once either vulnerabilities are triggered / exploited?

A: Besides a temporary slowdown of mobile mail application, users should not observe any other anomalous behavior.

When the exploit fails on iOS 12 – users may notice a sudden crash of the Mail application.

On iOS13, besides a temporary slowdown, it would not be noticeable. Failed attacks would not be noticeable on iOS 13 if another attack is carried afterwards and deletes the email. In failed attacks, the emails that would be sent by the attacker would show the message: "This message has no content." As seen in the following picture below:

Q: if the attackers fail, can they re-try to attack using the same vulnerability right after?

A: On iOS 13 – attackers may try multiple times to infect the device silently and without user interaction. On iOS 12 – additional attempt would require the user to click on a newly received email by the attackers. The victim does not need to open an attachment and just viewing the email is sufficient to trigger the attack.

Q: Can the attackers delete the received email after it was processed by the device and triggered the vulnerability?

A: Yes

Q; Is MacOS vulnerable to these vulnerabilities too?

A: No