why malware loves auto login (and why you shouldn’t)

Whenever I talk to people about the dangers of having their mac set to login automatically without requiring a password, I’m often waved away as an old worryguts. “I’m the only user on my mac”, they say, and “My mac is unlikely to get stolen”.

These optimistic dismissals may turn out to be true or false, but aren’t really relevant to the main security issue. Auto login presents a threat to anyone connecting to the internet.

To see why this is so, let’s look at how auto login works. First of all, the user enables auto login through System Preferences’ ‘Users & Groups’ pane. Open the pane and click on the Login Options item at the bottom of the sidebar (see the screenshot above). Choose a user from the ‘Automatic login:’ pop-up menu. You’ll need to provide the account password.

Where it gets interesting is what macOS does next with that information. You might perhaps think it secures that information safely in your Keychain, but that wouldn’t work at all. Your Keychain needs a user password to unlock it, so auto login can hardly unlock your Keychain to get the stored password out. No, it needs to be stored somewhere else that can be accessed when the computer starts up.

That place is in the hidden folder /etc/, and specifically in a file called kcpassword. This is outside of any user’s Home directory, so the system doesn’t need a user password to access it.

However, if you try to open that file to read it yourself (we’ll do this shortly, hold on), you’ll find you can’t read it without providing your admin password (the boot process already runs as root, so it doesn’t have this problem). For reasons we’ll see in a moment, you’d be mistaken to take much comfort from that in terms of security, but lets stick with /etc/kcpassword for a while first.

Now here’s something anybody can do, with or without elevated privileges (and by ‘anybody’ here we also mean ‘any process’): test to see if /etc/kcpassword exists. The file is only created when auto login is enabled, and it’s deleted when it’s turned off; thus, existence of the file is a simple way to check whether a mac has auto login enabled without needing to go through a user’s System Preferences pane.

A malicious program, for example, might run some code like this to test whether a target system is set to auto login:







If the file does exist, then passwordExploit will be ‘TRUE’, and all the attacker has to do now is execute code to read and parse the file:







We can take a look at what the file contains easily enough from the command line. Assuming you have auto login enabled (or you could just enable it temporarily for fun if you want to play along), try

sudo cat /etc/kcpassword

As we’ve already seen, you’ll need a password to see the password, but this isn’t a problem that’s going to phase a malware author, and nor does it mean that the malware author won’t be interested in the prize. Again, hold those thoughts while we look at what’s inside the kcpassword file.

Here’s what mine contains:







Hmm, goobledygook, it seems. Encrypted nonsense that surely takes a lifetime to break, no? Far from it. Be ready to behold the masterpiece of wisdom, humour or nearest book title that is your password by pasting this into the command line:


sudo ruby -e'key=[125,137,82,35,210,188,221,234,163,185,31];
IO.read("/etc/kcpassword").bytes.each_with_index{|b,i|break if key.include?(b);
print [b^key[i%key.size]].pack("U*")}'

Tradaa! And here’s my inglorious password: k33p_out_th3_badi3z.







How is that possible? No, it’s not some secret new encryption breaking technique. The fact is the kcpassword is not encrypted at all, it’s XOR’d. To see the basic idea, take the first character, ‘?’. The asci code for ‘?’ is 63 (this is for demonstration purposes only; the actual XOR’ing is done in hexadecimal rather than the simpler decimal used in this example). That number in binary is 00111111. To XOR it, all I have to do is provide another binary number, lets say 84, which is 01010100, and apply the rule that for each equivalent bit in the two numbers, if the bits are the same we output a zero, and if they are different we output a 1. Thus, ‘?’ (63) ^ ’T’ (84) comes out like so:

00111111 (asci 63 = ‘?’ – encoded password character)
01010100 (asci 84 = ’T’ – XOR mask)
—————
01101011 (asci 107 = ‘k’ – plain text password character)

Now, if we go through each of the characters in my encoded (note, not ‘encrypted’) password, and apply the correct XOR mask for each, we can reveal the password — note the mask for the first character in my demo was 84, but each character is XOR’d with a different mask — and that’s precisely what the Ruby script we used above did (again, noting that the masks are in hex rather than decimal).

OK, now you may have some questions. 🙂 The first is probably: do Apple KNOW THIS!? Oh sure, of course! Nobody uses XOR for security, at least not like this, but you can’t blame Apple that much. It’s a reasonable assumption on their behalf that if a user sets their computer to auto login, security isn’t high on their priority list. The second reason why Apple probably feel unconcerned by this is that you need a password to see the password, so surely there’s no real danger?

That may have made sense 30 or 40 years ago when the only people who had admin passwords were, well, administrators, and when processes couldn’t easily exfiltrate data via the internet. It doesn’t make much sense nowadays in a computing environment where people download software from unknown sources which immediately asks the user for a password to install and then phones home. Users rarely say ‘no’ to such requests (after all, they downloaded the software because they wanted to run it, right?) and almost certainly have no idea what processes run with admin privileges as a result.

It would also be a mistake to believe that, in this scenario, a piece of malware that has just tricked the user into providing an admin password to install would not need or want to run the exploit against the kcpassword file. Far from it.

Usually, when apps ask for your password to install, they don’t get to see the password directly. Some malware will present a false dialog to do this, but most will take the easier (and less suspicious) route of letting macOS mediate the process. A legitimate password dialog box is actually from macOS, and it only grants privileges to the requesting app; it does not give them the password in plain text. But the plain text password is the holy grail of malware persistence: as powerful as elevated privileges are, they may also be temporary, limited, and revoked; they also can’t be stored or easily transferred.

To see why this matters, consider a piece of malware that gains elevated privileges through the OS in the way described, but not the password. If the malware is discovered, it can be removed. If the attacker wants to strike again, they have to fool the same person into the same trick of installing their software as they did before. In a world where we’re all increasingly ‘once-bitten twice shy’ when it comes to computer security, that’s not a trivial task.

On the other hand, if the attacker gains the plain-text password from the first attack, this can either be stored elsewhere on the victim’s computer (somewhere that doesn’t need privileges to be accessed) or even sent back to the attacker’s remote command and control server. In that case, even deleting the malware isn’t going stop the attacker (indeed the attacker may delete the malware themselves to avoid detection!). All they have to do is connect to your mac remotely, input your admin password and they’re straight back in again.

I hope it’s clear from this that due to the weak obfuscation of the kcpassword file, auto login is a tremendously bad idea. It doesn’t matter whether your mac is locked in a one-person vestibule with round-the-clock guards. It’s when your mac is in use that it’s vulnerable.

Moral of the tale: disable auto login, folks, especially those of you that just enabled it to play along with this post!



Acknowledgements:
Ruby script: http://osxnotes.net/passwords.html
Background info: OSX Incident Response – Jaron Bradley

Advertisement

how to remove adware from your mac




Despite removing MacKeeper, I occasionally get reports from DetectX users who find that when they open their browser, MacKeeper is still haunting them. If your browser is popping open with images like the ones above, then like those users, you’ve got an adware infection.

It sounds nasty, but it’s more annoying and intrusive. It also may signal that your mac has been compromised in other ways by malware such as Pirrit, which has the capability to do more than just harrass you through your browser.

The easy solution to adware is to run my free app DetectX. If you find the problem isn’t solved, you can also send me the DetectX report and I’ll solve it for you, for free.

If you like rolling your sleeves up yourself, then follow this procedure:



1. Preparation
As you should always be running with a recent backup anyway (right, folks?) be sure to do a TM backup or clone before you start in case anything goes wrong. Do not ignore the necessity for a backup. If you don’t have one, stop now and get one.

You’re going to want to hunt down the adware in a few places. Be careful not to delete anything, but instead move suspicious items to a folder on your Desktop so that you can return them to where they came from if they are innocent. Create a new folder on your Desktop called ‘Quarantine’ for this purpose.

You’re going to want to keep a note of what you find and where you found it, so have a text editor like BBEdit or TextEdit open while you work. Save this file in your Quarantine folder, too.

When you find a suspicious item, an easy trick is to drag the suspect first into the editor to copy its path, and then drag it into your makeshift ‘Quarantine’ folder to move it. To copy the path in this way, use a plain text format in TextEdit. If you’re using BBEdit, command-drag the item. For moving to your Quarantine folder, you’re going to need to use ‘Command’-drag and supply an Admin password for the move if the item is outside of your Home folder.

2. Local and User Domain Libraries
Note these are two different libraries, but I’m assuming that if you’ve elected to follow this “roll your sleeves up” procedure, you already knew that. If you didn’t, I strongly suggest you reconsider trying to do this yourself. Messing under the hood requires a certain minimum level of experience and knowledge to avoid borking your entire system.

Assuming that all warnings and caveats so far have been heeded, you’re ready to inspect the /Library and ~/Library folders. Treat as suspicious anything at the root of /Library that begins with a lower case letter, particularly if it is an executable. Aside from the hidden .localized file, Apple don’t put anything at the root of /Library that begins with a lower case letter, and responsible 3rd party developers don’t either. If you find anything like that and you don’t know what it is, make a note of it (don’t move it yet).

At this point I’d love to be able to give you a list of file names to look out for, but I’m afraid we’re talking in the thousands if not more. A lot of this adware creates its own unique names on install by randomly choosing words from the /usr/share/dict/words file. Some of them disguise themselves as Apple files, like com.apple.morkim.plist and others disguise themselves by hiding themselves from the Finder (so ideally you want to be doing this on the command line, or at the very least use the Finder with invisible files showing).

The good news is that a lot of this adware is fairly obvious when you look at it. Move into the local (not user) Library’s LaunchAgents and LaunchDaemons folders and inspect the items in there. Move items that have random dictionary word names like ‘Bolshevik-remindful’ or gibberish concatenations of consonants and vowels like ‘com.xpbbptejonfy.plist’. If you’re not sure, open the plist (you can cat or sudo cat it if you’re in the Terminal) and see what executable it refers to. If that refers to a path to some similarly named binary you’ve never heard of, go check it out and see what it is. If in doubt, use Google your favourite search engine to search for that name on the web and see if its legit. Anything legitimate will be easy to find a reference to on the web. Anything that fails these tests should be moved to your Quarantine folder. If you find anything that refers to a folder or file you made a note of earlier in the root of /Library, then move both to your Quarantine folder.

After that, you’ll want to move on to your ~/Library/LaunchAgents folder, and follow the same procedure. Any items in here should refer to an app that you recognize and regularly use. Items with names that mispell words like ‘update’ and ‘download’ are dead giveaways as adware.

Adware plist files in here will typically refer to something funny sounding in your ~/Library/Application Support/ folder. Any apps found in the Application Support folder or subfolders should be treated as suspicious. Again, check the name through an internet search if you’re in any doubt, but since this is stuff in your user domain, really anything you don’t recognize shouldn’t be there anyway.

3. Browser Extensions
While you’re in the user Library, go check on what is in Safari/Extensions folder. You should see an Extensions.plist and only the safariextz files that refer to Extensions you use, if any. Fire up Safari, and check in the Preferences’ Extensions tab to uninstall any that you don’t use. If you use other browsers, use the Tools menu to inspect Extension or Add-ons, again removing any that you don’t use.

4. Restart and test
It’s time to restart your mac. After restarting, you’ll need to reset your browser to its default state. First, hold down the shift key while launching the browser from the Dock.

If you get redirected to an adware page or still get a pop up, clear your browser’s default settings. Although adware can no longer easily alter Safari’s defaults, you can check that your home page is correct in Safari’s Preferences. You can empty history and caches from the Safari menu and the Develop menu, respectively. For the latter, click ‘Advanced’ in Safari’s Preferences and check the ‘Show Develop menu in menu bar’ box at the bottom to enable the menu.

To reset Chrome and chromium based browsers to default settings, see:

https://support.google.com/chrome/answer/3296214

For Firefox, see

https://support.mozilla.org/en-US/kb/refresh-firefox-reset-add-ons-and-settings



Fixed it or not?
If you correctly identified and moved the adware, you should be all good. Depending on what you moved and from where, you might want to hang on to the items in your ‘Quarantine’ folder until you’re sure everything is working correctly. If you accidentally moved something you shouldn’t have, you’ll likely soon notice something isn’t working like it used to. Use your notes or your backup to undo the damage. When you’re sufficiently confident that everything in your Quarantine folder is definitely badware, move your notes to somewhere else if you wish to keep them for reference (I’d appreciate a copy of them, too :)) and delete your Quarantine folder.

If things didn’t work out, don’t despair or feel bad. Adware is complex, and the simple DIY guide above won’t cover all the cases. There are other places adware can hide, but it takes a lot of experience to track it all down. If you can’t solve the problem yourself, you can always check your mac with DetectX or contact me through DetectX’s Help menu item ‘Report a Problem to Sqwarq’ and have me do it for you (and no, I don’t charge for this service).

Good luck! 🙂

Related posts: Terminal tricks for defeating adware