iOS watering hole attacks – Explained by Paul Conaty
Another major announcement about vulnerabilities in mobile phone operating system, must be Android right? -Nope.
Affects a large number of OS versions and was not specifically targeted to one person or small group, must be Android right? -Nope.
Can exploit large amount of personal data including encrypted messaging platforms like Signal and Whatsapp via accessing data local on device i.e. breaks sandboxing. Must be Android right? -Nope!
The perception is being proven wrong, iPhones and iOS devices have generally been considered to be more difficult targets. That does not mean they are massively more secure but the basic principle; that to hack an iPhone required expensive sophisticated tools that were specific to one iOS version and normally the preserve of nation states or shady contractors has been around for quite some time.
The release by Google’s project Zero of their research into a 2 year “watering hole” iOS hacking campaign has turned the perception of iOS attacks on its head. A watering hole attack simply means an attack which requires a victim to visit an infected website or sites and then the malware and exploits drop down to the device.
It’s nothing new as an attack vector except no one thought it was something iOS users needed to particularly worry about. iOS attacks have worked off the idea of a million dollar per victim model and therefore were the preserve of state level actors and targeted against terrorists/freedom fighters, activists etc.
This watering hole attack uses a sophisticated set of 14 different exploits to gain access to a huge range of personal data on devices including GPS, Keychain, photos, messages, and message databases for the likes of WhatsApp and Signal.
It was completely indiscriminate, targeting any iOS devices (and probably Windows and Android) that browsed the affected sites. This massively increases the likelihood of a device being compromised which changes the risk assessment model for organisations managing iOS devices significantly.
What to do next?
As Google hasn’t named the websites that served as a ‘watering hole’ infection mechanism, or shared other details about the attackers or who the victims were, iOS users should take immediate action to keep everything up to date.
First, organisations need to ensure devices are on at least iOS 12.1.4 (released on Feb 7th – 6 days after Google Project Zero team advised Apple of their findings). This further highlights why its important to keep devices patched.
Second, organisations need to really study the threat model for iOS devices based on the types of data that was able to be stolen here. A tool that runs on device and/or at the network layer to detect data exfiltration is highly recommended as such tools could have prevented or at least detected any data loss in a situation like this.
In addition preventing corporate credentials from being held in the keychain (MDM control) and reducing requirement to have personal iTunes account (DEP devices) could also mitigate the impact.
This is a fascinating escalation in the threat model for iOS and really brings home the requirement to have defense in depth for all endpoints regardless of OS. I think anyone putting all of their trust for data security and privacy into a single OS vendor is very brave! Always assume at least the first layer of your defenses will be breached and plan multiple layers of defense. Also always assume even those can be breached, so aim to minimise the amount of data that can be lost and its value. This is the idea of ‘Zero Trust’, the framework and approach that involves treating your device as if there is already an issue with it, and authenticating appropriately.
“Some more things that are useful to know about MTD tools; Zero-day protection from MTD offerings doesn’t wait for OS updates. Once an exploit is discovered, security companies work to identify infected sites and prevent users from accessing them. Even if malware authors move to new sites, technologies can recognise traffic shaping and check who registered the website, and automatically blacklist before any traffic develops a “patient zero”. Coding against exploits can take time, as new code has to be written and then tested against the rest of the OS (iOS 12.4 inadvertently unpatched a jailbreak prevention that had been shut down with iOS 12.3, for example). Blocking traffic to a website is far easier and quicker to implement. “- Colm Warner, Customer Success Manager CWSI