Pourquoi un compte root compromis impose de reconstruire le serveur, pas de le nettoyer.
Un compte UID 0 sans trace de création n'a pas été créé, il a été écrit. Comment trouver un compte root caché, et pourquoi un root compromis impose une reconstruction, pas un nettoyage.
Dans cet article 5 sections
Chaque compte d'un système Unix a un acte de naissance. Une ligne dans le journal d'authentification qui enregistre qui l'a créé, quand, et avec quel outil. Un compte sans cette ligne n'a été créé par aucun outil. Il a été écrit, à la main, directement dans le fichier des utilisateurs. Quand ce compte porte aussi l'UID 0, la ligne manquante n'est pas un trou dans vos archives. C'est la preuve.
- Un compte root caché est la porte dérobée la plus difficile à voir, parce que sous Unix, root est un nombre, pas un nom. Tout compte dont l'UID est 0 a tous les droits root. Donnez à un tel compte un nom qui diffère d'un seul caractère d'un daemon système légitime, et il survit à un coup d'œil sur la liste des utilisateurs. L'œil le lit comme une faute de frappe, pas comme une menace.
- Deux observations ordinaires envoient l'intervenant dans la mauvaise direction : le nom déguisé ressemble à une faute d'orthographe d'un vrai daemon, et un contrôle de santé automatisé a déjà signalé un succès. Un feu vert.
- L'indice qui tranche les deux : il n'y a aucune entrée de création de compte dans les journaux. L'attaquant n'a jamais utilisé l'outil de création de comptes. Le hash du mot de passe a été écrit directement dans le fichier des utilisateurs, et dans le fichier des utilisateurs, pas dans le fichier shadow, ce qui est un second indicateur à lui seul.
- La doctrine : cherchez les comptes UID 0 indépendamment des journaux de création, traitez un hash dans le mauvais fichier comme une découverte, ne considérez jamais un seul contrôle automatisé comme une preuve, et quand root a été accessible pendant n'importe quelle fenêtre, reconstruisez depuis un point vérifié propre, antérieur à la compromission. Ne nettoyez pas sur place.
L'UID 0 est un nombre, pas un nom
Root n'est pas le compte qui s'appelle root. Root est tout compte dont l'identifiant utilisateur est 0. Le noyau accorde les privilèges sur le nombre, et le nom est une décoration. Une porte dérobée n'a donc pas besoin de toucher au compte root ni de deviner un mot de passe. Il lui faut une ligne de plus dans le fichier des utilisateurs avec un 0 dans le troisième champ.
Donnez à cette ligne un nom qui diffère d'un seul caractère d'un daemon système légitime, et elle disparaît à la vue de tous. Une liste d'utilisateurs est longue, les noms sont cryptiques par conception, et l'intervenant qui la parcourt lit un daemon connu, légèrement mal orthographié, et passe à autre chose. Le déguisement n'est pas sophistiqué. Il lui suffit de survivre à un regard.
# Root is a UID, not a name. List every account with UID 0.
awk -F: '$3 == 0 { print $1 }' /etc/passwd
# Exactly one line should come back: root. Any second line is a
# full-privilege account, whatever it calls itself.Deux raisons de passer à autre chose. Toutes deux fausses.
Un bon intervenant peut être conduit tout droit au-delà d'un compte root caché par deux observations raisonnables. Les deux sont du genre qu'on approuve d'un signe de tête avant de continuer. Aucune ne survit à un second regard.
| Ce à quoi cela ressemble | Ce que c'est |
|---|---|
| Le nom du compte se lit comme une faute de frappe d'un daemon système légitime | Un compte UID 0 complet, nommé pour survivre à un regard, à un caractère d'un vrai daemon |
| Un contrôle automatisé signale un succès. | Un seul contrôle automatisé n'est pas une preuve. |
“Un seul contrôle automatisé n'est pas une preuve. Confirmez-le par une recherche indépendante.”
Le compte sans acte de naissance
Chaque compte créé avec les outils standard laisse une ligne dans le journal d'authentification : créé par qui, quand, avec quelle commande. Un compte implanté n'en a aucune. Pas une ligne supprimée, aucune ligne du tout, parce que l'attaquant n'a jamais utilisé l'outil. Le hash du mot de passe est écrit à la main directement dans le fichier des utilisateurs, et c'est pourquoi il n'y a rien à journaliser.
Et il est écrit dans le mauvais fichier. Sur tout système Unix moderne, le champ mot de passe du fichier des utilisateurs est délégué au fichier shadow. Il contient un espace réservé, jamais un vrai hash. Un hash authentique dans le fichier des utilisateurs n'est ni un choix de configuration ni une bizarrerie héritée qu'on peut balayer. C'est l'empreinte d'une modification manuelle, et c'est un indicateur à lui seul.
Sans ligne de journal, la vraie date de création du compte doit être reconstituée à partir de sources indirectes : les horodatages de fichiers, et les traces que d'autres événements ont laissées autour de lui. L'absence d'acte de naissance ne vous empêche pas d'établir l'heure de la naissance. Cela veut simplement dire que vous allez devoir la mériter.
# The password field in /etc/passwd should be a placeholder (x),
# never a hash. The real hash lives in /etc/shadow.
awk -F: '$2 != "x" && $2 != "*" && $2 != "!" { print $1 }' /etc/passwd
# A name that comes back here has its hash in the wrong file.
# That is a manual edit, not a managed account.“Un compte UID 0 sans trace de création n'a pas été créé. Il a été écrit.”
Quand une mise à jour enferme l'attaquant dehors par accident
Le plus étrange dans ce mode de défaillance est ce qu'une mise à jour automatique de routine peut lui faire. Une mise à jour sans surveillance peut réécrire un hash implanté par effet de bord et enfermer l'attaquant hors de sa propre porte dérobée. Le compte reste. L'accès disparaît. La porte dérobée peut alors rester dormante indéfiniment : une porte déverrouillée vers une pièce dont la clé ne tourne plus. Cela ressemble à de la sécurité. Ce n'en est pas.
Une porte dérobée qui a cessé de fonctionner n'est pas une porte dérobée disparue. Un compte UID 0 dormant reste un compte UID 0 que quelqu'un a implanté. La présence est la compromission, pas la connexion.
Vous ne le nettoyez pas. Vous le reconstruisez.
La conclusion tentante est « on supprime le mauvais compte, on applique le correctif, terminé ». Refusez-la. Un accès root pendant n'importe quelle fenêtre, même une fenêtre que la chance a refermée plus tard d'un coup sec, signifie que chaque octet de cette machine est désormais suspect : les binaires, les tâches cron, les bibliothèques, et les outils mêmes que vous utiliseriez pour l'inspecter. Vous ne pouvez pas auditer votre retour vers la confiance sur un système dont vous ne faites plus confiance aux outils d'audit.
Cherchez root indépendamment des journaux.
Listez chaque compte UID 0 avec awk. Ne vous fiez ni au journal de création, ni à un seul contrôle automatisé, ni à une liste d'utilisateurs qui paraît normale.
Traitez un hash dans le mauvais fichier comme une découverte.
Un vrai hash dans le fichier des utilisateurs au lieu du fichier shadow est une modification manuelle. Enquêtez, ne l'expliquez pas pour l'écarter.
Confirmez chaque contrôle automatisé de façon indépendante.
Si un contrôle automatisé dit « propre » et que votre propre recherche trouve un compte UID 0 inexpliqué, poursuivez la découverte, pas le réconfort.
Fixez l'heure de la compromission, pas celle où vous l'avez remarquée.
Reconstituez la compromission la plus ancienne plausible à partir des sources indirectes. Votre point de restauration propre doit lui être antérieur, pas antérieur à la découverte.
Reconstruisez depuis un point vérifié propre.
Restaurez depuis une image connue bonne antérieure à la compromission, changez chaque identifiant que la machine a pu toucher, puis vérifiez à nouveau. Ne nettoyez pas sur place.
Root pendant n'importe quelle fenêtre signifie un système non fiable. Un système non fiable, on ne le nettoie pas. On le reconstruit depuis un point dont on peut prouver qu'il était propre, antérieur à la compromission, jamais postérieur.
“Root pendant une minute, c'est root jusqu'à la reconstruction. Cette machine, on ne la nettoie pas. On la reconstruit depuis un point dont on peut prouver qu'il était propre.”
Réponses directes
Comment trouver un compte root caché sous Linux ?+
Listez chaque compte avec l'UID 0, pas seulement celui qui s'appelle root : awk -F: '$3 == 0 {print $1}' /etc/passwd. Le noyau accorde root par UID, pas par nom, donc toute seconde ligne est un compte à privilèges complets, quel que soit son nom. Cherchez-le directement. Ne vous fiez ni à une liste d'utilisateurs qui paraît normale, ni à un seul contrôle automatisé qui signale « propre ».
Que signifie un hash de mot de passe dans /etc/passwd plutôt que dans /etc/shadow ?+
Sur tout système Unix moderne, le champ mot de passe de /etc/passwd est un espace réservé, généralement x, et le vrai hash vit dans /etc/shadow. Un hash authentique dans /etc/passwd n'est pas une configuration normale. C'est l'empreinte d'une modification manuelle du fichier des utilisateurs, et c'est un indicateur de compromission à lui seul.
Pourquoi n'y a-t-il aucune entrée de journal pour un compte qui existe clairement ?+
Parce qu'il n'a pas été créé avec les outils de comptes standard, qui sont ce qui écrit le journal d'authentification. Si quelqu'un modifie le fichier des utilisateurs à la main, le compte existe sans aucune trace de création. Un compte UID 0 sans trace de création n'a été créé par aucun outil. Il a été écrit.
Puis-je simplement supprimer le compte malveillant et appliquer les correctifs au serveur ?+
Non. Un accès root pendant n'importe quelle fenêtre signifie que tout le système est non fiable : les binaires, cron, les bibliothèques, et les outils avec lesquels vous l'inspecteriez. Supprimer le compte et appliquer les correctifs vous laisse faire confiance à une machine que vous ne pouvez plus vérifier. Reconstruisez depuis un point de restauration antérieur à la compromission, changez les identifiants, et vérifiez à nouveau.
Le compte de la porte dérobée paraît inactif. Est-ce toujours un problème ?+
Oui. Un compte UID 0 dormant ou verrouillé reste un compte à privilèges complets que quelqu'un a implanté. Sa présence est la compromission, pas une quelconque connexion. Une mise à jour automatique ou un changement de configuration peut désactiver une porte dérobée par accident sans supprimer la brèche sous-jacente. Prenez la présence, pas l'activité, comme déclencheur.
Un compte root que vous ne pouvez pas expliquer ?
Si vous avez trouvé un compte UID 0 sans trace de création, ou si vous n'êtes pas sûr que votre dernier point de restauration propre soit antérieur au problème, ne le nettoyez pas sur place. Parlez à un ingénieur qui reconstituera la chronologie à partir des sources indirectes et reconstruira depuis un point dont vous pouvez prouver qu'il était propre.
Parler à un ingénieurVous êtes arrivé à la fin.
Mettez la lecture en pratique
Que faites-vous tourner ?
Parlez-nous de la charge de travail, du trafic et des exigences de reprise. Commencez par le configurateur de serveur, ou passez en revue les détails avec un ingénieur.
Écrit par les ingénieurs qui construisent et exploitent l'infrastructure qu'il décrit.Parler à un ingénieur