Accueil > 1- Blog-Notes > A la maison > Histoire d’un piratage

Histoire d’un piratage

dimanche 14 juillet 2019, par Olivier Duquesne aka DaffyDuke

Ce matin, au réveil, après avoir passé une soirée de remise en route de la messagerie sur mon Kimsufi, quelle ne fut pas ma surprise avec le mail suivant :

Waw ! stupeur. D’abord, première réaction : "punaise, ils sont de mieux en mieux faits les spams de nos jours !" Je regarde l’en-tête, tout ce qui a l’air de plus légal. Alors, regardons ça de plus près. postgres, c’est probablement l’utilisateur de postgresql, je ne me souviens pas trop à quoi il sert mais en effet, ça fait un moment que mon outil de vérification des services cassés me le signale, je le redémarre quand j’y pense. Clairement, ce .satan semble très étrange mais rkhunter ne s’est pas plaint. lynis non plus. Poursuivons.

Analyses

Mon moteur de recherche préféré signale quelqu’un ayant eu une attaque similaire : https://social.imirhil.fr/@aeris/101864561434132681
Moi aussi, je découvre ce `.firefoxcatche`. Je découvre aussi un répertoire `.ssh` à côté. Bizarre, je ne me souviens pas de ça. Et là, j’épluche les logs. C’est là que snoopy va m’aider.

Ha ! Là, c’est clair. Mais alors, que fait mon google-authenticator ? Il m’a bien demandé un code pour ma propre connexion. J’essaye sur postgres. Stuper, le login se fait sans authentification ni mot de passe ni clé. OK, la machine est compromise.

Réfléchissions, si je me fais voir, il va prendre peur et peut-être tout casser. Je continue à analyser sans rien couper.

OK, dans les logs, je vois des accès de cron :

je vois aussi des accès à systemd, mais difficile de savoir de quoi il s’agit. Ca tombe pile pendant une opération de maintenance de ma part.

J’ai encore un peu de mal à savoir si c’est "lui" ou "moi". Si c’est l’autre, c’est uid:0 donc root, donc c’est vraiment grave. Le stress monte.

En effet, il y a quelque chose en cron :

Comprendre. Ce n’est pas moi sur ce créneau horaire, ça colle avec les logs, il ne faut pas rebooter, il y a d’autres répertoires pourris : /tmp/.X15-unix .
Là dedans, je trouve un tar.gz, un script rsync, des binaires comme ps ou kill.

OK, ça doit expliquer pourquoi je ne vois pas, ça a été remplacé ?
Un ps me montre que le process rsync tourne et c’est tout, rien à côté. Ce n’est donc pas le rsync que je connais. J’en profite pour réinstaller procutils après avoir vérifié que :
- la conf apt n’a pas été altérée récemment
- aucun fichier de configuration ne semble avoir été modifié récemment de façon illégitime. Mais c’est difficile à dire. le git log et les diff de toutes parts montrent bien qu’entre le premier login anormal distant et maintenant des tas de fichiers ont été modifiés. Normal, il y a eu une mise à jour de la Debian, une mise à jour majeur de Yunohost et surtout la migration de la configuration ssh de root vers admin.

Je trouve curieux que postgre ait un shell valide, je pop vite fait une debian pour y mettre un postgresql-server, pareil. Et l’utilisateur n’a a priori pas de mot de passe. Pareil donc, la faille ne vient pas de là, pas encore.

Je ne retrouve pas la clé SSH chez moi, les IP viennent de l’Equateur et de l’Inde.

Je ne retrouve pas de configuration systemd.

Les logs laissent penser que ce n’est pas un humain par leur quantité sur le temps imparti et les commandes exécutées.

Mais là ça devient intéressant :

Je vous le décode pour vous :

Je fais le curl au même endroit, ça pourra aider pour la suite.

Le .rsync est fait un script perl en base64 qui écoute en https.

Remédiation

J’oubliais de préciser. Entre temps, la mise à jour de procps a vraiment fait monter en I/O le serveur, l’accès SSH semble cassé.

Via l’interface web de Yunohost, j’arrête SSH purement est simplement. J’ai alors des alertes systèmes et d’indispo de la part du monitoring OVH, je prends peut, j’avoue, et je démarre la machine en mode rescue.

A supposer que des mots de passe soient compromis, je récupère les accès modifie les mots de passe de messagerie et supprime les mails reçus qui indiqueraient à l’attaquant comment accéder au mode rescue. Après, ça n’eclue rien , mais je me félicite d’y avoir pensé sur le moment.

Je prends le temps d’analyser le contenu du data2.tar.gz

C’est un truc de script kiddie.

La chaîne du .rsync se retrouve sur un site de machines compromises (la mienne n’y est pas encore) : http://threatwar.com/ssh/commands

Des gros finds sur l’uid 127 ne semblent pas confirmer la présence d’autres fichiers.

Je me contente de supprimer les répertoires critiques dans /var/lib/postgresql, dans /var/tmp, dans /tmp. Je dégage la cron. J’en profite pour n’autoriser qu’un seul utilisateur dans la configuration sshd.

Et je reboot.

Une fois online, je modifie le mot de passe de postgres (vu qu’on voit bien qu’il a été modifié dans les logs de snoopy), j’éteins postgresql, je désactive le compte.

Post analyses

Déjà, pas de nouvelles tentatives dans les logs d’authentification.

fail2ban a bien fait son travail mais vu qu’il n’y a pas assez de tentatives .... J’en conclue que la faille devait être connue sur un mot de passe postgresql faibles sur debian (avec yunohost ?).

Tous les services ont un comportement normal, les données n’ont pas été altérées. Volées ? Difficile à dire.

La lecture du data2.tar.gz est décidément instructif.

Je regarde ce qu’il y a dans cette instance postgresql. Conclusion, ce serveur ne sert plus rien. Pas de bases de données, aucune application ne semble y accéder, à l’inverse toutes les applications semblent trouver leur bases dans le mariadb à côté.

Je supprime donc toute trace de postgresql : packages et user.

Et j’observe. régulièrement. lnav en permanence.

Conclusion

OK, cette machine n’est pas forcément une crème de la sécurité mais si on se dit que
- l’OS est globalement à jour à la semaine près, tous les paquets debian aus
- nombre des recommandations de lynis ont été appliquées (sshd, nginx, ....)
- lynis, rkhunter, fail2ban sont installés
- iptables est configuré et démarré et n’autorise que les ports légitimes
- il y a une double authentification sur l’accès SSH

et pourtant la machine a été compromise ! et grossièrement !
Cela signifie peut-être qu’il y a autre chose, certes. Je n’ai pas encore pris le temps pour cela. Mais cela signifie surtout qu’il faut toujours rester vigilant.

Annexes

Le code est ici
https://www.hybrid-analysis.com/sam...

http://54.37.70.249/dota2.tar.gz

Les IP sources :