Hacker News new | past | comments | ask | show | jobs | submit login

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?

Tripwire is a linux util for doing just that. However you need some read-only media to store the hashes and I think rootkits can still just intercept the read calls.


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 changes (as they all were) from any potential illegitimate changes.

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.

On debian you can also use debsums which has the advantage that the checksums come from the distribution directly.

iowatch is a nice simple alternative.

I'm on mobile so links are annoying to get, but Apple has a great PDF on iOS security in general, which includes details on their protections against kernel patching. Windows has KPP, and Mac OS has SIP. Not familiar with anything for Linix but I'd be shocked if there weren't multiple incompatible implementations of similar features.

Realistically, this is also something virtualization can help guard against. If your OS is initialized from a known good version external to the VM, every time the VM starts, you greatly increase the difficulty for an attacker to get persistant root.

KPP: https://en.m.wikipedia.org/wiki/Kernel_Patch_Protection

SIP: https://en.m.wikipedia.org/wiki/System_Integrity_Protection

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.

Too bad that has it's own issues. Android/Google definitely has the clout to be able to call the shots (ie force the processor manufacturer to issue them a CA cert for their own use), but what would happen if ARM then became a dominant server arch?

Also, putting code signing in the processor wouldn't fix the problem: code signing already happens in higher levels (ie higher than userland), so moving the verification a level up would likely take the exploitable bugs with it. The problem remains.

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.

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

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact