There is no denying WordPress’ dominance on the web. It’s used by almost every major organization in the world, and is the platform of choice for a lot of first time entrepreneurs. And if you ever want confirmation, just look at what hosting companies are focusing on. They all dedicate countless resources to streamlining its deployment, and work hard to reducing the onboarding friction for WordPress users.
Even with all that, what has made WordPress so popular amongst online user is also it’s biggest weakness – its extensibility.
It’s because of this that it’s imperative that WordPress owners realize that deploying a WordPress site is step 1 of a series. The subsequent steps should include the basics of security and maintenance routines, in addition to the applications configuration.
A couple of weeks ago, I installed a new WordPress site, along with a number of other CMS applications (e.g., Drupal, Joomla!, etc…), to run some tests on our Content Delivery Network (CDN) and test the effectiveness of our Website Application Firewall (WAF). It took us less than 30 minutes to have our instances running, but took only two hours before we started seeing malicious traffic.
Malicious traffic would constitute anything that is looking for something that may or may not exist, or trying to actively exploit a vulnerability.
As expected, the attempts were coming from a compromised host on M27 (IP: 193.176.84.xx). You can clearly identify the automation through the successive requests in a short time period.
First, it tried the arbitrary file download vulnerability on the Duplicator WordPress Plugin (exploit from 2020). This vulnerability allows attackers to download any file from the system:
193.176.84.xx 17/May/2021:05:33:34 +0000 "GET /wp-admin/admin-ajax.php?action=duplicator_download&file=../wp-config.php HTTP/1.1" 200 1 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
They didn’t even check to see if it was installed, they just tried to blindly download the wp-config.php file. It returned 200 (success), but that doesn’t mean the exploit succeeded, just that the web server was able to find the file and return the content properly.
Next, it tried to download the wp-config.php file by leveraring another Arbitrary File Download vulnerability in the RevSlider plugin (circa 2014):
193.176.84.xx 17/May/2021:05:33:34 +0000 "GET /wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php HTTP/1.1" 200 1 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
While I personally hope no one is running that outdated of a plugin version, experience tells me it’s still very possible. The fact that it is still part of a bots script also tells me that it’s still providing effective.
Next up was another oldie, but goodie, the Cherry Plugin (circa 2016). This one, similar to the others, was a vulnerability that allowed attackers to download and upload random files to the vulnerable site.
In this case, they only tried to download the wp-config.php file:
193.176.84.xx 17/May/2021:05:33:35 +0000 "GET /wp-content/plugins/cherry-plugin/admin/import-export/download-content.php?file=../ ../ ../ / wp-config.php HTTP/1.1" 403 203 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
Because of the type of vulnerability, if that succeeded they’d likely proceed with uploading their backdoors.
The next in line was the MiwoFTP plugin (circa 2015). Again, another Arbitrary File Download vulnerability.
193.176.84.xx 17/May/2021:05:33:35 +0000 "GET /wp-admin/admin.php?page=miwoftp&option=com_miwoftp&action=download&dir=/&item=wp-config.php&order=name&srt=yes HTTP/1.1" 403 206 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
It allows for random file downloads and the attackers chose to try to get the wp-config.php file. This one returned 403, because we had access to wp-admin blocked by default at the web server level.
The next one was again an Arbitrary File Download vulnerability, this time in the CodeArt Google MP3 Player plugin (circa 2014). Similar to other attempts, attackers were trying to download the wp-config.php file.
193.176.84.xx 17/May/2021:05:33:35 +0000 "GET /wp-content/plugins/google-mp3-audio-player/direct_download.php?file=../../../wp-config.php HTTP/1.1" 403 203 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
Attacks are automated and agnostic to your business. It is why it is so important to harden and secure your WordPress instances (both new and old ones). Not every host is the same, even those that offer Managed WordPress will often draw a line in security between what they focus on, and what you’re responsible for. Have an active conversation with your host to clearly understand where that delineation is.
While the attacks above were focused on older vulnerabilities, they exist because they are still used in the wild. While unlikely that a new instance would have them, it is possible if a user installs a “free” version from somewhere other than the WordPress plugin repo. The same is not true for existing instances, where we know the risk increases because of poor maintenance by website owners.
Basic hardening tips like killing PHP execution in key directories (e.g., uploads, wp-admin) is essential, and one of the most effective hardening techniques any WordPress administrator can deploy:
Killing PHP Execution
deny from all
We’ve been helping organizations look after their websites for over a decade, and have helped millions of websites around the world. If there is one thing we have learned is that not everyone wants to spend their day analyzing and thinking of security threats. Thankfully, that’s why organizations like NOC exist.
If this is all just too much, and you prefer to not think about it, then we highly recommend leveraging a Website Application Firewall (WAF) service. We have one here, and others exist as well. At it’s core, they are designed to help stop these unnecessary scans, and most importantly stop them from being successful if your site is susceptible to one of them.
If there is anything we can help answer, we’re here to help firstname.lastname@example.org