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

NSO Group's iPhone Zero-Days used against a UAE Human Rights Defender

citizenlab.org

Post reply on HN
Print view View original

251–255 of 255 posts

Re: NSO Group's iPhone Zero-Days used against a UAE Human Rights Defender

#251

Post by amagumori »

mentat wrote: post #101
runesoerensen wrote: post #86

Earlier quoted context omitted.

Sure but how is that responsive to parent's point about Mansoor being an "outlier in taking precautions" ? The reason he found out about the previous attacks was likely because he took similar precautions: "When Ahmed Mansoor opened the document, his suspicions were aroused due to garbled text displayed. His email account was later accessed from the following suspicious IPs.." https://citizenlab.org/2012/10/backdoors…

I'm not sure if you call it a "precaution" when you notice someone's pwnd you. Still good job noticing it after the fact.

Then again, he's not some comfortable first-world programmer who makes $100K a year and enjoys talking about infosec and opsec as a fun diversion, he's a guy living in a repressive third-world dictatorship who has put his entire life on the line for the human rights of others and probably has little to no computer science or infosec education, so, maybe cut the guy some fucking slack.

Re: NSO Group's iPhone Zero-Days used against a UAE Human Rights Defender

#252

Post by bobsil1 »

amagumori wrote: post #251
mentat wrote: post #101

Earlier quoted context omitted.

I'm not sure if you call it a "precaution" when you notice someone's pwnd you. Still good job noticing it after the fact.

Then again, he's not some comfortable first-world programmer who makes $100K a year and enjoys talking about infosec and opsec as a fun diversion, he's a guy living in a repressive third-world dictatorship who has put his entire life on the line for the human rights of others and probably has little to no computer science or infosec education, so, maybe cut the guy some fucking slack.

> third-world

Agree strongly, just a small note: UAE is quite wealthy. Higher PPP-adjusted per capita income than Sweden.

Re: NSO Group's iPhone Zero-Days used against a UAE Human Rights Defender

#253

Post by nacs »

tannedNerd wrote: post #201
nacs wrote: post #183

Earlier quoted context omitted.

... or you could just hook it up to iTunes and let iTunes flash the whole phone with the latest iOS from scratch (9.3.5 fixes these exploits) instead of letting the on-device updater do it. No need for a whole new phone.

I guess I've never dug deep into how a iPhone restore to default from iTunes works, but does it actually zero out the whole disk or is it possible for this exploit to survive that.

There are 2 ways. It can do a quick reinstall or it can do a full flash that wipes out everything (you can force it to do that by holding shift or the Apple key or something when clicking the restore button).

Re: NSO Group's iPhone Zero-Days used against a UAE Human Rights Defender

#254

Post by SanPilot »

startling wrote: post #189
SanPilot wrote: post #149

I'm a beginner when it comes to software development (mostly web development), but it seems to me that the majority of complex exploits like this involve some type of memory overflow and subsequent code execution. Shouldn't there be methods for detecting these kinds of things in source code or more priority given to preventing it in the C/low-level community?

There are. "(Kernel) address space layout randomization" is one of them. It was circumvented here; that's part of why this is impressive.

How is it possible to put the malicious code in the correct memory spaces? Unless the attacker had a full image of the memory, I don't see how this can be accomplished.

Re: NSO Group's iPhone Zero-Days used against a UAE Human Rights Defender

#255

Post by startling »

SanPilot wrote: post #254
startling wrote: post #189

Earlier quoted context omitted.

There are. "(Kernel) address space layout randomization" is one of them. It was circumvented here; that's part of why this is impressive.

How is it possible to put the malicious code in the correct memory spaces? Unless the attacker had a full image of the memory, I don't see how this can be accomplished.

The second bit of the exploit chain, CVE-2016-4655, leads to disclosure of kernel memory addresses. Once a single memory address is known, you can calculate the random offset of the kernel, and then exploit the third part to overwrite the return address and return into specific chunks of kernel code ("Return Oriented Programming"), whose addresses you computed from the offset + a fixed code location. These can let you e.g. install your payload.
Post reply on HN