The NoneNone Brute Force Attacks: Even Hackers Need QA
For the last few weeks we’ve seen and blocked an increase in brute-force, credential stuffing, and dictionary attacks targeting the WordPress xmlrpc.php endpoint, on some days exceeding 150 million attacks against 1.9 million sites in a 24-hour period. These attacks attempt to guess the password of an authorized user on a site, and some of our users have noticed an odd phenomenon: brute force attacks with the username and password set to “None” or “NoneNone”. Since these requests are targeted against xmlrpc.php, changing the admin URL won’t prevent attackers from sending these requests.
What’s going on?
Because these attacks are attempting to login with unusual credentials, we’ve had curious site owners reach out to ask what might be happening. We’ve determined that the attackers are generating lists of domains to attack complete with credentials to attempt and that there is likely a flaw in the code of this target generation program.
In addition to reviewing our own attack data, we were able to find logs and domain lists that appear to have been used by the scripts performing these attacks.
These domain lists appear to have been generated programmatically and include a target to attack, a username to attempt, and a password to attempt. In the domain lists we found, “NoneNone” was frequently used as a username in cases where a real username was unknown to the attacker. In some lists, this was paired with a nonsense password such as “qwe123”, while in others the password would also be set to “NoneNone”.
It’s likely that the script used to generate these domain lists are written in Python, a language that has a “None” type that is equivalent to “Null” in other languages, and which is printed out as “None” when cast to a string. As such, a script to generate domain lists to attack could have set the username and password variables to default values of None (or concatenated multiple default values, resulting in “NoneNone”) when provided with incomplete information.
What should I do?
If you’re using Wordfence, our built-in brute force protection will protect your site against XML-RPC attacks. This is important because some of these attacks will be trying real usernames and passwords from credential breaches rather than invalid values. Additionally, sites running Wordfence Premium will automatically block any requests from IP addresses that have been attacking other sites in our network thanks to our real-time IP blocklist.
For an extra layer of protection, both free and premium users can disable attempts to authenticate via xmlrpc.php requests entirely by going to Wordfence->Login Security->Settings and clicking Disable XML-RPC authentication.
Please note that this can prevent certain plugins that rely on xmlrpc.php, such as Jetpack, from functioning properly.
Conclusion
Although we’ve seen a very large number of these attacks, the vast majority of them are unlikely to threaten sites unless the site administrator is using credentials that have been compromised. Nonetheless, this goes to show that scripts used for hacking can have bugs and unexpected behavior just like any other software.
Sites running the free version of Wordfence are protected by our built-in brute force protection, and sites running Wordfence Premium are additionally protected by the real-time IP blocklist. Both free and premium Wordfence users can disable XML-RPC authentication for full protection against attacks against this endpoint.
This article was written by Ramuel Gall, a former Wordfence Senior Security Researcher.
Comments
7:53 am
Thanks for staying on top of this. I had noticed this on a number of sites that I maintain
8:00 am
I don't pretend know even close to what you guys know, but I found this mod to .htaccess about 3 months ago that stops any xmlrpc attacks:
Modify .htaccess with following code to prevent unauthorized logins via xmlrpc.php:
# Block WordPress xmlrpc.php requests
order deny,allow
deny from all
allow from 123.123.123.123 (remove this line unless you need remote access w/o browser)
What do you think?
8:38 am
Hi jim,
If you don't need XML-RPC functionality this would work if your site is running Apache, we just wanted to make it as easy as possible for our less technical users to disable XML-RPC functionality as well.
(edit) as you mentioned in your second comment, it looks like the comments filter stripped out some tags.
8:02 am
Thank you for providing such an exceptional service for all of us.
8:04 am
Thank you for your continuous diligence! Will two-factor authentication help prevent these unauthorized access attempts, or would authenticating through XML-RPC bypass 2FA?
8:36 am
Hi Jim,
We actually provide a separate setting in the Login Security menu, "Require 2FA for XML-RPC call authentication", if you'd like to ensure that XML-RPC requires a 2FA code as well.
9:06 am
Ah, forgot about that setting. Thank you!
1:16 pm
So, would Jetpack or a plugin work if XML-RPC calls required 2FA?
2:18 pm
Hi John,
Currently we're not aware of any plugins, including Jetpack, that work with 2FA, but it is possible to create applications that make use of 2FA for XML-RPC calls and we hope to see this as an option in the future.
8:06 am
I noticed your filter excluded 2 lines of code:
1) at the beginning... files xmlrpc.php surrounded by
2) at the end... /files surrounded by
8:10 am
Thank you, I was wondering what the NoneNone issue was as I was getting alerts from 'them' one every hour from all over the world. I disabled the XPL-RPC feature and I have the bad login feature set to deny the user for two months. NoneNone seems to travel around the world pretty quickly, he/she must have a Tardis! Way to go Wordfence!
8:44 am
In the Wordfence settings i immediately blocked any IP using "NoneNone" as a login name. It immediately stopped all the attempts across all my sites. Does this not achieve the desired level of protection or is there something i'm missing? Thank you.
11:25 am
That works, too, but only for that particular username. Should the attacker attempt to use a different username, that attack would not be blocked that way.
8:49 am
Do you think there is value in leaving the email alerts enabled for when an IP address is blocked and / or when someone is locked out from login? I left these on for the longest time, but was getting tons of those emails and considering I don't really take any action when somebody IS locked out (unless they're a team of our team), I decided to turn off the alerts. Would it be a good idea to re-enable these, and if so, is there anything in particular a site owner should do when they see that an unauthorized user has been blocked / locked out?
1:49 pm
Every site is different, so an alert strategy is going to be different for each site. It's a balancing act to tune alerts to your needs. Too many alerts can cause alert fatigue, which can cause site admins to miss important data. But, if you do have users that get locked out frequently, it can be good to be alerted of these lockouts so you can take proactive steps to help them, especially if they are paying customers. When unauthorized users are locked out, nothing to do other than have the peace of mind that Wordfence is protecting your site.
9:01 am
Used the steps to disable xml-rpc authentication. Clicked on Skipped for JetPack. Question, should I deactivate the JetPack plugin altogether? I have a message from jetpack that it needs XML-RPC authentication to work correctly, as mentioned in the article. What effects of not using JetPack will I see on my website?
1:55 pm
Jetpack has a number of features that many WordPress users are taking advantage of, from site statistics to social media account connections. You'd need to know which elements you're using. If you're not sure, check with your site's developer to find out if your site's functionality requires Jetpack. If it was auto-installed by your hosting provider, you could check with them and determine what elements may or may not be used by your site.
9:08 am
Thank you for this info.
These guys have been at it for the past week or so and driving me crazy. The large pool of IP addresses they are using is mind boggling. In any case, I've always applied a policy of blocking all login attempts to xmlrpc.php. Notifying the web hosting services of various cloud services to investigate is pretty much a waste of time.
9:49 am
Could this be part of getting 'fingerprint information' because it doesn't make sense really otherwise?
2:33 pm
Hi,
These attacks could be used to determine whether xmlrpc is enabled in the first place but some of them are using what appear to be leaked credentials. Bear in mind that these scripts mostly run on sites that have already been taken over, so the cost of sending attacks is fairly minimal to the attacker.
10:12 am
Thanks for the information.
I'm seeing attacks using familiar email addresses, and older usernames (like from old sites); Probably the same sort of thing? I've been managing that same set of sites for years, so I recognize some of the emails because of the small group we work with.
1:58 pm
If older emails and usernames are being used, those may have ended up in breached credential sets at some point. Make sure you're using strong, unique passwords and two-factor authentication and you should be fine.
10:44 am
My Wordfence blocks these IP addresses for 2 months after unsuccessful attempts.
Every other user of Wordfence blocks these IP addresses for x months after unsuccessful attempts.
Does Wordfence recognize that thousands of people have blocked a specific IP address and automatically blacklist them?
1:59 pm
Wordfence Premium contains the real-time blocklist, which is a rolling blocklist based upon malicious activity detected by Wordfence. The IP addresses are blocked from accessing sites using Wordfence Premium.
10:48 am
How did you pull out the "NoneNone" password from the attackers' requests?
1:45 pm
We're seeing this in logged usernames of failed login attempts. You can see these in the failed logins in the Wordfence firewall dashboard on your site where both successful and failed logins are listed.
10:49 am
I noticed quite a few attacks on my primary site and some on secondary sites with None and NoneNone as usernames also some what might have been compromised emails from similar sites and businesses.
I did a manual immediate block on these user names.
10:52 am
Is there any way for me to check if my plug-ins need xmlrpc.php to function?
1:43 pm
Jetpack is the most widely known plugin using XML-RPC. You can check with plugin developers to determine if your plugins are using it, or you can run tests on a staging server to isolate any plugins that are using it by turning it off on a site in a test environment.
12:03 am
Indeed it had been noted before, for a few weeks occuring daily about once a day. It has a nuisance value but I felt it would not get far.Your settings suggestion will help but I will still make the IP blocks permanent. We use sensible passwords that would take GCHQ about 2 million years to crack.
2:38 am
I had these attack on all my websites, I was wondering what happened with this NoneNone. I've marked as permanent block with my wordfence plugin and will se for the XLM RPX (but one of my website use jetpack). Thank you for your security service on top !
Cecile from France
1:45 pm
I saw this and thought "what vulnerability do I not know about that this is attempting to target? What would add NoneNone to a WordPress user list for someone to target?" Now we know. Thanks!
2:19 pm
The user name I see most often in brute force login attempts in "[login]". I wonder what kind of low-quality code is causing that.