Large Scale Attack Campaign Targets Database Credentials
Between May 29 and May 31, 2020, the Wordfence Firewall blocked over 130 million attacks intended to harvest database credentials from 1.3 million sites by downloading their configuration files.
The peak of this attack campaign occurred on May 30, 2020. At this point, attacks from this campaign accounted for 75% of all attempted exploits of plugin and theme vulnerabilities across the WordPress ecosystem.
We were able to link these attacks to the same threat actor previously targeting XSS vulnerabilities at a similar scale. All Wordfence users, including Wordfence Premium and those still using the free version of Wordfence, are protected by our firewall’s built-in directory traversal protection.
Different vulnerabilities, same IPs
The previously reported XSS campaigns sent attacks from over 20,000 different IP addresses. The new campaign is using the same IP addresses, which accounted for the majority of the attacks and sites targeted. This campaign is also attacking nearly a million new sites that weren’t included in the previous XSS campaigns.
As with the XSS campaigns, almost all of the attacks are targeted at older vulnerabilities in outdated plugins or themes that allow files to be downloaded or exported. In this case the attackers are attempting to download wp-config.php, a file critical to all WordPress installations which contains database credentials and connection information, in addition to authentication unique keys and salts. An attacker with access to this file could gain access to the site’s database, where site content and users are stored.
Indicators of Compromise
Attacks by this campaign should be visible in your server logs. Look for any log entries containing wp-config.php in the query string that returned a 200 response code.
The top 10 attacking IP addresses in this campaign are listed below.
200.25.60.53
51.255.79.47
194.60.254.42
31.131.251.113
194.58.123.231
107.170.19.251
188.165.195.184
151.80.22.75
192.254.68.134
93.190.140.8
What should I do?
Sites running Wordfence are protected against this campaign. If your site is not running Wordfence, and you believe you have been compromised, change your database password and authentication unique keys and salts immediately.
If your server is configured to allow remote database access, an attacker with your database credentials could easily add an administrative user, exfiltrate sensitive data, or delete your site altogether. Even if your site does not allow remote database access, an attacker who knows your site’s authentication keys and salts may be able to use them to more easily bypass other security mechanisms.
If you’re not comfortable making the changes above, please contact your host, since changing your database password without updating the wp-config.php file can temporarily take down your site.
Conclusion
In today’s post, we covered another large-scale attack campaign against WordPress sites by a threat actor we have been tracking since February. All Wordfence users, including sites running the free version of Wordfence, and Wordfence Premium, are protected against these attacks. Nonetheless, we urge you to make sure that all plugins and themes are kept up to date, and to share this information with any other site owners or administrators you know. Attacks by this threat actor are evolving and we will continue to share additional information as it becomes available.
This article was written by Ramuel Gall, a former Wordfence Senior Security Researcher.
Comments
8:17 am
Thx for the info! Is a 200 response code for the config file in my logs but with no bytes transfered(0) dangerous? I think not but i'm a newbie.
8:23 am
Hi Daniel!
Some configurations might return a 200 response code even if the request was unsuccessful (though a 404 or a 301 would be more common). In these cases if no bytes were transferred then you should be in the clear.
8:29 am
I had a compromise on June 1, a post in French advertising an adult site. No evidence in the logs, all site protected by wordfence etc. Is this possibily related?
8:40 am
Hi Scott,
Since both the free and premium versions of Wordfence protect against the attacks used in this campaign, it's unlikely that your compromise was related. If you weren't using 2-factor authentication and couldn't find anything in the logs, it's possible that your site was compromised due to password reuse. This is common if you used your WordPress password in another location which suffered a data breach. Fortunately both the free and premium versions of Wordfence also provide a 2-factor authentication solution, though it might still be a good idea to change all passwords on your hosting account, including your database password.
8:34 am
Thanks for answering me so fast!!
8:55 am
Just realized that an error prevented my firewall rules from being updated just prior to this attack. The last update was May 23. Would the site still be protected?
9:08 am
Hi Amy,
Your site should be safe since the rule that protects against these attacks has been available to all of our users for a long time, and the existing rules remain in place even in cases where the rules fail to update.
8:58 am
Any way to get a full list of the offending IPs? I have no qualms blocking them entirely at the OS level.
9:22 am
Hi Chuck,
I'm afraid we don't currently share data at that scale. We were able to identify roughly 20,000 IPs sending the bulk of the attacks which allowed us to link the attacker to a previous campaign, but tens of thousands of other IPs sent attacks at a lower volume during this period as well.
9:29 am
Wouldn't apache have to output wp-config.php as text for this attack to have been successful?
9:53 am
Hi Ron,
There's actually a pretty large range of vulnerabilities being attacked here - most of them are in themes or plugins designed to allow file downloads by reading the content of a file requested in a query string and then serving it up as a downloadable attachment. You're correct that directly accessing and viewing the contents of the wp-config.php file itself isn't possible in sane configurations.
11:00 am
Makes sense now. Thanks!
1:49 pm
We use the FREE WF version and two IP's attacked the website 2 days back and it was blocked by WF. However as a best practice should we BLOCK all the IP Addresses listed above?
9:44 am
Hi Dan,
Typically attackers rotate through a number of different IP addresses, so you may not want to permanently block attacker IPs. This particular attacker seems to be using the same IPs in multiple attacks, and if you're seeing a lot of attacks from a given set of IP addresses then it may be worthwhile to at least block them temporarily.
6:44 pm
Hai, should be all database have to change password? Because I have many sites
9:47 am
Hi dzouuu,
You do not need to change your database passwords unless you have reason to believe that one of your sites has been compromised. With that said, if you are hosting multiple sites on a single hosting account and one of them becomes compromised for any reason, then you should assume that all of them have been compromised.
3:33 pm
Hi. I received email from wordfence, My site already installed wordfence plugin, is it still safe?
9:26 am
Hi Moh Luthi,
If your site has Wordfence installed, then you should be safe from these attacks.
4:27 pm
It's a situation that's been going on since before. I made a post commenting on this situation last May 28th. These are not only configuration files, but also dumps and backups of the CMS itself. You can see the post in spanish with real logs at https://www.alferez.es/sistemas/seguridad-sistemas/usuario-problema-ciberseguridad-botnet/
4:39 am
"if you believe you have been compromised, change your database password and authentication unique keys and salts immediately."
If wp-config.php is accessible, I'm not sure what point changing the DB password/salts would have - you're already compromised.
9:30 am
Hi Dev,
We do urge everyone to make sure that all plugins and themes are up to date in the conclusion, which should prevent any updated credentials from being stolen - wp-config.php isn't being accessed directly, instead these attacks targeted outdated plugins and themes that may have allowed wp-config.php to be downloaded.
7:03 am
Can you give some technical examples!
"In this case the attackers are attempting to download wp-config.php" - can you go into detail - what method they are using to do this!
9:32 am
Hi Joe,
Here's some of the exploit attempts we're seeing most frequently, but there are hundreds of different exploits being attempted. The only thing they really have in common is that they're all attempting to download or access wp-config.php:
https://www.exploit-db.com/exploits/40850
https://www.exploit-db.com/exploits/46252
https://www.exploit-db.com/exploits/39291
https://www.exploit-db.com/exploits/36554 (This one has CVE-2014-9734)
https://www.exploit-db.com/exploits/36733 (This one has CVE-2015-9406)
https://www.exploit-db.com/exploits/37559
https://www.exploit-db.com/exploits/37530 (This one has CVE-2015-5468)
https://www.exploit-db.com/exploits/35460
https://www.exploit-db.com/exploits/35493
https://www.exploit-db.com/exploits/46537 (This one has CVE-2019-9618)
12:14 pm
I change my database password and authentication keys and salts once a year. Just in case.