Rate-limiting login attempts out-of-the-box is something Wordpress should have included a LONG time ago. Maybe 1% of installs will setup the plugin to do this. No idea why they haven't added this yet.
Yep, I have to develop 'WordPress sites' sometimes and the only consistency is its awfulness. It's the PHP of PHP.
Having a default username in the first place is incredibly poor practice. So many users stick to 'admin', making it just a case of guessing the password.
And don't get me started on that bloody "the loop" finite state machine. I mean, really?
I actually find Wordpress to be much lighter and cleaner than many other CMS systems. It's impressive to me that the code is relatively consistent despite going through years of iterations. I also find the plugin mechanics of Wordpress to be simple to understand. It's got plenty of room for improvement but I think it's got a lot of good qualities too.
It has been consistent, all right. Consistently terrible. For years.
Every time I duck under the hood to debug something I always come away stunned and disturbed by the frequent use of globals, the frequent interleaving of different concerns and basically the all-round untraceability of the design as soon as themes or plugins are added. It's horrid.
Oh! And there are still no unit or functional tests. And no concept of release management (such as having security patches released independently of feature patches), which is why every Wordpress administrator gets to play their favourite game when there's a new release: continue with known-security-flaw code, or install code that might just blow away your data?
Yeah that hits home. I build Wordpress websites daily and also manage a number of them which are years old and I had no hand in making. Pressing that update button on some of these sites really is like russian roulette.
Well the entire style of WordPress uses the global namespace for everything so you do have to get over that shock. But, once you do there's a kinda simplicity to the whole thing. That's my impression anyway.
That's usually the first mod done for clients who insist on using WP. For a few clients specifically, we don't let any users set their passwords at all; they get a randomly generated password upon registering or reset;
WP is a good platform that does a lot out of the box (performance could use some work too though), so I don't think we should throw the baby out with the bathwater. There's just some housekeeping that needs to be taken care of beforehand.
The alternative, of course, is building something custom with the bare minimum of necessities server-side and scrubbing all input/global vars. A lot of flexibility can still be retained by implementing a taxonomy system that define what posts can be (which is pretty much a very loose Entity-Attribute-Value model).
Ditto for BWPS. You always want to pick plugins where the developers are actively participating in the community and regularly staying on top of any potential security issues.
Unfortunately it doesn't look like that would do any good here.
With over 200k different botnet controlled machines, all that tracking the IP sources would do here is create massive blocklists. There's already evidance growing that the botnet is trying 2-3 passwords per source IP - effectively bypassing existing limiting plugins.
A solution to the above is to limit the logins per account per timeframe, but that just locks the legitimate users out, causes the botnet to spread out the attack over longer periods, and ultimately only has a negitive affect for the user.
The Hosts are feeling the pain though, i've seen some hosts are disabling access to wp-login.php entirely, this tells me that the shared hosts are having resource issues, so a limit-login style plugin would do zero to help them, it'd still cause massive problems for the host.
WordPres, Joomla, and other smaller CMS's are being targetted here, so this is by no means just WordPress's problem either.
I get what you're saying but if the default setup were to rate-limit per-account logins, there'd be little reason for these botnets to do what they're doing. They don't want to block admin access to their CMS. They want to have actual access. Effective rate-limiting per-account would kill the effectiveness of their efforts.
Indeed a massive pain. I've been getting alerts from dreamhost regarding increased memory usage. I have http://www.wordfence.com/ installed and my blocklist only increases.
Simply use five random dictionary words as a password and you are fine. The browser will store then the password easy login.
Two-facor auth just adds to complexity, and that is a bad thing when it comes to secutiry. You want to be able to easily understand that a system is secure. The more complex a system is, the larger the likelyhood of a surprise "whoops, I overlooked that" somewhere down the road.
A great password won't protect you or your clients from keyloggers, writing the password on a post-it to stick to a monitor, shouting it across an office, emailing it to a friend's 'web genius' kid so he can fix that thing that's broken, and a dozen other password misadventures.
Two-factor auth is not just about rendering dictionary attacks ineffective.
How so? Assuming about 100,000 common words in the English language, with a five word phrase aren't you talking about 10000000000000000000000000 combinations for a dictionary attack to churn through? Even if you narrow it down to phrases that make grammatical sense (which certainly isn't a trivial thing to do algorithmically), you're still talking pretty astronomical numbers, and that doesn't account for the large increase in the corpus that would be needed for an attack that could include a name like "miffy" in its attempts.
But if the attacker knew with good probability that your passphrase is a valid sentence, they'd have ways to eliminate incorrect sentences, and so reduce the search space a bit (or a bit more, depending on how clever they are).
Have you ever used SwiftKey or Swype on Android? Vaguely the same principles apply here. It actually wouldn't be hard to generate passphrases where you try the most "predictable" phrases first. E.g. if you start your brute-forcing at "my cat" you would try "my cat likes" a long time before you tried "my cat algorithmically".
Also, 100,000 common words is a bit more than you would need. If people are plucking words from their heads, rather than rolling dice and picking from a list, you can assume a more limited corpus and still crack a lot of passwords.
Nobody starts brute forcing at "mycat." Even if they somehow knew that's how it started, that barely helps them. They don't know how many other words there are, or what the next one is. Simply because it is more likely to be "my cat likes" does not mean it is now feasible to crack. Without social engineering, that password is not crackable for all practical purposes and is far from a terrible password.
No, but we're talking about brute forcing billions of attempts per second, and we're not up against randomness, we're up against "the best pseudorandomness the human brain can muster", so the odds aren't 1 / <number of possibilities>. A password is severely weakened if it isn't sufficiently random.
One problem is that WordPrss sites are often built by small web designers for clients with limited computer skills and very little patience for complex passwords, much less two-factor authentication.
For 2/3 of the WordPress sites I administer, I use a very long, complex admin password. The other site is for a group that wanted multiple admin accounts, but the people who use these accounts have a lot of trouble with complex passwords. After several emails telling me that "the website doesn't work" because the user had trouble with a long password with special characters, I gave up and switched it to an easy-to-remember password with just uppercase and lowercase letters.
Or just generate random 15+ character passwords for admin accounts. From the article it appears the concern is from brute forcing "admin" account passwords. Good luck bruting MT#r!}A1(hIQ4^pC*7`K.KGiL\&[A\k#TUC4R<R?
I dont think it's practical to rely on memory for passwords anymore. If it's a site you really couldnt give a damn about, then sure, as long as you're okay with whatever information you submit being potentially linked to that password and to any other information.
I just use a text file on my computers desktop and a usb thumb drive. I don't note what the password is for. So my Amazon password is something like dkwjRw#4camzR4%7hjfgdelsdshWE
"...the distributed attacks are attempting to brute force the administrative portals of WordPress servers, employing the username "admin" and 1,000 or so common passwords."
I'm a little surprised that such a simple attack vector is a legitimate threat in creating a "super botnet."
On older Wordpress installs (pre-3.0 I believe), you couldn't change the username of the first user from "admin" when setting up a blog, and you had to manually change it later. Yes, it was stupid.
I remember having to perform some magical incantation to actually pull that off around then. Set up WP, log in, create new user, set it as admin, log in as the new user, try to delete the admin account, log back in as admin because you forgot something, log in as the new user again, actually delete account.
Exactly what I thought when I read "Operators of WordPress sites can take other measures too, including installing plugins such as this one and this one, which close some of the holes most frequently exploited in these types of attacks. Beyond that, operators can sign up for a free plan from CloudFlare that automatically blocks login attempts that bear the signature of the brute-force attack.".
Then I saw the source for this "news": Cloudflare's blog.
I've used WordPress in the past because it was easy to setup and use. However, given the consistently bad security record I'd love to try something different. Anyone have recommendations for other open source CMS's? Similar functionality to WP is enough - I don't need anything fancy.
It is time for every Wordpress user to consider to switch to Octopress. Static sites have no attack vector, don't need security updates and are faster out of the box. Octopress has importers for many blogging systems including Wordpress:
Static site generators require a lot of sacrifices:
What about non-technical users? Multi-author blogs? Idiot-proof extensibility? Updates from phones and tablets? Huge sites with thousands of posts? Editorial and review systems? Access to thousands of cheap or free themes?
The ideal static site user is in a pretty privileged group. Most WordPress users would be better off securing WordPress and using a caching plugin that gives them the benefits of a powerful, dynamic platform while serving static files with automatic serverside compilation: http://wordpress.org/extend/plugins/wp-super-cache/
Exactly. My own static blog is pretty much the perfect CMS that I wouldn't recommend to anyone for the life of me.
At the very least, it needs something like http://prose.io/ on top of it, and since their website keeps not working, you don't want to put all your eggs in one basket, if shit hits the fan.
I am prepared to bet folding money that only software-sy types like us consider this a viable option. For everyone else it will seem like an unnecessary complication.
- One doesn't need to be a coder or mess with cmd to use it.
- Abundance of tutorial(text/audio/video)
- You can host it anywhere, even for free. FTP? I know that from work.
- Hosting provider even install it for you
- Expert support is all over the web
- Drupal and Joomla can't beat WordPress new user adoption, why? They're made to be customized(more developer-centric). Too much option is apparently not good for new user.
2) Features
- Need something? there's plugin for that
- People/visitors loves nice design/layout, WordPress have thousands of themes
- Secure. Attacked by some random ddos/script kiddies? Hosting provider will take care of it. Malicious code? same case.
Static site generator.
1) Beginner friendly
- Yes, at least if you're familiar with cmd.
- Most tutorial suggesting Amazon S3/CDN/cloud etc. Well those service are inaccessible to many.
- Write new post, generate, upload...complicated!
- Lets embed image/audio/video with one-click...nope!
- Lets edit old blog post... oh why art thou so hard
- Lets try it on my phone, nope!
2) Features
- I want to add Facebook comment, how? Read the manual, download that, configure...blabla. No thanks
- Lets add analytics code. Edit template and insert this javascript, save and regenerate...blabla. No thanks
Conclusion : it might be a piece of cake for you but not to most people. Remember "most user are idiot"?. If I want to have simple static blog with nice editor I would use Blogger. Dumping random text? I have pastebin for that. Static site generator sure is attractive but we are just not there yet.
I have a feeling that 'campaign' to promote static site generator to WordPress user is strikingly similar to Windows-to-Linux campaign. It just never going to happen for most user, at this rate.
I can confirm. We host a lot of WordPress blogs (for photographers) and our scans have have detected an uptick in installs infected with malicious files. I'm not sure if it's the same attack mentioned in the article but the last 2 weeks have been the worst I've seen.
In my experience people get compromised due to bad folder permissions or old versions of WP. I hadn't considered brute-force password attacks.
Can I suggest it might be worth investigating the "Wordfence Security" plugin?
I use it pretty much everywhere that I have anything to do with WordPress - I'd noticed an uptick early this week of random ip addresses from far-flung countries getting locked out after 5 login attempts or multiple lost password attempts.
(One site in particular gets a _lot_ of drive-by login attempts - it's got the word "anonymous" in the ___domain, which I suspect attracts mostly the wrong sort of traffic... Wordfence is locked down _much_ tighter on that site.)
I've lost count of how many times I've seen people chmod /wp-content/upload to 777. I blame laziness, stupid presets in "one-click" installations and silly how-to's found all over the web.
I was setting up a Wordpress site for someone once (I'm not really a web developer). I downloaded an image gallery plugin and installed it locally. Wouldn't work. I went to the instructions and found that it required wp-content/upload to be set to 777. I abandoned the plugin soon after. However, if I hadn't been running Linux for a year before that, I'd probably have just done it.
The difficulty with the democratisation of software and web development is that inevitably, people will make mistakes like this. The sad part is there's probably millions of articles explaining why this is a bad idea, but the people most at risk will never see them.
It's actually two separate, but extremely similar attacks. One is exactly as described in the article, fairly distributed dictionary attack with user admin against wp-login.php. The second one is slightly more advanced, much much more distributed and I've seen it go for Joomla and wordpress, trying common usernames at times (though generally sticking to administrator/admin) and going through what appears to be a dictionary of about 3000 passwords. The bigger issue is these are coming in so fast and from so many directions, on resource constrained machines this is essentially ending up like a DDoS, which has a lot of ancillary effects. mod_sec and other similar methods of identifying these incoming before hitting apache and spawning a php thread are proving to be very much not enough.
I'm a new WordPress user. Are there any guides online with best practices that I can follow? (Some suggestions I see in this thread: rate-limiting plugin, don't have user id #1, don't have user "admin".)
You can add HTTP basic auth to your wp-login.php and wp-admin/ paths, which will require that the user provide authentication before ever getting to pass data to those scripts. That can protect you against vulnerabilities in the software, but it won't protect you from bad passwords.
What URL is the login requests sent to? Would changing the wp-admin directory to something random help avoid the attacks? Or does wordpress have another point of entry for authentication?
Not surprisingly one of the most commonly scripted search query at Blekko is for wordpress themes in one way or another. We do what we can to not return them any useful data.
Yes, of course you're right, my mistake. Mainly I wanted to share some information and give examples of passwords.
Here are some more observations which I made during the last months:
Most of the time it seems that the attackers are using a list of popular passwords, the same passwords appear over and over again: 12345, qwerty, 1q2w3e4r, and so on.
Most of the time they try to login as "admin", "Admin", "administrator", "root" or the name of the ___domain or blog or a part of that name, for example omitting a ".com".
In the HTTP requests, the parameters "log" (for the user name) and "pwd" (for the password) are always transmitted, but the parameters "wp-submit=Log In" and "testcookie=1" are not always transmitted.
Many of these attacks do not transmit a user-agent field in the HTTP headers. Blocking the empty user-agent seems like a good idea to me.
These attacks look simple, but I guess that they are successful on a big number of sites.
Don't know if this is a dumb question: but would it be possible for a good party to use the same method to get admin access and install rate-limiting login plugins on all of these insecure WordPress blogs? Seems like that would be badass.
I've also noticed an increase in spam comments and trackbacks that akismet doesn't catch. Is this possibly related? At least on two occasions I've noticed the ip address of a spam comment match against an attempted login.
Attacks are continuing, I've logged two more attempts from todays. There is no reason these sites have login attempts from said countries:
79.28.255.65 (Italy)
80.35.80.139 (Spain)
The effect is probably reasonably limited though. Most of the time you're going to be in safe mode or on shared hosting, which means no SYN floods and no bitcoin mining.
If you still have user id #1 and/or the user "admin" on your wordpress install, you just haven't been using wordpress long enough to know what bad ideas those are.
if user #1 is still an admin but with a different name you can just go to wpurl/?author=1 and if url rewriting is enabled you'll be redirected to wpurl/author/nicename and nicename is usually equal to the username
I don't think this adds the layer of security you think it does, merely a minor bit of obscurity. In context of the specific vector you reference, author={$user_id}, it probably doesn't do anything at all to protect you.
Not that there is anything wrong with adding a bit of obscurity, not using 'admin' as a username and using a non-privileged author for posts can go a long way.
However, if you are worried about someone getting your username from "author={$user_id}," using a user_id of 2,3,4,5, ect, probably isn't going to protect you. I think you are incorrectly assuming that the person that would use this method to get a username is going to stop if they get a 404 at #1(or even after just a single attempt.)
