Forum Linux.général Effacement de tous les fichiers d'un utilisateur

Posté par  . Licence CC By‑SA.
Étiquettes :
3
23
oct.
2017

Bonjour les amis,

J'ai un souci bien ennuyeux : durant le week-end, sur une machine du bureau, tous les fichiers d'un utilisateur ont été effacés :
- le répertoire de l'utilisateur était toujours présent, mais vide
- des fichiers de cet utilisateur qui se trouvaient ailleurs que sous /home (sous /var/www) ont disparu
- les fichiers qui se trouvaient sur un disque externe monté par cet utilisateur ont aussi disparu
- seuls ont survécu des fichiers de cet utilisateur qui se trouvaient sous /var/www/ et étaient en lecture seule.

Quelques précisions :
- personne n'a eu physiquement accès à l'ordinateur ce week-end
- il y a un serveur ssh, mais les logs dans /var/log/auth.log ne font pas état d'une connexion réussie ce week end (mais n'ayant pas l'habitude de fouiller dans les logs, il n'est pas exclu que quelque chose m'ait échappé).
- la commande history ne donne rien, puique le fichier d'historique a également disparu.
- le système est un linux mint 18.1 Serena (basé sur Ubuntu)
- Il s'agit de l'utilisateur principal, donc son mot de passe permet d'accéder à root. Toutefois, aucun fichier appartenant à root ne semble avoir été affecté.
- le répertoire /home est dans la même partition que /

J'avais heureusement une sauvegarde, mais j'aimerais comprendre ce qu'il s'est passé.
Je suppose que pour réussir cet exploit, il faut être loggé sous cet utilisateur et lancer une commande rm etc.. à la racine. Mais je ne vois pas comment celà a pu se produire.
Si vous aviez une piste pouvant m'aidez à cerner le litige, un log à consulter que je ne connaitrais pas, une expérience similaire, …

À bientôt

Pierre

  • # crontab

    Posté par  (site web personnel) . Évalué à 4.

    Regarde si l'utilisateur en question n'a pas une crontab qui a pu exécuter un script buggé pendant le WE (crontab -l).

    Un classique est d'écrire quelque chose comme

    rm -fr $VAR1/$VAR2

    avec $VAR1 et $VAR2 indéfinies.

    • [^] # Re: crontab

      Posté par  . Évalué à 1.

      Merci Matthieu
      J'ai effectivement des scripts lancés par crontab :
      1)
      find /tmp/ -maxdepth 1 -name "cookie*" -mtime +1 -delete

      Celui-ci efface les fichiers cookie* qui s'accumulent dans /tmp donc à priori pas de souci.

      2)
      find $ARCHIVES -xdev -name "*.bak" -mtime +365 -delete

      Même style. En cas de loupé sur la variable $ARCHIVES (qui indique le chemin d'un répertoire de sauvegarde), ce ne sont de toutes façons que les fichiers *.bak qui sont effacés.

      C'est vraiment un mystère cette histoire. Le système de fichier est ext4. Ça ne me paraît pas possible, mais est qu'un problème matériel pourrait causer la disparition de tous les fichiers d'un seul utilisateur ?

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 2.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: crontab

          Posté par  . Évalué à 1.

          Il y a bien un serveur web basique : apache2 et des pages web-php servant à consulter une base MySQL. Comment est il possible d'effacer des fichiers du /home par ce biais là ?

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 2.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: crontab

              Posté par  (site web personnel) . Évalué à 4.

              En principe le PHP est servi avec un utilisateur non-privilégié (genre www-data), donc une faille dans le code PHP ne permet de supprimer que les fichiers de cet utilisateur. @harlock974: tu peux vérifier si c'est bien le cas sur ton installation (et si cet utilisateur est bien différent de celui qui a perdu ses fichiers).

              Après, il peut y avoir autre chose qui permet à l'attaquant de passer de l'utilisateur sous lequel tourne apache à celui dont les fichiers sont perdus, mais c'est peu probable que ça se soit fait sans passer root entre temps (donc c'est presque suspect qu'il n'y ait pas plus de dégâts).

              • [^] # apache

                Posté par  . Évalué à 4. Dernière modification le 24 octobre 2017 à 11:37.

                L'après-midi où les fichiers ont disparu, j'ai eu une tentative d'attaque :

                /var/log/apache2/access.log :

    27.255.65.171 - - [20/Oct/2017:12:11:47 +0400] "POST //%63%67%69%2D%62%69%6E/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E HTTP/1.1" 401 697 "-" "-"

                Ce qui, traduit en bon latin, donne :

                    cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 -d auto_prepend_file=php://input -n

                D'après des infos équivalente sur le ouèbe, cette attaque permet de télécharger et d'exécuter un script qui va miner des bitcoins. Si je regarde mon error.log à la même heure, j'ai :

                    [Fri Oct 20 12:11:48.274578 2017] [access_compat:error] [pid 27640] [client 27.255.65.171:46553] AH01797: client denied by server configuration: /var/www/cgi-bin

                L'attaque aurait-elle échoué ? Ce serait intéressant de télécharger le script manuellement pour voir ce qu'il y a dedans, mais je ne vois pas comment reconstituer l'url de téléchargement à partir de la commande php ci-dessus. Quelqu'un à une idée ?

      • [^] # Re: crontab

        Posté par  . Évalué à 1.

        Si la variable $ARCHIVES n'est pas vérifiée avant la commande "find", je pense qu'en cas de loupé "mal intentionné" (de type injection de commandes dans la variable $ARCHIVES), cette tâche cron pourrait faire autre chose que d'effacer des fichiers .BAK.

        • [^] # Re: crontab

          Posté par  . Évalué à 1.

          Si la variable $ARCHIVES n'est pas vérifiée avant la commande "find", je pense qu'en cas de loupé "mal intentionné" (de type injection de commandes dans la variable $ARCHIVES), cette tâche cron pourrait faire autre chose que d'effacer des fichiers .BAK.

          En effet. Ceci dit $ARCHIVES est déclaré de façon statique en début du script, du style $ARCHIVES = /mnt/sauvegarde/… Donc si quelqu'un peut modifier le scripts, c'est qu'il a déjà accès au système.

  • # Bug similaire sur Xubuntu

    Posté par  . Évalué à 1. Dernière modification le 23 octobre 2017 à 22:07.

    J'ai eu le même bug (suppression de tout les fichiers dans le home de l'user principal) sur une Xubuntu 16.04.03 sur SSD il y a quelques mois.
    Hélas, aucune idée du pourquoi du comment par contre.

    Si vous codez un logiciel sans une interface chatoyante, alors vous faites de la merde. Donation bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

  • # logs

    Posté par  (site web personnel) . Évalué à 1.

    Je n'ai pas de réponse, mais peut être quelques idées de recherches:
    * Est-ce que tu as quelque-chose dans ~/.bash_history (si il n'a pas disparu lui aussi…), ou dans /root/.bash_history?
    * Est ce que le dossier personnel est sur une partition séparée du système? La partition est saine?
    * Tu peux voir la date des derniers changements effectués sur /home/user avec la commande ls -l, pouvant te donner une idée de l'heure à laquelle s'est produit le problème

    Un LUG en Lorraine : https://enunclic-cappel.fr

    • [^] # Re: logs

      Posté par  . Évalué à 1.

      L'historique du user a disparu avec le reste des fichiers, et rien d'anormal dans celui du root.
      Le dossier personnel est sur la même partition que le système.

      L'heure du problème a pu être cerné grâce à /var/log/syslog :

      à 12h30 un scripts situé dans le /home/user est lancé sans erreur par CRON.
      à partir de 13h23 j'ai des messages de pulseaudio et de rtkit-daemon qui ont l'air de mouliner dans la choucroute :

      Oct 20 13:23:49 Serveur01 pulseaudio[30315]: [pulseaudio] shm.c: shm_unlink(/pulse-shm-3311755292) failed: No such file or directory
      Oct 20 13:23:49 Serveur01 pulseaudio[30315]: [pulseaudio] shm.c: shm_unlink(/pulse-shm-975947294) failed: No such file or directory
      Oct 20 13:23:50 Serveur01 rtkit-daemon[2176]: Successfully made thread 30929 of process 30929 (n/a) owned by '1000' high priority at nice level -11.
      Oct 20 13:23:50 Serveur01 rtkit-daemon[2176]: Supervising 1 threads of 1 processes of 1 users.
      Oct 20 13:23:50 Serveur01 rtkit-daemon[2176]: Supervising 1 threads of 1 processes of 1 users.
      Oct 20 13:23:50 Serveur01 rtkit-daemon[2176]: Successfully made thread 30930 of process 30929 (n/a) owned by '1000' RT at priority 5.
      Oct 20 13:23:50 Serveur01 rtkit-daemon[2176]: Supervising 2 threads of 1 processes of 1 users.
      Oct 20 13:23:50 Serveur01 rtkit-daemon[2176]: Supervising 2 threads of 1 processes of 1 users.
      Oct 20 13:23:50 Serveur01 rtkit-daemon[2176]: Successfully made thread 30931 of process 30929 (n/a) owned by '1000' RT at priority 5.
      Oct 20 13:23:50 Serveur01 rtkit-daemon[2176]: Supervising 3 threads of 1 processes of 1 users.
      Oct 20 13:23:51 Serveur01 pulseaudio[30929]: [pulseaudio] authkey.c: Failed to open cookie file '/home/tom/.config/pulse/cookie': No such file or directory
      Oct 20 13:23:51 Serveur01 pulseaudio[30929]: [pulseaudio] authkey.c: Failed to load authentication key '/home/tom/.config/pulse/cookie': No such file or directory
      Oct 20 13:23:51 Serveur01 pulseaudio[30929]: [pulseaudio] authkey.c: Failed to open cookie file '/home/tom/.pulse-cookie': No such file or directory
      Oct 20 13:23:51 Serveur01 pulseaudio[30929]: [pulseaudio] authkey.c: Failed to load authentication key '/home/tom/.pulse-cookie': No such file or directory
      Oct 20 13:23:51 Serveur01 pulseaudio[30929]: [pulseaudio] backend-ofono.c: Failed to register as a handsfree audio agent with ofono: org.freedesktop.DBus.Error.ServiceUnknown: The name org.ofono was not provided by any .service files

      Et ça se poursuit comme ça sur des dizaines de lignes, à la même heure. Je ne sais pas ce qu'est rtkit-daemon.

  • # rm avec noms de fichiers corrompus ???

    Posté par  . Évalué à 3.

    Je continue à enquêter sur le problème, et j'ai pu déterminer à 10 mn près l'heure d'effacement des fichiers. Il apparaît que le dernier être humain à avoir eu accès à l'ordinateur, environ 15 mn avant l'incident, a fait l'action suivante : il a connecté une carte SD pour copier quelques fichiers qui s'y trouvaient, avec le navigateur de fichier Caja (de Mate). il a ensuite demandé le démontage de la carte, et Caja a proposé d'effacer les fichiers de la corbeille de la carte, ce que l'opérateur a accepté. Puis la carte a été retirée.
    Cette carte équipe un terminal de terrain, où le constructeur a eu la bonne idée d'utiliser une sorte de Windows embarqué. En vérifiant le contenu de cette carte, il s'est avéré que le système de fichier FAT était corrompu, que que le répertoire corbeille contenait plusieurs fichiers dont les noms incluaient des caractères non ascii et des caractères de contrôle. Le syslog affichait d'ailleurs les erreurs suivantes au branchement de la carte :

    Oct 20 12:00:24 Serveur01 kernel: [4409259.900670] FAT-fs (sde1): error, invalid access to FAT (entry 0x0000f92a)
    Oct 20 12:00:24 Serveur01 kernel: [4409259.900718] FAT-fs (sde1): error, fat_get_cluster: invalid cluster chain (i_pos 0)
    Oct 20 12:00:25 Serveur01 kernel: [4409260.803446] VFS: Lookup of '[02][0E][03][13][03]*[03]A[03]' in vfat sde1 would have caused loop

    En la formatant avec cfdisk, la carte a d'ailleurs pourri la console avec des caractères bizarres, et ce même après que la commande soit terminée (un peu lorsque l'on cat un fichier binaire).

    Bien que cela paraisse un manque de chance incroyable, serait il possible que Caja, en voulant effacer la corbeille, ait lancé l'équivalent d'un rm -rf sur un fichier commençant par les caractères '\' et 0x0A (saut de ligne) ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.