|Home » Learning Curve
Mac Malware Mania
Chicken Little works for AV. You're the only problem. Fix the problem.
PRETTY INFINITE, CA (Rixstep) — Sulfur's burning in your nostrils. The heavens grow darker. Far off you hear a voice you think might be Chicken Little.
'It's really trivial to infect a Mac these days', Chicken Little tells you. Scary! 'The only difference is that for historic reasons, there's so much more malware on Windows. That may not always be the case.'
OK, thanks, CL. Cos there sure is a lot of malware on Windows! Millions of strains. But there's a reason for that, right? Bill Joy understood why, and Bill Joy should know. He's one of the fathers of BSD Unix, which is one of the forefathers of Apple's OS. Bill simply can't understand how Microsoft could (in good conscience) put a standalone system on the Internet.
Not many people can either.
The cries to equip yourselves with new improved antivirus suites are going to grow louder. Much of the passive personal computing world has migrated to thumb scrolling and tap-tap. The AV cottage industry, born out of the endemic depravity of Microsoft products, is going to hurt more and more. Let them hurt. Not your problem.
'Our tracking of Mac malware has seen a more than 220 percent increase so far in 2017 over 2016', CL goes on. And it's assuredly true. But the professional system programmer, as opposed to the AV marketing department, will always have a problem with such a sweeping statement.
Where's the weak link in Apple system security, pray tell? Is it in the OS kernel? Or in one of its supervisors / hypervisors / Batmanvisors? Is it in the Registry, where all sorts of nocturnal creatures can find cosy resting places? Is it in the fact that user areas are only loosely defined, and thereby only loosely protected? Is it in the fact that the system kernel can be compromised at any time, so that the vendor can only tell you after the fact that Sauron and Voldemort are already dancing rhumbas inside your process table? Is it in the fact that your system is not a true multiuser system at all, lacking in the necessary granularity in file ownership, so that only arcane mechanisms are available to allow and deny?
No. All of the above applies to Windows and Windows only. Windows: that gorgeous Belgian Blue cash cow for the antivirus industry. Without Windows, that industry would not exist. (Without Windows, the multi-billion dollar malware industry wouldn't exist either. Without Windows, the spam industry wouldn't exist either. And so on.)
Try to find yourself a decent file management tool. (Yes, with your default Finder (what a name) you might run into difficulties.) But get yourself a graphic overview of /System/Library.
Look at it. Look at /System. What do you see? You see only one item in /System, right? It's Library, right? Right. What does that tell you?
Check the ownership. It's owned by root:wheel, right? root:wheel - that's top dog on your system.
Try to figure out how many items you have (recursively) in Library. This may take some time. We've got a tool, so we can do it fast. On one of our older systems, we find over 224,000 items.
Now who owns what? Aside from less than a dozen symlinks, which are associated with installed developer tools, everything is owned by root, and aside from three additional items (which are still owned by root) all 224,000+ of them belong to user group wheel, which means they're still top dog.
What does that tell you? It should tell you that your system is locked down pretty fucking tight.
But couldn't a highly ambitious piece of megaton malware, given you're AFK for a fortnight or two, simply copy out the entire Library hive, put some nasty things in there, and then use it to replace the original Library?
Look at the permissions on Library's parent directory /System. They're at least 0755. Which is 'read/write/enter' for top dog - but no write for anyone else. So what does that mean? It means you can't change anything in there. You can't change Library... And you already know, because you checked the contents of Library (or at least we did for you) that nothing can be changed in there either.
But what about /System itself? Say you were able to dupe someone into taking a full sabbatical - could you simply replace the complete /System hive with your own nefarious version? Can you muck about in / itself?
Check the access control entries. You might have to go to the command line for this, it's unlikely (haha) your Finder has a clue what that's all about, but again we can do it for you. /System is marked as:
group everyone deny delete
And to muck with /System, you'd have to delete it and then replace it. So that doesn't work either.
Taken all together, what does that tell you? If you've been paying attention, it should tell you that your system is locked down tight. Really tight. All your most important files - Apple's system files - are located in /System/Library. Nobody can touch them. Nobody.
And now Apple have additional protection mechanisms, to protect the protectors, so it gets almost silly. Good luck in trying to get in, in other words. (And that's good for you, in case you missed the implication in there.)
There are command-line Unix binaries in several other locations, but they too are at least owned by root and have very restrictive permissions.
So this means - what? It means it's a Herculean (not to say outright impossible) task to compromise your system. So if the shadow of Mordor is approaching as Chicken Little claims, wherein is the weakness? How can the Mordor orcs get in?
The weak link is you. These supposed 'system hacks' on macOS don't attack the system per se - as is the case with Windows. They attack you. They try to fool you. Imagine you're the sole caretaker of Fort Knox (or the NY Federal Reserve, you pick it) and you have complete access to the security system - and then some huckster in a cheap polyester suit comes along and tricks you into giving away the keys. Is it the system's fault? Or is it yours?
'As is often the case with Mac malware, user assistance is required for the attack to succeed. The phony installer attempts to gain full system control by asking for your username and password to install additional codecs.'
Ah. Gee whiz. What the hack.
'This serves as a reminder to always think critically when you get a system prompt for your password.'
Yes it does serve as a reminder. Something we at this site have hammered on about for 10-15 years. There are only a handful of things that can't be done to a system once that password is given away.
(Yes there are a few things, and for them you need physical access to the computer hardware, but they're not that many. Most of the system is exposed once that password is known.)
Recent articles on the topic also highlight the illusory (some would say 'dangerous') threat of Apple's Gatekeeper. As we've pointed out for years, the code-signing - which is at the core of the Gatekeeper idea - can easily be defeated. We were able to accomplish this with great ease, and it was readily apparent, throughout our experiment, what a straightforward process it'd be to create programmatic tools that can automate this process for any binary one wants to pwn.
Protection through code-signing - with Gatekeeper - is illusory, but more: it's dangerous, in that it instills a false sense of security in the user.
'One issue is that Apple lets anyone with an email address and $99 get an Apple developer certificate, which can then be used to sign malware so that it's automatically accepted as safe by Gatekeeper.'
Apple tie your security to a remote procedure, over which neither you nor the developer have any control, at which point a member of staff over there, someone with strange pointy ears, can compromise the product, and you'll just assume all is fine, because it's signed, and Gatekeeper tells you so.
And even if there's nobody behaving badly at Apple, that fly-by-night hacker with the $99 cert will be.
Gatekeeper's bad. Baaad.
So what do you do? Or do you accept the warnings of Chicken Little, the new poster-chick for the AV industry?
Go back to the first point. And don't give your password (passphrase) to anyone. Or anything. Or any piece of software. No exceptions.
Oh sure, there will be exceptions. But if you make that rule stick in your mind, you might just might think twice before giving it away. (This might be easier for girls to grasp than guys. Whatever.)
Yes, there will be occasions when you have to use (give away) that password. But make sure you really understand why you do it. You don't give your password away just because someone asks for it. You have to know who's asking for the password, know why they want it, and know you can trust them.
Giving away a password to an app you downloaded from a funky location on the net, just to install a few codecs, doesn't cut it.
No, XProtect isn't much protection. But do you seriously think Apple will leave you (and their own engineers, remember) in the lurch? Apple have at times made mistakes, such as running all iPhone apps as root back when Gruber was telling everyone that there had to be a good reason. (Hahaha. There wasn't of course.) Only for Apple to swiftly cease and desist with the next update. (Proving the tenet correct, and Gruber wrong, same old same old.) But those errors are rare today. The system itself is nigh-on bulletproof, and the above sightseeing tour through the file system should prove it.
Is there anything else you can do to make sure you don't find yourself drinking a nasty wizard potion in a short time? Other than guarding your password the way Guinevere saved herself for Arthur?
Yes. Keep your system tidy. Remember the words of Paul McCartney.
He likes to keep his fire engine clean
It's a clean machine
So do it. Don't keep stuff around that you don't use. Not that it's going to activate like a zombie and attack you in the dead of night, but because you want to keep things tidy - you want to know what you have and where you have it, so that if something should suddenly turn up that shouldn't be there, it'll stick out. It's easy to trick a disorderly user.
Try to find places to put things. This from our utility Lightman.
What does that tell you? Here's a clue: the Lightman output is from a programmatic call. That means that the data retrieved is resident in the system.
The two arrays above are for ordinary applications and for 'admin' applications (utilities). All those paths are automatically checked by the system (the 'launch services') when you invoke an application call.
Your applications can be anywhere, in any of those locations. (And it's good with freedom.)
No, some of those paths may not be accessible (or even exist) on your system. Don't worry: your OS will figure that out all by its lonesome. The important thing here is to understand that you don't need to put everything you acquire in /Applications - and probably shouldn't, either.
Look at that /System hive again. That's locked down tight. Shouldn't all of Apple's system software be located there? A lot of it already is - at, amongst other places:
/Applications is itself protected with an access control entry today, but still and all, ten years ago, 'MOAB' made a mess of it, showing how incorrect permissions could compromise an entire system. And then there was the incessant nagging about 'fixing file permissions'...
None of which would happen if you used your own path for your own software. Yes, it's listed above, but here it is again.
/* * */
No, those directories don't exist on a pristine system, but yes, you can actually create them yourself, and yes, your macOS will automatically look for them when you want to run an application whose exact location isn't known.
And if you stick to your own corner of the file system, a lot fewer bad things can happen in /Applications. Think about it.
And remember: if you're on Windows, no power in Gondor can save you. We had good friends and neighbours at the US naval base in Souda, Crete. They were top dogs there. They had a nice place on a slope a bit downhill from our own. They had a gate and a driveway, almost like Beverly Hills (or at least Bel-Air). They had a groundskeeper who liked to keep his goat tethered to a tree nearby when he was there to work (which was way too often). They had lots of spacious rooms on multiple levels. But off to the right, just inside their main entrance, was a 'workroom'. It had a long bench against the outer wall, two chairs pulled up to it, and computer monitors, computer keyboards, and computer mice at the two seats along with big ugly desktop tower computers. That workroom was never used on Saturdays (Σάββατα). No, Saturday was the day their Windows computers had to do the 'deep scan'. Looking for malware of course. All day long. The husband's computer activity was only the ordinary navy honcho stuff like reading and writing email mostly. The wife probably visited Facebook a few times during the week, that was it. Mostly they took care of accommodations and personnel records, nothing real 'NOFORN'. But they ran Windows. So there was no play allowed at the weekends - antivirus all day on Saturdays, without exception.
You're not running Windows. Be glad for that.