Root user password causing security hole...

[Daniel Yap]

If anyone has seen this, please help...
I stumbled across a problem where the root password is set, yet when ANY user 'su' and enter a blank password they are granted entry as 'root'. The password set for root is not blank, yet somehow the blank entry is also accepted. Any clues on where to start looking?
Thanks in advance. This even happens upon login, rlogin, and telnet as 'root'.

[Andy Monks]

Are you using NIS? and if so, is it setup correctly.

[Daniel Yap]

Yes, I believe we are.

[Andy Monks]

if 'ypbind' is running you are!

So, if so check your local /etc/passwd file. It will have a line that begins with a "+". It should be after the 'local only users'. So, after all the system users is a minimum.

[Daniel Yap]

Andy,
'ypbind' is not running, and there is no '+' entry in the /etc/passwd file. I guess we are NOT running NIS. Sorry. Any other ideas?

[Sam Nicholls]

What command are you using to set the root password?

What does the /etc/passwd entry for root look like?

-sam

[Dan Hetzel]

Hi Daniel,

If you're NOT using NIS, remove the line starting with 'passwd:' in the file /etc/nsswitch.conf

Regards,

Dan

[Daniel Yap]

The entry for 'root' in the /etc/passwd file is as follows:
root:vIoK1y0bdoV5E:0:3::/:/sbin/sh

There is no 'nsswitch.conf' in /etc. There are only example files which could be copied to /etc/nsswitch.conf.

Am I simply overlooking something?

[Shannon Petry]

You may be missing something.
Q: Is this on ALL clients that people can su with no passwd?
Q: If you are using NIS, where is the "+::0:0:::" in /etc/passwd? It should be the LAST line!

Q: Do any of the local or NIS users have a UID of 0? This is the most critical! I have seen many backdoors made by people assigning a UID of 0 to an ID. This UID means the user is really root already, so a su is only beneficial for the accounting system.

Make sure that No user is assigned UID=0, GID=0!. Make sure permissions on /etc/passwd and /etc/group are 444. Make permissions on "/" 555, chown root "/" chgrp root "/".


Regards,
Shannon

[Andy Monks]

Daniel,

a few things that may be worth checking :-

1. the 'root' user is the first entry in the passwd file.
2. the 'root' user is only in the passwd file once.
3. no other user had a uid of '0'.
awk -F: '{ print $3 " " $1 }' /etc/passwd | sort -n | more

Andy

[Daniel Yap]

Sorry it took me a while to get back with you. I verified all that you guys have suggested and we are not using NIS and 'root' is the first entry in /etc/passwd and is the only user w/ UID 0 and no other user is in the 'root' group. I am at a loss as to where else to look. Any other help or suggestions would be greatly appreciated. Thanks again guys.

[Andy Monks]

Hmmm, this is strange.

I do have something to try, but don't do it with users on the system.

Firstly, take a copy of the existing /etc/passwd file and put it somewhere safe.

The copy the passwd file in /usr/newconfig/etc to /etc (over-writing the existing one).

Then add a new user (using sam or useradd) and also assign root a new password. Then try your test again.

This should at least prove if it's the passwd file or something else.

After you've finished the test, copy the old passwd file back.

[dw_3]

...from an audit/security background: either your system has been significantly compromised (hacked) or you are familiar with the concepts of "social engineering"

[Daniel Yap]

Andy, I tried your test with replacing the /etc/passwd file. It still allowed me to enter without a password for root. I have placed a call into HP Support, but if you still have any other ideas, let me know. Thanks for all your help.

[Patrick Wallek]

Check what version of su you are using. There could be a problem there.

Here is su on my 10.20 system:

# ll /usr/bin/su
-r-sr-xr-x 1 root bin 20480 Feb 20 1998 /usr/bin/su
[scrooge:root] 1241 /
# file /usr/bin/su
/usr/bin/su: s800 shared executable dynamically linked
[scrooge:root] 1242 /
# what /usr/bin/su
/usr/bin/su:
$Revision: 80.1.1.1 $
PATCH_10_20: su.o 98/02/20

Here is su on my 11.0 system:

[uran:root] 223 /tmp/pww
# ll /usr/bin/su
-r-sr-xr-x 1 root bin 24576 Aug 6 1998 /usr/bin/su
[uran:root] 224 /tmp/pww
# file /usr/bin/su
/usr/bin/su: PA-RISC1.1 shared executable dynamically linked
[uran:root] 225 /tmp/pww
# what /usr/bin/su
/usr/bin/su:
$Revision: 82.15.1.1 $
PATCH_11_00: su.o 98/08/06

[Patrick Wallek]

You might also search your system for other versions of su. There could be a rogue version out there that is getting used instead of the su in /usr/bin. You could do a 'which su' to see which one you are using by default.

[Bill Hassell]

which su is not going to catch aliases or functions. The preferred method to determine where a command originates is:

whence -v su

Because sysadmins so commonly type su, hackers will hide a false su in your $PATH, aliases or function libraries. which will not find these aliases. Try this:

alias su=aBADcommand
which su
whence -v su

which will not tell what the shell is going to do with su.

[Andy Monks]

As a followup to Bill's response, try running /usr/bin/su and see what happens.