Two root accounts, what to do?

Question

I'm on Ubuntu 15.04 and today I've been reading an article about Linux security from this link.

Everything went good until the part of UID 0 Account

Only root should have the UID 0. Another account with that UID is often synonymous to backdoor.

When running the command they gave me, I found out there were another root account. Just after that I disabled the account as the article do but I'm sort of afraid of this account, I can find him on /etc/passwd

rootk:x:0:500::/:/bin/false

And in /etc/shadow

rootk:!$6$loVamV9N$TorjQ2i4UATqZs0WUneMGRCDFGgrRA8OoJqoO3CCLzbeQm5eLx.VaJHeVXUgAV7E5hgvDTM4BAe7XonW6xmup1:16795:0:99999:7::1:

I tried to delete this account using userdel rootk but got this error ;

userdel: user rootk is currently used by process 1

The process 1 is systemd. Could anyone give me some advice please ? Should I userdel -f ? Is this account a normal root account ?

Solution 1

Processes and files are actually owned by user ID numbers, not user names. rootk and root have the same UID, so everything owned by one is also owned by the other. Based on your description, it sounds like userdel saw every root process (UID 0) as belonging rootk user.

According to this man page, userdel has an option -f to force removal of the account even if it has active processes. And userdel would probably just delete rootk's passwd entry and home directory, without affecting the actual root account.

To be safer, I might be inclined to hand-edit the password file to remove the entry for rootk, then hand-remove rootk's home directory. You may have a command on your system named vipw, which lets you safely edit /etc/passwd in a text editor.

Solution 2

That indeed looks like a backdoor.

I'd consider the system compromised and nuke it from orbit, even if it is possible to remove the user you have no idea what interesting surprises were left on the machine (e.g. a keylogger to get users' passwords for various websites).

Comments

[Julie Pelletier]

I strongly suspect this error is simply because they have the same UID (0). I just did a test by creating a second user with an existing UID and it was reported as being the first one in /etc/passwd. I also doubt that removing that account could have any impact on the machine since files and processes refer to the UID and not the username. It would be advisable (although most likely not required) to have a recovery disk handy but I would remove it and restart the machine without any worry.

[Lulzsec]

Remove what? Entry from passwd & shadow or remove the whole account using userdel -f ?

[Lulzsec]

Removed rootk from /etc/passwd & /etc/shadow ; rebooted and everything is good now, root is being the only one shown as root user Thank you for your help !

[Luis Colorado]

Either case, try to run some root-kit detector, as you could probably have been infected by one. rootk is too suspicious name, and having a non-disabled password is worse a symptom of having been defeated by a trojan horse. By the way, don't remove the entry, just insert some letter at the password field to disable it, as it will give you clues to know how did you get infected.

[Luis Colorado]

@DarkHeart, Nope, I'm afraid not... but having a rootk account with a supposed valid password (not disabled) is a strong symptom of some network exploit or misuse of the root account by the local user. As we use to say: "Do trust the Holy Virgin, and don't run...". By the way, do you think I'm a sixteen years old guy with no experience in unix/linux? :(

[Baard Kopperud]

A bit OT, but some Unix-systems - like FreeBSD - comes (came?) default with a second root-account - toor (root spelled backwards) - both with UID #0. This could be used by a second administrator, or as a way to log-in if you forgot the password to root or you deleted the root-line in your password file. Another reason may be if you wanted to be able to use different shells - eg. root = bash, zoot = zsh, toor = tcsh. On Linux though, it's very suspicious.

[Lulzsec]

@LuisColorado I'm currently doing this, thank you for the advice - MarkPlotnick checked and everything seems good, thanks :) - BaardKopperud Yeah I've heard of it but my Ubuntu didn't come with any other root accounts - Now I've got a new question, how could I check what the user "rootk" did ? Aren't there any logs file or something ?

[Lulzsec]

@Gilles it was first "/bin/bash" and I'm the one who changed it to /bin/false :)

[Lulzsec]

Thank you answering! I feel king of relieved, I thought it was some badass backdoor ! I did as you said, I removed the entry for rootk in /etc/passwd. But there were no rootk's home directory

[Julie Pelletier]

@Lulzsec: This in no way tells us if the rootk account was created as a backdoor. It just means that it can be removed easily.

[Luis Colorado]

I think you have not completely solved the problem. Check my comments on your question, please.

[Gautama]

put it in the microwave and buy a new one.

[Freiheit]

What makes that look like a backdoor? Does it match any known profiles, rootkits, etc.?

[IMSoP]

@Freiheit Well, an additional user with root permissions is pretty much the definition of a rootkit / backdoor. Once somebody was logged in as that user, they could pretty much compromise anything on the system. Even if the account was created for some innocent purpose (amd I have no idea what that would be), someone else could have discovered it and used it maliciously (read up on the Sony DRM that rootkitted Windows for example).

[Jeff Schaller]

Be careful not to run userdel -r, as apparently rootk's home directory is /

[Rob C]

One thing is a bit odd though. If it is indeed a backdoor, then why is the password disabled?

[DaleHarris541]

@kasperd: The password's not disabled, it's in /etc/shadow. Setting the shell to /bin/false (if that hasn't been tampered with) may disable interactive login, but won't prevent the account from being used in other ways. For example, sudo -s will look at the SHELL environment variable, not /etc/passwd, to determine what shell to run.

[DaleHarris541]

@kasperd: Ah, ok. Might it be a way to get tasks executed periodically as root from a hidden crontab (although the choice of / as home directory seems inconsistent with that)?

[Rob C]

@BenVoigt A crontab is not stored in the users home directory but rather as /var/spool/cron/crontabs/$USER, so that is a possibility.

[Blrfl]

Better: use vipw if the system has it.

[DaleHarris541]

@kasperd: After some more reading, it seems that a default configuration won't process crontab for a locked user account due to pam_access.so, but since skipping that test won't break anything, if it were removed from the configuration, the execution of rootk's crontab might go unnoticed for a long time.

[Lulzsec]

Thanks for all these answers, I've indeed edited the file using vipw :) Now checking with rootkit checker!

[Lulzsec]

@AaronMcMillin doing as you said deleted the rootk users! Magnificent

[Lulzsec]

@kasperd Because it was first "/bin/bash" and I'm the one who changed it to /bin/false :)

[Rahul]

@Lulzsec did you come to know about conclusion ?