Patchstack Weekly #32: Are Millions of WordPress Sites Really Under Attack?

Welcome back to the Patchstack Weekly Security Update! This update is for week 29 of 2022.

This week’s weekly knowledge share is a response to the all too common headlines about “Millions of WordPress websites are under attack” we see every so often.

I will share why attempted attacks are just the background radiation of the Internet and not something to get into a panic over.

This week’s weekly knowledge share was supposed to be about SSRF. I had all my notes written but then I came across a headline about millions of WordPress websites being under active attack in my news feed.

I did some review of what was being reported, and I felt it best to remind everyone:

Don’t Panic

Here is why: When has panicking helped an already bad situation? We can be persuaded into acting without thinking things through if we give way to panic. There is an alternative though – look into some facts instead.

I run a few personal blogs and after reading this article about millions of attacks I wanted to see what attacks I could spot in my own websites’ logs.

Finding attacks everywhere

Brushing off a little Linux shell know-how, we can sort a web server’s access.log using grep, AWK and a few sorting commands. Here is how we can see how many attempts to log in to my website(s) wp-login.php were made in the last day:

$ grep wp-login.php access.log | awk '{print $6" "$7"\""}' | sort | uniq -c | sort -n
    2 "GET //wp-login.php"
    3 "GET /wp-login.php?wp_lang=en_US"
    3 "POST /wp-login.php?wp_lang=en_US"
    6 "POST //wp-login.php"
    169 "GET /wp-login.php"
    338 "POST /wp-login.php"

This cool little shell one-liner parses out all of the requests to wp-login, pulls out applicable columns (using AWK) and counts how many attempts were made for each unique URI.

The output of the one-liner shows 338 attempts to POST (or requests that sent credentials) to wp-login.php in one day only. Like many personal blogs, I am the only user, and I haven’t attempted to log in to the website. So, I can conclude that all of these 338 POST requests to /wp-login.php were “attacks”.

These attacks can be classified as brute force attempts. Specifically – unsuccessful brute force attempts. Unsuccessful, because I practice good password hygiene and have 2FA enabled even on a small blog. So, these attempts pose no risk.

This evidence of attempted attacks is not newsworthy. It is reported that WordPress powers over 455 million websites. We could extrapolate 300 brute force attempts per WordPress website, per day, into an article about 136 billion brute force attempts per day against WordPress websites.

Yet, 136 billion attacks per day would still not be newsworthy. Unsuccessful attacks are the background radiation of the internet. It’s important to know they are there so that you can take reasonable precautions, but it is not an emergent risk. It is not the sort of thing that deserves a headline.

Detecting probes

Let’s do some more digging into the logs. I want to see if we can find any activity of a bot actively trying to look for vulnerable components or make a profile for what components the website is running.

A rudimentary way to do that is to look for requests to the readme.txt files.

$ grep readme.txt access.log | awk '{print $6" "$7"\""}' | sort | uniq -c | sort -n 
    1 "GET /wp-content/plugins/ninja-forms/readme.txt

Looks like I found a request to check if my site is running the ninja-forms plugin. I don’t even use Ninja Forms on this site, but I bet this is related to the Ninja Forms security bug which was patched just a few weeks ago! If you remember (or read the blog post about this) the Ninja Forms developers requested a forced auto-update due to the risk this security bug posed.

Looks like that was a good decision. Bots are actively looking for sites running insecure versions of Ninja Forms, and those bots are going to come up empty-handed thanks to the forced auto-update and efforts from the WP.org team.

Looking for unexpected scripts

For one final check, I want to find all requests for unexpected .php scripts. The following bash one-liner will also include the response code from the web server, this is important so we can determine if the request was successful or not.

$ grep \.php access.log | awk '{print $6" "$7"\"" "$9}' | sort | uniq -c | sort -n | grep -v "\(wp-cron\|wp-login\|xmlrpc\)\.php" | tail 
    1 "GET /wp-config.php" 404
	1 "GET /wp-content/1index.php" 404
	1 "GET /wp-content/indeeex.php" 404
	1 "GET /wp-content/indeex.php" 404
	1 "GET /wp-content/radio.php" 404
	1 "GET /wp-content/wp-options.php" 404
    1 "GET /wp-logs.php" 404
    1 "GET /wp-options.php" 404
    1 "GET /wp-signup.php" 404
    1 "GET /wp-signups.php" 404

How interesting! I found a lot of requests for random .php files (hundreds in total, I had to reduce the output in the example above) and none of these files existed on a web server. Well, there is one request for wp-config.php which was an attempt to access secret data within, which was as unsuccessful as the rest. The HTTP response codes I included help show me the files did not exist when requested, the HTTP response code is always “404” or file not found.

What have we learned looking through logs, and how does that apply to headlines about “millions of sites being attacked”?

Yes, sites are being attacked (we can see that) but that is not the same as sites being compromised. The response code for most of these attempts was “404”, not found. “Not found” is how anyone who follows security best practices should feel when they read these hyperbolic headlines or articles: 404, threat not found.

A better headline could be:

Millions of failed attacks

It is true that WordPress sites are targeted every day. It comes with the territory of being the most popular CMS on the internet. Attempts to brute force passwords are a universal threat, followed by a long tail of attempts to look for and exploit insecure components. So, this is why the best WordPress security advice (for site owners) is to make sure you have good passwords (2FA if possible) and do not run insecure components (patch or replace).

Attempts to attack websites are real. But, your response to them should be to make sure you know who the people responsible for securing your website(s) are taking the proactive steps to protect websites, and not just clean up after the fact. If you’re responsible for the security of websites, and you’re unsure what to do, consider implementing a security solution like the Patchstack App which will alert you if your sites are running insecure components.

Don’t buy into panic-driven rhetoric. Be calm, follow security best practices, and carry on.

Vulnerability news

WSM Downloader – Unauthenticated Arbitrary File Download

The WSM Downloader plugin has multiple public security bugs being reported in the codebase. Unfortunately at this time, it appears there are no patches available for these security bugs, the plugin might have been abandoned. This emphasize the importance of avoiding abandoned WordPress plugins.

Youzify – Unauthenticated SQL Injection

The Youzify plugin, which is a BuddyPress Community, User Profile, Social Network & Membership plugin for WordPress patched an unauthenticated SQL Injection recently. If you have not yet patched to the most recent version of Youzify then you will want to take action ASAP.

GiveWP – Authenticated Arbitrary File Creation

The popular GiveWP plugin, with over 100,000 active installations patched multiple security bug, including one authenticated arbitrary file creation vulnerability. The good news is this security bug would require a high-privilege account on the site to perform. So, patch soon, but remember: don’t panic.

Thanks and Appreciation

This week’s thanks are given to the developers of GiveWP and Youzify plugins. Thank you for supplying those important security patches for your users, and keeping their sites secure.

This week’s special thanks goes out to GiveWP. It may be odd to thank them twice, but this time this thanks is for their mission what a great plugin to help WordPress websites seamlessly integrate fundraising features into their projects.

I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!