Ever Had Your Screen Saver Hacked? (and Are You Sure)

by Matthew Russell

If you dig around a bit, you'll find that /private/var/log/secure.log contains a record of your recent screen saver authentication activity. A typical snippet looks something like this:

Oct 6 19:46:51 Goliath com.apple.SecurityServer: authinternal failed to authenticate user matthew.
Oct 6 19:46:56 Goliath com.apple.SecurityServer: authinternal authenticated user matthew (uid 502).
Oct 6 19:46:56 Goliath com.apple.SecurityServer: uid 502 succeeded authenticating as user matthew (uid 502) for right system.login.screensaver.
Oct 6 19:46:56 Goliath com.apple.SecurityServer: Succeeded authorizing right system.login.screensaver by process /System/Library/CoreServices/loginwindow.app for authorization created by /System/Library/CoreServices/loginwindow.app.

So if anyone has recently failed at guessing your password, there should be a line containing the string "authinternal failed" (shown above), and assuming you had just stepped out for a little while, this line would have a recent time stamp and be toward the bottom of the log.

Here's a quick one liner you can run in Terminal that will flag invalid login attempts for the current day. Wrap it up as a Bash script if you find it to be handy.

cat /private/var/log/secure.log | grep "authinternal failed" | grep "`date | awk {'print $2 " " $3'}`"

In case you're new the pipes and filters architecture, this is just a little three-part pipeline. It's pretty simple, but you can check the man pages by typing man <command name> in Terminal or post back up a question if you want additional info. The only thing you may not have seen before is the command substitution that takes place with the grave accents. All that's happening there is that the output of the command in the accents is replacing the command itself. The output that's substituted back in for the command is what grep picks up and uses as a filtering criteria.

You should note that although our three-part pipeline does tell you about invalid attempts, it doesn't tell you anything about valid logins (meaning that someone did successfully guess your password.) If you want to know about them, you'll need to get a synopsis of the most recent activity. Taking the last 6 lines or so from the log file should be enough to tell if you if there has been any covert activity since your current login and when you stepped out to lunch.

cat /private/var/log/secure.log | tail -6

So back to that question...

...Ever had your screen saver hacked? (and are you sure)


2005-10-06 19:43:23
Easier date command
Instead of piping the nested date command into awk, you could simply format the date command as:

date "+%b %e"

That gives the same output. That's the great thing about Linux/Unix, there's more than one way to do the same job.

2005-10-06 20:03:24
Easier date command
Good call. I like this much better than my cryptic rendition. If only I had time to read all of the man pages...Guess I won't have a good reason for being bored again until that's done :)
2005-10-07 00:25:37
...you win today's Useless Use of Cat award1 ;-)

cat /private/var/log/secure.log | tail -6

Why not just "tail -6 /private/var/log/secure.log"?

The same applies to the grep too, which if I'm not mistaken could just be:

grep "`date "+%b %e"`.*authinternal failed" /private/var/log/secure.log


2005-10-07 01:03:12
Or, for non-technical users
simply open Console.app, select the appropriate log file from the list on the left, and type 'authinternal failed' in the search box.

Couldn't be any simpler !

2005-10-07 07:45:54
One think I really like about Unix tools is the fact that, for the most part, they are designed to do one thing really well. For that reason, I don't really understand the trend to bash people who use cat to pass text to another tool.

One benefit of getting into the habit of doing "cat ... | other" is it's easy to replace cat with zcat, bzcat or another tool as needed without having to rethink (or recode if it's on a script) the command.

May be we should start a "Cat's not useless" campaign.

2005-10-07 08:24:29

Ne'er shall I make such a spectacle of my unlearnedness e'er again

I'd never heard of this award, but find it interesting and amusing enough that I'm glad I'm glad to have received it -- but just this once -- if for nothing else than the laugh I just got.

I think my illegitimate use of cat dates back to watching my old Linux admin do a cat somePasswordsFile | grep matthew to look up my passwords every time forgot them (which was pretty often). Seeing those two commands in combination so many times must have tainted my poor mind forever...but hopefully I can break the bad habit...with all of you as a support group, of course.

But seriously, I appreciate the criticism. I try to be a purist at heart, and what you say makes good sense. I'm now waiting for my opportunity to give this award to someone ;)

2005-10-07 19:22:08
Probably the cleanest way yet...
...all of these comments are great, and I just wanted to post up an e-mail that I just got from a reader that introduces what might be the cleanest way to do this chore at all.

Looks like this has turned out to be more of a discussion on the pipes and filters architecture (and how not to "uselessly use" processes) than anything else, but I think that's great. (I know I sure learned a few things here, and if you all did as well, then we're making progress and progress is good.)

Anyhow, here's the e-mail:

The pipeline

cat /private/var/log/secure.log | grep "authinternal failed" |\
grep "`date | awk { 'print $2 " " $3' }`"

can be reduced to

grep "^`date +%b' '%e` .* authinternal failed " /private/var/log/secure.log

i.e., grep directly form what you want, and use the date command's command-line arguments to make it produce what you want, rather than wasting a pipeline on parsing its default output. You use 2 processes instead of 5 and type a lot fewer keystrokes.

You might add that it may be necessary to precede it with a "sudo ", as the log file may be readable only by root.

The pipeline

cat /private/var/log/secure.log | tail -6

is more concisely expressed as

tail -6 /private/var/log/secure.log

...fewer keystrokes and no superfluous extra process.

2005-10-12 15:54:05
The error message that a login failure generates in secure.log is different in 10.3 than 10.4. This particular script seems to be Tiger-oriented.
2005-10-12 16:07:55
Although I can't check for you, I recall doing this exercise in my Panther days, so I know that there's something that's written in Panther's log that you could grep out.

Just open up Console and take a look.

2005-12-13 09:06:19
privacy log
This is a question dealing with the privacy log.

When running disck utility, I often find a permissions vary statement.

Permissions differ on ./private/var/log/secure.log, should be -rw------- , they are -rw-r-----

First, what is rw, then what does the change mean.

I run the repair function, (sometimes twice), and it's corrected. But, I often find that this shows up.

Am I being hacked?



2005-12-18 18:38:35
privacy log
For an enlightening journey, read the man page on "ls" sometime. In Terminal, type "man ls" and check it out.

It's a bit much to get into here.

As for the "Am I being hacked?" question, the short answer is -- almost definitely not.