A new Citizen Lab report describes state actors using NSO Group's new zero-click/no interaction exploits on journalists in the Middle East. https://citizenlab.ca/2020/12/the-great-ipwn-journalists-hacked-with-suspected-nso-group-imessage-zero-click-exploit/<p>I then started reading:
https://www.vice.com/en/article/qvakb3/inside-nso-group-spyware-demo
https://www.vice.com/en/article/pkyzxz/spain-nso-group-pegasus-catalonia<p>If NSO Group and many other companies and intelligence agencies are actively developing zero-days, how can one protect against it?<p>Is security through obscurity (e.g. using the PinePhone or an unknown platform) the only option?<p>I'm only really asking about individual solutions to protect data, rather than systemic ones, like the recommendation by the U.N. Special Rapporteur on freedom of expression for a global moratorium on the sale and transfer of surveillance technology. Such systemic solutions seem unlikely as of yet.
I don't think it's super helpful for most orgs to try (to stay ahead of NSO type orgs), honestly.
You can't have a 100% secure computer, so you are already making some compromises. And, by definition, a zero-day is something that you have no forewarning of.<p>I think MOST orgs don't have to worry about NSO or state-level actor attacks. Most orgs are far more susceptible to ransomware and phishing, and should focus first on those.<p>The best approach to mitigating Zero-days is _detection_, to be honest. Would your shop be able to detect files flowing out? Odd time access? Weird probes from a computer inside the network?
Security through obscurity is never a good solution. That means bespoke stuff that might be hard to work with, but doesn't necessarily improve your security posture.<p>You want to develop a deep defense with good detection and monitoring with review. That will help you not just with Zero days, but all security aspects.
This is not so much a technical answer to your question, but a generalization. If you can determine what specifically an application must be able to do to function properly, then you can write rules and implement them in Linux Security Modules (SELinux, AppArmor, Tomoyo) [1] that enforce mandatory access controls describing what the applications are permitted to do, then it becomes a bit harder to bend an application to do your bidding through code bugs and deficiencies. Android has SELinux, so this could be done on some cell phones. It would be up to cell phone vendors and app developers to work together to implement this properly. I am betting they won't actually do this, but some of the <i>open source</i> phones like PinePhone [2] might be open to it. You can also containerize applications and set/unset "capabilities" [3] for the container to the bare minimum required for the application. MAC + Capabilities implemented properly can make exploiting zero days significantly harder. It can also make spotting and logging exploit attempts easier. This raises the risk for people holding zero days to utilize <i>and burn</i> them.<p>[1] - <a href="https://en.wikipedia.org/wiki/Linux_Security_Modules" rel="nofollow">https://en.wikipedia.org/wiki/Linux_Security_Modules</a><p>[2] - <a href="https://www.pine64.org/pinephone/" rel="nofollow">https://www.pine64.org/pinephone/</a><p>[3] - <a href="https://man7.org/linux/man-pages/man7/capabilities.7.html" rel="nofollow">https://man7.org/linux/man-pages/man7/capabilities.7.html</a>
Get one of these <a href="https://www.solianiemc.com/en/cp/shielded-tent/" rel="nofollow">https://www.solianiemc.com/en/cp/shielded-tent/</a> .<p>Otherwise, assume basically all software and hardware is vulnerable for a price if it's anywhere near anything that can connect to a wireless network or bluetooth device.