3 ms·

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

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.

sneak 3y ago
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.
- Obscurity4340 3y ago
  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)
- jxcl 3y ago
  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
  - rodgerd 3y ago
    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.
    - glompers 3y ago
      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.
  - highwaylights 3y ago
    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.
    - _cenw 3y ago
      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.
      - highwaylights 3y ago
        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.
  - sneak 3y ago
    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").
  - cj 3y ago
    > 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!
- hackmiester 3y ago
  You don't have to use iCloud Backup.
  - sneak 3y ago
    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.
    - hackmiester 3y ago
      Fair point.
- deleted 3y ago
  [deleted]
computator 3y ago
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.
- zuhsetaqi 3y ago
  > 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
- jupp0r 3y ago
  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.
_jal 3y ago
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.)
lloeki 3y ago
> 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.
- TheDong 3y ago
  > 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-imessage-in-ios-14.html 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)
  - Obscurity4340 3y ago
    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...
saagarjha 3y ago
It’s an attack vector because it’s convenient. If iMessage didn’t exist people would email you exploits.
- VHRanger 3y ago
  Are there zero click exploits in email?
  - fragmede 3y ago
    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.
  - wffurr 3y ago
    There were, eg in Outlook: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-23397 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.
  - acdha 3y ago
    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.
speak_plainly 3y ago
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.
dwaite 3y ago
> 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.

sneak 3y ago

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.

Obscurity4340 3y ago
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)
jxcl 3y ago
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
- rodgerd 3y ago
  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.
  - glompers 3y ago
    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.
- highwaylights 3y ago
  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.
  - _cenw 3y ago
    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.
    - highwaylights 3y ago
      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.
- sneak 3y ago
  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").
- cj 3y ago
  > 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!
hackmiester 3y ago
You don't have to use iCloud Backup.
- sneak 3y ago
  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.
  - hackmiester 3y ago
    Fair point.
deleted 3y ago
[deleted]

computator 3y ago

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.

zuhsetaqi 3y ago
> 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
jupp0r 3y ago
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.

_jal 3y ago

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

lloeki 3y ago

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

TheDong 3y ago
> 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-imessage-in-ios-14.html 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)
- Obscurity4340 3y ago
  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...

saagarjha 3y ago

It’s an attack vector because it’s convenient. If iMessage didn’t exist people would email you exploits.

VHRanger 3y ago
Are there zero click exploits in email?
- fragmede 3y ago
  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.
- wffurr 3y ago
  There were, eg in Outlook: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-23397 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.
- acdha 3y ago
  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.

speak_plainly 3y ago

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.

dwaite 3y ago

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