Live data from Hacker News

A deep dive into iOS Exploit chains found in the wild

googleprojectzero.blogspot.com

191–200 of 202 posts

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

#191
post #61

Earlier quoted context omitted.

Absolutely. It is such a disgrace to open society that we have allowed our phones, computers and cars to be so taken over by corporate interest that we cannot even peek inside. NB I heard some infosec research companies actually get rooted phones from Apple with some big caveats.

This is what the free market chose. People bought these devices en masse and continue to do so. It’s on us - the end user.

there‘s no better alternative.

no, please don‘t tell me about android. that‘s a fucked up mine field altogether.

we need to remember that there is no and will never be 100% security. while not open — which is worth nothing to the average user — we get pretty close with ios given all we know.

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

#192
I literally don't understand how do you get the knowledge to write an exploit like this. I'm a c++ programmer working on game engines, so manual memory management is my bread and butter, you have to have a detailed understanding of the underlying hardware architecture to do this job, but I don't understand how you go from where I am to writing a low level exploit like this.

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

#193

Do you think theres a bank of iPhones at Google loading every webpage on the internet, and looking for unexpected background processes or network traffic?

That's what the crawler infra can be used for. It can easily be adjusted for this purpose.

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

#195

From about 2016-2018 I was wondering why my iMessages became fodder for strangers to parrot back to me at coffee shops in the small USA town in which I was living. Of course, I explored the idea that the other parties of these iMessage conversations (usually thousands of miles away with no apparent connection to people in my locale) had somehow betrayed me. This was likely not the case, as I confronted those parties…

I’m sorry, what? Strangers at coffee shops in your small town would read your private iMessages to which they somehow had access? That makes literally 0 sense.

- how did they know your name / for whom to look up these hacked messages? - how did they know where to find these hacked messages? - why would they reveal their ability to watch your every move by repeating your private messages? - even if they had all of these capabilities and no shame about letting you know, why on earth would they care enough to look at your messages?

The scenario you’re convinced happened sounds completely bizarre, and gives me some strong Terry Davis vibes (no disrespect to him - that’s the person he became due to his illness).

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

#196

A while ago, Google showed messages at the top of Gmail for some users "We believe state-sponsored attackers might be attempting to compromise your account or computer". If they had send some OAuth tokens for a honeypot gmail account to the C&C server used for these attacks, they could then track the usage patterns of that token, and find all the other attacked users. Perhaps thats how they identified who was being a…

I was thinking the exact same thing. It's possible that because it has been so long since Google identified this threat actor, they did in fact use a honeypot account to trace the attackers prior to burning them.

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

#197
post #157

Earlier quoted context omitted.

That's not the worst part. The worst part is the attacker getting the data. The slight chance that while you're infected you also happen to be on a public wifi in the same room at the same time as a random opportunistic hacker, or that an ISP employee is risking their job by combing through petabytes of transient customer data, is much less concerning.

Attacker already got the data http or https. But by publishing over http...other sniffers of public traffic also get your data.

This makes sense if a state level actor, with global network visibility (including playback capabilities, aka XKEYSCORE and TEMPORA) is behind it.

Even if a C&C server is taken down, they would still be able to persist the data.

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

#198

It seems the webkit renderer process goes into an infinite sleep when this exploit is used. Since iOS doesn't use a seperate renderer for different web domains/iframes, that would mean the entire tab will freeze. Surely that would be a pretty big giveaway for the user - "I was just browsing round the bombmaking-for-dummies webpage, and my browser just froze, and I had to kill it and reopen it".

Safari on iOS is pretty much the most unstable browser I have been using in the last ~5 years. I can't count how many times I had to kill and repopen Safari just because it froze on some Youtube video. So, no this is not a big giveaway. Unless something on the Youtube site targeted my own and most of my friends' iOS devices, of course.

Never happened to me.

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

#199

I literally don't understand how do you get the knowledge to write an exploit like this. I'm a c++ programmer working on game engines, so manual memory management is my bread and butter, you have to have a detailed understanding of the underlying hardware architecture to do this job, but I don't understand how you go from where I am to writing a low level exploit like this.

fuzzing using something like AFL possibly?

http://lcamtuf.coredump.cx/afl/

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

#200

Earlier quoted context omitted.

Either that or they have specialized web-crawlers that emulate various browsers.

Emulating a browser wouldn't be good enough for most exploits. Most stealthy malware immediately deactivates itself if it thinks it is on an emulated or virtualized system.

If I understood what little I read of the exploit details, it actually loads an opaque payload through WebGL calls, so simply crawling with an iPhone's user-agent wouldn't be enough to notice anything "fishy". The site can just serve the payload to all visitors, then the implant will get installed if the resulting kernel calls are broken as described in the article.
Post reply on HN