6 ms·

This is a good overview of the public commercial spyware landscape on iOS over the years, including attributions to several of the high profile players in this

• ignoramous 2y ago
  Thanks. > ...we're currently in the Stone Age of iPhone forensics on the defensive side. Since I've seen your comments show a pretty good understanding of AOSP/Android, what's your take on its posture against CSVs? Especially given that Google has been pursuing both legal [0] & technical defenses (at every level of the software stack) against them quite actively. [0] Ex: https://www.centerforcybersecuritypolicy.org/hacking-policy-council https://www.centerforcybersecuritypolicy.org/hacking-policy-...
  • pxeger1 2y ago
    What does CSV mean?
    • saagarjha 2y ago
      Commercial Spyware Vendor
    • technol0gic 2y ago
      Comma Separated Values...theyre hyperspamming it with spreadsheets
  • saagarjha 2y ago
    I don't know much about the legal stuff you linked but I am generally supportive of most of the things Google is doing to harden Android against CSVs. If you have specific mitigations or policies you were thinking of I can tell you what I think of those (not all of them are necessarily positive) but on the whole the OS has been getting more difficult to hack and I view this as a good thing.
    • ignoramous 2y ago
      > specific mitigations or policies - How much impact will moving sharedlibs (mediaserver, for example) / runtime / libcore to Rust will bring? And if all libs will need to be moved? Or, are the likes of memory tagging, sanitizers, hardened allocators (Scudo in bionic / Arena/dl/Ros in ART) enough of a defense? - Now that Android devices have as much compute/RAM as servers do (and fast battery charging is almost ubiquitous), do you see VM sandboxing apps (like in ChromeOS does with crostini) become a thing? - Believe the drivers (Binder at one stage, GPUs, of late) remain a source of exploits; do you see a microkernel like Zircon being folded into the Android Kernel? Longer-term, will moving away from Linux (but maintaining compat via emulation, say) become a necessity to combat CSVs? - I see a bunch of eBPF use since Android 12+. Do you foresee Google providing more APIs to aid forensics / monitoring (like Knox/EMM) without needing root (or abusing Accessibility/VPN/DeviceAdmin/ADB Shell/etc). Thanks.
      • saagarjha 2y ago
        > How much impact will moving sharedlibs (mediaserver, for example) / runtime / libcore to Rust will bring? And if all libs will need to be moved? - Or will the likes of memory tagging, sanitizers, hardened allocators (Scudo in bionic / Arena/dl/Ros in ART) enough of a defense? I'm not an expert on specific attacks against allocators, but my general rule of thumb based on what they describe themselves as is that this helps but does not obviate heap memory corruption from being the source of exploitable vulnerabilities. So I would say that moving to Rust would still be useful. > Now that Android devices have as much computer/RAM as servers do (and fast battery charging is almost ubiquitous), do you see VM sandboxing apps (like in ChromeOS does with crostini) become a thing? So Android has a thing called pKVM that was designed, as far as I can tell, to run secret ML models and DRM. When I left they seemed to be looking for more pleasant clients, so it seems reasonable that they one day actually work to put security-critical services into VMs. But the overhead is quite high so I assume there will need to be a lot of work put into this if they want it to be practical. > Believe the drivers (Binder at one stage, GPUs, of late) remain a source of exploits; do you see a microkernel like Zircon being folded into the Android Kernel? Longer-term, will moving away from Linux (but maintaining compat via emulation, say) become a necessity to combat CSVs? I'm not entirely sure if this is possible, to be honest. Drivers on Android have been a pain point for a while. Google has much more control over their own hardware, of course, but for random other OEMs what typically happens is their drivers are binary blobs that rarely get updated. Making improvements in this area is a major effort. I think, in the long term, that you can't just go "microkernel" to the problem of drivers, because some hardware is always going to have broad access for performance reasons. You can stick an IOMMU between things but some hardware (e.g. graphics) usually bypasses that and other hardware (e.g. storage, flash ROM) can compromise the entire device if tampered with. So I expect to see greater integration in the stack to try to secure these. Some of this may involve userspace drivers, but some might be more specialized to protect against more specific attacks. > I see a bunch of eBPF use since Android 12+. Do you see Google actively work to provide more APIs for forensics / monitoring (like Knox/EMM) without needing root (or abusing Accessibility/VPN/DeviceAdmin/ADB Shell/etc). So I don't think Google will give you arbitrary eBPF just because eBPF gets exploited a lot, so letting apps upload arbitrary programs is probably too spooky for them. More generally though they are interested in this space but it's very difficult to provide good APIs, because a lot of the people in this space are selling borderline-scam EDR, and providing the things they want just lets people make spyware easier. I have no idea what is next but I can say that when I was there the things I was creating signals that we felt were very costly to bypass. Unfortunately this is very, very difficult, and the difficulty only goes up as you attribute more capabilities to an attacker.
• faramarz 2y ago
  That’s an interesting comment. I have a sidebar question for you: what phone do you use if you are comfortable sharing. I’m wondering if you are bias towards the walled garden of apple with its perceived security or android or some other.
  • jimmySixDOF 2y ago
    the suggestion is whatever you do use it should involve a presumption of compromise as the default posture
    • saagarjha 2y ago
      I don't think this is a useful model to have, because it's too simple and not actionable. Who is compromising you? What is their cost to doing so? What level of compromise can they achieve? If you just go "you are always hacked" what is your suggestion? That I never touch a computer ever again?
      • dmbche 2y ago
        That you treat the computer as compromised. You need to calculate something? Great, do that. You need to encrypt files, and keep them on your device which is connected to the internet, and want to trust that you are the only person that can access them? Think twice. Can be considered trivial for many attackers to have full access to your device, and assume ring 0 access. They could realistically record all keypresses and your screen, no need to decrypt anything. Need to hide things from state actors? Never touch a computer again and go live in a cave somewhere until they find you.
        • SirHumphrey 2y ago
          > Need to hide things from state actors? Never touch a computer again and go live in a cave somewhere until they find you. I always found this kind of thinking to be a bit unhelpful. Because what is an alternative? Paper? Hope you don't live in jurisdiction of the country because search warrant is not a difficult thing to get and even an illegal search is not that hard (even outside of the country). As with everything - people in IT and IT security vastly underestimate the security of IT infrastructure while overestimating the security of non-IT infrastructure. IMO the use of computers makes you much more vulnerable to broad "we monitor the members public for signs of terrorism" kind of spying, rather than specific targeted state actor attacks - as was shown recently with the whole pager fiasco - there are many others non IT vulnerabilities around.
• cookiengineer 2y ago
  I am currently trying to combine my EDR agent that I wrote over the last 2 years for POSIX systems in Go + eBPF and the Hypathia project [1] which actually was very promising but is now inactive because the author gave up. So far the approach still seems promising, but I would need more devs to help me as I'm contributing in my free time and I won't accept funding for my cyber security related projects, ever. Would be nice if some other folks feel the same way as you and we can revive the Hypathia project to be better in the sense of eBPF process analysis, in-memory modification detection, and network analysis via XDP. [1] https://github.com/Divested-Mobile/Hypatia https://github.com/Divested-Mobile/Hypatia
  • saagarjha 2y ago
    I don't have the time, sorry. Too much on my plate! But I (and I apologize in advance for this) can tell you that one of the reasons why I would not have that much time for this is that I don't think it is fundamentally interesting in the face of a sophisticated adversary. Scanning files and memory or whatever is largely irrelevant in the age of exploits that completely compromise the device, all the way to a privilege level higher than where the actual scanner operates. Signatures fall apart if it is very cheap to evade them (and it is, with trivial modifications to payloads). Typical approaches to catching malware do not apply to zero-day attacks. They may sometimes work but my point in the comment above was to point out that this is just luck rather than a sustainable practice. Someone who knows you are looking for them can hide and lie far harder than you can possibly imagine. And if they've broken the system, they can use those very protections that were supposed to keep them out to prevent you from going after them. Kind of like how a castle is designed to prevent people from storming it, up until they actually sneak in and all those defensive measures stop you from retaking it ;)
    • cookiengineer 2y ago
      But the issues you're describing are literally where the eBPF kernel module chimes in and what the process analysis is about, no? You can detect a lot of malicious behaviour this way, where programs and processes deviate from their usual behaviour; e.g. trying to access files they're not supposed to.
• momento 2y ago
  The "meme" you refer to is simply survivorship bias: https://en.wikipedia.org/wiki/Survivorship_bias https://en.wikipedia.org/wiki/Survivorship_bias
  • saagarjha 2y ago
    Yep. The plane image itself (in the article) is a common meme though
• sylware 2y ago
  I can see kiddies in my logs, but the real ones, they are already here and watching. Nowadays, presuming anything else is unreasonable, unless you want to scam somebody into buying a 'security product'.
  • saagarjha 2y ago
    I don't actually think this is true; I just think that waiting for nation-states to show up in your logs is the wrong way to go about it.
    • sylware 2y ago
      There is no 'security product': you must engage in the permanent tracking of security flaw and intrusion: do heavily trap your kernel/applications, do man-in-the-middle traffic analysis between known traffic and unknown traffic, do not trust off-the-self crypto, etc. But the basics are not even here: you should not use any compiler, all critical pieces of software should be assembly written with very lean SDK (aka extremely stable machine code), namely without the abuse of macro-preprocessor. Everything else is just posture.
      • saagarjha 2y ago
        I strongly disagree with this assessment
        • sylware 2y ago
          Well, this is for the classic ASIC CPU world. But really critical stuff should go as deep as custom ASIC and/or FPGA. (A decade ago, I don't recall exactly, but those "security guys" did not even try with classic CPU ASICs, they were going custom _simple_ design on FGPA). That was a decade ago... nowadays...
• Hilift 2y ago
  What you describe is the artifact of an ecosystem where the consumer is a second class citizen. These exploits don't work on a desktop or notebook precisely due to that ecosystem is obtuse and pretty much the opposite of an extensible platform.
  • saagarjha 2y ago
    These exploits work perfectly well on those platforms. The reason you hear about people targeting them less is that they are easier to target with less sophisticated attacks and also not as valuable to attackers. In the cases they are your Android "root" exploit becomes a Linux LPE super fast.
    • jacooper 2y ago
      I think the difference is desktop systems are way more transparent about what's going on in the OS compared mobile OS's which behave closer to a blackbox.
      • saagarjha 2y ago
        Sure, but my point above is that even with more transparency you won't catch people who are good at hiding.
  • dagmx 2y ago
    Are you seriously saying there aren’t exploits on non mobile platforms? The platforms that have famously had many significant exploits over the years, and are the cause of many major data exfiltration operations? Are you pretending that viruses and worms don’t exist? Why does forwarding through we have things like windows defender or anti viruses then?
• meisel 2y ago
  Do you expect that Apple’s bigger security initiatives, like pointer authentication and writing the OS in a memory safe language, will improve the situation?
  • tptacek 2y ago
    All these things increase attacker costs. In the current landscape, increasing attacker costs has the effect of shaking out some of the lower-rent players in the market, which may put some targets out of reach of lower-caliber threat actors. The problem you have over the medium term is that CNE is incredibly cost-effective, so much so that you need something like multiple-order-of-magnitude cost increases to materially change how often it's applied. The alternative to CNE is human intelligence; it competes with literal truck rolls. You can make exploits cost 10x as much and you're not even scraping the costs just in employee benefits for an alternate intelligence program. What that means is, unless you can foreclose on exploitation altogether, it's unlikely that you're going to disrupt the CNE supply chain for high-caliber state-level threat actors. Today, SOTA CNE stacks are probably available to the top IC/security agencies† of all of the top 100 GNP countries. It probably makes sense to think about countermeasures in terms of changing that to, like, the top 75 or 50 or something. I think we tend to overestimate how expensive it is for adversarial vendors to keep up with countermeasures. It's difficult at first, but everything is difficult at first; I vividly remember 20-30 extraordinarily smart people struggling back in 1995 to get a proof-of-concept x86 stack overflow working, and when I first saw a sneak preview of ROP exploitation I didn't really even believe it was plausible. As a general rule of thumb I think that by the time you've heard about an exploitation technique, it's broadly integrated into the toolchains of most CNE vendors. Further, remember that the exploit development techniques and people you've heard about are just the tip of the iceberg; you're mostly just hearing about work done by people who speak fluent English. † Reminder that customers for CNE vendors usually include many different agencies, invoiced separately, in the same governments.
    • Jesus_piece 2y ago
      Reminds me of the book “this is how they tell me the world ends” - a history on cyber weapons. It’s written from the perspective of a journalist without a comp sci background but delves deeply into the topic of how cyber weapons are procured, priced, and sold to multiple agencies in the same government. It’s unfortunate these are used for exploits and not for reporting bugs or vulnerabilities. Stockpiling exploits only makes everyone less safe