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

A deep dive into iOS Exploit chains found in the wild

googleprojectzero.blogspot.com

Post reply on HN
Print view View original

111–120 of 202 posts

Re: A deep dive into iOS Exploit chains found in the wild

#111

Post by eswat »

Hitton wrote: post #83
js2 wrote: post #12

This is terrifying. Just thinking about the data on a typical phone... the Implant could easily grab everything it needs to empty all of your financial accounts. The only way to be safe is probably to access your financial sites from a browser running inside a VM, maybe even a dedicated laptop, and never sync the passwords to anywhere outside the VM unencrypted. Ouch.

The dedicated laptop would be smarter idea. Running "sensitive" tasks from VM doesn't provide much protection if the host might be compromised.

I guess you'd have to worry about malware breaking out of the VM as well, but are there many exploits that do that these days?

Re: A deep dive into iOS Exploit chains found in the wild

#112

Post by eranation »

iandinwoodie wrote: post #104
sgjohnson wrote: post #101

Any way to check if my iPhone is affected? I'm still on 12.1.2, which was released before the fix, so if I'm affected, I should still have the malware on my device. I'm not opposed to jailbreaking to check.

The implant binary does not persist on the device; if the phone is rebooted then the implant will not run until the device is re-exploited when the user visits a compromised site again. [1] 1. https://googleprojectzero.blogspot.com/2019/08/implant-teard...

Just important to note that restarting the device is not the end of it. "Given the breadth of information stolen, the attackers may nevertheless be able to maintain persistent access to various accounts and services by using the stolen authentication tokens from the keychain, even after they lose access to the device."

I would recommend checking your login history / OAuth permissions to anything you had in your keychain, changing passwords for anything critical you used on your device if you suspect you were infected, a restart won't undo stolen information.

Re: A deep dive into iOS Exploit chains found in the wild

#113

Post by Godel_unicode »

bscphil wrote: post #45
maxdamantus wrote: post #36

Earlier quoted context omitted.

When you run any given application on your laptop, it's normally run in such a way that it has all of your user's priveleges on the system; that is, it can access all files that you can access, it can look at the screen that you're looking at, it can produce any input that you can produce, it can manipulate the memory of any process that you can manipulate. When you run an application on iOS or Android, it doesn't ha…

You're right that from a defense standpoint, sandboxed OSes like Android and iOS are "better" than your average laptop. Granted. The point I (and probably your parent comment) were originally trying to make is that the amount of data stored on a phone makes it a very good target for vulnerabilities like these. None of my banking, chat, email, etc information is stored on my laptop because I access these things throug…

> because I access these things through the browser.

Meaning the session cookies are stored on your computer, meaning I can steal those and then do whatever nefarious things I want to do off-box. Locality is a myth, attackers don't care about that. They just want the data, and finding/weaponizing bugs is the hard part.

Re: A deep dive into iOS Exploit chains found in the wild

#114

Post by iandinwoodie »

I'm always impressed by Google's Project Zero team, but I'm also impressed by abilities of the implementer(s).

What's interesting is that (for most of these cases) I find that I can understand the process of the reverse engineering, but I am completely stupefied as to the process of the initial implementation. I understand finding relatively superficial vulnerabilities (e.g., an SQL injection attack [1]), but I don't understand how these vulnerabilities are found when they are so many layers deep.

If anyone has an insight I would really appreciate it.

1. https://xkcd.com/327/

Re: A deep dive into iOS Exploit chains found in the wild

#115

Post by draugadrotten »

londons_explore wrote: post #66
yamrzou wrote: post #55

The list of apps being monitored which are hardcoded directly in the implant[1] include : com.yahoo.Aerogram com.microsoft.Office.Outlook com.netease.mailmaster com.rebelvox.voxer-lite com.viber com.google.Gmail ph.telegra.Telegraph com.tencent.qqmail com.atebits.Tweetie2 net.whatsapp.WhatsApp com.skype.skype com.facebook.Facebook com.tencent.xin [1] https://googleprojectzero.blogspot.com/2019/08/implant-teard...

This is an odd list. Some big messaging apps like Signal and Line are notably missing, while tools like Mail Master and Voxer seem like pretty minor players compared to the rest. Is there a particular region of the world or community where this specific list makes most sense?

com.tencent.xin makes a lot of sense in China https://en.wikipedia.org/wiki/Tencent_QQ

Re: A deep dive into iOS Exploit chains found in the wild

#116

Post by kemayo »

feanaro wrote: post #93
hannob wrote: post #72

Earlier quoted context omitted.

> Some big messaging apps like Signal and Line are notably missing Line is mostly used in Japan, Signal is mostly used by nerds. So you can assume neither japanese peopel nor nerd were their primary target. Given that this is true for the vast majority of the world population I'd not call this odd.

I've recently seen a surge of non-nerd Signal users. Mostly random people from my contacts starting to use it.

Hopefully a popularity surge will translate into the app getting better. It's notably less pleasant to use than Telegram, which I'd think of as its closest competitor.

Re: A deep dive into iOS Exploit chains found in the wild

#117

Post by lostgame »

dmix wrote: post #56
lawnchair_larry wrote: post #48

Earlier quoted context omitted.

Because the entity who supplied the exploit has no relation to the entity who supplies the implant and control framework. The latter is commodity developer work, easily done in house or via a defense contractor. It’s not unlikely that the exploit developer had no idea what it was being used in or how.

In my experience infosec people tend to be pretty awful programmers. They are experts at mining other people's code bases for common exploit patterns but not so great at the wider systems/engineering stuff. But agreed it was probably purchased from some vuln dev and put together by some hack gov employee with some Microsoft certifications or (far less likely) some indifferent blackhat with powerful weapons well out o…

Cleartext is the issue, here.

Even the most basic infosec folk will be aware to not do that - what this does is, as others have said, reveal that the developers were not the ones who found the exploit - it was likely simply purchased.

Re: A deep dive into iOS Exploit chains found in the wild

#118

Post by saagarjha »

snazz wrote: post #90
Wowfunhappy wrote: post #81

Earlier quoted context omitted.

I agree this is "a step in the right direction", but if the iPhones are special, would the exploit run on them? I suppose it depends on how "special" they are—do they run standard iOS with normal Safari and actual apps?

I think it just means they can run unsigned code. But yes, I would presume that Safari and the other default apps are present.

Production iPhones can do that already. Three phones probably give researchers root access and allow for disabling AMFI, etc.

Re: A deep dive into iOS Exploit chains found in the wild

#119

Post by js2 »

anon9001 wrote: post #63
js2 wrote: post #38

Earlier quoted context omitted.

> Earlier this year Google's Threat Analysis Group (TAG) discovered a small collection of hacked websites. The hacked sites were being used in indiscriminate watering hole attacks against their visitors, using iPhone 0-day. Crazy that the Implant was never detected directly on a phone. It's certainly visible to iOS itself, but apparently iOS isn't looking for unexpected processes running on the phone. As well, the Im…

It would be fun to check, but the attackers could just turn it off. It's a user-facing option: https://support.apple.com/en-us/HT202100

Of course they could, but the Implant according to Google didn't make any attempt to hide itself.

I'm the tech lead for my company's in-house mobile app crash reporter. Every so often we get reports that make no sense. Sometimes they are corrupted in strange ways which I just chalked up to bad device memory or storage, but who knows if something like this wasn't the cause. Semi-related, but I used to have jailbreak detection in the crash reporter SDKs but I had to remove it. Just attempting to detect a jailbroken device was in some cases causing the SDK to crash because the anti-jailbreak detection code injected into the app was buggy.

Re: A deep dive into iOS Exploit chains found in the wild

#120

Post by bt848 »

saagarjha wrote: post #41
bt848 wrote: post #30

Earlier quoted context omitted.

Perhaps it would behoove security-sensitive users to use such devices, but they make up a tiny fraction of all iOS devices in the field. 90% of deployed iOS devices in the USA lack the A12 CPU and the number is higher abroad. Obsolete 32-bit CPUs are more common than CPUs with PAC.

> Obsolete 32-bit CPUs are more common than CPUs with PAC. According to this (taken soon after iPhone XS/XR went on sale) this is not true: https://www.statista.com/statistics/755593/iphone-model-devi...

That apparently costs $50/mo to read. But it seems to discuss iPhone only. The universe of iOS devices is not limited to iPhones.
Post reply on HN