Almost all traditional antivirus products want to deeply integrate with the system and affect the performance a lot. Also some of these companies are know to make questionable decisions like trying to intercept HTTPS communication, etc.
https://objective-see.com/products/blockblock.html
It picks up background daemon tasks that suddenly are created and allows you to block them immediately. That's certainly one major way to pick up and block hidden malware on your computer.
All of the tools by this guy are incredible, they are also recommended, e.g. tools to pick up and allow you to block access to microphone or camera.
(Intereseting fact: A lot of malware quits immediately if Little Snitch is installed. So running Little Snitch alone prevents some malware from infecting your system)
KRD is just a live Linux distro with Kaspersky's tools on it.
I make no representations as to whether or not rkhunter actually does anything of benefit.
The only two I know of is Malwarebytes and Kaspersky.
The former installs with root privileges, runs on boot and cannot be ever closed, despite the fact that it is only an on-demand scanner. I've written to them to request an explanation, and did not get any response.
Kaspersky has had a fair share of rumors against it, and I am not in a position to evaluate if they are trustworthy.
Closed source, no references, and free (so how do they support themselves?)
Very nice, but why would I trust it?
Used to use them years back, before I jumped off MacOS. Past few years they went a subscription model for sustainability. Based on ClamAV.
Because they try to up-sell you their paid option, which scans automatically for you, with a 30-day trial.
This virus infected Delphi installations, injecting its code and compiling it into a system library. All programs using the infected library contained the virus, including some popular ones.
Because they came straight from the developer, and the virus didn't do anything unless you had Delphi installed they were often considered false positive when they weren't. Originally, it had no malicious payload beside its replication mechanism.
To understand why this happens, it's important to know how massive a typical .pbxproj file looks:
https://opensource.apple.com/source/CommonCrypto/CommonCrypt...
Ostensibly it's human-readable, but because it's generated by Xcode and filled with inscrutable UUIDs, people treat it like a binary file, and they're trained to do so:
https://stackoverflow.com/questions/2004135/how-to-merge-con...
Even the React Native team apparently allowed the file to be treated as non-diffable for some time: https://github.com/facebook/react-native/pull/11047
And note the large number of commits on all types of projects that essentially say "whoops forgot to update pbxproj" - there are likely far more. https://github.com/search?q=update+pbxproj&type=Commits
So why does this matter? Because the brilliance of this attack is how it "jumps the blood-brain barrier" between a developer's machine and their canonical codebase. Usually, code review and auditing of what goes into a commit prevents this kind of attack from leaping to VCS. But Apple makes the pbxproj so inscrutable, and does such a good job at hiding all its complexity behind (usually well-designed) wizards and dropdown menus, that people take it for granted. If code shows up there, people believe Apple intended that to be the case even if, say, your last commit was a small change in Interface Builder (or whatever they call it nowadays). Your code reviewer might just skip the file entirely, because they've been trained to expect the same.
And that's scary.
At the end of the day, this is just another way of exploiting the lack of a mature and centralized CI ecosystem in the modern package distribution world. There's no organization running a security-minded linter on pbxproj files as a general rule. But, then again, there doesn't need to be a linter on package.json or project.clj or Makefiles because there was never a history of hiding complexity - if that file changes, you'd better darn well know what you're doing. What we have here is a perfect storm of move-fast-break-things package management, a file designed to slip through code reviews, and a pretty creatively designed malware payload.
EDIT: Perhaps another way to look at it is that having one file responsible for both compilation logic and non-compilation-related IDE-specific file status can be problematic. It's like your Makefile also needs to be your .gitignore-but-only-top-level-is-allowed-and-all-files-need-to-be-whitelisted. Of course, this is very much an Apple thing to do.
+1 to Bazel - though it’s best suited for monorepos where you are building completely from source.
Inscrutable? It seems like a textual dump of in-memory project structure using UUIDs to represent pointers and links (graph). Yeah, it's a chore to follow manually, but even to me, who has seen this format for the first time ever, it looks rather straightforward. Hasn't anyone written a utility "explorer" of these files?
I'm a bit confused about
>two zero-day exploits: one is used to steal cookies via a flaw in the behavior of Data Vaults, another is used to abuse the development version of Safari.
Malware on the local machine can steal data from Safari on the local machine. Is that a surprise? Does Safari have a threat model that it intends to protect against locally running malware?
Eg, if there is a file/directory that only safari is meant to have access to, no other app should be able to read it, without at least bringing up one of the annoying “allow X to access your Y”. For example, the first time you, say, feel your home directory you’ll get a bunch of TCC requests asking if the host app (Terminal.app say) should be allowed to access those files.
Anything not on those locations is not protected, so there's no Data Vault for Chrome's cookie file, for example.
Interestingly it's happened to Xcode before, and an impressive number of bad apps made it to the App Store as a result. See https://en.wikipedia.org/wiki/XcodeGhost.
ragulSimpragma/twitterTask
yimao009/MVC-MVP-MVVM
I suspect that attacker thought that Xcode project contains some binary/text blobs so hard to notice it.
Stupid question. Was it bad that I clicked on the github.com links? This is not something spread just with viewing the links, right?