Vulnérabilité dans WooCommerce 2.3.10 : Object Injection

WooCommerce 2.3.10

Hier, le 10 juin 2015, WooCommerce a été patché d’une faille de sécurité nommée “Object Injection“.

Cette faille déjà rencontrée sous WordPress < 3.6.1 est ici à risque très élevé, contrairement à WP pour laquelle le risque était quasi nul.

Le risque ne dépends pas de la faille en elle même, mais de plusieurs critères évalué et calculés selon le modèle DREAD qui signifie :

• Damage (dégâts),
• Reproducibility (reproductibilité),
• Exploitability (exploitation),
• Affected users (utilisateurs affectés),
• Discoverability (découverte).

Si cette faille a un risque très élevé, c’est par ce que son DREAD score est élevé (8/10). En effet, il est facile de trouver et reproduire cet exploit sur n’importe quelle installation WordPress contenant WooCommerce < 2.3.11.

Cependant, il arrive que certains sites ne puissent pas mettre à jour ce plugin pour des raisons de maintenabilités. Pourtant, il est très très très important de patcher cette vulnérabilité.

Alors que faire si on ne peut pas mettre à jour WooCommerce mais qu’on souhaite tout de même être sécurisé de cette faille.

SecuPress vous propose un mu-plugin, ce fichier se dépose simplement dans le dossier “wp-content/mu-plugins“, créez le s’il n’existe pas.

Ce fichier sera automatiquement inclus par WordPress avant les plugins.

<?php
/*
Plugin Name: Patch WooCommerce 2.3.10 -> 2.3.11 - Object Inhection Vulnerability
Author: SecuPress
*/
add_action( 'plugins_loaded', 'patch_woocommerce_2310', 1 );
function patch_woocommerce_2310() {
	if ( isset( $_REQUEST['cm'] ) ) {
		$raw_custom = $_REQUEST['cm'];
		$custom = sanitize_text_field( stripslashes( $_REQUEST['cm'] ) );
		if ( ( false === ( $custom = json_decode( $raw_custom ) ) ) || ! is_object( $custom ) &&
			! preg_match( '/^a:2:{/', $raw_custom ) || preg_match( '/[CO]:\+?[0-9]+:"/', $raw_custom ) || 
			( false === $custom = maybe_unserialize( $raw_custom ) ) 
		) {
			$_REQUEST['cm'] = 'a:2:{i:0;i:0;i:1;i:0;}';
		} 
	} 
}

Le code et la faille, en quelques mots

Le soucis vient du paramètre cm venant d’un utilisateur via $_REQUEST sera unserialized, et quand on unserialise un objet, on l’instancie.

Si l’utilisateur parvient à passer un objet serialisé malicieux, alors il sera instancié. Bien sûr il faut que la classe de cet instanciation soit présente sur le site.

Néanmoins il a été possible de réaliser l’exploit de télécharger le fichier wp-config.php via cette faille, je pense que cela a ajouté du poids dans le DREAD score.

Dans mon code, je vérifie que ce que je vais unserialize est du JSON ou alors un tableau et surtout pas un objet. Si je trouve ça, alors je force un tableau contenant un double zéro afin que la suite soit gentiment cassée.

À propos de Julio Potier Tous les articles de Julio Potier

Créateur de SecuPress et de la Formation LearnWPSecurity, Julio est aussi organisateur du WordCamp Lille.
Orateur compulsif, formateur sénior et ingénieur WordPress, il s’est spécialisé dans la sécurité depuis 2002 et contribue à WordPress sous diverses formes.