Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple iMessage Zero-Click Hacks

wired.com

Post reply on HN
Print view View original

111–120 of 156 posts

Re: Apple iMessage Zero-Click Hacks

#111

Post by dannyw »

gruez wrote: post #19
cyckl wrote: post #14

Earlier quoted context omitted.

I’m also getting these—no idea what the exploits actually are or how they work. Am I theoretically already exploited?

Not really. 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 di…

Disagree with all 3 points.

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.

Re: Apple iMessage Zero-Click Hacks

#112

Post by dannyw »

yokoprime wrote: post #105
ec109685 wrote: post #86

Why aren’t lightweight hypervisors used more outside the public cloud? It seems that would go a long way in protecting the rest of the device from poorly written c code parsing user input.

On device? The vast majority of people don't give a flying fuck about privacy, for them the decrease in battery life would not be worth it

so we should get rid of all security features then? No memory management, no code signing, no HTTPS, no certificate pinning?

Vierualisation has a negligible impact on power consumption.

Re: Apple iMessage Zero-Click Hacks

#113

Post by dannyw »

kossTKR wrote: post #52

"Apple hasn't issued a fix for this particular vulnerability"..."new defenses are coming with iOS 15, which will likely come out next month". 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?

It can take time to fix things properly. You don't want to half arse a mitigation, only for the attacker to bypass it in a week.

Re: Apple iMessage Zero-Click Hacks

#114

Post by eloisius »

dannyw wrote: post #110
eloisius wrote: post #88

I got corrected last time this topic came up. I originally thought Messages was part of the OS and not a pre-installed userspace app. However, if it's in userspace, why is it such a vulnerable vector for compromising the phone? Is there some privilege-escalation component to this that I haven't read about?

iMessage is one of few apps that have broad permissions to execute code in response to notifications. 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 thi…

So, in theory other messaging apps have the same vulnerabilities, but I’d have to open the message to get burnt?

Re: Apple iMessage Zero-Click Hacks

#115

Post by dannyw »

kenferry wrote: post #81
iamnotwhoiam wrote: post #78

Does this mean that iMessage evaluates messages as code for some reason? Why on earth would that be the case? It's a foundational security principle to not do that. And even if they did then why is that so hard to fix?

It’s more like, if you send someone a photo, iMessage will decode the photo and display it. If the imaging library has a bug a maliciously crafted image may be exploitable. 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.

iMessage is also the only messaging app that triggers all its decode functions upon notification, because of its special privileged status.

Re: Apple iMessage Zero-Click Hacks

#116

Post by dannyw »

eloisius wrote: post #114
dannyw wrote: post #110

Earlier quoted context omitted.

iMessage is one of few apps that have broad permissions to execute code in response to notifications. 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 thi…

So, in theory other messaging apps have the same vulnerabilities, but I’d have to open the message to get burnt?

Yes. These apps also have happened to WhatsApp.

Re: Apple iMessage Zero-Click Hacks

#117

Post by saagarjha »

CyberRage wrote: post #108
saagarjha wrote: post #104

Earlier quoted context omitted.

This is correct. My point is that you would want to access messages data after doing that.

So let's circle back to the original question. 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.

Exploiting the kernel is obviously always desirable, but it's not always possible.

Re: Apple iMessage Zero-Click Hacks

#118

Post by xvector »

est31 wrote: post #27
SalimoS wrote: post #16

Wouldn’t be not parsing incoming media unless it’s for someone from contact is a first step that can reduce largely the thread ? So it will stay the same for people in your contact list but a new touch to load for message from unknown person

https://en.wikipedia.org/wiki/Dancing_pigs

A reasonable trade-off would be disabling parsing for people not in your contacts list.

Re: Apple iMessage Zero-Click Hacks

#119

Post by xvector »

kenferry wrote: post #81
iamnotwhoiam wrote: post #78

Does this mean that iMessage evaluates messages as code for some reason? Why on earth would that be the case? It's a foundational security principle to not do that. And even if they did then why is that so hard to fix?

It’s more like, if you send someone a photo, iMessage will decode the photo and display it. If the imaging library has a bug a maliciously crafted image may be exploitable. 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.

Can Apple not rewrite the parsing components in a memory-safe language?

Re: Apple iMessage Zero-Click Hacks

#120

Post by KaiserPro »

dannyw wrote: post #109
bb123 wrote: post #106

Earlier quoted context omitted.

I wouldn't want this at all. Just off the top of my head I can think of a ton of use cases this makes hard: * 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, bu…

All of this can be on a "Tap to view" basis for the first media received. 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.

This a million times.

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.

Post reply on HN