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.