A post by Ian Beer of Google Project Zero released late yesterday evening sent the security community reeling. According to Beer, a small set of websites had been hacked in February and were being used to attack iPhones, infecting them with malware. These sites, which see thousands of visitors per week, were used to distribute iOS malware over a two-year period.
History of iOS infections
Historically, iOS has never been completely free of malware, but it has mostly been limited to one of two scenarios: Either you jailbroke your device, hacking it to remove the security restrictions and installing something malicious as a result, or you were the target of a nation-state adversary. A classic example of the latter was the case of Ahmed Mansoor, in which he was targeted with a text message in an attempt to infect his phone with the NSO’s malware, now referred to as Trident.
The difficulty with infecting an iPhone is that it requires some kind of zero-day vulnerability (i.e., unknown to the security community at time of its release), and these vulnerabilities can be worth $1 million or more on the open market. Companies like Zerodium will purchase them, but widespread use of such vulnerabilities “burns” them, making it more likely that Apple will learn of their existence and apply fixes.
This is exactly what happened in the Trident case—a clumsy text message to an already-wary journalist resulted in three separate million-dollar vulnerabilities being discovered and patched.
Thus, iPhone malware infections were always seen as problems that didn’t affect average people. After all, who would burn $1 million or more to infect individuals, unless the gain was greater than the potential cost? There was never any guarantee, of course, and Beer’s findings have upended that conventional wisdom.
Mechanism of infection
According to Beer, the websites in question “were being used in indiscriminate watering hole attacks against their visitors,” using 14 different vulnerabilities in iOS that were combined into five different attack chains.
An attack chain is a series of two or more vulnerabilities that can be used together to achieve a particular goal, typically infection of the target system. In such cases, one of the vulnerabilities alone is not sufficient to achieve the goal, but combining two or more makes it possible.
Among the vulnerabilities used, only two were mentioned as still being zero-days at the time of discovery (CVE-2019-7286 and CVE-2019-7287). These were fixed by Apple in the iOS 12.1.4 release on February 7. The remaining 12 were not zero-days at the time, meaning they were already known, and they had already been patched by Apple. The various attack chains were capable of infecting devices running iOS 10 up through iOS 12.1.3.
For the technically-minded, Beer has included excellent, highly-detailed descriptions of each attack chain. However, what’s important is that each of these attack chains was designed to drop the same implant on the device, and it is that implant (the iPhone malware) that we will focus on here.
iPhone malware/implant behavior
The iPhone malware implant, which has not been given a name, is able to escape the iOS sandbox and run as root, which basically means it has bypassed the security mechanisms of iOS and has the highest level of privileges.
The implant communicates with a command and control (C&C) server on a hard-coded IP address over plain, unencrypted HTTP. In addition to uploading data to the server, it can also receive a number of commands from the server.
systemmail : upload email from the default Mail.app device : upload device identifiers (IMEI, phone number, serial number etc) locate : upload location from CoreLocation contact : upload contacts database callhistory : upload phone call history message : upload iMessage/SMSes notes : upload notes made in Notes.app applist : upload a list of installed non-Apple apps keychain : upload passwords and certificates stored in the keychain recordings : upload voice memos made using the built-in voice memos app msgattach : upload SMS and iMessage attachments priorapps : upload app-container directories from hardcoded list of third-party apps if installed (appPriorLists) photo : upload photos from the camera roll allapp : upload container directories of all apps app : upload container directories of particular apps by bundle ID dl : unimplemented shot : unimplemented live : unimplemented
This list of commands reveals a frightening list of capabilities. Among other things, the iPhone malware is capable of stealing all keychains, photos, SMS messages, email messages, contacts, notes, and recordings. It can also retrieve the full call history, and is capable of doing real-time monitoring of the device location.
It also includes the capability to obtain the unencrypted chat transcripts from a number of major end-to-end encrypted messaging clients, including Messages, Whatsapp, and Telegram. Let that sink in for minute. If you’re infected, all your encrypted messages are not only collected by the attacker, but they’re transferred in clear-text across the Internet.
What do I do now?
The bad news is that we don’t yet know which websites were affected, so it’s impossible to know who may have been infected with this mysterious iPhone malware. That is causing a substantial amount of fear among those aware of the problem.
Fortunately, there’s no need to panic at this point. These vulnerabilities have been patched for quite some time now. Also, the implant is actually incapable of remaining persistent after a reboot. This means that any time an infected iPhone is restarted—such as when an iOS update is installed, for example—the implant is removed. (Of course, a vulnerable device could always be re-infected by visiting an affected site.)
Because of this, any device running iOS 12.1.4 is not only immune to these particular attacks, but it can’t be infected anymore either, due to the reboot when installing 12.1.4 (or later). It’s unlikely that anyone is still infected at this time, unless they never update or restart their phone. If you’re concerned you may be infected, just install the latest iOS update, which will also reboot the phone and remove the malware, if present.
If you do have a phone that you suspect could be infected, it sounds like there is an easy test to see if it is, but you would have to do so before rebooting, as the malware needs to be active. (Disclaimer: without having a copy of the implant, I have not been able to verify this personally, or find anyone else who was able to do so.)
First, connect the affected device to a Mac via a Lightning (or, in the case of an iPad Pro, USB-C) cable.
Next, open the Console app on the Mac, which is found in the Utilities folder in the Applications folder.
In the Console, locate the phone in the Devices list and select it.
At this point, you’ll see log messages from the iOS device start scrolling past in the right-hand pane. Although the Console will not show you past messages, if you monitor, within 60 seconds or less, an infected iOS device should generate messages containing certain phrases, such as “uploadDevice,” “postFile success,” and “timer trig.” A full list of possible strings to look for can be found in Beer’s teardown of the implant; anywhere the code shows an NSLog command, that represents a message that will be echoed into the log.
Who was affected?
At this point, it is impossible to know who is responsible, or who was infected, without more information, such as the names of the sites that were compromised.
Beer’s article begins by saying that the malware did not target specific people:
The hacked sites were being used in indiscriminate watering hole attacks against their visitors, using iPhone 0-day.
There was no target discrimination; simply visiting the hacked site was enough for the exploit server to attack your device, and if it was successful, install a monitoring implant.
Ian Beer, https://googleprojectzero.blogspot.com/2019/08/a-very-deep-dive-into-ios-exploit.html
This leaves things a bit open to interpretation. It certainly seems that the malware did not target individuals. However, that does not necessarily mean that it wasn’t targeted.
As an example, in the watering hole attacks used in the recent attacks on Coinbase and other cryptocurrency companies, using a Firefox zero-day, many people visited the page containing the exploit. However, only a handful were selected by the malicious scripts to be infected.
Clearly, that kind of targeting did not happen in this case. However, that doesn’t necessarily mean that the attack wasn’t targeted at a particular group of people who would be likely to visit the hacked sites. In fact, that is the typical modus operandi for a watering hole attack: a site likely to be visited by the target group is compromised and used to spread malware. Such a thing happened in 2013, when attackers compromised a developer website with a Java-based exploit, infecting developers at many major companies, including Apple, with the OSX.Pintsized malware.
Near the end of the article, it says:
The reality remains that security protections will never eliminate the risk of attack if you’re being targeted. To be targeted might mean simply being born in a certain geographic region or being part of a certain ethnic group.
Ian Beer, https://googleprojectzero.blogspot.com/2019/08/a-very-deep-dive-into-ios-exploit.html
Some have interpreted this as a hint that people within a certain region or ethnic group were targeted by this attack, but my read is that this is simply general advice about what it means for someone to be “targeted,” in the greater context of the discussion of targeted vs. untargeted malware.
My personal opinion—which could very well be wrong—is that this was likely to be a targeted attack against a particular group of people, and that it was likely the work of a nation-state. Techniques such as watering hole attacks, targeted payloads in Microsoft Word documents, and targeted email campaigns with malicious attachments have been used frequently by China against the Uyghur people.
I do not intend to imply that China is the culprit, as that cannot be known with the currently available information. This is merely an example to point out that this could be a similar incident, perpetrated by a country that is using similar techniques. Then again, it also may not be. Time will hopefully tell.
Although the threat from this particular incident has passed, this was an eye-opening revelation. Ultimately, nothing has actually changed. This kind of attack was always a possibility; it just hadn’t happened yet. Now that it has, people will not look at the iPhone in quite the same way.
I still think the iPhone is the most secure phone on the planet (not counting obscure or classified devices that are only secure because few people actually have them). However, there are always vulnerabilities, and it’s entirely possible this kind of attack could be going on right now, somewhere else, against the current version of iOS.
It’s also worth pointing out that most of these vulnerabilities were not actually zero-days at the time of their discovery. Many people never update their devices, and as a result, zero-days aren’t always necessary. Updating to the latest version of iOS is always recommended, and would have protected against all but one of the attack chains up to February 7, and all of them after.
The extremely closed nature of iOS means that when malware like this crops up, there’s no way for people to tell if their devices are infected or not. If this malware were capable of remaining persistent, and if it didn’t leak strings into the logs, it would be most difficult to identify whether an iPhone was infected, and this would lead to dangerous situations.
Although Apple doesn’t allow antivirus software on iOS, there does need to be some means for users to check their devices for known threats. Perhaps something involving unlocked devices connected by wire to trusted machines? If such a thing were possible, this attack probably wouldn’t have gone undetected for two years.
Hint, hint, Apple!
Refer Here for Original Post and Source https://blog.malwarebytes.com/mac/2019/08/unprecedented-new-iphone-malware-discovered/