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