Live data from Hacker News

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

citizenlab.org

211–220 of 255 posts

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

#211

Earlier quoted context omitted.

If you can tie the tool to any circumvention of copyright protections -- pretty broad argument (DMCA), you can be sued or arrested.

and then you lean on USC Title 17 Chapter 12 § 1201 (f) : the interoperability with other software defense, broad argument.

That makes more sense then my idea. But it would have to be Apple that brought the suit.

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

#212
post #45

There is a frustration, as a user, that as the value of the iOS exploits increase, they become more and more 'underground'. The time between OS release and public jailbreak is continually growing - and it doesn't seem to only be due to the hardening of the OS. People are selling their exploits rather than releasing them publicly. And the further underground they go, the more likely they will be utilized for nefarious…

I look at it the other way: as exploits become more and more underground, I feel safer: I know those exploits are more likely to be used by state actors against activists and other people who are doing illegal stuff, and less likely to be used against me and millions of other users to install malware on our phones (to make them send spam, to make them send expensive texts...) So yes I feel safer now.

"activists and other people who are doing illegal stuff"

Does this actually read how you intended it to, or was there an invisible comma/parenthesis there?

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

#213
post #160

Earlier quoted context omitted.

Love that Technical Analysis. If Apple, Google, MS, Linux distribution does the following: * Create sha1, sha256, sha256 chksums of every system, app files and store them in a secure database somewhere. * Check and audit the system files from time to time and notify the user when change happen. Would it prevent these type attack or at lease notify the user that system security has be compromised?

Doubt it. Once you have control of the system, why would you not be able to just disable the check? What they should do is enforce code signing at the processor level.

If the checks are enforced by the bootloader which is signed, then you cannot disable them. I think this is how the system partition is protected on recent Android versions. As this attack demonstrates, simply requiring all code to be signed isn't enough.

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

#214

Earlier quoted context omitted.

Separating code from knowledge was part of the fun of the decss debacle. "That's not a haiku; that's an illegal perl script!"

And fundamentally it's the knowledge that matters. Programmers are "expensive" but not that expensive. Give any decent off-the-shelf code monkey the specifics of a vulnerability and he can give you exploit code. Which means restricting the exploit code is quite useless. But restricting the knowledge itself doesn't work because the same knowledge is necessary to mitigate the vulnerability and to test that the mitigati…

These days, exploiting vulnerabilities in most interesting code actually seems to be quite fiddly thanks to all the mitigation techniques and requires a bunch of specialist knowledge and tools that isn't exactly trivial to come by. The knowledge is already restricted, just for commercial rather than legal reasons.

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

#215
post #214

Earlier quoted context omitted.

And fundamentally it's the knowledge that matters. Programmers are "expensive" but not that expensive. Give any decent off-the-shelf code monkey the specifics of a vulnerability and he can give you exploit code. Which means restricting the exploit code is quite useless. But restricting the knowledge itself doesn't work because the same knowledge is necessary to mitigate the vulnerability and to test that the mitigati…

These days, exploiting vulnerabilities in most interesting code actually seems to be quite fiddly thanks to all the mitigation techniques and requires a bunch of specialist knowledge and tools that isn't exactly trivial to come by. The knowledge is already restricted, just for commercial rather than legal reasons.

Which is still knowledge. If you have the information you can make the tools.

I mean obviously in reality the line between "information" and "software" is non-existent because software is just a type of information, but if you insist on trying to draw a line anyway then it still fails because it's still possible to convey everything of significance using natural language, and the skillset required to convert plain language instructions into software is not rare enough to be prohibitive.

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

#216

Earlier quoted context omitted.

Some years ago, I had Tripwire installed for a few days but quickly removed it again because whenever I upgraded installed packages, I'd get a storm of messages about files which had changed and that was just annoying since I was the one who had initiated the action that caused the files to change, but at the same time there were so many files that changed of course, that I had no way of distinguishing legitimate cha…

That's precisely what it's supposed to do. If you update the Tripwire db every time you "initiate an action that causes monitored files to change" - then it does a _magnificent_ job of telling you when someone _else_ changes those files. You need to run 'tripwire --update' every time you run 'apt-get update' or 'pip install foo' or 'npm install bah' or whatever - then you wont get that storm of false positives.

Honest question from an interested party: have you actually had it alert you about someone else changing the files?

I've been in the previous boat: of having it running on a system I've inherited, and given up because it seemed too much hassle.

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

#217
post #216

Earlier quoted context omitted.

That's precisely what it's supposed to do. If you update the Tripwire db every time you "initiate an action that causes monitored files to change" - then it does a _magnificent_ job of telling you when someone _else_ changes those files. You need to run 'tripwire --update' every time you run 'apt-get update' or 'pip install foo' or 'npm install bah' or whatever - then you wont get that storm of false positives.

Honest question from an interested party: have you actually had it alert you about someone else changing the files? I've been in the previous boat: of having it running on a system I've inherited, and given up because it seemed too much hassle.

Yes - a few times a year when normal and authorised things or people have unexpectedly changed files in tripwire-protected places, and in ~20 years I think three times when I'd had an intrusion.

Those three timely notifications of real breaches have made 20+ years worth of occasional false positives 100% worth it.

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

#218

Earlier quoted context omitted.

> I can draw a conceptual line: Ban using exploits on other people's equipment. But practically, I don't see how to stop that without criminalizing distribution, in which case I can't get my data from my phone (or install a 3rd party OS) without the vendor's permission. I don't understand what the problem is supposed to be. You don't need laws against knives because there are already laws against assault and murder a…

> You don't need laws against knives because there are already laws against assault and murder A good point. In this case it's so hard to catch perpetrators that to stop the crimes, it could be necessary to ban the weapons or their distribution (if that even is a practical option). Are the other similar situations, where perpetrators are so hard to catch and you have to ban the means? Counterfeiting is all I can thin…

> Are the other similar situations, where perpetrators are so hard to catch and you have to ban the means?

The nearest thing is clearly DMCA 1201. The problem of course being that DMCA 1201 is an epic failure. DRM circumvention tools are widely available to pirates, meanwhile it regularly subjects honest people to a choice between breaking the law and having it interfere with their legitimate activities.

> Also, color printers are dual-use: They have many legitimate uses, exploits have very few.

Exploits seem to have more legitimate uses than illegitimate ones. The only illegitimate use that comes to mind is wrongfully breaking into systems, which is the mirror image of the legitimate use of rightfully breaking into systems, in case you somehow get locked out (or some malicious third party locks you out).

Then on top of that, sysadmins require exploits to verify that a patch actually prevents the exploit. And proof of concept exploits are sometimes the only way to convince a vendor to fix a vulnerability. And academics need to study the newest actual exploits in order to keep up with what currently exists in the wild.

> Weapons that help foreign governments oppress large parts of their population might qualify, though clearly not all exploits fit that description.

Smallpox is inherently dangerous. Some exploits could be specifically dangerous in the sense that some very sensitive systems could be vulnerable to them, but only in the same sense that a Fire Axe could be used to break down some doors leading to very sensitive areas. The problem then is not that the public has access to axes, it's that there aren't enough independent security layers protecting sensitive systems.

And you can't fix that problem by banning tools because a high value target with bad security will fall to a state-level attacker regardless. The only answer is to improve the security of sensitive targets.

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

#219
post #160

Earlier quoted context omitted.

Direct links to other resources: Technical analysis: https://info.lookout.com/rs/051-ESQ-475/images/lookout-pegas... CitizenLab analysis of the nation-state side of things: https://citizenlab.org/2016/08/million-dollar-dissident-ipho... Apple update: https://support.apple.com/en-us/HT207107

Love that Technical Analysis. If Apple, Google, MS, Linux distribution does the following: * Create sha1, sha256, sha256 chksums of every system, app files and store them in a secure database somewhere. * Check and audit the system files from time to time and notify the user when change happen. Would it prevent these type attack or at lease notify the user that system security has be compromised?

Doesn't "rpm -Va" do this (minus the "secure database" part)?

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

#220

Earlier quoted context omitted.

> You don't need laws against knives because there are already laws against assault and murder A good point. In this case it's so hard to catch perpetrators that to stop the crimes, it could be necessary to ban the weapons or their distribution (if that even is a practical option). Are the other similar situations, where perpetrators are so hard to catch and you have to ban the means? Counterfeiting is all I can thin…

> Are the other similar situations, where perpetrators are so hard to catch and you have to ban the means? The nearest thing is clearly DMCA 1201. The problem of course being that DMCA 1201 is an epic failure. DRM circumvention tools are widely available to pirates, meanwhile it regularly subjects honest people to a choice between breaking the law and having it interfere with their legitimate activities. > Also, colo…

> Smallpox is inherently dangerous.

I think the equivalent (or much worse, actually) for exploits is something that is self replicating and disruptive. For example, a bug in the BGP routing protocol (or a certain percentage of the common implementations) that propagates bogus routes and disrupts some or all traffic for affected systems and spreads. Something that disrupted a large enough chunk of global traffic would not only be horrendous in its own right, but would also make dissemination of any fix quite problematic.

Then again, I assume it's probably good practice to somewhat lock down how BGP functions in your routers (if that makes sense. I'm not that familiar with it), but a certain incident from last year[1] leads me to believe that's either not possible, hard to do, or people just don't do it.

1: http://www.bgpmon.net/massive-route-leak-cause-internet-slow...

Post reply on HN