Able to Locally Login as Root with ANY password??

ECRocker · 01-20-2010, 01:12 PM

Found a major security hole in one of my more crucial linux servers today. (Only locally) I can use the user name "root" and any string for the password. So I can literally type "poop" as the password and the server lets me in.
I know how to set root password settings for SSH and sudo, but where are settings located for local access that would allow something like this??
Thanks,
Dan

i92guboj · 01-20-2010, 01:15 PM

It depends on how do you access. Usually, nowadays, this is via pam on most regular distros. So, it's probably the pam config what you should be looking at.

Mara · 01-20-2010, 01:30 PM

Moved: This thread is more suitable in Linux-Security and has been moved accordingly to help your thread/question get the exposure it deserves.

Mara · 01-20-2010, 01:35 PM

Look first into /etc/passwd. There should be an entry for root (first column). It should start from
root:x
The 'x' means that there's a password in /etc/shadow. /etc/shadow should also have an entry for root, something starting from
root:somestring:
'somestring' is the password (not in plain form).

ECRocker · 01-20-2010, 01:49 PM

There's definitely a password for root, and it's used for everything else (SSH, Sudo, Su -, etc.).
I'm looking at PAM and I'm not sure what might be out of place...

ECRocker · 01-25-2010, 09:24 AM

Code:

[root@linadmin1 pam.d]# cat login
#%PAM-1.0
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
auth       include      system-auth
account    required     pam_nologin.so
account    include      system-auth
password   include      system-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    include      system-auth
session    required     pam_loginuid.so
session    optional     pam_console.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open
session    optional     pam_keyinit.so force revoke

Code:

[root@linadmin1 pam.d]# cat system-auth
# $Id: system-auth,v 1.1 2009/02/04 19:37:35 root Exp root $
# system-auth

auth            required        pam_env.so
auth            sufficient      pam_unix.so nullok_secure
auth            requisite       pam_krb5.so use_first_pass


account         required        pam_unix.so
account         required        pam_access.so
account         sufficient      pam_succeed_if.so uid < 600 quiet
account         required        pam_access.so
account         required        pam_ldap.so use_first_pass

password        sufficient      pam_unix.so nullok obscure min=4 max=8 md5
password        sufficient      pam_krb5.so use_authtok

session         required        pam_unix.so
session         optional        pam_krb5.so
session         required        pam_mkhomedir.so silent umask=0077 skel=/etc/skel

acid_kewpie · 01-25-2010, 09:28 AM

Code:

auth            sufficient      pam_unix.so nullok_secure

tada.

And you thought Debian wasn't meant to be awful? http://www.redhat.com/archives/pam-l.../msg00001.html

anomie · 01-25-2010, 12:03 PM

Goodness gracious. Gotta love these obscure, poorly documented options.

ECRocker · 01-25-2010, 01:22 PM

I read that article earlier this morning, it left me even more confused!

I tried to test this by creating a test account, and actually the system denies access to both good and bad passwords. Ok, so it appears that is a separate issue. I just now tested this theory on another system that was having the same original problem, and changing the auth parameters to:

Code:

auth            required        pam_env.so
auth            sufficient      pam_unix.so
auth            sufficient      pam_krb5.so use_first_pass
auth            required        pam_deny.so

works!

OK, so if I merely changed

Code:

auth            sufficient      pam_unix.so nullok_secure

to

Code:

auth            sufficient      pam_unix.so

this does not resolve the issue. I figured removing the nullok_secure option would suffice, but it does not??
and

Code:

auth            required      pam_unix.so

works, does not allow for authentication over pam_krb5.so
So adding pam_deny.so allows for both sufficient modules but denies invalid password entries.

OK OK, so this is where I'm left feeling confused:
I was looking for the answer in the "password" module... why does the "auth" module have anything to do with verifying the password of an account??

amonamarth · 01-25-2010, 01:37 PM

I was recently studying this specific subject for my RHCE RH302 test. Quoting Michael Jang's book, RHCE Linux Study Guide(fifth edition), page 306:

"Authentication management(auth): Establishes the identity of the user [...] a PAM auth module command decides whether to prompt for a username and/or password."

carbonfiber · 01-25-2010, 02:45 PM

What distribution are we talking about? And is this the default setup?

ECRocker · 01-25-2010, 02:56 PM

CentOS 5.4 yes, I believe it's the default set up. I've never made any modifications to PAM myself. Can anyone confirm this?
What I did notice today was the only servers that had this PAM configuration were those running as virtualized guests on an ESXi server...

anomie · 01-25-2010, 07:23 PM

Quote:

Originally Posted by ECRocker

CentOS 5.4 yes, I believe it's the default set up. I've never made any modifications to PAM myself. Can anyone confirm this?

That's definitely not the default setup for CentOS / RHEL. Look at the first line of your system-auth file, and you can see that someone has it under version control.

amonamarth · 01-26-2010, 12:38 AM

Hello:

That is NOT the default with CentOS 5.4.
I recently redid one of servers from scratch with CentOS 5.4
Here is how my file looks like: (KEEP READING AFTER IT)

--------------------------------------------------------------
[root@hostname pam.d]$ cat system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so

account required pam_unix.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password required pam_deny.so

session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so

-------------------------------------------------------------

Notice the "try_first_pass" ending the second line. Referring to Michael Jang's book once again, it seems that this argument to the "auth" command "allows the use of a previous successful password."
But if that is the case, why my system works ok then?
Weird ... now I have questions lol I hope no hard issues about this in the test :-/

ECRocker · 01-26-2010, 09:04 AM

Ok, I figured out that the system-auth file was copied on install from a central config repository on my network - explains why all the newest servers are setup this way.

@amonamarth
Maybe the try_first_pass option causes +1 failed attempts and could cause issues if you set an account to lock out after so many tries? That's my educated guess.

Quote:

password - specifies the module that allows users to change their password (if appropriate) ~Wale Soyinka

I've been very mistaken, the password module does not have anything to do with initial authentication. So it's all in the auth module.

****I'm still confused on this last point. If this is my auth module stack, then if the root password is incorrect, it should be passed to pam_krb5.so which by the "requisite" (or "required") flag should terminate the login attempt.

Code:

auth            required        pam_env.so
auth            sufficient      pam_unix.so
auth            requisite       pam_krb5.so use_first_pass

This is showing not to be the case. I have to add the pam_deny.so

Quote:

The pam_deny module implements all the PAM service module functions and returns the module type default failure return code for all calls. http://docs.sun.com/app/docs/doc/816...-deny-5?a=view

So I understand that pam_deny.so sends the failure code, but why is it needed, by my logic I feel like the stack should never proceed to that step in the first place!

Anyone have any ideas?
Thanks