Updates on WordPress security, Wordfence and what we're cooking in the lab today.

Wordfence Blog

The Official Facebook Chat Plugin Created Vector for Social Engineering Attacks

This entry was posted in Research, Vulnerabilities, WordPress Security on August 4, 2020 by Chloe Chamberland   0 Replies

On June 26, 2020, our Threat Intelligence team discovered a vulnerability in The Official Facebook Chat Plugin, a WordPress plugin installed on over 80,000 sites. This flaw made it possible for low-level authenticated attackers to connect their own Facebook Messenger account to any site running the vulnerable plugin and engage in chats with site visitors on affected sites.

We initially reached out to Facebook on June 26, 2020 and included the full disclosure details at the time of reaching out. They initially responded on June 30, 2020, and after much back and forth, Facebook released a patch on July 28, 2020.

We highly recommend updating to version 1.6 immediately to keep your site protected against any attacks attempting to exploit this vulnerability.

Wordfence premium users received a new firewall rule on June 30, 2020 to protect against exploits targeting this vulnerability. Sites still using the free Wordfence plugin received this rule on July 30, 2020.


Description: Authenticated Options Change
Affected Plugin: The Official WordPress Facebook Chat Plugin
Plugin Slug: facebook-messenger-customer-chat
Affected Versions: < =1.5
CVE ID: Pending.
CVSS Score: 7.4 (HIGH)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L
Fully Patched Version: 1.6

The Official WordPress Facebook Chat plugin is a very simple plugin designed to add a “Facebook Messenger” chat pop-up to any WordPress site and connect a site owner’s chosen Facebook page to receive messages and interact with site visitors.

It does most of the design work through a dialog on Facebook.com However, once finished it updates the plugin options fbmcc_pageID and fbmcc_locale to set the chat’s page ID that will be connected to the pop-up on the front end of the site, and the language localization that should be used.

In order to do so, the plugin registered an AJAX action wp_ajax_update_options hooked to the fbmcc_update_options function.

add_action( 'wp_ajax_update_options', 'fbmcc_update_options');

function fbmcc_update_options() {
  check_ajax_referer( 'update_fmcc_code' );
  update_option( 'fbmcc_pageID', sanitize_text_field($_POST['pageID']));
  update_option( 'fbmcc_locale', sanitize_text_field($_POST['locale']));
  wp_die();
}

Unfortunately, this AJAX action had no capability checks to verify that a request was coming from an authenticated administrator. This made it possible for any authenticated user, including subscriber level accounts, to send a request to update the options and hook-up their own Facebook Messenger account.

In addition, the nonce that was used for CSRF protection was easily discoverable in the source code of any /wp-admin dashboard page due to the admin_enqueue_scripts registered action that made the nonce visible in the admin area of a site.

As a reminder, all default user accounts can access the /wp-admin area of a WordPress site. This means that any authenticated user could scrape a page for a usable nonce and send it with the update_options request to pass the check_ajax_referer check.

add_action( 'admin_enqueue_scripts', 'fmcc_localize_ajax' );
function fmcc_localize_ajax() {
  $ajax_object = array(
    'nonce' => wp_create_nonce( 'update_fmcc_code' )
  );

  wp_register_script( 'code_script', plugin_dir_url( __FILE__ ) . 'script.js' );
  wp_localize_script( 'code_script', 'ajax_object', $ajax_object );
  wp_enqueue_script( 'code_script' );
}

As a result, attackers could link their own Facebook Page Messenger account, by updating the page ID, to any given site running the plugin as long as they were able to register on the site and access the /wp-admin dashboard. The attacker would then receive any messages initiated from the site’s Messenger Chat, and the site owner would no longer receive any messages initiated from the chat.

How Could this Vulnerability be Used?

This vulnerability could be exploited and easily go undetected by a site owner, causing site visitors to interact with an attacker instead of the site owner. Exploit attempts targeting this vulnerability could easily be used as part of a social engineering attack by posing as a site owner requesting personally identifiable information, credentials, or other information.

Another possible scenario for this vulnerability to be exploited is that a competitor could use it to their advantage. By supplying nothing for the pageid parameter, a competitor could completely disable the chat, causing a loss of availability for the chat service, potentially resulting in a loss of sales.

Worse yet, they could connect a fake page to look like the target site’s original page and, when site visitors begin interacting, they could be intentionally rude or offensive, deterring those site visitors from doing further business with the target site and ruining the site’s reputation, or driving traffic to the competitors business, causing a loss in customers and revenue.

What is Social Engineering?

Social engineering attempts to exploit “weaknesses” in humans through social interactions. An attacker could exploit a human’s inherent ability to trust others or to trust a site’s content. If someone hasn’t gone through any security awareness training for internet usage, they may not know what social engineering is and may not take any precautions to stay protected.

The following is an example of how this vulnerability could potentially be exploited. It is completely fictitious, and not a very likely scenario. But hopefully it helps clarify what could happen in a social engineering attack of this nature, what needs to be done to make sure you stay safe from social engineering attempts, and help you understand why it is important to update this plugin so your site visitors stay safe.

Social Engineering with The Official Facebook Chat Plugin Scenario: Gaining Credentials

In this scenario, we have “Jimmy’s Jammin’ Music Plugin for WordPress,” and a WordPress site setup to sell this WordPress plugin and provide support to Jimmy’s users. He allows users to register as subscribers so that they can access his support portal, but he hasn’t taken any precautions to disallow these users from accessing /wp-admin once authenticated. Jimmy has The Official Facebook Chat Plugin installed on his site so he can quickly answer any pre-sales related questions.

Jimmy’s site had been compromised because he was running an outdated version of The Official Facebook Chat Plugin and an attacker used this vulnerability to enable a spoofed Facebook Page’s Messenger Account. Now, the attacker receives any chat initiations and can converse with Jimmy’s customers and site visitors.

Our unsuspecting visitor is “Jane,” and she needs help getting setup with the Jimmy’s Jammin’ Music plugin. She instantly found the messenger pop-up and started interacting with someone who she thinks is “Jimmy.” After all, she’s on Jimmy’s site, but she doesn’t know that Jimmy’s site has been compromised and an attacker is using their own Facebook Messenger account.

The conversation starts out innocent with the attacker asking some basic questions and answering all of Jane’s questions. After the attacker feels they have gained trust from Jane, the attacker says “Okay, thanks for the information Jane! I’d love to login to your site and get everything set up properly for you. Can you please provide me with your site’s login details?”

Jane, excitedly, responds with her administrative credentials. “Oh, thank you so much Jimmy! My WordPress Login URL is http://JaneMusicCo.com/wp-login.php, my username is Jane, and my password is janelovesmusic! Please let me know if you need anything else!”

Now, the attacker has just effectively socially engineered Jane to obtain her site’s credentials. From there, the attacker can log into her site and inject a backdoor that Jane won’t detect and do a lot of damage to her site.

Though social engineering exploits may be harder to successfully execute, the results can be detrimental. As we have recently seen in the news with the “Twitter Hack,” social engineering attacks are very real and can happen to anyone. Only education and awareness can help protect you from being socially engineered by a malicious attacker. Site owners have additional responsibilities to make sure you have the most secure site to help keep others safe.

How can you protect yourself as a site visitor?

Never, in any situation, divulge sensitive information, like access credentials or credit card data, to anyone unless you can truly verify the person or company is who they say they are and they have a legitimate “need to know.”

In the above scenario, Jane should’ve said something along the lines of “I would prefer not to provide my credentials. Can you please just walk me through the process instead?” or taken steps to verify the identity of the person she was interacting with prior to sharing credentials. If she decided to provide access, it should have been a temporary account with the least amount of privileges necessary to perform the role, which could be deleted once finished.

Proof of Concept Walkthrough

Today we demoed how this could be exploited during Wordfence Office Hours. If you’re interested in learning how this vulnerability could be exploited, check out today’s episode of Wordfence Office Hours below. The video below starts at 40:40 when the demo starts, alternatively, you can watch the entire video to see us exploit the vulnerabilities in both wpDiscuz and Newsletter plugins.

Disclosure Timeline

June 26, 2020 – Initial discovery of vulnerability. We develop a firewall rule and move it into the testing phase. At the same time, we reach out to Facebook’s security team with the full disclosure.
June 30, 2020 – The WAF rule is sufficiently tested and released to premium users.
July 24, 2020 – The security team let us know that they have forwarded the details to the appropriate team for resolution.
July 28, 2020 – A sufficient patch released in version 1.6.
July 30, 2020 – Wordfence free users receive the firewall rule.

Conclusion

In today’s post, we detailed a flaw in The Official Facebook Chat Plugin that provided authenticated users with the ability to update the plugins options to use any Facebook page for the Messenger feature. Along with that, we provided some insight as to what social engineering attacks could look like, and what you can do to protect yourself against them. This flaw has been fully patched in version 1.6. We recommend that users immediately update to the latest version available, which is version 1.6 at the time of this publication.

Both sites using Wordfence Premium and those still using the free version of Wordfence are protected from attacks against this vulnerability. If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected as this is a critical security update. We also ask that you share this social engineering scenario with friends, to educate them about the potential consequences of social engineering attacks. Through education about possible security threats, like social engineering, we can all make the internet safer.

Did you enjoy this post? Share it!

No Comments on "The Official Facebook Chat Plugin Created Vector for Social Engineering Attacks"

Follow Us

      


Protect your websites with the #1 WordPress Security Plugin

Get Premium
Over 150 million downloads

Wordfence Newsletter

Get WordPress Security Alerts and Product Updates