Apple iMessage Zero-Click Hacks
wired.com
wired.com
* I ask a seller on FB marketplace to send me some pictures of an item
* I need to send pictures of some documents to my solicitor
* A new friend I've just met in a bar tries to send me her contact card
* My mechanic tries to send me a PDF of the invoice for his work
Sure, there are ways around all of these, but it makes iMessage (or any messaging service) a lot less useful.
Right now, iMessage processes everything in the background upon receiving.
That enables zero click, instantly delete message attacks. The only trace you have is a random imessage sound, or vibrate, with no corresponding notification.
Can be tuned to send at 4am when most people have do not disturb on.
Whatsapp of all things has this. (mostly to save on bandwidth, because whatsapp as all about efficiency at one point)
There is no real reason to auto process untrusted data. I would have thought we'd learnt from the years of exploits outlook dealt with in the late 90s/early 2000s.
settings -> storage & data -> media auto download
> But, it does appear that attachment/image processing is happening via Whatsapp without my control/without my viewing the message + its attachments.
For me at least, on iOS whatsapp doesn't insert pictures and video into my photostream even if I tap "download"
If they think my friend has sent a picture, or a business has sent an invoice, they're likely to click it.
Especially in the 3 receiving situations that bb123 outlined (1, 3 and 4) you're not likely to have the contact info, or it's plausible that the person could be using another phone to send that message.
Now - I know to check the sender, don't click strange links, all of that. I run trainings on how to avoid phishing and improve personal & organizational digital security. But it comes down to the fact that people are using technology as a tool.
Apple made headway with BlastDoor but it's clearly not good enough.
Otherwise an attacker will usually be able to figure out a way to fake a message from someone already in your contact list.
Of course iMessage doesn't do identity verification which is why it does not have effective end to end encryption in the first place. So they would have to solve that, perhaps larger problem, first.
> In fact, Citizen Lab researchers and others suggest that Apple should simply provide an option to disable iMessage entirely.
There's a checkbox in Settings > Messages that does exactly this? It seems strange they published this.
Not really, there's a ton of government services that require you to have a phone number (depending on where you live). I don't see any real suggestion for an alternative to having a phone number. If nothing else, to receiving notification. You can't really rely on iMessage, WhatsApp, Signal and similar services, you need one system that you're sure will cover 98% for all people. 3. parties can't even integrate into many of these services.
You could use email, but I don't really see how that's any better and many seniors will use SMS, but not email to any great extend.
SMS is still the only unified messaging service you can be sure that all your friends and family will have.
Phone numbers, like emails, are very robust and reliable, interoperable, not centralized to one entity, and the quality of service vs cost ratio is excellent.
Not to mention text messages:
- they work no matter if the person is using whatsapp, telegram, signal or the new hype stuff
- no GAFAM is collecting my text history to sell me ads
- they require no internet connection
There are 3 things that we must absolutely cherish and preserve in this race for tech: cash, emails and phone numbers.
They are a beacon of stability in this sea of ever moving innovation greed.
And I say that while I'm thinking about setting up an IFPS website, compiling python 3.10 beta to test it and buy a secondary e-ink screen for my laptop. I'm not technophobic.
SMS is unencrypted so someone's harvesting your data.
They require a cell tower connection, that's only 1 step away from an internet connection, probably 0 in many cases.
Cash and Phone numbers are trivial to steal.
Most people do not want this feature. 9/10 of my iMessage contacts turn off read receipts; I bet the number would be similar on Facebook/Whatsapp if they allowed it.
For me, ephemerality, one-shot, and unidirectionality are characteristics, not issues.
> SMS is unencrypted so someone's harvesting your data.
There is not a single entity that is getting all of it, which is the most important to me. Encryption is nice, but for most of my communications, that's not the most important feature.
> They require a cell tower connection, that's only 1 step away from an internet connection, probably 0 in many cases.
I'm regularly in situations where the phone works, but not internet. On the move, or in the country side.
> Cash and Phone numbers are trivial to steal.
Sure, and so is a bike. But I don't always want to take the bus.
You've no idea if your SMS ever arrived, or if your email even got into the Inbox of the reader instead of the spambox.
Buy a data-only subscription, and use Google Voice or some sort of PBX powered app to still be able to receive regular phone calls.
Preferably I’d want a really basic voice only, open source PBX powered app for iOS that I could use. Then I could get me a data-only plan and SIM.
Caveat: I still need Norwegian BankID to work with my SIM though. I dunno if any of the data-only plans available in Norway support BankID, or if you need a regular subscription like I have now in order to use that.
Same in India, Banking & Payment apps need to verify that the SIM i.e. Phone number is indeed the one associated with the bank account and so they send SMS in the background at random intervals.
I don't do real-time communication and so I had the lowest tier prepaid carrier plan just for this purpose, But the oligopolies decided to remove SMS from the low tier plans suddenly and all my payment apps are now deactivated!
Meanwhile scammers continue to use phone numbers (SIM) bought dime a dozen with fake identity cards[1].
WhatsApp should never be forgiven for making phone number as a flawed identity of a living person, It's disappointing that Signal continued with it.
[1] https://twitter.com/Abishek_Muthian/status/14069649600815718...
The data only plans is is good path to follow, it at least makes it more obvious each time a service clearly wants too much personal data.
This threat demonstrates how difficult it is to keep us safe from hacks. We can keep our bank account and one day have to deal with fraud recovery, or we can ask them to stop, some banks 2fa activation via a voice call.
Until banks cease to dominate and control our finances, we should at least do what we can protect ourselves from their incompetence.
I haven't had too much luck just being able to get a stand-alone data sim from Verizon, AT&T or TMobile...
it's less feature rich, so presumably there's less attack surface.
Fantastic way to not have people send you messages anymore.
Phone numbers are technically becoming useless. They are practically still the by far dominant choice when someone goes to send you a new message.
We’ve had decades of texting phone numbers to reinforce this.
Instant-Messaging = Worthy target for exploits.
Just like web-browsers get exploited after years of patching.
Wrong. Whatsapp relies on SMS as 2FA OTP.
The point of these apps is that I can get content(picture, message, video etc) to your local device and it get processed.
You can do this already. If you "manage" your iphone with Apple Configurator you have fine-grained control over every little thing it does. You can disable imessage (and many other things like the app store, etc.)
So it will stay the same for people in your contact list but a new touch to load for message from unknown person
The idea is that contacts can still send you media without prior approval. Do their children never make mistakes? Do their spouses/gardeners/etc.?
Many services from banks to healthcare utilize SMS as a main way of communicating with end-users. many rely on dynamic numbers.
Moreover, spoofing SMS messages is not that hard.
Messaging apps whether it is SMS or alternatives like whatsapp, telegram etc. will always offer a powerful vector to infect devices.
This is iMessage, and instead of _never_ parsing, requiring user action to parse. It will cut out the majority of the noclick exploits, and make iphones safer for most people.
This of course doesn't protect against spear phishing. But it should give apple time to fix their shit.
I seem to be under attack lately.
3-4 times a day random links sent from gmail addresses or unknown phone numbers to imsg with sketchy looking links in them.
https://calleridreputation.com/blog/robotexts-are-replacing-...
"Robotech spammers are also targeting group messages by using automated programs to send thousands, even millions of group texts to random phone numbers with the hopes that somebody will take the prey and respond."
Also, some users give random apps access to their address book for whatever reason then there is a whole list of known good emails and numbers to spam.
"There's a sucker/fool born every minute." --PT Barnum
And there are businesses of all types where that is their sole business model.
Though this option precludes the random war-dialing explanation.
1. There's no reason why a threat actor would have to send you 3-4 messages per day. Of the exploits I've seen, they only need to send one. Sending 3-4 messages per day just unnecessarily increases the risk of getting caught (ie. the target getting suspicious and asking on hacker news whether they're getting hacked)
2. There's no reason why the message has to contain sketchy links. They could very well disguise messages as ads/notifications for well known businesses, political organizations, or from random people who got the wrong phone number.
3. There's no reason why the attacker can't erase any trace of the initial message after your device is infected, so unless you're staring at your phone 24/7 it's very easy to miss the message.
If I am sneaking a payload in, and I have different exploits for different OS versions, I would exactly disguise it as spam.
Pretending to be a busines, or a random person with wrong number, and then DELETING IT is a noteable indicator of compromise.
I know this isn't how Pegasus works, but I'm sure there are more exploit kits being sold in the world. Some may not be as sophisticated, and may rely on spraying and praying with different exploits.
Right, but the point is that GP seems to have been tipped off by the "sketchy links", rather than the spam itself, and that there are far better ways to compose your spam texts than ones with sketchy links.
>Pretending to be a busines, or a random person with wrong number, and then DELETING IT is a noteable indicator of compromise.
It depends on the nature of the exploit. I was operating under the assumption that "0 click" means the exploit gets run as soon as the phone receives it, which would allow for the exploit to clean up after itself without alerting the owner, unless the owner was staring at the phone the exact moment the message came in.
That's completely insane, isn't it? Have Apple just given up, or am i missing the scope of this vulnerability?
Also how can Apple not have better security with such an incredible amount of money in the bank?
For other apps like Telegram; the server can send a predefined notification message.
For iMessage, when you get something even from someone outside your contacts, its daemon invokes specific code to handle the message, and its attachments.
Whilst this doesn't help if someone opens the app, it does at least change this from a zero click attack, to a one click attack.
(This is also another example of Apple not following its own app store rules. It has privileged access to frameworks.)
The attack mentioned in the Wired article[1] relies on iMessage asking the sandboxless Springboard[2][3] to deserialize a maliciously crafted field, included in the incoming iMessage, to escape the sandbox. This specific vulnerability doesn't appear to apply to other apps.
[1] https://googleprojectzero.blogspot.com/2019/08/the-fully-rem... [2] https://en.wikipedia.org/wiki/SpringBoard [3] https://iphonedev.wiki/index.php/SpringBoard
I’m surprised this code isn’t being rewritten in something like Rust, but perhaps there are more things going on at play, like the plist serialization attacks that end up coding for esoteric classes that contained various bugs.
[1] https://habr.com/ru/post/191654/
[2] https://appleinsider.com/articles/15/05/27/bug-in-ios-notifi...
[3] https://blog.zecops.com/research/analyzing-the-ios-telugu-cr...
[4] https://www.macrumors.com/2018/05/09/how-to-fix-black-dot-im...
I imagine the internal discussion is something like "by rewriting it, we will just introduce 100 new bugs. once we squash these last few bugs in the current tried-and-tested C code, it will be bulletproof!"
Being Apple I imagine they would prefer to rewrite it in Swift, but Swift may not be mature enough
Job posting links are dead now, but there was a reddit thread about it: https://old.reddit.com/r/rust/comments/fkngza/apple_hiring_r...
Also: https://jobs.apple.com/en-us/search?search=rust&sort=relevan...
From what I can tell, the combination of unsafe-by-default languages like C/C++/Obj-C and the way the human brain works is Not-A-Good-Combination© . Too many opportunities for error.
Some of Apple's OS code is pretty ancient. Switching to Swift or Rust is not necessarily a panacea if you call too many OS routines still in C-ish.
I have a few months experience in it, and I can definitely agree that if you're writing Swift-only, it's very nice. The emphasis on values, and value semantics is definitely a differentiator from most other languages.
However, anytime you have to use/interop with an older API designed for Obj-C (for example, AVFoundation), it's much more of a pain. Effectively, you're writing Obj-C in Swift.
If someone is insisting on Obj-C instead of Swift in 2021, I would attribute it to a form of a Stockholm Syndrome. Many people form psychological bonds with whatever they are familiar with.
SwiftUI in particular is excellent and if you can use it you should. But you can’t say Swift in general is ready to replace Objective-C. It’s not.
The big missing features (from my perspective) are fixed-size arrays, placement allocation, and the ability to guarantee that no allocations or refcount operations occur in a marked critical section. There’s a lot of other stuff I would like to have, but those are the things I can’t live without.
There are very real ways in which Swift isn't ready for systems programming, but this sure ain't one of them.
- In C and C++, this doesn't trap, it's undefined behavior. Trapping is _always_ better than UB. Are C and C++ "not ready for systems-level programming"? (Yes, but that hasn't stopped people from doing it).
- C and C++ compilers don't catch this statically either by default. They just silently invoke UB (https://godbolt.org/z/seTh9cva6).
- Unlike C and C++, Swift's standard library provides the tools you need to easily do something about it: if you don't want to trap, you can write `Int(exactly: x.rounded(.towardZero))` and get an Int? that is nil if a floating-point value is out of range.
There are rough edges here, but they are much, much less rough than the languages that people routinely use for systems programming. Sibling poster got at some of the real problems that _do_ need to be addressed.
At the end of the day, it is still an app with app level permissions, sandbox etc.
Kernel\Kernel modules are far more likely to be written as they allow for vastly more access than an app.
Reasons for worry about the baseband code:
a) Code is written by a third parties
b) Apple is more restricted applying defence-in-depth (customised security CPU changes like PAC, customised compiler changes, etcetera).
c) harder to detect intrusion?
Versus reasons not to worry so much:
z) Baseband has more limited access to information
y) harder to make exploit survive a reboot - mainly useful as part of chain of exploit into main CPU?
x) Baseband code is device specific - helps to know target device to attack
you can pretty much access whatever you want.
You don't need to access the messages app in order to get access to the messages.
it's the opposite actually, the messaging app needs permissions for the system level messaging component.
you're already root.
you can access any component without much restriction.
How the data is stored has nothing to do with this
Pwning the app will only provide access to whatever permission it has and we are still sandboxed.
Pwning a kernel module\driver will provide access to everything whether its messaging, call logs, pictures etc. we are not sandboxed, we don't need an LPE exploit.
I think the priority is clear.
And even if they did then why is that so hard to fix?
iMessage has more integrations than that too. If you send someone a URL, e.g., the recipient will see a preview of the content.
iMessage does a lot to mitigate the attack surface, but people still get through.
Rewriting these libraries is probably also a common good, that would be better done through open source initiatives.
That said you’re not wrong that it’s a gargantuan task that can’t be realistically undertaken, just you’ve really really underestimated the number of Rust developers.
Getting an application that's running in a hypervisor to seamlessly, for example, accept deep-link clicks is more complicated for the same reason that they're more secure. That extra boundary is another wall, another interface. And of course that means more complexity for app developers, and more compute cost/battery utilization.
Vierualisation has a negligible impact on power consumption.
[citation needed] Virtualization on embedded devices with constrained power is a big ask. They are not asking to get rid of all security protections, just pointing out that loosing 10-20% of battery life for marginal security improvement isn't a product winner.
Does iMessage accept arbitrary code that it can execute?
[1] https://googleprojectzero.blogspot.com/2020/04/fuzzing-image...
For example (IIRC this was a real bug), if you exploit a bug in the text layout code, you could attack a device by getting a notification to appear on the lock screen - and SMS messages usually trigger a notification
A message has to be able to display so many different types of content. A flaw in any one of those could be exploited. Combine a bunch of flaws together and you suddenly can do quite a bit.