root passwd has been changed

[Tom Satinet]

Hello,

We have recently experieced 2 instances where the root password appears to have been changed. I believe!

I have been able to log in using an emergency account and change the passwords back. However, obviously there could be a serious problem here.

What is the best way to track how and how the root password is being changed?

We are not running a trusted system. or, sigh, even password shadowing... (because of a poor app).

Thanks

[MarkSyder]

Curious.

I would change the password to one that only I know, then divulge it to other people who need to know one at a time, so I would have a chance of knowing who had changed it.

Do you have sudo? If so, it may be that someone is logging in with sudo and switching user to root. If this is what is happening it would be a good idea to tighten up your sudo configuration.

Mark Syder (like the drink but spelt different)

[Tom Satinet]

Hi,

no i don't have sudo installed on this box. I have it configured on other boxes. I'm pretty comfortable with the config.

The password is only know by 3 people. 1 of which is not here and one of which is me. The other guy didn't change it. so.....

Any ideas?

[A. Clay Stephenson]

1) Get rid of all of these "emergency" accounts. Accounts other than root with UID 0 are ticking time bombs. Make sure that the mode of /etc/passwd is set to 444.

2) Immediately change the root account and don't tell anyone other than trusted fellow admins. Choose a well-formed plaintext password that would be very difficult to "Crack". When you begin to get complaints then you have an indication of who is using root.

3) Do a find on the system looking for setuid and setgid scripts/programs and compare these via cksum to known required scripts/programs. It is good practice to ban all setuid scripts and replace them with sudo'ed scripts.

4) After doing step 3, repeat step 2.

5) Don't overlook that one of the easist methods of changing the password would be a restore from backup.

6) Avoid logging in as root for routine tasks. Login as a normal user and then su to root for the required task and then immediately logout from root access. This minimizes the chance of you being your own worst enemy.

The problem with trying to track how the root password has been changed is that essentially anyone with root access can hide their tracks. It does bother me that you say the root password APPEARS to have been changed. How could you possibly not know that? Either it has or hasn't been.

[Tom Satinet]

Sorry, when i say 'appears to have been changed' I meant deliberatly rather than as part of a script or suid programme as you mention.

My only certainty is that the password was not as it should have been and i could not log in.

I tend to agree about about 'UID 0' accounts, but i am not the boss i'm afraid. If it was up to me we'd be running much higher levels of security all round.

normal users don't have shell access on this system. So i am somewhat concerned. Sigh. this is a really insecure system - connections are via telnet. I guess there could be a packet sniffer on the lan.

I don't think the password has been craked as it was changed - changing it is going to alert the sys admins straight away.

I really don't quite know what to do....

[Kofi ARTHIABAH]

Hmm... If you had not already changed the password, I would check the date the passwd file was last modified ( with ll /etc/passwd) that would give you an idea when the password changed.
In the absence of that I would check the usual suspects ~/.sh_history ; /var/adm/syslog/syslog.log ; last ; check your cron/at jobs to see if any of them has something wonky.
Do you suspect that your system has been "owned"? You can configure auditing on the box to help keep an eye on it:
http://docs.hp.com/en/B2355-60127/audit.5.html

Good luck

[A. Clay Stephenson]

It is part of your job to explain that these emergency accounts are a security threat. These accounts are not needed because one can always login on the console in single-user boot to restore the root password. I think looking at modification times and audit trails is all but a complete waste of time because any competent
intruder could alter the metadata and remove the audit entries.

Your most likely suspects at this point are these emergency accounts and if you aren't willing to close those barn doors then worrying about caulking the windows is pointless. When you say ordinary users aren't allowed shell access, how do you login? If the answer is as root then "We have met the enemy and the enemy is us."

[Rick Garland]

Check out the utility /usr/sbin/logins. Can help identify accts that have duplicate UIDs.

Do you have other accts with UID=0? At the very most, should have only 1 of these accts, root=0.

[Sยภเl Kย๓คг]

Hi,

If your system is not in trusted mode, person who does an rlogin to this box from some other boxes(if configured) can change the password, without knowing the root password if this box. I would really recommend not to have non root users with uid 0, u can very well implement sudoers.And give an access to thoese administrators to exceute their respective commands with superuser permissions, which can be defined in the /etc/sudoers file. Disable the direct root login and implement sudo su - kind of super user login . Convince your Team not to enable rlogin, direct root login etc. securuty threts
Regards,
Sunil

[Kent Ostby]

sudo is probably a good way to go.

If you switch to trusted system, it would help with logging changes.

While it's a kludge, you could also add an entry into root's profile to make some kind of a note in a log file.

[Muthukumar_5]

May be some of other is known with root passwd. Set root users $HOME/.profile file with necessary logging of using root account. You can also refer /var/adm/sulog (if enabled with /etc/syslog.conf for *.auth /var/adm/sulog).

touch /root/su_root.log
chmod 744 /root/su_root.log

root profile file
--- $HOME/.profile ---
echo "`who -mu` is logged" >>$HOME/su_root.log

Now every su to root is logged with /root/su_root.log file.

You can trace those.

hth.

[Tom Satinet]

Thanks for the advice. I am aware of the implications os uid 0 accounts and logging in as root etc. however, i am rather hamstrung by the application we use and by the fact that i am not in charge of the systems and can't make changes that i want to.

I am hoping the less knowledgable member of our team has reset root's password by mistake rather than a user password. To defend myself i am fully conversant in the configuartion of sudo, but seeing as the other 2 admins will log in as root regardless, there's not much point in enabling it.

[Ted Buis]

Also, I didn't see it mention, but anyone with phyiscal access to the system can power cycle it and boot up in single user mode and change the root password. Check uptime and look over the logs.

Ted

[Rick Garland]

How about setting the /etc/securetty file so that only CONSOLE will allow direct root logins. Unless your other admins are sitting at the console they cannot login as root

[Tom Satinet]

thanks for your suggestions. They're all very valid. however, i can't stop the other 2 admins from loggin in using telnet. I'm not in a position to do that.

however, i am trying to push for greater security controls. But there just isn't the will for change in our organisation. it would take a serious breach for anything to get done.

One of our apps can't read shadow password files - you can't even force a password change! and it's a telnet connection. lol

lordy!

[Muthukumar_5]

You can control specific console login based on ip-address with /etc/profile.

You can check login with telnet using process status itself.

ps | grep -q telnet
if [ ${?} -eq 0 ]
then
who -mu -> will give ip-address. With that we can control it.
fi

hth.

[Tom Satinet]

pebcak