Deux comptes root, que faire?

Je suis sur Ubuntu 15.04 et aujourd'hui j'ai lu un article sur la sécurité Linux à partir de ce lien.

Tout s'est bien passé jusqu'à ce que la partie du compte UID 0

Seul root doit avoir l'UID 0. Un autre compte avec cet UID est souvent synonyme de backdoor.

En exécutant la commande qu'ils m'ont donnée, j'ai découvert qu'il y avait un autre compte root. Juste après, j'ai désactivé le compte comme le fait l'article, mais j'ai un peu peur de ce compte, je peux le trouver sur/etc/passwd

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

Et en /etc/shadow

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

J'ai essayé de supprimer ce compte en utilisant userdel rootkmais j'ai eu cette erreur;

userdel: user rootk is currently used by process 1

Le processus 1 est systemd. Quelqu'un pourrait-il me donner quelques conseils s'il vous plaît? Dois-je userdel -f? Ce compte est-il un compte root normal?

ubuntu security root Lulzsec
la source

Je soupçonne fortement que cette erreur est simplement due au fait qu'ils ont le même UID (0). Je viens de faire un test en créant un deuxième utilisateur avec un UID existant et il a été signalé comme étant le premier /etc/passwd. Je doute également que la suppression de ce compte puisse avoir un impact sur la machine, car les fichiers et les processus se réfèrent à l'UID et non au nom d'utilisateur. Il serait souhaitable (bien que probablement pas nécessaire ) d'avoir un disque de récupération à portée de main, mais je le retirerais et redémarrerais la machine sans aucun souci.

Julie Pelletier

Rootk supprimé de /etc/passwd& /etc/shadow; redémarré et tout va bien maintenant, root est le seul affiché en tant qu'utilisateur root Merci pour votre aide!

Lulzsec

Dans les deux cas, essayez d'exécuter un détecteur de root-kit, car vous pourriez probablement avoir été infecté par un. rootkest un nom trop suspect, et avoir un mot de passe non désactivé est pire un symptôme d'avoir été vaincu par un cheval de Troie. Au fait, ne supprimez pas l'entrée, insérez simplement une lettre dans le champ du mot de passe pour la désactiver, car cela vous donnera des indices pour savoir comment vous avez été infecté.

Luis Colorado

@DarkHeart, Non, j'ai bien peur que non ... mais avoir un rootkcompte avec un mot de passe supposé valide (non désactivé) est un symptôme fort d'un certain exploit du réseau ou d'une mauvaise utilisation du compte root par l'utilisateur local. Comme nous disons: "Faites confiance à la Sainte Vierge, et ne courez pas ...". Soit dit en passant, pensez-vous que je suis un gars de seize ans sans expérience dans unix / linux? :(

Luis Colorado

Peut vouloir vérifier si /bin/falsele fichier est authentique en exécutant sudo dpkg -V coreutils. S'il a été modifié, pensez à tout réinstaller. Ubuntu 15.04 est en fin de vie depuis 6 mois, de sorte que les failles de sécurité existantes et futures ne seront pas corrigées, vous pouvez donc installer une version plus récente telle que 16.04.

Mark Plotnick

Réponses:

Les processus et les fichiers appartiennent en fait à des numéros d’ID utilisateur et non à des noms d’utilisateur. rootket rootont le même UID, donc tout ce qui appartient à l'un appartient également à l'autre. Sur la base de votre description, il semble que vous ayez userdelvu chaque processus racine (UID 0) en tant rootkqu'utilisateur appartenant .

Selon cette page de manuel , userdela une option -fpour forcer la suppression du compte même s'il a des processus actifs. Et userdelsupprimerait probablement juste l' rootkentrée passwd et le répertoire personnel, sans affecter le compte root réel.

Pour être plus sûr, je pourrais être enclin à modifier manuellement le fichier de mot de passe pour supprimer l'entrée pour rootk, puis à supprimer manuellement le rootkrépertoire personnel de. Vous pouvez avoir une commande sur votre système nommée vipw, qui vous permet de modifier /etc/passwden toute sécurité dans un éditeur de texte.

Rahul
la source

Merci d'avoir répondu! Je me sens roi de soulagé, je pensais que c'était une porte dérobée badass! J'ai fait comme vous l'avez dit, j'ai supprimé l'entrée pour rootk dans / etc / passwd. Mais il n'y avait pas rootkde répertoire personnel

Lulzsec

@Lulzsec: Cela ne nous dit en aucun cas si le rootkcompte a été créé comme porte dérobée. Cela signifie simplement qu'il peut être retiré facilement.

Julie Pelletier

Je pense que vous n'avez pas complètement résolu le problème. Vérifiez mes commentaires sur votre question, s'il vous plaît.

Luis Colorado

Attention à ne pas exécuter userdel -r, comme le répertoire personnel de rootk est apparemment/

Jeff Schaller

@JeffSchaller Mais si vous le faites, vous avez également résolu le problème, d'une certaine manière. Un utilisateur malveillant n'a pu voir aucun fichier!

kirkpatt

Cela ressemble en effet à une porte dérobée.

Je considérerais le système compromis et le neutraliserais de l'orbite, même s'il est possible de supprimer l'utilisateur, vous n'avez aucune idée des surprises intéressantes qui ont été laissées sur la machine (par exemple, un enregistreur de frappe pour obtenir les mots de passe des utilisateurs pour divers sites Web).

Simon Richter
la source

mettez-le au micro-ondes et achetez-en un nouveau.

Aaron McMillin

Qu'est-ce qui fait que cela ressemble à une porte dérobée? Correspond-il à des profils, rootkits, etc. connus?

Freiheit

@Freiheit Eh bien, un utilisateur supplémentaire avec des autorisations root est à peu près la définition d'un rootkit / backdoor. Une fois que quelqu'un était connecté en tant qu'utilisateur, il pouvait à peu près tout compromettre sur le système. Même si le compte a été créé dans un but innocent (et je n'ai aucune idée de ce que ce serait), quelqu'un d'autre aurait pu le découvrir et l'utiliser de manière malveillante (lire sur le DRM Sony qui rootkit Windows par exemple).

IMSoP

@kasperd: Le mot de passe n'est pas désactivé, il l'est /etc/shadow. La définition du shell /bin/false(s'il n'a pas été modifié) peut désactiver la connexion interactive, mais n'empêchera pas le compte d'être utilisé d'une autre manière. Par exemple, sudo -sexaminera la SHELLvariable d'environnement, non /etc/passwd, pour déterminer le shell à exécuter.

Ben Voigt

@kasperd: Ah, d'accord. Serait-ce un moyen d'obtenir des tâches exécutées périodiquement en tant que root à partir d'une crontab cachée (bien que le choix du /répertoire personnel semble incompatible avec cela)?

Ben Voigt