Le lundi 4 mai 2020, l’équipe Wordfence Threat Intelligence a découvert deux vulnérabilités présentes dans Générateur de pages par SiteOrigin, un plugin WordPress installé activement sur plus de 1 000 000 de sites. Ces deux failles permettent aux attaquants de forger des requêtes au nom d’un administrateur de site et d’exécuter du code malveillant dans le navigateur de l’administrateur. L’attaquant doit inciter un administrateur de site à exécuter une action, comme cliquer sur un lien ou une pièce jointe, pour que l’attaque réussisse.
Nous avons d’abord contacté le développeur du plugin le 4 mai 2020. Après avoir établi un canal de communication approprié, nous avons fourni la divulgation complète plus tard dans la journée. Le développeur a rapidement publié un patch le lendemain, soit le 5 mai 2020.
Ces problèmes sont considérés comme des problèmes de sécurité à haut risque pouvant conduire à une prise de contrôle complète du site. Nous recommandons une mise à jour immédiate de Page Builder by SiteOrigin vers la dernière version disponible. Au moment de la rédaction, c’est version 2.10.16.
Les versions gratuite et Premium du pare-feu Wordfence protègent contre ces vulnérabilités via la protection intégrée XSS (Cross Site Scripting) du pare-feu Wordfence.
Page Builder by SiteOrigin est un plugin qui simplifie la modification des pages et des publications dans WordPress. Les utilisateurs peuvent créer du «contenu réactif basé sur des colonnes» en utilisant à la fois des widgets de WordPress et des widgets du plugin SiteOrigin Widgets Bundle.
Le plugin a un éditeur en direct intégré afin que les utilisateurs puissent mettre à jour le contenu et faire glisser / déposer des widgets tout en observant les modifications apportées en temps réel. Cela rend l’édition et la conception d’une page ou la publication d’un processus beaucoup plus fluide.
Une vue de la fonction de l’éditeur en direct de Page Builder by SiteOrigin.
Afin d’afficher les modifications en temps réel via l’éditeur en direct, le plugin enregistre le is_live_editor() pour vérifier si un utilisateur est dans l’éditeur en direct.
static function is_live_editor(){
return ! empty( $_GET['siteorigin_panels_live_editor'] );
}
Si l’utilisateur est dans l’éditeur en direct, le siteorigin_panels_live_editor sera défini sur « true » et enregistrera qu’un utilisateur accède à l’éditeur en direct. Le plugin tentera alors d’inclure le fichier de l’éditeur en direct qui restitue tout le contenu.
// Include the live editor file if we're in live editor mode.
if ( self::is_live_editor() ) {
SiteOrigin_Panels_Live_Editor::single();
}
Toutes les modifications de contenu apportées sont définies et envoyées en tant que paramètre $ _POST: live_editor_panels_data. Ce paramètre contient tout le contenu qui a été modifié par l’utilisateur et est requis pour afficher un aperçu en direct des modifications.
Une fois la modification effectuée, le fichier live-editor-preview.php est utilisé pour restituer le contenu fourni par le live_editor_panels_data et mettre à jour l’aperçu de la page en affichant les modifications apportées en temps réel.
> >process_raw_widgets( $data['widgets'], false, false ); } echo siteorigin_panels_render( 'l' . md5( serialize( $data ) ), true, $data); } ?>
Alors que des vérifications de capacité étaient post_metadata pour garantir qu’un utilisateur accédant à l’éditeur en direct était autorisé à modifier les publications, il n’y avait pas de protection nonce pour vérifier qu’une tentative de rendu de contenu dans l’éditeur en direct provenait d’une source légitime.
function post_metadata( $value, $post_id, $meta_key ) {
if (
$meta_key == 'panels_data' &&
current_user_can( 'edit_post', $post_id ) &&
! empty( $_POST['live_editor_panels_data'] ) &&
$_POST['live_editor_post_ID'] == $post_id
) {
$value = array( json_decode( wp_unslash( $_POST['live_editor_panels_data'] ), true ) );
}
return $value;
}
Dans le cadre de cet exploit, certains des widgets disponibles, tels que le widget «HTML personnalisé», pourraient être utilisés pour injecter du JavaScript malveillant dans une page en direct rendue. Si un administrateur du site était amené à accéder à une page d’aperçu en direct conçue, tout Javascript malveillant inclus dans le widget «HTML personnalisé» pourrait être exécuté dans le navigateur. Les données associées à un aperçu en direct n’ont jamais été stockées dans la base de données, ce qui entraîne une faille XSS réfléchie plutôt qu’une faille XSS stockée, conjointement avec la faille CSRF.
Cette faille peut être utilisée pour rediriger l’administrateur d’un site, créer un nouveau compte d’utilisateur administratif ou, comme on l’a vu dans la récente campagne d’attaque ciblant les vulnérabilités XSS, être utilisé pour injecter une porte dérobée sur un site.
Nous avons découvert une faille supplémentaire de falsification de requête intersite dans le action_builder_content fonction du plugin. C’était lié à l’action AJAX wp_ajax_so_panels_builder_content.
add_action( 'wp_ajax_so_panels_builder_content', array( $this, 'action_builder_content' ) );
Le but de cette fonction était de transmettre le contenu soumis en tant que panels_data de l’éditeur en direct à l’éditeur WordPress afin de mettre à jour ou de publier la publication en utilisant le contenu créé à partir de l’éditeur en direct. Cette fonction avait une vérification des autorisations pour vérifier qu’un utilisateur avait la possibilité de modifier les messages pour la donnée post_id. Cependant, il n’y avait pas de protection nonce pour vérifier la source d’une demande, provoquant la faille CSRF.
/**
* Get builder content based on the submitted panels_data.
*/
function action_builder_content() {
header( 'content-type: text/html' );
if ( ! current_user_can( 'edit_post', $_POST['post_id'] ) ) {
wp_die();
}
Dans le cadre du processus, le contenu du panels_data La fonction a été délibérément récupérée afin de pouvoir être répercutée sur la page.
if ( empty( $_POST['post_id'] ) || empty( $_POST['panels_data'] ) ) {
echo '';
wp_die();
}
// echo the content
$old_panels_data = get_post_meta( $_POST['post_id'], 'panels_data', true );
$panels_data = json_decode( wp_unslash( $_POST['panels_data'] ), true );
$panels_data['widgets'] = $this->process_raw_widgets(
$panels_data['widgets'],
! empty( $old_panels_data['widgets'] ) ? $old_panels_data['widgets'] : false,
false
);
$panels_data = SiteOrigin_Panels_Styles_Admin::single()->sanitize_all( $panels_data );
Avec cette fonction, le widget «HTML personnalisé» n’a pas créé de faille XSS de la même manière que la vulnérabilité précédente en raison de certaines fonctionnalités de nettoyage. Cependant, nous avons découvert que le widget «Texte» pouvait être utilisé pour injecter du JavaScript malveillant en raison de la possibilité de modifier le contenu en mode «texte» plutôt qu’en mode «visuel». Cela a permis d’envoyer du JavaScript potentiellement malveillant sans filtrage. En raison de l’écho des données des widgets, tout code malveillant faisant partie des données des widgets de texte pouvait alors être exécuté dans le cadre d’une attaque combinée CSRF vers XSS dans le navigateur d’une victime.
Comme pour la vulnérabilité CSRF vers Reflected XSS mentionnée précédemment, celle-ci pourrait finalement être utilisée pour rediriger l’administrateur d’un site, créer un nouveau compte utilisateur administratif ou, comme on l’a vu dans la récente campagne d’attaque ciblant les vulnérabilités XSS, être utilisé pour injecter une porte dérobée sur un site.
4 mai 2020 – Découverte initiale et analyse des vulnérabilités. Nous vérifions que la règle de pare-feu XSS intégrée à Wordfence offre une protection suffisante. Premier contact avec l’équipe du plugin.
4 mai 2020 – Le développeur du plugin confirme le canal approprié et nous fournissons une divulgation complète.
5 mai 2020 – Le développeur reconnaît les vulnérabilités et conseille de publier un correctif plus tard dans la journée.
5 mai 2020 – Un correctif suffisant est publié.
Dans l’article d’aujourd’hui, nous avons détaillé deux failles présentes dans le plugin Page Builder by SiteOrigin qui permettaient aux attaquants de forger des requêtes au nom d’un administrateur de site et d’exécuter du code malveillant dans le navigateur de cet administrateur. Ces failles ont été entièrement corrigées dans la version 2.10.16. Nous recommandons aux utilisateurs de mettre immédiatement à jour la dernière version disponible.
Sites en cours d’exécution Wordfence Premium, ainsi que les sites utilisant la version gratuite de Wordfence, sont protégés contre les attaques Cross-Site Scripting contre cette vulnérabilité en raison de la protection intégrée du pare-feu Wordfence. Si vous connaissez un ami ou un collègue qui utilise ce plugin sur leur site, nous vous recommandons fortement de leur transmettre cet avis afin de les protéger.
Un merci spécial à Greg Priday, le développeur du plugin, pour une réponse extrêmement rapide et pour avoir publié un patch très rapidement.
Source link