Le 22 décembre 2020, notre équipe Threat Intelligence a révélé de manière responsable une vulnérabilité dans Facebook pour WordPress, anciennement connu sous le nom de Official Facebook Pixel, un plugin WordPress installé sur plus de 500 000 sites. Cette faille a permis à des attaquants non authentifiés ayant accès aux sels et clés secrets d’un site de réaliser l’exécution de code à distance grâce à une faiblesse de désérialisation.

De plus, le 27 janvier 2021, nous avons divulgué une vulnérabilité identifiée séparément dans Facebook pour WordPress qui a été introduite lors du changement de marque du plugin dans la version 3.0.0. Cette faille permettait aux attaquants d’injecter du JavaScript malveillant dans les paramètres du plugin, si un attaquant pouvait réussir à tromper un administrateur pour qu’il exécute une action telle que cliquer sur un lien.

Nous avons initialement contacté l’équipe de sécurité de Facebook le 22 décembre 2020 pour la première vulnérabilité et avons inclus tous les détails de la divulgation au moment de la communication. Ils ont initialement répondu le 25 décembre 2020 pour demander des informations complémentaires qui ont été fournies le 26 décembre 2020. Un correctif a été publié le 6 janvier 2021.

Pour la deuxième vulnérabilité, nous avons de nouveau contacté l’équipe de sécurité de Facebook le 27 janvier 2021 et avons inclus tous les détails de la divulgation au moment de la communication. Ils ont initialement répondu le 1er février 2021 pour demander des informations complémentaires qui ont été fournies le même jour. Un correctif initial a été publié le 12 février 2021 et un correctif pleinement suffisant a été publié le 17 février 2021.

Celles-ci sont considérées comme des vulnérabilités de gravité élevée et critique. Par conséquent, nous vous recommandons fortement de mettre à jour immédiatement vers la dernière version disponible contenant les deux correctifs, 3.0.5.

Les utilisateurs de Wordfence Premium ont reçu une règle de pare-feu pour protéger les tentatives d’exploitation contre la première vulnérabilité le 22 décembre 2020 et ont reçu une règle de pare-feu pour protéger les tentatives d’exploitation contre la deuxième vulnérabilité le 27 janvier 2021. Les sites utilisant toujours la version gratuite de Wordfence ont reçu la même chose protection pour la première vulnérabilité le 21 janvier 2020 et le 26 février 2021 pour la deuxième vulnérabilité.

Injection d’objets PHP

Description: Injection d’objets PHP avec chaîne POP
Plugin concerné: Facebook pour WordPress, anciennement connu sous le nom de Pixel Facebook officiel
Plugin Slug: officiel-facebook-pixel
Versions concernées:
ID CVE: En attente.
Score CVSS: 9.0 (CRITIQUE)
Vecteur CVSS: CVSS: 3.1 / AV: N / AC: H / PR: N / UI: N / S: C / C: H / I: H / A: H
Version entièrement corrigée: 3.0.0

Facebook pour WordPress est un plugin conçu pour créer une intégration transparente entre Facebook Pixel, un outil de mesure de conversion, et un site WordPress. Le plugin surveillera le trafic du site et enregistrera des données lorsque les utilisateurs accèdent aux pages et effectuent certaines actions sur un site.

Le plugin a enregistré un admin_post action, admin_post_wp_async_send_server_event, afin que les événements ViewContent et AddToCart soient déclenchés en même temps lorsque les clients WooCommerce ajoutent des produits à leur panier.

public function __construct( $auth_level = self::BOTH ) {
   if ( empty( $this->action ) ) {
      throw new Exception( 'Action not defined for class ' . __CLASS__ );
   }
   add_action( $this->action, array( $this, 'launch' ), (int) $this->priority, (int) $this->argument_count );
   if ( $auth_level & self::LOGGED_IN ) {
      add_action( "admin_post_wp_async_$this->action", array( $this, 'handle_postback' ) );
   }
   if ( $auth_level & self::LOGGED_OUT ) {
      add_action( "admin_post_nopriv_wp_async_$this->action", array( $this, 'handle_postback' ) );
   }
}</pre>
<pre>

Cette action était liée à la handle_postback fonction qui a finalement vérifié un nonce valide et a déclenché le run_action() fonction lorsqu’un nonce valide a été fourni.

public function handle_postback() {
   if ( isset( $_POST['_nonce'] ) && $this->verify_async_nonce( $_POST['_nonce'] ) ) {
      if ( ! is_user_logged_in() ) {
         $this->action = "nopriv_$this->action";
      }
      $this->run_action();
   }

   add_filter( 'wp_die_handler', function() { die(); } );
   wp_die();
}</pre>
<pre>

En raison de handle_postback fonction nécessitant un nonce valide, un attaquant aurait besoin d’un nonce valide afin d’exploiter cette vulnérabilité. Le nonce généré n’utilisait pas de données utilisateur normales lors de la création d’un nonce, rendant le nonce sans rapport avec aucune session utilisateur. Nous avons découvert que ce nonce pouvait facilement être généré avec un script personnalisé. Cela exigeait qu’un attaquant accède au sel et à la clé nonce du site via une vulnérabilité d’injection SQL, une vulnérabilité de traversée de répertoire ou une sauvegarde accessible au public du wp-config.php déposer.

Le cœur de la vulnérabilité d’injection d’objets PHP se trouvait dans le run_action() fonction. Cette fonction était destinée à désérialiser les données utilisateur du event_data POST variable afin qu’il puisse envoyer les données à la console de pixel. Malheureusement, ce event_data pourrait être fourni par un utilisateur. Lorsque l’entrée fournie par l’utilisateur est désérialisée en PHP, les utilisateurs peuvent fournir des objets PHP qui peuvent déclencher des méthodes magiques et exécuter des actions pouvant être utilisées à des fins malveillantes.

protected function run_action() {
  try {
    $num_events = $_POST['num_events'];
    if( $num_events == 0 ){
      return;
    }
    $events = unserialize(base64_decode($_POST['event_data']));
    // When an array has just one object, the deserialization process
    // returns just the object
    // and we want an array
    if( $num_events == 1 ){
      $events = array( $events );
    }

    FacebookServerSideEvent::send($events);
  }</pre>
<pre>

À elle seule, une vulnérabilité de désérialisation est relativement inoffensive, cependant, lorsqu’elle est combinée avec un gadget ou une méthode magique, des dommages importants peuvent être causés à un site. Dans ce cas, nous avons trouvé une méthode magique dans le plugin qui pourrait être utilisée pour télécharger des fichiers arbitraires et réaliser l’exécution de code à distance sur une cible vulnérable.

La chaîne POP complète

Le plugin Facebook pour WordPress utilise Guzzle, un client HTTP PHP, qui a le __destruct méthode magique utilisée dans la classe FileCookieJar. Cette méthode enregistre un fichier lors de l’arrêt pour stocker les cookies de session. Cela signifiait qu’une charge utile correctement construite qui appelle la classe FileCookieJar pouvait permettre à un attaquant de créer un fichier.

<?php
namespace GuzzleHttpCookie;

/**
 * Persists non-session cookies using a JSON formatted file
 */
class FileCookieJar extends CookieJar
{
    /** @var string filename */
    private $filename;

    /** @var bool Control whether to persist session cookies or not. */
    private $storeSessionCookies;</pre>
<pre>
/**
 * Saves the file when shutting down
 */
public function __destruct()
{
    $this->save($this->filename);
}

/**
 * Saves the cookies to a file.
 *
 * @param string $filename File to save
 * @throws RuntimeException if the file cannot be found or created
 */
public function save($filename)
{
    $json = [];
    foreach ($this as $cookie) {
        /** @var SetCookie $cookie */
        if (CookieJar::shouldPersist($cookie, $this->storeSessionCookies)) {
            $json[] = $cookie->toArray();
        }
    }

    $jsonStr = GuzzleHttpjson_encode($json);
    if (false === file_put_contents($filename, $jsonStr, LOCK_EX)) {
        throw new RuntimeException("Unable to save file {$filename}");
    }
}</pre>
<pre>

Nous avons pu construire la charge utile suivante, avec l’utilisation d’un outil externe, PHPGGC, qui appelle la classe FileCookieJar une fois désérialisée. Cette charge utile définit le nom de fichier FileCookieJar sur /var/www/html/new.php, qui est le chemin et le nom de fichier du fichier qui sera créé lors de la désérialisation. Le paramètre de données SetCookie définit la charge utile PHP malveillante dans le fichier nouvellement créé sur:<?php phpinfo();?>. Enfin, il définit également quelques autres valeurs telles que FileCookieJar storeSessionCookies sur enabled et SetCookie sur true.

O:31:"GuzzleHttpCookieFileCookieJar":4:{s:41:"GuzzleHttpCookieFileCookieJar*filename";s:21:"/var/www/html/new.php";s:52:"GuzzleHttpCookieFileCookieJar*storeSessionCookies";b:1;s:36:"GuzzleHttpCookieCookieJar*cookies";a:1:{i:0;O:27:"GuzzleHttpCookieSetCookie":1:{s:33:"GuzzleHttpCookieSetCookie*data";a:5:{s:4:"Name";s:4:"test";s:5:"Value";s:18:"<?php phpinfo();?>";s:7:"Discard";b:0;s:7:"Expires";i:1;}}}s:39:"GuzzleHttpCookieCookieJarstrictMode";N;}

Cela signifiait qu’un attaquant pouvait générer un fichier PHP new.php dans le répertoire personnel d’un site vulnérable avec le contenu <?php phpinfo();?>. Le contenu du fichier PHP peut être changé en n’importe quoi, comme <?php shell_exec($_GET['cmd']);?> ce qui permettrait à un attaquant de réaliser l’exécution de code à distance.

Notez que la présence d’une chaîne POP complète signifiait également que tout autre plugin avec une vulnérabilité d’injection d’objet, y compris ceux qui ne nécessitaient pas de connaissance des sels et des clés du site, pourrait potentiellement être utilisé pour réaliser également l’exécution de code à distance s’il était installé. sur un site avec le plugin Facebook pour WordPress.

Falsification de requêtes intersites

Description: Falsification de requêtes intersites vers des scripts intersites stockés
Plugin concerné: Facebook pour WordPress, anciennement connu sous le nom de Pixel Facebook officiel
Plugin Slug: officiel-facebook-pixel
Versions concernées: 3.0.0 – 3.0.3
ID CVE: En attente.
Score CVSS: 8,8 (élevé)
Vecteur CVSS: CVSS: 3.1 / AV: N / AC: L / PR: N / UI: R / S: U / C: H / I: H / A: H
Version entièrement corrigée: 3.0.4

En plus de la vulnérabilité d’injection d’objets PHP, nous avons découvert une vulnérabilité de falsification de requêtes intersites vers des scripts intersites stockés dans la version mise à jour du plugin. Dans la version 3.0.0, les développeurs ont réécrit une grande partie du code du plugin tout en renommant et en introduisant de nouvelles fonctionnalités.

L’une des modifications qu’ils ont apportées lors de la mise à jour du plugin concernait la fonctionnalité derrière l’enregistrement des paramètres du plugin. Cela a été converti en une action AJAX pour rendre le processus d’intégration plus transparent. La nouvelle version a introduit le wp_ajax_save_fbe_settings Action AJAX liée à la saveFbeSettings fonction.

 public function init(){
        add_action('wp_ajax_save_fbe_settings', array($this, 'saveFbeSettings'));
        add_action('wp_ajax_delete_fbe_settings',
        array($this, 'deleteFbeSettings')
        );
    }

Cette fonction est utilisée pour mettre à jour les paramètres du plugin avec l’ID de pixel Facebook, le jeton d’accès et la clé professionnelle externe. Ces paramètres aident à établir une connexion avec la console de pixel Facebook afin que les données d’événement puissent être envoyées du site WordPress au compte de pixel Facebook approprié.

</pre>
<pre>public function saveFbeSettings(){
    if (!current_user_can('administrator')) {
        $this->handleUnauthorizedRequest();
    }
    $pixel_id = $_POST['pixelId'];
    $access_token = $_POST['accessToken'];
    $external_business_id = $_POST['externalBusinessId'];
    $settings = array(
        FacebookPluginConfig::PIXEL_ID_KEY => $pixel_id,
        FacebookPluginConfig::ACCESS_TOKEN_KEY => $access_token,
        FacebookPluginConfig::EXTERNAL_BUSINESS_ID_KEY =>
            $external_business_id,
        FacebookPluginConfig::IS_FBE_INSTALLED_KEY => '1'
    );
    update_option(
        FacebookPluginConfig::SETTINGS_KEY,
        $settings
    );
    return $this->handleSuccessRequest($settings);
}</pre>
<pre>

Il y avait une vérification d’autorisation sur cette fonction, empêchant les utilisateurs inférieurs aux administrateurs de pouvoir y accéder, cependant, il n’y avait pas de protection nonce. Cela signifiait qu’il n’y avait aucune vérification qu’une demande provenait d’une session administrateur authentifié légitime. Cela a permis aux attaquants de créer une requête qui serait exécutée s’ils pouvaient inciter un administrateur à effectuer une action alors qu’il était authentifié sur le site cible.

L’action pourrait être utilisée par un attaquant pour mettre à jour les paramètres du plugin pour pointer vers sa propre console Facebook Pixel et voler des données métriques pour un site. Pire encore, comme il n’y avait pas de nettoyage des paramètres stockés, un attaquant pouvait injecter du JavaScript malveillant dans les valeurs de paramètre. Ces valeurs seraient ensuite reflétées sur la page des paramètres, provoquant l’exécution du code dans le navigateur d’un administrateur de site lors de l’accès à la page des paramètres. En fin de compte, ce code pourrait être utilisé pour injecter des portes dérobées malveillantes dans des fichiers de thème ou créer de nouveaux comptes d’utilisateurs administratifs pouvant être utilisés pour la prise de contrôle complète du site.

En plus de l’action AJAX utilisée pour mettre à jour les paramètres, il y avait une action AJAX wp_ajax_delete_fbe_settings accroché au deleteFbeSettings fonction. Cette fonction a été utilisée pour effacer les paramètres du plugin. Il manquait également la protection nonce appropriée, ce qui permettait aux attaquants de réinitialiser les paramètres du plugin via CSRF. Bien que la réinitialisation des paramètres du plugin puisse être ennuyeuse et que cela puisse entraîner une brève perte de données métriques, il n’y a pas eu de dommage trop important qui pourrait être fait sur un site WordPress avec cette vulnérabilité.

Calendrier de divulgation [PHP Object Injection]

22 décembre 2020 – Conclusion de l’analyse du plugin qui a conduit à la découverte de la vulnérabilité PHP Object Injection dans Facebook pour WordPress. Nous développons des règles de pare-feu pour protéger les clients de Wordfence et les diffusons aux utilisateurs de Wordfence Premium. Nous prenons contact avec l’équipe de sécurité de Facebook Pixel. Nous recevons des réponses automatisées confirmant la réception de notre rapport.
25 décembre 2020 – Nous recevons une réponse demandant des informations complémentaires.
28 décembre 2020 – Nous envoyons les détails supplémentaires demandés.
4 janvier 2021 – Nous recevons la confirmation que les développeurs du plugin ont pu dupliquer notre rapport et ont commencé à travailler sur un correctif.
6 janvier 2021 – Une version corrigée du plugin est publiée en tant que version 3.0.0. Nous vérifions que la vulnérabilité a été corrigée.
21 janvier 2021 – Les utilisateurs gratuits de Wordfence reçoivent une règle de pare-feu.

Calendrier de divulgation [CSRF to Stored XSS]

27 janvier 2021 – Conclusion de l’analyse du plugin qui a conduit à la découverte de la vulnérabilité CSRF to Stored XSS dans Facebook pour WordPress. Nous développons des règles de pare-feu pour protéger les clients de Wordfence et les diffusons aux utilisateurs de Wordfence Premium. Nous prenons contact avec l’équipe de sécurité de Facebook Pixel. Nous recevons des réponses automatisées confirmant la réception de notre rapport.
1 février 2021 – Nous recevons une réponse demandant des informations complémentaires. Nous envoyons des détails supplémentaires le même jour.
5 février 2021 – Nous recevons la confirmation que les développeurs du plugin ont pu dupliquer notre rapport et ont commencé à travailler sur un correctif.
12 février 2021 – Une version corrigée du plugin est publiée en tant que version 3.0.3.
15 février 2021 –Nous faisons un suivi pour informer les développeurs du plugin de l’absence de désinfection sur les paramètres stockés, ce qui conduit à un patch insuffisant.
17 février 2021 – Un patch supplémentaire et entièrement suffisant est publié.
26 février 2021 – Les utilisateurs gratuits de Wordfence reçoivent une règle de pare-feu.

Conclusion

Dans l’article d’aujourd’hui, nous avons détaillé deux failles dans le plugin Facebook pour WordPress qui permettaient aux attaquants de réaliser l’exécution de code à distance en raison d’une vulnérabilité d’injection d’objet PHP et d’injecter du JavaScript malveillant en raison d’une vulnérabilité CSRF, qui peuvent toutes deux être utilisées pour un site complet. reprendre. Les failles sont toutes deux entièrement corrigées dans la version 3.0.4. Nous recommandons aux utilisateurs de mettre immédiatement à jour vers la dernière version disponible, qui est la version 3.0.5 au moment de cette publication.

Wordfence Premium les utilisateurs ont reçu des règles de pare-feu protégeant contre la première vulnérabilité le 22 décembre 2020 et la deuxième vulnérabilité le 27 janvier 2021, tandis que ceux qui utilisent toujours la version gratuite de Wordfence ont reçu la même protection pour la première vulnérabilité le 21 janvier 2020 et le 26 février , 2021 pour la deuxième vulnérabilité.

Si vous connaissez un ami ou un collègue qui utilise ce plugin sur son site, nous vous recommandons vivement de lui transmettre cet avis pour aider à garder ses sites protégés car il s’agit de vulnérabilités graves pouvant entraîner l’exécution de code à distance et la compromission complète du site.


Source link