Onderwerp: cleartext passwords get into log files

author: l0om
page: www.excluded.org
date: 03.02.2006

cleartext passwords get into log files
(this was first noted from a sshd [SSH-1.99-OpenSSH_3.7.1p2])

once on a linux box i have noticed cleartext passwords in the
"/var/log/messages" logfile. how this happens and how to prevent
is the aim of this mail because it might be possible to find such
things in other log files as well.

from computer security we know one fact for sure:
never rely on the human concentration and perfection!

the cleartext password came into the log file because someone
has been out of concentration and entered the password instead of
the username in some client for connecting to a ssh server.

badass@badhost:~> grep "illegal user" messages.bak | grep input
Dec xx 10:10:18 hostname sshd[7793]: input_userauth_request: illegal user <clear-text-root-password>
Jan xx 15:31:01 hostname sshd[12328]: input_userauth_request: illegal user <dunno for sure>
Feb xx 09:29:44 hostname sshd[7318]: input_userauth_request: illegal user <a user who is not on this system but on others>
Feb xx 03:57:28 hostname sshd[14841]: input_userauth_request: illegal user <ssh brute force + n>
[...]

the problem has been constructed with:
- human unperfection
- software which fergot about human unperfection

as most servers need a valid username and a vaild password this problem
can be found in different log files with different access permissions.

another problem might be cause by showing the illegal username for
the login and even if this is caused by another lame written software
the problem is real (remind human unperfection):

the username could contain characters that might be interpreted wrong
from other software. example from log file (caused by sshd again):

Feb 2 10:20:28 hostname sshd[7419]: Failed keyboard-interactive/pam for invalid user d'a<d>;(m)l from ...

just note the characters:
<> XXS, html injeciton?
';() SQL injection?
'; shell commands?

just keep in mind that this behavior can be also found in other
applications. so why not prevent it?!

prevention:
illegal users dont need to be shown in the log files. most servers
only print a "UNKNOWN USER" in their log file and in my opinion this
makes a lot of sense.

thanks for your time and always keep watching your log files!

l0om - http://www.excluded.org

greets to detach, murfie, theldens, maximilian, johnny, Dr.Dohmen,
mattball, molke

On Fri, Feb 03, 2006 at 11:53:55AM -0000, innate@gmx.de wrote:
> cleartext passwords get into log files

This is just one of many, many reasons why the system log files in general,
and the auth failure log in particular (if separate), should only be
readable by root (or by an admin group who know the root password anyway).
That is the default situation on every implementation of Unix that
I have ever seen.

Care needs to be taken not to break this security by using Logwatch etc
to mail the contents of logs far and wide.

> from computer security we know one fact for sure:
> never rely on the human concentration and perfection!
....
> badass@badhost:~> grep "illegal user" messages.bak | grep input
> Dec xx 10:10:18 hostname sshd[7793]: input_userauth_request: illegal user <clear-text-root-password>

Perhaps someone who is that badly lacking in concentration should not
be trusted with the root password in the first place?
You might also consider disallowing remote root logins as an inherent risk,
requiring admins to login under their own username first and use su(1)
(also makes it easier to see who's done what).

There are legitimate reasons why a sysadmin might want to know the
usernames being used for failed attempts. If you really don't want to
see those messages, you can disable them, or if you must have
lax permissions on /var/log/messages, send them to a separate
secure log instead.

> the username could contain characters that might be interpreted wrong
> from other software. example from log file (caused by sshd again):

Then the other software is broken and needs to be fixed. If it fails
to sanitise log data when necessary, it may have other significant flaws
as well and a code audit would be in order.

> Feb 2 10:20:28 hostname sshd[7419]: Failed keyboard-interactive/pam for invalid user d'a<d>;(m)l from ...
>
> just note the characters:
> <> XXS, html injeciton?
> ';() SQL injection?
> '; shell commands?

What kind of software is going to be evaluating a log message
as a shell command or passing it on a commandline??

> just keep in mind that this behavior can be also found in other
> applications. so why not prevent it?!

It is up to the consumer of data to sanitize it in a way that is
appropriate to how it is going to be used. A program which displays
it on a webpage will need to encode HTML entities, whereas one which
puts it in a database will need to escape SQL special chars. Above all,
people who write such programs really need to be non-brain-dead enough
to realise that. It's not up to the producer of data to try to predict
what it will be used for.

Ben

On Fri, 3 Feb 2006, innate@gmx.de wrote:

> the cleartext password came into the log file because someone
> has been out of concentration and entered the password instead of
> the username in some client for connecting to a ssh server.

Seeing what accounts people are trying to log into is also important.
I'm sure that most administrators would be interested in seeing, for
example, login attempts on a deleted ex-staff member's account.

> another problem might be cause by showing the illegal username for
> the login and even if this is caused by another lame written software
> the problem is real (remind human unperfection):
>
> the username could contain characters that might be interpreted wrong
> from other software. example from log file (caused by sshd again):
>
> Feb 2 10:20:28 hostname sshd[7419]: Failed keyboard-interactive/pam for invalid user d'a<d>;(m)l from ...
>
> just note the characters:
> <> XXS, html injeciton?
> ';() SQL injection?
> '; shell commands?

OpenSSH tries to be idiot proof against stupid syslogds by stripping
control characters from log strings, but you can always invent a
bigger (hypothetical) idiot.

If your log processing software is so fundamentally broken that it
passes unmodified data to shells, SQL servers or HTML then nothing is
going save you - you will need to ensure that every piece of software
that logs can never be cajoled into writing something that could be
misinterpreted.

> prevention:
> illegal users dont need to be shown in the log files. most servers
> only print a "UNKNOWN USER" in their log file and in my opinion this
> makes a lot of sense.

This destroys useful information and lessens the evidentary value of
the log file. A better prevention:

chmod 0600 /var/log/authlog

(assuming it isn't already).

-d