There are always a lot of myths floating about … about Macs and about malware. There always seem to be two camps with diametrically opposed positions. Some hold on to the rather antiquated “Macs can’t/don’t get viruses” which is inaccurate, and in fact never was accurate at any point in time. The other camp is claiming with each new news story that it’s the thin end of the wedge and soon OSX will be as much of a helpless victim as Windows always has. This is also incorrect, and probably not true of Windows any longer either.
While it is true that OSX is not without its occasional security holes, its very architecture is secure – in the way that Linux is secure, provided they are properly configured and managed. The biggest, most blatant, gaping security hole in any operating system is …. the user. That means you.
Those of us who work as techies have an acronym for just this sort of problem – PEBKAC or “Problem Exists Between Keyboard and Chair”. It’s kind of an inside joke that a machine’s worst enemy is the user that uses it. This is far from arrogant, and true even in cases of the most experienced power-users. We all have our derp moments.
Our best line of defence is to adopt good practices in using our machines to prevent such an occurrence happening. To understand both the nature of possible threats and their delivery systems and how they might be disabled and removed. To make all of this second nature so we do all that we love and need to do with our machines every moment of every day.
A digression into Users, Groups, Permissions and Root
OSX has a rather robust, unix-style user and permissions system. This is designed to separate not only what each user owns and what each user does from one another, but to keep what they do and make from affecting the overall operating system from doing its job.
Each user has an account, which is registered under their short user name and given an ID number. They are also given a directory under /Users where all the stuff they do and make will happen. For example, if your name is john, your home directory will be /Users/john/. Anything south of that, such as /Users/john/Documents/ is your space you can do anything you want with. It’s where all your documents, pictures, settings, music, cache files everything goes. Going back up the tree to /Users or / or down any other branch of the tree you will notice you can’t write or even can’t see the contents of those directories. This is intentional. It is outside your user space.
This is designed to protect the system from modifications by any one user, or to any user by any other user. Keeping everything nice and compartmentalized. Your data, settings and everything are also kept safe, by virtue of your user password which you use to log into your account. No one else at the user level can access your files without this password and it can only be overridden by a higher level account, such as Administrator or root.
Some users are designated as Administrators. The first account created with a fresh install of OSX is an Administrator account. An Administrator can make any other account Administrators also. This does not make the user god, nor does it give them too little protection from accidentally breaking the operating system, but it does give them the ability to temporarily execute commands as root.
Root is the highest level of access an OSX, unix or Linux machine can have. It basically allows someone to do absolutely anything with the machine, including break it. This is never (and should never) be used as a user account. One doesn’t log into it and use it to check their email. An administrator user account can request permission of root to view or edit a file owned by root, or to execute a command as root. This is called “sudo” or “super-user do”. Instead of saying “rename this file”, it’s “you have the permission of root to rename this file owned by root”.
Confused yet? Here’s the application. If you look above your home directory, up the tree, from /Users to / (the top level of your hard drive), you will recall above that your user account cannot modify anything up there or in some cases, can’t even see what’s up there. Your user account password only entitles you to use what’s at /Users/john/ and below. However, if your user is an administrator account, trying to do something up there will cause it to ask permission of the user that owns it – root. You will then have a dialog pop up that will say you have to enter your password to make changes. By entering your administrator password, it will then temporarily give you permission to do what you are trying to do. If your user account is not administrator, it will tell you you do not have permission to make such a change, and to please enter an administrator account and password to make such a change. If you don’t have an admin username and password to provide &ndash you can’t do it.
Everything north of your User account is all the critical stuff. Your operating system, your Applications, your device settings, things that are designed to be accessible to all users of the machine. By being disallowed by default, and requiring at least the sanity check of requiring an admin password, unauthorized changes to these critical files belonging to the operating system is prevented outright, and any accidental changes you may not have intended are prevented also by calling it to your attention.
You have probably done this many times already without even thinking about it. The most common being installing an Application. Since /Applications lives higher up the tree than /Users/john/, in order to install an application (i.e. copy the program to that directory, which is owned by the system), you will need to enter your (administrator) password.
The same goes for all other directories up there, including the system. Anything that wants to run at higher than the user level has to be put up there with the administrator’s expressed permission. Do you see what I’m getting at?
Permission to Run!
With everything so nicely compartmentalized, it is virtually impossible to mess up your system or any other user account on that computer – unless you explicitly enter your administrator password when the system pops up a dialog saying “hey! are you sure you want to do this? let’s see some ID”. One of the most important – and obvious conclusions is to never enter your administrator password unless you are absolutely sure.
Just as files need permission of the owner (be it root or your user) to be changed, moved, modified or deleted, programs also need permission to be able to run. Enter Gatekeeper. In addition to the traditional unix-style permissions noted above, Gatekeeper does what it says on the tin and provides the last line of defence when you run an Application. After all, you could do a google search, find a program you think fits your needs, download it, put in your password to install it into /Applications and then discover it actually has malicious intent – often too late. What Gatekeeper does when you first run a program, is check it against a list of verified developers. Depending on Gatekeeper’s settings (found in System Preferences -> Security & Privacy -> Allow apps downloaded from:), it will run the program if the identity is confirmed, or throw an error saying it is from an unidentified developer if it isn’t and refuse to run the program.
Gatekeeper has three settings: “Mac App Store”, “Mac App Store and identified developers”, and “Anywhere”. The default is (I think) the second one and should never, ever be changed. Any program that comes with instructions to circumvent this (change the setting to “Anywhere” for example, or click “Run anyway”) should be highly suspect and never used. Your best bet is to find a piece of software that does the same thing yet can be download/purchased from the App store or is from a recognized, legitimate developer such as Adobe, Microsoft etc. and passes Gatekeeper on its own. Many, many developers have gone through the process of getting verified by Apple and in 99.9% of cases you should never have to approve an app manually. It’s an invitation for trouble.
If you tried a program and it said it can’t run because it is from an unidentified developer, do not worry. Nothing bad happened, because Gatekeeper didn’t allow it to run. Just throw it out and find a valid substitute for what you are trying to do.
Daemons under the hood
Apart from applications you know to interact with, .app apps that you double click to run or run from the launchpad, there are small programs that run under the hood called agents and daemons. These are little things that provide services even when their associated apps aren’t running explicitly, or give extra functionality when they do. These can include things that are meant to run periodically to check on things or perform repetitive tasks or watch for conditions to react to. They are immensely useful and free the user from doing a lot of tedious things that we’d forget to do manually or just find more convenient if it just runs on its own.
They also often run invisibly, and there’s not much of any outward sign that they may be there or be doing anything at all from a casual glance. After all, you don’t want to be pestered if a program is just checking if there is an update, do you? This does present a problem however if someone accidentally installs a malicious daemon, as what its doing after that, you won’t be able to see unless you look in the console.
It is important to distinguish agents from daemons. If you recall from above, there is a big difference between what a user can do, and root can do. Users cannot modify the system, install software, or change anything outside their user directory. Root on the other hand can do anything. Following this system Agents are user processes, they can only do what you could do manually without entering an administrator password. Daemons are higher level, and run as root and thus have system level permissions to do things we can’t do without entering in an administrator password.
The file structure follows this accordingly. There are three directories where these live:
- /Users/john/Library/LaunchAgents – user processes, Agents that run as the user, in this case john
- /Library/LaunchAgents – user processes, Agents that run as whatever user is currently logged in, and are available to all users of the machine
- /Libray/LaunchDaemons – root processes, Daemons running as root and have root permission to do pretty much anything
You can have a look for yourself and see what’s in there. If the developers of installed programs did things properly, they should be named in reverse domain order according to who made them and what they are for. For example those starting in “com.apple” are made by Apple for Apple programs and OSX itself. “com.google” for Google apps etc. The second part tells you what program they are associated with. A common one people would have is com.microsoft.office.licencing.helper.plist. Let’s just dissect that name and you’ll see it’s easy to understand: com.microsoft – it’s from Microsoft and their web address is microsoft.com, com.microsoft.office – it’s for Microsoft Office. The latter parts licencing.helper tells you what this does – it checks to validate your MS Office license. The last bit .plist is the file format, in this case “property list”. All agents and daemons are are files that simply say “run this every so often or under this condition” and point to the actual file to run. Then an OSX program that runs all the time, called launchd performs the task.
These are human readable files, and even though they may look complex at first, they are actually very simple and a cursory look into them can tell you exactly what they do. Here’s a quick example to show you what I mean:
Let’s take a common one: com.google.keystone.agent.plist. It is found in /Library/LaunchAgents.
So we can tell right away this file is an agent from where it lives, that it belongs to google, but what is keystone? I don’t know either. Let’s find out. Here’s the entire contents of that file:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.google.keystone.system.agent</string> <key>LimitLoadToSessionType</key> <string>Aqua</string> <key>ProgramArguments</key> <array> <string>/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/MacOS/GoogleSoftwareUpdateAgent</string> <string>-runMode</string> <string>ifneeded</string> </array> <key>RunAtLoad</key> <true/> <key>StartInterval</key> <integer>3600</integer> <key>StandardErrorPath</key> <string>/dev/null</string> <key>StandardOutPath</key> <string>/dev/null</string> </dict> </plist>
Looks like some strange ancient dialect? Don’t worry, this really is very easy. This is what’s called an XML file, so without going into an explanation on that I’ll just tell you that it’s simply a way to organize commands so they can be read. They are always in pairs, there’s a
This just tells you the name of the agent, or its “label”
This just tells it to only run if a user is logged in normally, using the graphical interface. Not using SSH or any other method.
<key>ProgramArguments</key> <array> <string>/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/MacOS/GoogleSoftwareUpdateAgent</string> <string>-runMode</string> <string>ifneeded</string> </array>
This next bit, ProgramArguments, tells us what it is going to run when called upon, this is the important bit. In this case, it is pointing to a program called GoogleSoftwareUpdate.bundle, and the rest are “arguments” telling it how to be run, in this case “ifneeded”.
This tells it to run at load, in this case since it is an Agent, it will run when the user logs in.
This tells it how often to run, in seconds. In this case five minutes.
So what can we conclude? Through just a quick look we can see that this Agent belongs to Google, it will run a program called GoogleSoftwareUpdate when the user logs in, and every five minutes after at.
Little Hack – I actually found it annoying that google has to check for updates every five minutes. You can’t see it going on, but it still is something extra running more frequently than it needs to. I changed the value under StartInterval to 604800 so it checks once a week instead of every five minutes! Of course, to change this file, I had to enter my administrator password.
So really it’s not hard at all to understand! With a cursory glance we can see what all the agents and daemons are doing, and that they belong to legitimate programs and are doing legitimate things. That being said, it is my personal belief that many programs install agents and daemons when they don’t need to. I mean, how arrogant are they to think we need to check for a program update continuously even if the program isn’t running? I digress.
So now we’ve identified agents and daemons, what they are and how they work. This is important to our original topic because one of the few ways a malicious program can insinuate itself and run invisibly on your machine, and be persistent across reboots, is installing a daemon to keep calling it.
Agents and Daemons to be installed in /Library/LaunchAgents and /Library/LaunchDaemons can only be installed with an administrator password. When you first install and run an app, it may ask you to make changes and ask for an admin password, and this is usually what it’s doing. A program can install an agent into /Users/john/Library/LaunchAgents/ without a password however, but these ones will only run for that user, and cannot do anything that would involve an admin password.
We’ve covered cases above that assume you can see the files in a normal finder window without problem. So you could catch an unknown agent living in the LaunchAgents folder… but what if it was there and you couldn’t see it? Every operating system has “hidden files” that are invisible to the user by default. This is normal, and really you don’t want to look at them all the time. Without going into to much detail, file names starting with a period “.” are invisible. So mydocument.txt is visible, .mydocument.txt isn’t. Often a cheap trick those who write things they don’t wish the user to see will simply make the file invisible by putting a dot at the beginning of the filename.
You can always see invisible files if you open the Terminal, use cd to get to any directory, and type the command “ls -lah” to give you a file listing including invisibles.
Putting it all together with a real world example
So we’ve covered users, admins and root. We’ve covered agents and daemons. We’ve touched on hidden files. Lets take a look at a real-world example of how this works. Recently, a piece of malware has been detected called FruitFly. It targeted mainly biomedical research facilities and did silly things like take screenshots and upload them to the attackers servers, ostensibly for industrial espionage or … something.
Without getting into excruciating detail as to how it worked, we can identify it, catch it, and delete it safely knowing only the information I’ve given in this article. Have a look at malwarebytes blog post on the subject with the code:
Without repeating the article linked above, you can see the malicious program is made of two pieces: a program that runs called .client, and an Agent called com.client.client.plist.
Using what we have learned above, let’s dissect this threat:
- The file lives in ~/Library/LaunchAgents so it is a user agent without admin or root privileges, and would run only for this user account
- The agent name is pretty generic, com.client? there’s nothing at client.com, it’s most certainly not a reputable software manufacturer. The name is so generic as to hopefully be ignored by a casual glance but sticks out for being so
- Looking inside the file, we see that KeepAlive is TRUE, meaning the program will continuously run and relaunch if shut down
- The label is as pointless as the file name
- The ProgramArguments definitely calls that invisible .client file, which is the actual executable that takes screenshots and uploads them
- RunAtLoad is also true, so it will start running when the user logs in
So that’s all fine and nice. We’ve determined that this is obviously bogus and not something we want running on our machine! But how .. HOW do we battle this scourge? this veritable immortal dragon of malware?
I’m not kidding. Just throw out com.client.client.plist and log out, and log back in. Gone. It is killed, it cannot run. For extra good measure, delete the executable itself by typing the following into the terminal “rm ~/.client” and hitting return. Done. Since it was just a user agent, you don’t even need to reboot, just log out and log back in to clear the process if it was running. Or you can reboot, either will work.
This is example is most interesting. Though I have made a lot of emphasis above on being very careful when you enter your admin password, you note with this example that at no time did you have to do that, and the malware itself did not require admin privileges to run. Yet, it was perfectly capable of taking screenshots and uploading them to some crazy server. That doesn’t require admin privileges at all. Though the operating system and any other users on this computer are totally safe, within the confines of this user it was compromised.
It could have been made more powerful, it could have been made into a daemon and thus have even deeper access as to what it could do across all users of the machine… at the risk of asking for the user to input an admin password once to install it.
This article was intended to give you an idea of how OSX works, and how malware tries to trick you and how it can run inside your operating system without you knowing it, and really how in most cases it’s trivial to remove. OSX has some very robust security features but they all depend on you, the user. Nothing can actually run on your computer without you giving it expressed permission. It is you that double clicks the app, has the power to bypass Gatekeeper, or enter your admin password. It is important to be very careful to recognize when that program you downloaded is not to be trusted.
General Useful Hints
- Whenever your computer asks for your admin password, look at the dialog, it will tell you who is asking and usually for what purpose. If you don’t agree, then it’s perfectly fine to say no
- Do not trust any app that gives you instructions on how to bypass Gatekeeper, it is there for a reason. In the very rare case a legitimate developer is not verified by Apple, verify them
- Apps that promise wild things like speeding up your computer or cleaning it out or venturing into the fantastical are always lying, and are out to get your credit card number to unlock dubious functionalities. Examples would be MacKeeper, MacDefender, MacReviver. OSX takes pretty good care of itself and I will be posting another article on how you can maintain it yourself
- Take the time to look for independent reviews and verify the legitimacy of programs and services you install before you install them
- Check periodically, if you have installed things you probably shouldn’t have, the LaunchAgents and LaunchDaemons directories to ensure nothing is in there that shouldn’t be
- Do not open random email attachments. Seriously we’ve been saying this since the 90s
- Do not believe any website or program that tells you you are infected with malware or viruses unless that program is reputable anti-malware software from a recognized developer such as sophos, avira, malwarebytes etc.
- Do believe your browser when it tells you that the website you are visiting might possibly contain malicious code
- Take the time to read all dialogs your OS and programs pop up and do not get click happy and dismiss them without reading. Often, they contain important information and you may not actually want to click OK!
- Do look for the lock icon next to the URL in your browser when visiting sites, this confirms that the site you’re asking for is the one you are getting
- Do make strong passwords. Many malicious programs (and malicious people) will happily try all the easy passwords, if yours is one of them, you are helpless. Remember a computer program can try thousands of passwords in a blink of an eye. Don’t be the low hanging fruit that gets eaten
- Do make your passwords different from one another. Otherwise if one password is compromised, they all are.
- Do not be afraid to google things you do not understand
- If anything promises you free movies, free music, free books – it’s a scam. Yes it is. Don’t do it.
- If something wants to install a browser extension, don’t do it. That is a common ploy that involves very little user interaction. Unless you want a specific plugin that is legit, don’t click OK
- If you note your home page suddenly changes to something strange that looks like google but isn’t, that’s a common sign you have an annoying piece of adware
- Restrict your kids to non-administrator accounts and do not give them the admin password. You may think your 8 year old is computer smart but he really isn’t and while he’s finding “free games” he’s installing a crapton of malware along with it. Trust me, I’ve cleaned enough family machines.
- Install an adblock extension like AdBlock or AdBlockPlus. Most malware is delivered by people clicking malicious advertisements and best if they are just filtered out anyway. For those that argue that a website makes money on it’s advertising, well that’s true but only if people click the adverts. If you don’t click adverts, you don’t need ads
- Knowledge is power. Learn about your operating system, learn about the programs you run, learn how your computer and the internet works. Anyone can with a bit of reading and exploration. The more you learn, the better you know, and the safer you are