ssh leaking information

[Richard Hepworth]

Hi,

Does anybody know how to stop the system printing "Your password was changed by root"?

If somebody is trying to hack their way into a server, say via ssh, by trying to find valid account names the above message gives the hacker the information he would be looking for - the account must exist.

[Duncan Edmonstone]

Richard,

This is I think, not particularly a function of ssh, but a function of the Pluggable Authentication Modules used by ssh, telnet, login etc...

I don't know ssh well enough to know whether there is a way of turning this off - I do however have a little "hack" that at least makes the information "less obvious", by changing the message catalogue used by the PAM modules...


cd /usr/lib/nls/msg/C/
cp -p /usr/lib/nls/msg/C/pam_comsec.cat /usr/lib/nls/msg/C/pam_comsec.cat.old
dumpmsg /usr/lib/nls/msg/C/pam_comsec.cat > pam_comsec.msg

**edit pam_comsec.msg and replace "Your password was changed by %s" with just some white space - I found that just removing the whole line doesn't work **

gencat /usr/lib/nls/msg/C/pam_comsec.cat.new pam_comsec.msg

cp pam_comsec.cat.new pam_comsec.cat

This at least obfuscates a little in that instead of:

----------
ssh user@myhost
Your password has been changed by root
Password:
----------

I now get:

----------
ssh user@myhost

Password:
----------

Although its not perfect cos during a normal login you would get

----------
ssh user@myhost
Password:
----------

Which is subtly different for a hacker (but maybe not for an auditor!) I only played with it quickly, so there may be some way of inserting an escape sequence in the pam_comsec.msg file prior to generating the new pam_comsec.cat file with gencat.

That worked OK for me - but then I haven't done more than 5 minutes testing and its *is* a hack...

HTH

Duncan

[Richard Hepworth]

thanks Duncan.

It does work but that newline is still a bit of a giveaway (or at least will be in the auditors eyes - they don't let much go :-) ). I have been unable so far to stop it from printing the newline......

[Duncan Edmonstone · Accepted solution]

Richard,

Can you tell us a little more about your configuration? Are you runninmg a trusted system? On my 11.11 workstation which is trusted I can reproduce your problem, but on my untrusted 11.31 systems I can't...

Assuming this is a trusted system, the other way to get around this is to remove the u_pwchanger=root entry from the tcb file for the user, so you never get the message. I guess this could be scripted reasonably easily... e.g. if I've changed the password for user oracle then I'd need to remove the u_pwchanger=root entry from the file /tcb/files/auth/o/oracle

This could be a manual process on password resets or I guess it could be scripted like something like this:

#!/sbin/sh
# mypwreset.sh
# $1 = user to reset

user=$1

passwd ${user}
sed s/:u_pwchanger=root//g /tcb/files/auth/$(echo ${user} | cut -c 1)/${user} > /tmp/${user}.$$
cp /tmp/${user}.$$ /tcb/files/auth/$(echo ${user} | cut -c 1)/${user}
rm -f /tmp/${user}.$$


so that's quick and dirty and there's much more to think about - but I'm sure you get the gist...


HTH

Duncan

[Richard Hepworth]

Duncan,

All our systems are trusted (11.31).

Your second solution is probably best, we can just change our procedures for passwd resets (at least the procedure the auditor see's anyway!).

It would be easier if u_pwchanger was editable via modprpw, but I can understand why it's not.

thanks for your help!

Richard

[Duncan Edmonstone]

Richard,

One final point - I assume you are aware of the "deprecated" nature of trusted mode on 11iv3 (i.e. supported, but won't be in the next release) - you should at least be thinking about adopting standard mode security extensions instead:

http://docs.hp.com/en/5992-3387/ch04s01.html

HTH

Duncan

[Richard Hepworth]

problem solved