I would argue that iMessage is way to problematic to be used safetly, at all. By anyone. Full-stop. It also seems to be the primary attack vector of NSO related zero-days as well and its become known that phone country/area codes have relevance to its chance of succes in past exploits, which suggests a phone/messaging type attack vector.
back
7 comments
That fact that Apple blended iMessages, SMS text messages, and email into an extremely confusing mess may also be the reason for so many security issues related to iMessage. Perhaps not directly responsible for this particular NGO exploit, but I find iMessage's logic and behavior bewildering at times.
For example: If you stop using WhatsApp for example, nothing bad happens if you try to send messages another way. But if you stop using iMessage, then you can no longer send a normal SMS to someone with whom you've communicated before using iMessage. The Messages app will tell you, "You must enable iMessage to send this message", even if it's an SMS text message to a normal phone number! Why shouldn't that work?
To be able to again send SMS text messages to someone you used to talk with is to disable iMessage of course, then sign out of Facetime (who could imagine that as a necessary step?), sign out of iCloud, reboot the iPhone, and wait some minutes to hours to days until you are "deregistered" from iMessage. I'm talking about the same phone with the same SIM chip. The problem can become much worse if you've switched phones or SIM card.
The source code for iMessage must be a nightmare having integrated SMS and email and a new messaging system all together.
There is no email (the protocol) in iMessage (the app). You can use somebody's email address as the recipient for an iMessage (the protocol). No email is ever sent.
You can type in a contact with an email address by just their name and send an email from iMessage. I have done it to contacts accidentally many times.
I think sending SMS to emails and receiving SMS from emails is a functionality of the mobile network. You should be able to do that in any app that can send/receive SMS.
The point is that those other apps don’t use email addresses as the handle to contact someone. If someone iMessages you, the iMessage might (appear to) come from their phone number, or it could (appear to) come from their email. If you have an iMessage contact that’s just an email and you iMessage them, it works fine. If you try to then add Android users to your group chat, everyone gets SMS and the iMessage user with an email handle gets an empty body email from AT&T with an attachment containing the SMS as a plaintext file. And then this user gets another empty email for every reply to that group text.
I'm fairly certain that "text to email" is a feature of MMS - I've used it a few times years before iPhones were around.
I don't remember if MMS is enabled by default in iOS but theres a toggle to disable it, and realistically there's very minimal real world use-case for MMS these days.
On Apple's end, iMessage also supports email addresses as a user identifier (and it's the only one you get if you don't have an iPhone with an assigned phone number).
It's still not sending emails, though. The iPhone Messages app sends SMS, MMS, and iMessage; email is the responsibility of the Mail app.
The point is that iMessage lets you send to any contact and it’s not clear if it will send to their iMessage, which uses email as an identifier, or to their actual email inbox through mms.
You are referring to MMS.
> For example: If you stop using WhatsApp for example, nothing bad happens if you try to send messages another way. But if you stop using iMessage, then you can no longer send a normal SMS to someone with whom you've communicated before using iMessage. The Messages app will tell you, "You must enable iMessage to send this message", even if it's an SMS text message to a normal phone number! Why shouldn't that work?
To be able to again send SMS text messages to someone you used to talk with is to disable iMessage of course, then sign out of Facetime (who could imagine that as a necessary step?), sign out of iCloud, reboot the iPhone, and wait some minutes to hours to days until you are "deregistered" from iMessage. I'm talking about the same phone with the same SIM chip. The problem can become much worse if you've switched phones or SIM card.
That’s simply not true. I just turned off iMessage and instantly switched to the Message app and sent a SMS to someone I have a iMessage chat with and it worked without any problems
For a new iPhone user are there alternatives to using iMessage for texts to avoid this?
You can disable iMessage and the Messages app will then just send SMS. Or you can install Signal or WhatsApp or whatever
Don’t use SMS instead of iMessage though. Then all your texts will be sent across the network without any kind of decent encryption. And WhatsApp is almost unusable unless you consent to uploading all your contacts to Facebook. (IIRC this was the red line that got crossed that caused the WhatsApp founder to quit FB post-acquisition.)
Signal is a good recommendation, but you won’t be able to convince 100% of people you need to interact with over text to use Signal. You might convince friends and family, but not acquaintances or random people who might need to text with (like your electrician etc.)
Given the tradeoffs, iMessage is pretty good for day-to-day messaging.
It's a tradeoff. Do you want messages from strangers to run through a bunch of parsers that historically had problems, or do you want to take advantage of your peer group using iMessage.
I'm outside the US, so I don't even need to consider. Nobody here uses iMessage, even the people with iPhones.
> And WhatsApp is almost unusable unless you consent to uploading all your contacts to Facebook.
What? How-so? I've never allowed it to do that and it works fine for me, across iOS/Mac/Windows.
It works but it shows phone numbers rather than contact names and you can’t assign a name to a number without giving access to your entire contacts … it ticks me off.
Contact scoping on grapheneos solves that.
You see userpics though. Works for me...
Ah right, fair enough.
"but but my precious text bubble colors!!1"
Yeah, it seems iMessage in iPhone is like IE in Windows, a needlessly ingrained mess for market segmentation purposes
That is because iMessage has the same function as the night men in the Eagles song Hotel California:
"Relax,” said the night man, “We are programmed to receive
You can check out any time you like but you can never leave"
[1] https://www.smoothradio.com/features/the-story-of/eagles-hot...
> I would argue that iMessage is way to problematic to be used safely, at all.
Maybe I'm missing something but every single time the only part of iMessage (actually Messages.app) that is insecure is the bit that automatically unfurls attachments and the payload is exploiting a vulnerability elsewhere. So any other app unfurling the attachment thus triggering the payload would be equally vulnerable.
Imagine ping had a privilege escalation vulnerability and someone does ssh foomachine ping <payload> to get root, it'd be a bit weird to call out ssh as being unsafe because it can execute commands, one of them being able to privesc.
Disabling ssh would be a mitigation, and I do wish Messages would disallow unfurling for senders not in the recipient's contact list.
> So any other app unfurling the attachment thus triggering the payload would be equally vulnerable.
What you're missing is that iPhone's app sandboxing applies to other apps, not to iMessage.
Sure, imessage does have blastdoor and some sandboxing, but it also still has imagent: https://googleprojectzero.blogspot.com/2021/01/a-look-at-ime...
imagent runs as root and processes incoming messages. whatsapp or signal or whatever cannot ship an unsandboxed always on daemon like imagent.
signal/whatsapp/etc have to parse incoming messages inside the app sandbox. iMessage doesn't.
(I'm saying this all very confidently because the quickest way to get the right answer is to be confident about the wrong one and get corrected by a techbro)
Why would they give that specific process (imagent) that much privilege? Can nefarious motives be inferred from such a choice? It seems pretty damning to me that a glorified GIF processing helper is given root access to the entire system. It just doesn't add up that this is all accidental.
What are the odds that something like the NSO just happens to luck into being able to remotely initiate and sustain the building of an entire Turing-complete internal and unauthorized computer internally that also happens to be able to override all hardened protections to the contrary? It just seems so unlikely that there was not a hand in facillitating this internally at Apple. That's what happened with the GreyKey guy...
> imagent [...] processes incoming messages
does it?
IIUC (from a cursory look) according to the diagram it delegates all message processing to MessageBlastDoorService/IM{Transfer,Transcoder,Persistence}Agent, relying only on locally computed boolean-ish metadata replies from these services, and merely transparently forwarding actual data between those.
I'm no security pro, but last night I iMessaged a friend a TikTok video and according to him, the link initiated an App Clip. Perhaps it's totally safe and I'm just naive but it just seems like the risks of a link initiating code like that outweigh any rewards. Even if it's totally safe and all involved can be trusted, that experience is enough to creep me out.
It’s an attack vector because it’s convenient. If iMessage didn’t exist people would email you exploits.
Are there zero click exploits in email?
There’s been a long history of them, and an entire industry doing things like filtering attachments or rendering HTML emails in sandboxes.
I think the original poster made an attribution error: iMessage gets attacked because it’s popular. If it didn’t allow you to receive rich messages from anyone, people would switch to other apps which do and there’s a long history of those being exploitable, too. What makes iMessage special is that you can assume an iPhone user has it enabled without having to check whether they use WhatsApp, Telegram, Facebook Messenger, etc.
There were, eg in Outlook: https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
There probably still are and it’s possibly some three letter agencies or bad actors know about them.
There have been! One was in Microsoft Outlook parsing email subject lines, so you had to do was recieve email in order to get hacked. And there was another one around when heartbleed was a thing that had to do with parsing of the DNS lookup and response of who the email was coming from.
> It also seems to be the primary attack vector of NSO related zero-days as well and its become known that phone country/area codes have relevance to its chance of succes in past exploits, which suggests a phone/messaging type attack vector.
If you are using a phone, you have a phone number. Targeting the phone and SMS handling apps will always be the go-to vector for these sorts of attacks, because you don't want to tell your customer that they can only spy on targets that have Evernote installed and configured.
I agree, and there really need to be controls on it. I understand they want the "IMessage Network" to have predictable functionality, but I care about security more, and IMessage has been demonstrably unsafe for a long time.
I would really prefer to keep it text-only, and am fine with the goofy symbols. If they want to make photo exchange safe, they have the hardware to securely sign images taken on-device and only allow those.[1] (Although that would probably piss off regulators even more.)
[1] With some work, this could be a new feature, used to demonstrate images haven't been altered. With some lockdown of the clock, it could have secure timestamps. (Location could still be spoofed with a GPS hijack.)
It's also insecure. The sync keys for iMessage are backed up in the non-e2ee iCloud Backup, which means that iCloud serves as a key escrow for iMessage's e2ee, rendering it useless (as Apple, which is definitively not an endpoint, has a private key of the participant and can read all the messages in real-time).
iMessage should be assiduously avoided.
This is less true now, with the option to enable “advanced data protection”. Turning this setting on disables Apple’s access to your iMessage keys along with a bunch of other stuff, though of course if you get locked out, Apple can’t help you
Yeah, and this is the sort of thing that I think drives Apple's care in recommending the most secure modes; they don't want people causally turning it on and discovered that they've buggered themselves up.
I agree with you; Amazon servers receiving 80,000 or 800,000 requests per second or 8,000,000 is all a different ballgame than it is for 800 individual actual families around the world (or 8,000 or 80,000) to get their telephones totally buggered up before work that morning on any given workday -- just because somebody trustworthy has advised them to play it super safe without making equally sure the listeners were understanding the UX difficulties of recovering their smartphone's functionality in certain mundane use cases, etc, which would ensue. That's a lot of panic to deal with. Apple user help forum volunteers would be helpless to reach all the affected frustrated people.
I don’t believe this is true. You can change your iCloud password at any time, which means they definitely are not encrypting your iCloud data based on that key or a derivative. If I had to guess, they generate a key and encrypt that key with your password so it can be changed but they also aren’t able to produce it on request.
The drawback here is that the encryption key for your data never changes, even if you change your password (the private key is just re-encrypted with the new password).
If they’ve implemented it well then this is mostly academic but it does mean they must be escrowing encrypted keys for every account, and those with ADP enabled are just encrypted against their password rather than the Apple key. It also means if they’ve suffered an undetected breach in the past then changing your password doesn’t help protect your data going forward necessarily. That being said, if an attacker had ongoing access to iCloud data then it probably doesn’t matter (although the presumably-more-secure key vault wouldn’t need to be breached again).
I have no insight into Apple’s practices and this is all speculation, this is just the trade-off I would make to keep it usable.
The keys in advanced protection are derived from your device passcodes, your macOS user password and a recovery key. You'll notice you have to approve from one of your devices to use iCloud web or add a new device.
The deviation function takes a while to run and depends on the secure enclave, but you still probably want to avoid 4-digit passcodes.
They are, but they also must be encrypted n separate times where n is the number of signed in devices.
Mac iPad iPhone Recovery Key
Each of the above would have a separate uniquely encrypted device backup key as a result of the derivation function. I can change the password on any of those (or regenerate the recovery key) without a full iCloud re-encryption or duplication of my iCloud data - therefore Apple must be holding a key in escrow that is the actual decryption key. One would assume it's that key that is encrypted against the derivation function, as then it could still be credibly argued as end-to-end, but that's just an assumption I'm making.
I'm not sure why you're doing all this speculation, when wrapping keys is a pretty standard technique (i.e. LUKS key slots) and Apple provides the details themselves[1]. Yes, they're doing a handshake with secure enclave keys and transfer the master key to your devices. Turning on Advanced Protection will reencrypt all the data in iCloud in the background whereas turning it off will submit the master key to Apple so they can presumably place it on an HSM. Apple already did this before advanced protection with your Keychain.
[1]: https://help.apple.com/pdf/security/en_US/apple-platform-sec...
It's opt-in, so approximately nobody uses it.
Unless BOTH ends of a conversation are using it, it's pointless.
This means that turning it on does nothing in terms of privacy, in practice, today. All of the iMessages you send and receive will be readable using the escrowed keys from the other users you are messaging with.
Perhaps at some point Apple will prompt or nudge people to migrate, but that's unlikely given the risks to data loss for people who forget their credentials (and have "nothing to hide").
> if you get locked out, Apple can’t help you
Unfortunately, I can attest to this.
I probably spent 100+ hours doing everything possible to regain access to an iCloud account with advanced data protection.
I lost the password and the recovery key (with no 2nd apple device that was logged in). The only outcome in that scenario is losing your iCloud account completely.
Lesson: enable advanced security, but save your recovery key!
You don't have to use iCloud Backup.
It's on by default, which means everyone you iMessage with is escrowing the keys that allow Apple to decrypt all of the messages. Turning it off on only one end of the conversation has no meaningful effect.
Fair point.
Was going to mention. iMessage seems to be that golden key thing the FBeye asked them for back in 2015 in San Bernadino (insofar as iCloud itself isn't a/the key itself, already)