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

51–60 of 156 posts

Re: Apple iMessage Zero-Click Hacks

#51

Post by passerby1 »

CyberRage wrote: post #22
kylehotchkiss wrote: post #4

A small way to reduce attack surface - have iMessage just setup for your iCloud email address instead of phone number. Phone numbers are becoming increasingly useless. > 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.

whatsapp doesn't rely on SMS protocols nor does it rely solely on phone numbers but is still being exploited quite often. Instant-Messaging = Worthy target for exploits. Just like web-browsers get exploited after years of patching.

>whatsapp doesn't rely on SMS protocols

Wrong. Whatsapp relies on SMS as 2FA OTP.

Re: Apple iMessage Zero-Click Hacks

#52

Post by kossTKR »

"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?

Re: Apple iMessage Zero-Click Hacks

#53

Post by dylan604 »

rmorey wrote: post #46
dylan604 wrote: post #34

Earlier quoted context omitted.

Can you war-dial attack with these? Seems like it would be super easy for a script kiddie to just start at 111-111-1111, send message, increment by 1, repeat. Maybe narrow it down to valid area codes and what not, but seems like a super low budget thing to do.

Well, send from what? Every iMessage comes from an account with an Apple ID, so I presume stolen credentials would be the only way to really do this, adding to the cost.

If you know the email address that is used for the Apple ID, you can send it a message without being in messages. You can also send a text to a phone number via email based on the carrier and knowing how to structure the address. So, it's not impossible to do this at all. No stolen credentials necessary.

Re: Apple iMessage Zero-Click Hacks

#54

Post by hypothesis »

gjsman-1000 wrote: post #8
kevingadd wrote: post #7

Earlier quoted context omitted.

Similarly to Android there have been attacks that involve exploiting bugs in the code that parses incoming messages, and then via the exploit you can get remote code execution 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

There was a developer who discovered a bug with the XML parser, and wrote a whole blog post about how he was able to cause iOS's security system to malfunction using a specially-crafted XML permissions file and allow his app to do anything he wanted, even escape the sandbox. He kept it secret for years for his private experimentation until Apple patched it by accident, by adding a 5th XML parser to the other 4 for so…

Are there seriously 5 XML parsers available in iOS? Are they all written in C? Do they validate all of them whenever a bug is found in one? I can’t tell if this is some sort of defense in depth or just swiss cheese copy-paste…

Re: Apple iMessage Zero-Click Hacks

#55

Post by azinman2 »

saagarjha wrote: post #40
azinman2 wrote: post #25

Earlier quoted context omitted.

Objective-c has bounds checks and lengths built into NSData, NSArray, and NSString… so many of the buffer overflow techniques likely won’t work against it. However, images and video seem to hit C++ code and from all of the past CVEs it seems this is a giant attack surface over and over again. I’m surprised this code isn’t being rewritten in something like Rust, but perhaps there are more things going on at play, like…

Objective-C can run into other issues, though: NSSecureCoding exists for a reason ;)

Which is why I mention plists

Re: Apple iMessage Zero-Click Hacks

#56

Post by SV_BubbleTime »

kylehotchkiss wrote: post #4

A small way to reduce attack surface - have iMessage just setup for your iCloud email address instead of phone number. Phone numbers are becoming increasingly useless. > 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.

> email address instead of phone number. Phone numbers are becoming increasingly useless.

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.

Re: Apple iMessage Zero-Click Hacks

#57

Post by dylan604 »

zsmi wrote: post #45
dylan604 wrote: post #34

Earlier quoted context omitted.

Can you war-dial attack with these? Seems like it would be super easy for a script kiddie to just start at 111-111-1111, send message, increment by 1, repeat. Maybe narrow it down to valid area codes and what not, but seems like a super low budget thing to do.

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

>Also, some users give random apps access to their address book for whatever reason

"There's a sucker/fool born every minute." --PT Barnum

And there are businesses of all types where that is their sole business model.

Re: Apple iMessage Zero-Click Hacks

#58

Post by stephencanon »

setpatchaddress wrote: post #47
raspasov wrote: post #35

Earlier quoted context omitted.

I agree. Swift is a nice language, compared to the alternatives. 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. Effe…

Yes, there are some people who simply prefer Objective-C, but you need to also realize that Swift is still not ready for system-level programming. Analysis tools aren’t ready; debugging basically means you go to printing variables to stderr and praying. The standard library defaults to crashing at runtime for simple float integer conversion bounds errors which you’d think would be caught statically with more thoughtf…

> The standard library defaults to crashing at runtime for simple float integer conversion bounds errors which you’d think would be caught statically with more thoughtful design.

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.

Re: Apple iMessage Zero-Click Hacks

#59

Post by robocat »

CyberRage wrote: post #23
gjsman-1000 wrote: post #5

I wonder if Apple's devs are just going to say, screw it, we'll rewrite the whole thing in Rust with audits and formal analysis the whole way...

Well I would dare to say iMessage isn't the biggest target to convert to Rust. 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.

I would pick the baseband processor as the biggest target. https://www.theiphonewiki.com/wiki/Baseband_Device

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

Re: Apple iMessage Zero-Click Hacks

#60

Post by saagarjha »

passerby1 wrote: post #51
CyberRage wrote: post #22

Earlier quoted context omitted.

whatsapp doesn't rely on SMS protocols nor does it rely solely on phone numbers but is still being exploited quite often. Instant-Messaging = Worthy target for exploits. Just like web-browsers get exploited after years of patching.

>whatsapp doesn't rely on SMS protocols Wrong. Whatsapp relies on SMS as 2FA OTP.

I don't think that is the context that the commenter was using when they said WhatsApp doesn't rely on SMS.
Post reply on HN