What is FTP? Why use it to clean hacked websites?

The File Transfer Protocol (FTP) is a network protocol used to transfer files between a client server and a network. In other words, it is through FTP that we get text and images onto a website.

Why is FTP used to clean up a website?

Not only is FTP used to insert files into a website, It’s also necessary for removing malicious files left by a hacker. Let’s take a look at what FTP is and why we need access to it when cleaning infections and removing malware from websites.

Continue reading What is FTP? Why use it to clean hacked websites? at Sucuri Blog.

WordPress Malware Collects Sensitive WooCommerce Data

During a recent investigation, our team found malicious code that reveals how attackers are performing reconnaissance to identify if sites are actively using WooCommerce in a compromised hosting environment. These compromised websites are victims of the ongoing wave of exploits against vulnerable WordPress plugins.

Why are WooCommerce websites being targeted?

WooCommerce is a powerful WordPress plugin that can help a website owner set up an ecommerce store. WooCommerce’s popularity has allowed it to quickly grow a large market share and become one of the biggest ecommerce platforms in the world.

Continue reading WordPress Malware Collects Sensitive WooCommerce Data at Sucuri Blog.

The Elementor Attacks: How Creative Hackers Combined Vulnerabilities to Take Over WordPress Sites

The Elementor Attacks: How Creative Hackers Combined Vulnerabilities to Take Over WordPress Sites

On May 6, our Threat Intelligence team was alerted to a zero-day vulnerability present in Elementor Pro, a WordPress plugin installed on approximately 1 million sites. That vulnerability was being exploited in conjunction with another vulnerability found in Ultimate Addons for Elementor, a WordPress plugin installed on approximately 110,000 sites.

We immediately released a firewall rule to protect Wordfence Premium users and contacted Elementor about the vulnerability. As this vulnerability was being actively exploited, we also publicly notified the community of the vulnerability to help protect users from being compromised.

Elementor quickly released an update for Elementor Pro the same day we published a notice on the Wordfence blog. In today’s post, we provide the technical details of the two vulnerabilities along with a closer look at how these two vulnerabilities were used together to compromise WordPress websites using these plugins.

We urge any website owners who have not yet updated to the latest versions of these plugins to do so immediately. For Elementor Pro, that is version 2.9.4 and in Ultimate Addons for Elementor, that is version 1.24.2.

Ultimate Addons for Elementor

Description: Registration Bypass
Affected Plugin: Ultimate Addons for Elementor
Plugin Slug: ultimate-elementor
Affected Versions: <= 1.24.1
CVE ID: CVE-2020-13125
CVSS Score: 7.2 (High)
Fully Patched Version: 1.24.2

Ultimate Addons for Elementor is a plugin made by Brainstorm Force. It is an extension to Elementor, providing many additional widgets to use with Elementor.

One of the widgets adds a registration form, called the “User Registration Form” to any page. This is an easily customizable registration form that can be placed anywhere on the site. Unfortunately, there was a flaw in the functionality of this form that allowed for users to register even when registration was disabled, and even if the form widget was not actively in use on the site.

Is User Registration enabled?

The developers registered both nopriv and regular AJAX actions tied to the get_form_data function in order to provide functionality for the User Registration Form widget.

	public function __construct() {

		add_action( 'wp_ajax_uael_register_user', array( $this, 'get_form_data' ) );
		add_action( 'wp_ajax_nopriv_uael_register_user', array( $this, 'get_form_data' ) );
		add_filter( 'wp_new_user_notification_email', array( $this, 'custom_wp_new_user_notification_email' ), 10, 3 );

Diving into the get_form_data function, we see that it was designed to retrieve the information submitted in the registration form. This data was then used to create a new user on the site using the WordPress wp_insert_user hook. Nowhere in the function did it verify that user registration was enabled on the site, nor did it do any alternative checks to verify that the registration form widget was active.

	 * Get Form Data via AJAX call.
	 * @since 1.18.0
	 * @access public
	public function get_form_data() {

		check_ajax_referer( 'uael-form-nonce', 'nonce' );

		$data     = array();
		$error    = array();
		$response = array();

		if ( isset( $_POST['data'] ) ) {

			$data = $_POST['data'];

*Note several lines are omitted for brevity.

			$user_args = apply_filters(
						'user_login'      => isset( $user_login ) ? $user_login : '',
						'user_pass'       => isset( $user_pass ) ? $user_pass : '',
						'user_email'      => isset( $user_email ) ? $user_email : '',
						'first_name'      => isset( $first_name ) ? $first_name : '',
						'last_name'       => isset( $last_name ) ? $last_name : '',
						'user_registered' => gmdate( 'Y-m-d H:i:s' ),
						'role'            => isset( $user_role ) ? $user_role : '',

				$result = wp_insert_user( $user_args );

These missing checks were what made it possible for attackers to bypass the user registration settings on a WordPress site. Fortunately, Brainstorm Force added checks in the latest version to verify both that user registration is enabled and that the widget is active.

	 * Get Form Data via AJAX call.
	 * @since 1.18.0
	 * @access public
	public function get_form_data() {

		check_ajax_referer( 'uael-form-nonce', 'nonce' );

		$data             = array();
		$error            = array();
		$response         = array();
		$allow_register   = get_option( 'users_can_register' );
		$is_widget_active = UAEL_Helper::is_widget_active( 'RegistrationForm' );

		if ( isset( $_POST['data'] ) && '1' === $allow_register && true === $is_widget_active ) {

			$data = $_POST['data'];

Registration Nonce is always displayed

Though nonces are primarily used to mitigate CSRF attacks and verify the legitimacy of a request, they can also act as a fail-safe in instances like this where a function contains a small flaw, that is, if the nonce is undiscoverable by an attacker.

The get_form_data function did use nonce verification that could have potentially stopped rogue user registration. However, we discovered that the form_nonce was always visible in the source code of a page where a UA for Elementor widget was enabled, even when there was no form present on the page.

	 * Setup Actions Filters.
	 * @since 0.0.1
	private function setup_actions_filters() {

		add_shortcode( 'uael-template', array( $this, 'uael_template_shortcode' ) );

		add_action( 'elementor/init', array( $this, 'elementor_init' ) );

		add_action( 'elementor/elements/categories_registered', array( $this, 'widget_category' ) );

		add_action( 'elementor/frontend/after_register_scripts', array( $this, 'register_widget_scripts' ) );

*Note several lines are omitted for brevity.

				'invalid_mail'       => __( 'Enter valid Email!', 'uael' ),
				'pass_unmatch'       => __( 'The specified password do not match!', 'uael' ),
				'required'           => __( 'This Field is required!', 'uael' ),
				'form_nonce'         => wp_create_nonce( 'uael-form-nonce' ),
				'incorrect_password' => __( 'Error: The Password you have entered is incorrect.', 'uael' ),
				'invalid_username'   => __( 'Unknown username. Check again or try your email address.', 'uael' ),
				'invalid_email'      => __( 'Unknown email address. Check again or try your username.', 'uael' ),

This meant that attackers just needed to scrape the source code of pages on a site running this plugin for var uaelRegistration. If that site had at least one widget in use on any page, they would be granted a usable nonce to register on the site.

A look at the discoverable UAE nonce in the source code of a page with a UAE widget enabled.

The Exploit

Combined, these flaws made it possible for attackers to register as a subscriber on any vulnerable site and potentially use that access to pivot and exploit vulnerabilities that required subscriber level access. This is precisely what we saw being exploited in the case of the Elementor Pro vulnerability.

Special thanks to Ramuel Gall for his research contributions on this vulnerability.

Elementor Pro

Description: Authenticated Arbitrary File Upload
Affected Plugin: Elementor Pro
Plugin Slug: elementor-pro
Affected Versions: <= 2.9.3
CVE ID: CVE-2020-13126
CVSS Score: 9.9 (Critical)
Fully Patched Version: 2.9.4

Elementor is a popular WordPress page builder plugin, currently installed on over 5 million WordPress sites. The Pro version adds additional enhancements like the ability to upload custom icons and fonts. It also adds over 50 additional widgets to improve the page building process along with enhanced customizability.

When a plugin introduces the ability to upload files, regardless of the file type, the proper control measures should always be included in order to prevent unauthorized users from uploading files or bypassing any file filters or privileges established on the site.

Unfortunately, the ‘Custom Icon’ upload functionality in Elementor Pro did not have appropriate measures in place. Attackers discovered an effective way to bypass restrictions on which file types could be uploaded, and once authenticated they were able to upload PHP files like webshells and backdoors.

Lack of Permissions Check

Elementor Pro registers an AJAX endpoint used to trigger the icon upload function. Neither the AJAX action nor the upload function had any permission checks, allowing any authenticated user, including those with minimal permissions, the ability to trigger the function and upload a .zip file.

	public function register_ajax_actions( Ajax $ajax ) {
		$ajax->register_ajax_action( 'pro_assets_manager_custom_icon_upload', [ $this, 'custom_icons_upload_handler' ] );

Fortunately, the patched version of the plugin implemented a permissions check on the custom_icons_upload_handler function that blocks low-level users from being able to upload files.

public function custom_icons_upload_handler( $data ) {
		if ( ! current_user_can( Icons_Manager::CAPABILITY ) ) {
			return new WP_Error( Exceptions::FORBIDDEN, 'Access denied.' );

Unchecked Uploads

It appears that the custom icon upload functionality was intended to only allow .zip files that were created from the Fontello, IcoMoon, or Fontastic icon creation sites. It did this by checking the files included in the .zip file and verifying that those aligned with the files generated from the trusted icon sources. However, the plugin never checks to verify if any additional files have been included in those .zip files.

	$supported_icon_sets = self::get_supported_icon_sets();
		foreach ( $supported_icon_sets as $key => $handler ) {
			 * @var IconSetsIcon_Set_Base $icon_set_handler
			$icon_set_handler = new $handler( $results['directory'] );

			if ( ! $icon_set_handler ) {
			if ( ! $icon_set_handler->is_valid() ) {

This made it possible for attackers to include malicious files in a trusted .zip file, bypassing the restrictions the plugin had in place. This included .php files.

Discoverable Nonce

There was a nonce check on the function, but just like we saw in the Ultimate Addons for Elementor plugin, the nonce was easily discoverable due to being included in var elementorCommonConfig as “ajax” in the page source of all administrative dashboard pages.

A closer look at the Elementor Pro nonce discovered in the page source of /wp-admin.

An attacker could find a usable nonce by scraping the page source of the /wp-admin dashboard while authenticated. This could then be used as a legitimate Elementor AJAX nonce to execute the vulnerable action and upload crafted .zip files.

The Exploit

These three flaws made it possible for attackers to upload arbitrary files by creating a Fontello, IcoMoon, or Fontastic icon .zip file, extracting that file, injecting arbitrary files of their choice to the folder, re-compressing the .zip file and uploading it to the site via the AJAX action.

Uploaded .zip files are extracted into the /wp-content/upload/elementor/custom-icon directory in a newly generated folder. If the site owner previously had not uploaded any custom icons, the malicious files would be located in the /-1 folder. If there were previously uploaded custom-icon files that directory may have been a different number such as /-5, and the attacker would need to use brute force in order to find the directory into which their malicious payload had been extracted.

An attacker would be able access any newly uploaded files, like a webshell, by going directly to the file:


If the file uploaded was a .php file, the code would also be executed upon access. This allowed for remote code execution (RCE) and ultimately the total compromise of the WordPress site and hosting environment.

Disclosure Timeline for Elementor Pro

May 5, 2020 – Wordfence notified of recently patched vulnerability in Ultimate Addons for Elementor. In the same notice, it was mentioned that Elementor Pro may have a “bug” that caused rogue files present in the /custom-icons directory. We begin to investigate Elementor Pro to determine if there is a security flaw present. We conclude that there is an authenticated arbitrary file upload vulnerability present.
May 5, 2020 – We quickly provision Premium customers with a firewall rule to provide protection against the vulnerability found in Elementor Pro.
May 5, 2020 – We contact the team at Elementor to alert them of the vulnerability’s presence.
May 5, 2020 – Hosting company provides us with log files that confirm this is being actively exploited.
May 6, 2020 – We publish a public service announcement with limited details to inform users how to secure their site until a patch is available.
May 6, 2020 – Elementor releases a patch for Elementor Pro.
June 4, 2020 – Wordfence free users receive firewall rule.

Attack Scenario Walkthrough


In today’s post, we provided technical details of the vulnerability found in the Elementor Pro plugin and how this vulnerability was used in active exploits in conjunction with the vulnerability found in Ultimate Addons for Elementor. These flaws have both been patched and we recommend that users update to the latest versions available immediately.

Sites running Wordfence Premium have been protected from attacks against the vulnerability in Elementor Pro since May 5, 2020. Sites running the free version of Wordfence will receive the firewall rule update on June 4, 2020. If you know a friend or colleague who is running one, or both, of these plugins on their site, we highly recommend forwarding this to them immediately to help them secure their site.

Special thank you to the team at Elementor for working quickly to get a patch out to protect Elementor Pro users. Also, thank you again to Ramuel Gall, Kathy Zant, Gerroald Barron, and Stephen Rees-Carter from the Wordfence team for their assistance in researching this attack and testing mitigations.

The post The Elementor Attacks: How Creative Hackers Combined Vulnerabilities to Take Over WordPress Sites appeared first on Wordfence.

Episode 76: Ongoing Attacks on WP Growing in Volume Plus Numerous Plugin Vulnerabilities

On this week’s Think Like a Hacker podcast, we cover an active attack campaign targeting WordPress sites and numerous plugin vulnerabilities. This active attack campaign has been ongoing and has outpaced all other attacks on WordPress vulnerabilities. Our threat intelligence team has been tracking this attacker for months now, and we’re seeing these attacks intensifying. We also look at vulnerabilities found in Google’s Site Kit plugin and the Page Builder by SiteOrigin, and why it’s so important for plugin developers to have a Responsible Disclosure Policy published in an easy to find location on their site.

We also look at how a combination of two vulnerabilities were used in a zero-day active attack on sites running Elementor Pro and the Ultimate Addons for Elementor plugin.

We also look at some new updates to Fast or Slow, the new global site speed profiling tool created by the Wordfence engineering team, and the impromptu hard launch the site experienced when it rose to the #1 position on Hacker News on May 8, 2020.

May has been a rather busy month in WordPress security and for the Wordfence team. Enjoy the podcast, and stay safe.

Here are timestamps and links in case you’d like to jump around, and a transcript is below.
0:24 Fast or Slow rises to the #1 position on Hacker News, and our team launches a re-architecture and expands profiling to 18 global locations.
5:37 Vulnerability discovered in Google Site Kit grants attackers Google Search Console access.
7:50 28,000 GoDaddy hosting accounts compromised.
9:32 Combined Attack on Elementor Pro and Ultimate Addons for Elementor put 1 million sites at risk.
13:34 Vulnerabilities patched in Page Builder by SiteOrigin affects over 1 million sites.

Find us on your favorite app or platform including iTunes, Google Podcasts, Spotify, YouTube, SoundCloud and Overcast.

Click here to download an MP3 version of this podcast. Subscribe to our RSS feed.

Episode 76 Transcript

Hello my WordPress friends and welcome to episode 76 of Think Like a Hacker. This is the podcast about WordPress, security and innovation. I am your host, Kathy Zant. We have a number of stories this week about WordPress security. So, let’s get started.

First, a quick note about Fast or Slow. This is the application developed by the engineering team here at Wordfence. On Friday, May 8th, we started to see some increased traffic to the site at fastorslow.com. Upon further investigation, we found that Fast or Slow was being featured on the front page of Hacker News, which was surprising and big news. We had only soft launched this application, mailing to just a few select recipients and just watching how the application performed with a lot of traffic coming at it because it is rather complex.

Fast or Slow is a tool that measures your site performance from various locations around the globe. Obviously you are in one location and when you look at your site, it may respond differently for you than it does with someone on the other side of the world. So we wanted to create a tool that allowed people to measure performance across a wide variety of geographic locations.

So one of the users that we had mailed to saw the value and shared to Hacker News, and we had the experience of an impromptu hard launch. The site is growing since then, garnering additional traffic from places around the world. The team was actually in the midst of rearchitecting parts of it for growth, preparing for growth. The site now is prepared for future growth. We’ll have some news about that coming soon.

We created Fast or Slow for ourselves, and it’s really great and exciting to see it received so well by the web development community, even beyond WordPress. So thank you to everyone who is using Fast or Slow and watch for those improvements and features to be added soon. If you haven’t looked at it yet, why not. Go to fastorslow.com and see how your site is performing around the world.

You may have noticed I didn’t get a podcast out last week. Part of that was watching that meteoric usage of Fast or Slow. But there was also just an insane amount of security research and news happening in the WordPress world in the first week of May. Now we’re in the second week of May and it certainly does not want to be the neglected younger sibling of the month. So we’ve had another week of just a ton of news in WordPress security. So let’s get started with that.

Our first WordPress security story is a continuing story that started on Monday, May 4 when we loaded things up in our virtual offices as a remote team around the world. Ram Gall on our QA and threat research team noticed a dramatic increase in the number of attacks hitting sites running the Wordfence firewall. Most of these were cross-site scripting attacks that were targeting smaller plugins with rather old vulnerabilities. But the news there was just the sheer volume of attacks.

We published a post detailing what we were seeing because we were fairly certain we’d start seeing additional attacks coming from this threat actor. True to form, about a week later, we saw another uptick to the point where this singular threat actor, now it could be a group of people, but this singular campaign was launching more attacks against vulnerabilities than any other vulnerability exploding campaign happening that is targeting WordPress in the world.

So Ram Gall, Chloe Chamberland, and Mark Maunder, took a look at what was happening and not only did we find that these threat actors had fixed a bug in their code, we found that this threat actor has been around for a while. We were starting to see similar patterns and markers from a campaign that was happening earlier this year, that was using Bulletproof Hosting to launch attacks against sites worldwide.

What is our take from this? WordPress obviously is running about a third of the internet and threat actors are always going to keep targeting WordPress. Once you know a system and you know probable vulnerabilities and probable exploits, you’re likely to keep targeting it. So what we’re seeing with this particular threat actor is that their attacks are maturing, in both size and the vulnerabilities being targeted. The great thing about Wordfence Premium is that this real time blacklist that’s part of Wordfence Premium tracks this attacker. So as they move from IP address to IP address, the blacklist follows them, ensuring their attacks can’t even see your WordPress site. So if you do have a vulnerability that they’re targeting, they won’t even be able to see it because those IP addresses are going to be blocked by this rolling blacklist. It’s the most powerful feature of Wordfence.

To me, especially for a site that’s critically important, it’s a must have for your WordPress site. It’s too bad those other content management systems don’t have something as powerful. But again, Wordfence is very specific in the WordPress world, protecting WordPress sites, and our threat intelligence is all about WordPress. So count that as another reason to stick with WordPress.

Our next story is about a vulnerability in the Google Site Kit plugin, installed on over 300,000 WordPress sites. Chloe Chamberland discovered this vulnerability. It allows attackers to add themselves as an owner of the site within Google search console. Owner access will allow them to modify site maps, remove pages from Google search engine result pages, or even to facilitate black hat SEO campaigns using your site. We strongly recommend that if you are using this, that you update to the latest version of the plugin, which is version 1.8.0 of Site Kit by Google. This is a really powerful tool for WordPress site owners.

I was at WordCamp Sacramento last fall, and I was able to see this demonstrated before it even launched. Jake Goldman from the web design agency, 10Up introduced Google Site Kit to a packed standing room only crowd. So I’m sure this talk will make it up on WordPress.TV soon. You might want to check that out. If you’re using Google’s tools to manage your rank in search engine results, having quick and easy access to the data within Google to help you make good decisions with your site is really helpful. So I think this is going to be a great tool for website owners worldwide. Again, as a note, just because a plugin has a vulnerability doesn’t mean that plugin should not be used. It just means that it’s a bug and it needs to get fixed. It’s great that Chloe and Ram and our threat intelligence team continue to uncover these vulnerabilities and work with developers to patch these important plugins. Those of us who are premium customers are supporting that. That supportive Wordfence helps us produce that research and get it out to everyone in the community as quickly as possible, including through this podcast. Education is such a huge part of security because when you have that information, it helps you make good decisions about the data you’re getting and that’s the backbone of security.

Our next story was covered widely in the general tech press. 28,000 GoDaddy accounts were compromised. This is just a small percentage of the company’s 19 million customers. So according to the disclosure that GoDaddy released, on April 17 they discovered and began investigating suspicious activity and it dated back to about October 2019. As soon as they identified this, they began their remediation. They have no indications that this threat actor was using customer credentials and no data shows that they had modified any hosting accounts. They just changed those passwords as a precaution. This only affected SSH logins. SSH stands for secure shell, and basically it gives you a command line access to the server for the account you’re logging into. If you have what they call sudo privileges, it grants you access to basically the entire server in order act as the route administrator. That’s likely not a problem on GoDaddy accounts. Just to put a trivia for something to understand about SSH and how critical it is.

So our advice is if you are using GoDaddy as your hosting provider, and you are not using SSH to login on that command line, you can turn this off. Or you can turn it on when you are using it and then off as a security precaution when you’re not. Again, 28,000 customers sounds like a lot, but it’s really just a drop in the bucket for GoDaddy’s wide user base.

For our next story, on May 6 there was an active exploitation campaign happening that was targeting Elementor based WordPress sites. Now this active attack was targeting a specific combination of two different vulnerabilities. The first was a vulnerability in the popular Elementor Pro plugin, which we estimate as installed on over 1 million WordPress websites. Now, just to differentiate, this does not affect the Elementor plugin that is installed on up to 5 million websites, now, that’s available in the WordPress repository. This vulnerability only affected the Pro version of this plugin. It let anyone with an account, even a subscriber level account, upload a file to the site. That file could be an image, or it could be a PHP backdoor, thus allowing someone to take over the whole site.
This is what we call an authenticated vulnerability, meaning someone has to have an account in order to exploit it. It sounds like not that big of a deal, right? You could just turn off subscribers in many cases and protect your site, but for sites using WordPress as an eCommerce platform with customer accounts or membership sites with member logins or LMS sites with student logins or anything else that requires subscriber accounts for the functionality of the site or greater, it’s kind of a big deal.

With this attack on the zero day vulnerability, another plugin came into play. This plugin is called the Ultimate Addons for Elementor. This is a paid plugin and it’s made by a company called Brainstorm Force. We estimate that this has an installation base of about 110,000. That’s just our estimate. It could be greater, it could be less. This team also makes the lightweight Astra Theme for WordPress. This plugins vulnerability allowed anyone to create an account on a site, even if subscription registration was turned off. So attackers were using this vulnerability to create a user account. Then they proceeded to use the newly registered accounts to exploit the Elementor Pro zero-day vulnerability and essentially achieve remote code execution.

We were alerted this vulnerability and this act of exploitation by someone whose WordPress site was compromised. Then a hosting provider shared their log files with us. We were able to corroborate and verify these reports of active exploitation. Brainstorm Force posted in the wordpress.org forums that they had to fix in place and had contacted Elementor. We had contacted Elementor immediately upon discovery of this and wrote a firewall rule, obviously to protect sites from exploitation that is currently available to premium customers. It didn’t take long for a fix to get posted, but there was a time when the [existence of] a zero day exploit was exposed in numerous Slack channels, as well as the wordpress.org forums.

This is just a testament to how fast the WordPress community acts when a security vulnerability is found. As a reminder, if you find that your site is hacked or you see chatter in a Slack forum or elsewhere about an exploit happening, it’s really important to get notification to the developer of that vulnerable plugin or theme as soon as possible. When things are publicly discussed like that, it puts the entire community at risk. Of course, Wordfence customers receive firewall rules to protect their sites.

Congratulations also to Elementor who just recently hit 5 million active installations with that free plugin in the repo, even in the midst of the Zero Day vulnerability. A reminder that Zero Days are just celebrity bugs. Responsible developers who patch quickly to protect their customers and they’re continuing to create amazing software, these companies will always succeed.

Our final WordPress security story for the second week of May is about the page builder by SiteOrigin plugin. This is installed on over a million sites. Chloe Chamberland found two vulnerabilities in this plugin. Both of these flaws allowed attackers to forge requests on behalf of a site administrator and execute malicious code in the administrator’s browser. The attacker needed to trick a site administrator into executing an action, like clicking a link in an attachment for this attack to succeed. The patched version is version 2.10.16. Both free and premium versions of the Wordfence firewall protects against these vulnerabilities via the built-in cross site scripting protection. This developer patched very quickly and was very thankful for the report of these vulnerabilities via responsible disclosure. They even bought a premium license for Wordfence as a gesture for thanking us to make their software even more secure. So we thank you. That was a great gesture and made us feel really great.

See, a lot of people think that security researchers and developers have a contentious relationship, and that developers look at us with contempt for finding vulnerabilities. It’s simply not true, especially in the WordPress community, this open source community that makes WordPress what it is. Finding and patching security bugs before the hackers find them, making everyone safer, developers understand this. They’re grateful for the additional support in finding vulnerabilities and disclosing them responsibly and getting things patched. It’s also really helpful when these developers have easy to find responsible disclosure policies so that security researchers from Wordfence and elsewhere can contact developers securely, quickly and easily. Especially in cases when there might be active attacks happening, like what we saw last week with the Elementor plugins, the faster we can get in touch with developers, the faster we can contact you and explain what’s going on and give you a proof of concept, showing you what’s happening, it’s going to protect the entire community.

So there are links in all of the show notes for this. Go check out Chloe’s blog posts, both for the SiteOrigin Page Builder, as well as for the [Google] Site Kit. She’s got some proof of concept videos in there that show you how these vulnerabilities are exploitable. I think these videos are great. It really helps explain how vulnerabilities work and also gives you an idea of how the firewall works.

If you like these videos, we have a treat coming up on an upcoming episode of Wordfence Office Hours. We’ve moved Wordfence Office Hours to YouTube, and we’re doing them every Tuesday at noon eastern, 9:00 AM Pacific Time. Chloe will be joining us on an upcoming episode. She’s going to show us how she hacks sites. So there’s going to be some live hacking on Office Hours, which is going to be fun. Chloe is also an amazing human being and I can’t wait for you guys to all meet her. Though if you have been listening for a while, you’ve heard my interview with her a few months ago, weeks ago. This quarantine thing and lockdown his me all discombobulated with days and months.

Anyway, join us for Office Hours, every Tuesday 9:00 AM Pacific, noon on the East coast. It will be very exciting. You can go subscribe to the Wordfence channel on YouTube. I’ll put a link in the show notes. If you hit the bell on the video placeholders for office hours for the upcoming episodes, you’ll get a reminder when the next Wordfence Office Hours is. As of today, we have two episodes up on YouTube. You can go check those out. If you expand the description box, you can see some timestamps of sections of the show so you can dive in and learn more.

In the most recent episode that we recorded on May 12, Tim Cantrell, who joins me along with Scott Miller on Office Hours, he talked about a phishing campaign hitting a lot of inboxes. It is targeting website owners. So that’s definitely something to listen to. It’s yet another bitcoin scam hitting all of these inboxes. I’m excited that more of our team is going to be joining us for future episodes of Office Hours. It’s a heck of a lot of fun, especially since we miss seeing all of you at WordCamps.

Thanks for listening to Think Like a Hacker. Go ahead and give us a like or give us a review on Apple podcasts. Definitely join us over on YouTube. Follow me on Twitter and I’ll let you know what the whole Wordfence team is up to. Of course, if you’re not following Wordfence on your favorite social media, we are Wordfence everywhere, whether it is Instagram or Facebook or Twitter.

Give us a follow and we will keep you updated on all of the security news hitting WordPress. Thanks for listening and we will talk to you soon.

The post Episode 76: Ongoing Attacks on WP Growing in Volume Plus Numerous Plugin Vulnerabilities appeared first on Wordfence.

Vulnerability in Google WordPress Plugin Grants Attacker Search Console Access

Vulnerability in Google WordPress Plugin Grants Attacker Search Console Access

On April 21st, our Threat Intelligence team discovered a vulnerability in Site Kit by Google, a WordPress plugin installed on over 300,000 sites. This flaw allows any authenticated user, regardless of capability, to become a Google Search Console owner for any site running the Site Kit by Google plugin.

We filed a security issue report with Google on April 21, 2020. A patch was released a few weeks later on May 7, 2020.

This is considered a critical security issue that could lead to attackers obtaining owner access to your site in Google Search Console. Owner access allows an attacker to modify sitemaps, remove pages from Google search engine result pages (SERPs), or to facilitate black hat SEO campaigns. We strongly recommend an immediate update to the latest version of this plugin. At the time of writing, that is version 1.8.0 of Site Kit by Google.

Wordfence Premium customers received a new firewall rule on April 21, 2020 to protect against exploits targeting this vulnerability. Free Wordfence users will receive this rule after thirty days, on May 21, 2020.

Description: Google Search Console Privilege Escalation
Affected Plugin: Site Kit by Google
Plugin Slug: google-site-kit
Affected Versions: <= 1.7.1
CVE ID: Will be updated once identifier is supplied.
CVSS Score: 9.1 (Critical)
Fully Patched Version: 1.8.0

Site Kit by Google is a plugin used to obtain and display insights on a site’s visitors and search performance as well as advertising performance, page speed insights and other metrics from Google services in the WordPress dashboard. It does this by initially connecting to a Google Search Console account, later providing additional capabilities to connect to Analytics, AdSense, PageSpeed Insights, Optimize, and Tag Manager.

Site Kit by Google Dashboard.

In order to establish the first connection with Site Kit and Google Search Console, the plugin generates a proxySetupURL that is used to redirect a site’s administrator to Google OAuth and run the site owner verification process through a proxy.

proxySetupURL Disclosure

Due to the lack of capability checks on the admin_enqueue_scripts action, the proxySetupURL was displayed as part of the HTML source code of admin pages to any authenticated user accessing the /wp-admin dashboard.

More specifically, the admin_enqueue_scripts action triggers the enqueue_minimal_admin_script function which enqueues the googlesitekit-base assest and ultimately includes the ‘googlesitekit-base-data‘ that returns the inline base data. This includes the proxySetupURL.

	new Script_Data(
					'global'        => '_googlesitekitBaseData',
					'data_callback' => function () {
						return $this->get_inline_base_data();

Here is a look at the inline_js_base_data function that retrieves the data to display in the WordPress dashboard’s source code as part of the the admin_enqueue_scripts action. This includes the proxySetupURL.

	 * Modifies the base data to pass to JS.
	 * @since 1.2.0
	 * @param array $data Inline JS data.
	 * @return array Filtered $data.
	private function inline_js_base_data( $data ) {
		$first_admin_id  = (int) $this->first_admin->get();
		$current_user_id = get_current_user_id();

		// If no first admin is stored yet and the current user is one, consider them the first.
		if ( ! $first_admin_id && current_user_can( Permissions::MANAGE_OPTIONS ) ) {
			$first_admin_id = $current_user_id;
		$data['isFirstAdmin'] = ( $current_user_id === $first_admin_id );
		$data['splashURL']    = esc_url_raw( $this->context->admin_url( 'splash' ) );

		$auth_client = $this->get_oauth_client();
		if ( $auth_client->using_proxy() ) {
			$access_code                 = (string) $this->user_options->get( ClientsOAuth_Client::OPTION_PROXY_ACCESS_CODE );
			$data['proxySetupURL']       = esc_url_raw( $auth_client->get_proxy_setup_url( $access_code ) );
			$data['proxyPermissionsURL'] = esc_url_raw( $auth_client->get_proxy_permissions_url() );

		return $data;

A closer look at the data discoverable in the source code of the admin dashboard:

proxySetupURL found in the source code.

This was fixed in the latest version of the plugin by the addition of a capability check on the admin_enqueue_scripts action. This prohibits the inline_js_base_data from being included in administrative pages for users who do not have the appropriate privileges, such as subscribers. This prevents the proxySetupURL from being displayed to unauthorized users.

	add_action( 'admin_enqueue_scripts', $register_callback );
		add_action( 'wp_enqueue_scripts', $register_callback );

			function() {
				if ( ! current_user_can( Permissions::AUTHENTICATE ) ) {

Unprotected Verification

In addition to displaying the proxySetupURL to any authenticated user, we discovered that the verification request used to verify a site’s ownership was a registered admin action that, again, did not have any capability checks. This allowed verification requests to come from any authenticated WordPress user, including those with minimal permissions.

The admin_action_googlesitekit_proxy_setup action was registered here.

			'admin_action_' . Google_Proxy::ACTION_SETUP,
			function () {

			'admin_action_' . Google_Proxy::ACTION_SETUP,
			function () {
				$code      = $this->context->input()->filter( INPUT_GET, 'googlesitekit_code', FILTER_SANITIZE_STRING );
				$site_code = $this->context->input()->filter( INPUT_GET, 'googlesitekit_site_code', FILTER_SANITIZE_STRING );

				$this->handle_site_code( $code, $site_code );
				$this->redirect_to_proxy( $code );

This is the function that handles the verification request:

	 * Handles receiving a verification token for a user by the authentication proxy.
	 * @since 1.1.0
	 * @since 1.1.2 Runs on `admin_action_googlesitekit_proxy_setup` and no longer redirects directly.
	private function handle_verification_token() {
		$verification_token = $this->context->input()->filter( INPUT_GET, 'googlesitekit_verification_token', FILTER_SANITIZE_STRING );
		$verification_type  = $this->context->input()->filter( INPUT_GET, 'googlesitekit_verification_token_type', FILTER_SANITIZE_STRING );
		$verification_type  = $verification_type ?: self::VERIFICATION_TYPE_META;

		if ( empty( $verification_token ) ) {

		switch ( $verification_type ) {
				$this->authentication->verification_file()->set( $verification_token );
				$this->authentication->verification_meta()->set( $verification_token );

			function ( $params ) use ( $verification_type ) {
				return array_merge(
						'verify'              => 'true',
						'verification_method' => $verification_type,

Here’s a look at the verification request sent during the process:
/wp-admin/index.php?action=googlesitekit_proxy_setup&googlesitekit_code=[SITEKIT-CODE]&googlesitekit_verification_token=[VERIFICATION TOKEN]&googlesitekit_verification_token_type=FILE&nonce=[NONCE]

This was fixed in the latest version with a capability check added on the handle_verification_token function to verify that a verification request occurred during a legitimate authenticated session with a user that had administrative permissions to SETUP the Site Kit by Google plugin.

		if ( ! current_user_can( Permissions::SETUP ) ) {
			wp_die( esc_html__( 'Sorry, you are not allowed to do that.', 'google-site-kit' ), 403 );

These two flaws made it possible for subscriber-level users to become Google Search Console owners on any affected site.

The Impact

When a new owner for a property in Google Search Console is set up, a message is sent via email saying, “Property owners can change critical settings that affect how Google Search interacts with your site or app.”

There are several ways an attacker could make use of Google Search Console owner access for a site. For malicious attackers, the ability to manipulate search engine result pages through Blackhat SEO is particularly attractive. Additionally, an attacker could use search console access in conjunction with another exploit that involves malicious content being injected on a site for monetization.

An owner in Google Search Console can do things like request that URLs be removed from the Google Search engine, view competitive performance data, modify sitemaps, and more.

Unwarranted Google Search Console owner access on a site has the potential to hurt the visibility of a site in Google search results and impact revenue as an attacker removes URLs from search results. More specifically, it could be used to aid a competitor who wants to hurt the ranking and reputation of a site to better improve their own reputation and ranking.

Verifying the Integrity of Google Search Console Ownership

Fortunately, there are ways to verify and monitor if any new Google Search Console owners have been added and the Wordfence firewall provides your site with protection.

As our site cleaning team often sees malicious property owners in Google Search Console added to hacked sites, we’ve included some guidance from them.


Google will alert you via email whenever a new Search Console owner has been added. If you receive one of these emails and have not recently added a new Google Search Console owner, take immediate action and remove the unknown owner.

Verifying and Removing Unwanted Owners

Even if you haven’t received any emails from Google alerting you to the presence of a new Google Search Console owner, you can verify owners from the Google Search Console dashboard.

Checking for Google Search Console users:

  1. Log into your Google Search Console and go to “Settings.” This is where you will find “Users and Permissions.”

    Google Search Console settings location.

  2. Click on “Users and Permissions.” You will see a list of all the Google Search Console users with their name, email address, and role.
  3. Review the users listed. Verify that there are no unknown owners listed.

If you do discover a rogue Google Search Console owner, please take the following actions:

  1. Click the three dots next to the site owner you would like to remove.

    Removing owner.

  2. Click on “Manage property Owners.” Here you can see a log of verification requests and can determine when owners were added, along with the ability to unverify any site owners.

    Managing property owners.

  3. Click “Unverify” for any rogue owner you would like to remove. This will un-verify that account and revoke access to the search console account.

    Un-verifying site owner.

Extra Precaution

Site Kit by Google provides functionality to reset a site’s connection with Site Kit. If you discover that a rogue Google Search Console owner has been added, then we recommend taking the extra step to reset Site Kit by Google on your WordPress site.

Resetting Site Kit by Google:

  1. Log into your WordPress site, and navigate to the Site Kit by Google’s “Settings.”

    Site Kit by Google settings.

  2. Navigate to “Admin Settings” and click on “Reset Site Kit.” Confirm the reset by clicking on “Reset” when prompted. This will reset your Site Kit connection and require you to reconnect any Google services that were previously connected.

    Resetting Site Kit by Google.

Wordfence is Keeping you Protected.

We released a firewall rule on April 21, 2020 to Wordfence Premium users that will block any verification attempts that do not come from administrators, which ultimately provides protection against the creation of any unwarranted Google Search Console owners.

Due to some limitations, the firewall cannot prevent the ProxySetupURL from being displayed in the source code. However, the firewall rule blocking verification requests is enough to provide optimal protection on a site using a vulnerable version of Site Kit by Google.

Free Wordfence users will receive this rule on May 21, 2020.

Proof of Concept Walkthrough

Disclosure Timeline

April 21, 2020 – Initial discovery and analysis of vulnerability. Firewall rule was released for Wordfence Premium customers. We submitted the vulnerability disclosure through Google’s Vulnerability Reward Program, as this appears to be their primary vulnerability disclosure channel.
April 22, 2020 – The vulnerability report was triaged and assigned by the Google Security team.
April 30, 2020 – The Google Security team notifies us that the vulnerability was verified and a bug was filed.
May 4, 2020A commit appears in Site Kit by Google Github Repository that appears to provide a patch for the vulnerability.
May 7, 2020A patch was released.
May 21, 2020 – Free Wordfence users receive firewall rule.


In today’s post, we detailed a flaw that allowed low-level WordPress users the ability to become a Google Search Console owner by exploiting a vulnerability in the Site Kit by Google plugin. This flaw has been fully patched in version 1.8.0. We recommend that users immediately update to the latest version available.

Sites running Wordfence Premium have been protected from attacks against this vulnerability since April 21, 2020. Sites running the free version of Wordfence will receive this firewall rule update on May 21, 2020. If you know a friend or colleague using this plugin on their site, we strongly recommend forwarding this advisory to them so that they can update and protect their Google Search Console account and WordPress site.

The post Vulnerability in Google WordPress Plugin Grants Attacker Search Console Access appeared first on Wordfence.

Pin It on Pinterest