10.20 so called "trusted system" root account disabled

[Ralph Grothe]

Hello,

looks like I've locked myself out.
Don't ask how this could have happened.
Maybe the system has been compromised?
Btw, do you know of any "post mortems" I could excercise to see what went wrong, after I regained access?
Of course, haven't I run tripwire or the likes before :-(

Anyway, the system is a so called trusted one, which to me conveys that there shouldn't appear any crypt string in the 2nd field of /etc/passwd but a sole asterisk.
However, this isn't the case and line noise is appearing in the field.
When I try to login as root I get

"Account is disabled -- see Account Administrator."

Of course, this sounds to be in accordance to trusted philosophy since the 2nd field in my "compromised" /etc/passwd defeats the trustedness, doesn't it?

When I take the salt prefix from this string and invoke Perl's crypt() together with what should be the correct password I get a deviating crypt string.
Well, maybe a "trusted system" is using some other (stronger) cypher anyway (e.g. MD5) ?

I think I have to down the box to single user mode, and get my hands on /etc/passwd and /tcb/files/auth/r/root.

Will it suffice if I substitute the asterisk for the misplaced crypt string in /etc/passwd and blank the value for u_pwd= in /tcb/files/auth/r/root in order to regain access, or is something more involved required?

Rgds.
Ralph

[Victor BERRIDGE]

Hi,
If nobody changed the passwd, you can still get connected from your console

All the best
Victor

[Victor BERRIDGE]

I forgot to mention:
/usr/lbin/getprpw -r -m lockout
To reactivate:
/usr/lbin/modprpw -k
verify exit status(=0)

Now this used to happen to me before I created a /etc/securetty file, the reason was DBAs had the root passwd and prefered to connect root and do su oracle (!!!). I stopped all this nonsense but suffered a bit for few weeks...
Dont forget to increase your retries for root... 3 is really short when people go and try...


All the best
Victor

[Tom Maloy]

I think that those two steps may be sufficient, although I have never seen anything but an asterisk in that passwd field.

You might want to add sudo to the system, allowing the administrators to do /usr/lbin/getprpw and /usr/lbin/modprpw in case this happens again.

Can't think of any post mortem steps, though.

[Simon Hargrave]

IIRC root can also be disabled with a file in /tcb/files/auth/r/ called -root, root- or something like that? If you delete the file it unlocks the account. Can't remember the exact name.

If you have an ITO agent on the server, then you should be able to remotely run commands as root from the ITO server, so you can re-enable, change the password etc without a reboot.

[Victor BERRIDGE]

in /tcb/files/auth/r/root I empty the value for u_pwd, mind you Im just checking and guess what, in that directory I have a sa_root:
root:u_name=root:u_id#0:\
:u_pwd=l/0lSfe8x6p4c:\
:u_bootauth:u_auditid#0:\
:u_auditflag#1:\
:u_pswduser=root:u_suclog#945946073:u_suctty=console:u_unsuclog#945945672:\
:u_unsuctty=console:u_lock@:chkent:

Already blanked so I can cp -p root with no passwd to sort myself out of trouble...

All the best
Victor

[Victor BERRIDGE]

Thinking of it
(BTW sorry my previous copy had a passwd, I pasted the bad one...)

This is what is espected when bad passwd:

login: toto
Password:
Login incorrect

Wait for login retry: ..
login:

Could it be something like quotas
Have you any quotas defined ?

All the best
Victor

[Victor BERRIDGE · Accepted solution]

So I tried on a trusted 10.20
Wait for login retry: ..
login: toto
Password:
Login incorrect

Wait for login retry: ..
login: toto
Password:
Account is disabled -- see Account Administrator.

Wait for login exit: ..
Connection closed by foreign host....

So if its not its very close to a trusted 10.20...
And so as mentionned you should be able to connect at the console only as root if root account is disabled BUT this only works if you know the passwd (that is - nobody changed it meanwhile). So you will have to reactivate the account with /usr/lbin/modprpw -k, after having removed the value of u_pwd: :u_pwd=:\

Good luck
Victor

[Sridhar Bhaskarla]

Hi Ralph,

As said before, you can be able to login from the console and then unlock it using modprpw -k root command.

There should be a * in /etc/passwd file in the encrypted field. Having somethingelse doesnt' matter as long as the system is trusted. This can happen if someone try to manipulate the /etc/passwd file instead of using the account administration tools like useradd, usermod etc.,.

This will most likely happen time and again. Because anyone could try to login as root and depending on your settings (default: 3), successive unsuccessful logins can disable this account. Particularly the risk of it is more if you enabled /etc/securetty file as no one can login as root from the console. I would do the following

1. Have /etc/securetty file and increase the number of unsuccessful attempts to say 50 but get notified if someone tried to access the system in 10 unsuccessful attempts. That way you can catch the user as well avoid locking of root account. Since you have /etc/securetty file, increasing the number of unsuccessful attempts wouldn't compromise the security.
2. Get reports from /var/adm/sudo.log, last and lastb daily and look at who is trying to access root accounts.
3. Keep a console handy always so you can access root from there.
4. Have sudo installed and give only your system administrators to have the permissions to do 'su', but not with "NOPASSWD" option. That way you can have your root accounts disabled but still can do your work. 'sudo' would be my last resort if these incidents are not controllable.

-Sri

[Sridhar Bhaskarla]

Sorry Ralph.. a typo in one of the sentences in my post.

*/etc/securetty file as no one can login as root from the console*

Please read it as */etc/securetty file as no one can login as root other than from the console or through su*

-Sri