Cancel

Jeff Chandler

WordPress Not The Direct Cause Of Mass Site Attacks

Sucuri has published more information regarding the compromising of at least 30,000 domains. Based on their research, they are ruling out the possibility that the attacks are taking advantage of a new vulnerability within the core of WordPress.

The first question is how are these sites getting hacked? On all the cases we analyzed, they either had outdated versions of WordPress, or of a plugin. We can safely rule out any new vulnerability on WordPress itself.

To stay on top of the latest malware threats on the web, you should subscribe to their RSS feed. Perhaps the more people that realize this stuff is happening on a daily basis, the more it will persuade them to keep sites, plugins, and themes updated.

Category:
Tags: , ,
29

29 responses to “WordPress Not The Direct Cause Of Mass Site Attacks”

  2. With WordPress providing the SQL login and password in plain text in its wp-congfig.php is it any wonder why so many WordPress sites get hacked and WordPress gets the reputation for being difficult to impossible to make secure?

    Terence.

    Create forum topic from comment

  4. this is the first I’ve heard of wordpress sites being compromised. There have always been issues with vulnerabilities in older versions; what are the characteristics of this latest hack? I dealt with a site that was a pharma-hack victim, and after trying to manually remove it I ended up having to resort to wiping the site clean.

    Create forum topic from comment

  5. In its discussion of the exploit, the Sucuri article (linked above in this post) does not mention the wp-config.php file. There is no indication that it is involved at all.

    Sucuri then links to a previous post of theirs, Malware Campaign from .rr.nu which offers more info on how the exploit is (and isn’t) being conducted.

    This is an organized campaign.

    To repeat the repetition – Sucuri says:

    We can safely rule out any new vulnerability on WordPress itself.

    It should be noted, that older versions of WordPress could be the target, in part simply because older versions have been available for study, longer. Given time, the current version could prove vulnerable, too.

    Does that mean that Matt Mullenweg is a security silly-goose and his product is a threat to Civilization? Probably not. Recall, that the CIA, FBI, Microsoft, Google, etc, are also subject to attacks, with some interruptions and other problems resulting.

    It has more to do with ‘the price fame & prominence’.

    Create forum topic from comment

  6. @Terence –

    With WordPress providing the SQL login and password in plain text in its wp-congfig.php is it any wonder why so many WordPress sites get hacked and WordPress gets the reputation for being difficult to impossible to make secure?

    FUD. If true, every WordPress site in existence would be currently and constantly exploited. Also: the wp-config.php file can be moved elsewhere. The instructions are right in the Codex, along with plenty of other hardening suggestions.

    @Yoro Nestoridis –

    What I read here is complete nonsense.
    Even updated WP sites get attacked and hacked; in fact, just look it up on Google and you will find WP hack-ware allowing any junkie to mess up your WP site.

    More FUD. For the vast majority of compromised WordPress installs, the exploit vector was not WordPress, but rather compromised FTP credentials, or insecure shared-hosting configurations. For the sites for which WordPress itself was exploited, the issue has almost always been either an insecure Plugin, or an outdated version of WordPress. Nearly every WordPress release includes some sort of hardening, and usually such hardening is preventative. In 7 years of using WordPress, I can only remember a couple zero-day exploits being patched.

    Create forum topic from comment

  7. I have no idea where on earth this reputation for WordPress storing DB details in clear text comes from. WordPress has never stored them in clear text all the way back to version 1.5 (I haven’t looked in older versions but I assume they didn’t then either).

    I’ve also never heard of an up to date WordPress installation being hacked via WordPress itself. I don’t think that has happened for a very long time.

    Create forum topic from comment

  8. I agree with Yoro, even unpdate wordpress site gets hacked. Every blogger should get used to uninstalling wordpress/data bases and installing fresh copies. It is the only way to stay ahead of hackers.

    Create forum topic from comment

  9. With WordPress providing the SQL login and password in plain text in its wp-congfig.php is it any wonder why so many WordPress sites get hacked and WordPress gets the reputation for being difficult to impossible to make secure?

    So does Drupal, Joomla, MovableType, ZenPhoto, MEdiawiki… Shall I go on? Not the point.

    I have no idea where on earth this reputation for WordPress storing DB details in clear text comes from.

    Ryan, it stems from the wp-config.php having the SQL user ID, password and DB name in it. That’s all. Which … well. Yes. You have to have those to get into the DB.

    Create forum topic from comment

  10. I’ve had a client site recently hacked and displaying a “blackhole exploit kit” being the issue, I’m by no means a security expert as I’ve seldom had to deal with such issues but I learning quickly, any advice on this particular exploit? any help would be great.

    Just to chime in as a general rule my WP sites have been secure, out of a very large number of site I’ve worked on and monitor this has only happened twice, on the site I’ve mentioned and previously with the timthumb hack (again – not really WP’s fault) from both personal experience and the stats I could find, WP is fairly secure as far as al of its competitors which I think is largely due to its active and well, massive community.

    Create forum topic from comment

  14. @Chip Bennett – well if its not exploitable, why does the codex suggest “hardening” by moving the wp-config.php file elsewhere? Seems to me, if its so safe, there’s no need. You can’t have it both ways. But the whole idea of leaving those credentials in plain text, no matter how many other programs do it as well, seems to my non-developer (il)logical thinking, to be an accident just waiting to happen. And for @Ipstenu to say they all do, so its OK, to me seems rather like saying – “those cars all have lousy brakes, it doesn’t matter if my car has lousy brakes too”.

    Create forum topic from comment

  15. @Terence –
    You need to – actually – “make your case” that wp-config.php is providing the means to compromise sites. You aren’t doing that.

    If you have serious accusations to make, you need to do right by yourself, by making them well.

    You might need to do homework. You certainly need to find & present some specific evidence.

    I understand that this config info might look like an exposure. However, Terrence, Ipstenu points to the key clue/fact – that these files exist and are not leading to issues.

    I think there are other elements involved, that forestall the scenario you think config-info is posing.

    There has been a problem, but again, the wp-config.php file was not involved.

    Create forum topic from comment

  16. @Terence

    The section on hardening your WordPress install is like purchasing a deadbolt for the door to your house. If you lock your door when you leave the house you are secure but if you wish to sleep a little better at night you install a deadbolt making it more difficult to break in. That is why the section it labeled “hardening” your WordPress install and not “securing” your install.

    Also, having the MySQL login details in plain text of the wp-config.php file is the standard way that most, if not all, frameworks connect to the DB. Until another more secure way comes along, this is the best option.

    Create forum topic from comment

  17. The Securing wp-config.php sub-section of the Hardening WordPress page in the Codex says, in its entirety:

    You can move the wp-config.php file to the directory above your WordPress install. This means for a site installed in the root of your webspace, you can store wp-config.php outside the web-root folder.

    Note that wp-config.php can be stored ONE directory level above the WordPress (where wp-includes resides) installation. Also, make sure that only you (and the web server) can read this file (it generally means a 400 or 440 permission).

    If you use a server with .htaccess, you can put this in that file (at the very top) to deny access to anyone surfing for it:

    (code omitted: see link)

    The key thing to note here is:

    “Also, make sure that only you (and the web server) can read this file (it generally means a 400 or 440 permission).”

    Since read-permission for the file restricts access, the fact that the file is ‘just laying there’ in a specific location on *everyone’s* server … makes it effectively ‘not there’, to everyone but “you”, and “your server”.

    I think the rationale in suggesting wp-config.php “can” be moved, is that it offers an added level of security, if your server is compromised and access were possible through it. I believe that is a rare occurrence.

    Create forum topic from comment

  18. @Terence –

    well if its not exploitable, why does the codex suggest “hardening” by moving the wp-config.php file elsewhere? Seems to me, if its so safe, there’s no need.

    Just because something can be made more secure doesn’t mean that, in its current state, it is inherently insecure.

    You can’t have it both ways.

    Yes, you can. Technically speaking, WordPress doesn’t actually even install the wp-config.php file. The end user does. WordPress provides a sample, and provides instructions for where/how to configure and upload it. The WordPress boot routine is designed to look in the root install directory, and one directory higher, for wp-config.php. One may or may not be more secure (if WordPress is installed in a subdirectory, then both locations are still in the public_html space; so it really doesn’t matter).

    But the whole idea of leaving those credentials in plain text, no matter how many other programs do it as well, seems to my non-developer (il)logical thinking, to be an accident just waiting to happen.

    You are conflating plain text with publicly accessible. Yes: the wp-config.php is in cleartext. That’s rather required for a server PHP script to communicate with the SQL server. But even though the credentials are in cleartext, they are not publicly accessible.

    And for @Ipstenu to say they all do, so its OK, to me seems rather like saying – “those cars all have lousy brakes, it doesn’t matter if my car has lousy brakes too”.

    My brakes are just fine, thanks. (Go ahead: try to grab my wp-config SQL credentials.)

    Create forum topic from comment

  20. The wp-config file is plain text but it is like trying to read it in the dark bc it is not accesible by browsing. You cant browse to yousite.co m /wp-config and see it! If it were encrypted it would not work with mysql as far as I know. If there was a way then we would be using it i am sure.

    If your info is that desired then they will find a way in no matter what u do or what you use. If host has insecurities then it might be easy for hacker to get in thru ftp and then they can see the config and get info DB but that not WordPress fault.

    I have built bought and sold 50+ sites over the few years I have been using WordPress and Never had an issue with hacking on my vps. I hate having to update stuff every day but it is better than pulling out hair trying to fix a site. I have helped 3-4 peopl get their sites fixed and they were all several updated behind.last fall one was 2.7.x!

    Has any self hosted sites been hacked on a dedicated or vps? Mostly all I hear about is with shared hosting.

    Create forum topic from comment

  24. @Ted Clayton – the ability to determine exactly what was used to gain access is not always evident, but the fact remains, the SQL credentials are in a known location and often. through inexperience or carelessness, not as well protected as they might be. There now Ted, will you accept that statement without requiring the Spanish Inquisition?

    Create forum topic from comment

  25. @Terence –

    That you are a WP-Config.php Heretic, and Blaspheme the security of WordPress is, in & of itself, not what invites my Torquemada upon you.

    Rather, your feet are held to the fire on this spurious assertion of Config-danger, because this is no ordinary WordPress chit-chat and back-scratch blog. A link to WP-Tavern is installed on the Admin Dashboard of every WordPress installation out there, and many newcomers & novices could be in the audience.

    It is not necessary that I save your eternal soul from the awful fate your willful words incur, but we do wish that the many supplicants who may come here seeking WordPress enlightenment, are not led astray.

    You have modified your impetuous config-assertion to :

    [T]he SQL credentials [in wp-config.php] are in a known location and often. through inexperience or carelessness, not as well protected as they might be.

    The SQL credentials are safeguarded in what amounts to a nuclear bunker. Is a nuclear bunker actually perfectly unassailable? No, it is not. But the fact is, the Read-Permissions that you do not have in order to access Chip Bennett’s wp-config.php file (go ahead. you know exactly where it is. you can’t, can you?) place the config-info behind the software version of a steel-reinforced concrete wall.

    These config files, which everyone has, are seriously secure. There is nothing off-hand, casual or in any way even faintly irresponsible about the way that WordPress handles these data. Other website softwares use the same method. It is safe, secure, and sensible.

    Now then, Terence, lay down upon the Rack. You will feel so much better when we have freed your spirit of these demons.

    – Ted the Terrible ;)

    Create forum topic from comment

  26. I’ve been using WordPress since its first year of existence. In that time, despite the very best firewalling, testing for exploits, and employing all the recommended security hole plugs, several of my WordPress-based sites were hacked, sometimes multiple times. It has been a source of frustration.

    That said, the problem has not been in WordPress itself but in plugins and themes.

    In the case of a theme, a well-respected theme in the WordPress theme repository had a backdoor in it that allowed the hacker to reroute my domain to a terrorist site. My copy of the theme was up-to-date, which made no difference at all, since the backdoor was purposefully implanted in the code, which passed every security test I ran it through. Only an adept and careful PHP coder may have been able to see the problem.

    In the case of plugins, an orphaned plugin did not receive a needed code update, which allowed an exploit to occur. A different plugin used an unsafe process that was known to have problems. In both cases, these plugins passed all tests with flying colors. Both plugins were highly regarded and recommended by the most prominent WordPress aficionados.

    So while WordPress code itself never failed me, other software integral to it did. WordPress is only as strong as its weakest links, and despite my precautions, those links failed. It may not be the case that WordPress itself is broken, but I would be hard pressed to state that the WordPress model is in good shape. If anything, the Open Source software ideal is fundamentally flawed in this regard, with too many failings to avoid problems. No matter how strong the core WordPress code may be, out-of-date, orphaned, and poorly written add-ons will forever be its Achilles heel. And that’s a serious problem for anyone who wants his or her site to be bulletproof. WordPress simply can’t deliver that promise.

    Create forum topic from comment

  27. @DLE –

    [F]or anyone who wants his or her site to be bulletproof[, the] WordPress [model] simply can’t deliver that promise.

    While that is technically true, it is true only because “bulletproof” is not available.

    There is literally no website, anywhere, at any level, that is bulletproof. Not the Pentagon, the Kremlin, the CIA, Microsoft, Google, you-name-it. They’ve all been hacked. Not ‘could be’, not ‘are vulnerable’, but, quote “have been hacked”. Repeatedly. Every one of them.

    There is no amount of money or expertise that can make any website bulletproof.

    There is no alternative to WordPress that can make your website bulletproof. Drupal? Joomla? Bulletproof? No.

    What can we do?

    1.) Do backups.

    2.) Keep copies of the site. Localhost. Mirrors. Duplicate hosts.

    3.) Learn to actually restore from backup. Rebuild. Mirror. Localhost.

    When an exploit goes ripping through gigabytes of stuff in a government site, or in a major social media site, do they “fix” all that mangled content? Heavens no. It could take centuries. No – they just switch to a copy.

    If you are fairly modest in scope, you just perform backups, and if something bad happens, you wipe the site slick, and rebuild with a fresh copy of WordPress (or Drupal, Joomla, etc) and your backup file. If you are getting pretty seriously-big, then you make mirror copies of everything, real-time.

    In a few hours, a few days, you’re back in business. “Fixing” compromised website is oh-my-gawd the hard way to do things.
    ==========

    If we don’t quite understand a plugin or theme, we don’t contact WordPress about it, because we know that it isn’t theirs, they didn’t write it, and they aren’t supporting it. We know that questions about a plugin/theme have to go to its author.

    The plugin/theme author is responsible for her own code. It is our decision to put that author’s code on our website. We the site owner is responsible for 3rd-party software additions that we make to WordPress. Not WordPress.

    Many of us ought to do more looking-into a plugin, instead of just reading a one-line blurb, and clicking “Install”. (This is a personal weakness of mine … but these days I don’t activate them right away. I stick them in ‘quarantine’ while I read their docs, peek at the code, and do some searches using ‘plugin-name’ with words like ‘broken, “doesn’t work”, problem, sux’, etc.)

    The problem of ‘dirty’ plugins and themes is not nearly as big as it once was. WordPress made the Extend Library, so that they can enforce some basic standards, to weed out obvious bad apples. This is a huge help. Problems with add-ons are diminishing.

    It helps to pick plugins that are small & simple, and/or broken down into small & simple components, which work together in a transparent way. If the code is small/simple, then it is harder to hide crap in it, and – most importantly – it is far more likely that someone knowledgeable has or will spend the time and make the effort to study the code and understand what is there & how it works.

    Hairball, bloated, Gotham City code makes the task of investigating a plugin too much of a challenge. People who have the ability to do this, have too many other things to do with their lives, than to get tied up doing heavy-duty, long-term forensics on a freakin’ bad plugin.

    Go for the small & simple plugins. Make a conscious effort to replace the big, does-everything plugin, with several that do one thing each. There is a logarithmic/geometric complexity-cost, with do-everything plugins.

    When an issue arises with a small code, it is approachable/addressable. When the big one goes bad, the effort to tackle it is prohibitive.
    ==========

    My condolences, DLE, on the bad experiences you’ve had with WordPress. I know these things happen, and that the personal impact can be severe. My apologies, too, for riffing off on your straight-up report with a bunch yeah-buts & ya-knows … but you gave me such a great opportunity. :)

    Create forum topic from comment

  29. @DLE –

    In the case of a theme, a well-respected theme in the WordPress theme repository had a backdoor in it that allowed the hacker to reroute my domain to a terrorist site. My copy of the theme was up-to-date, which made no difference at all, since the backdoor was purposefully implanted in the code, which passed every security test I ran it through. Only an adept and careful PHP coder may have been able to see the problem.

    Did you report this Theme, I hope? If not, is the Theme still live in the repository?

    Please report such findings! For Theme-related issues, you can email the Theme Reviewers mail list, and we will suspend the Theme. (Note: this list is public; if you need to divulge exploit/vulnerability specifics, please email security@wordpress.org.)

    In the case of plugins, an orphaned plugin did not receive a needed code update, which allowed an exploit to occur. A different plugin used an unsafe process that was known to have problems. In both cases, these plugins passed all tests with flying colors. Both plugins were highly regarded and recommended by the most prominent WordPress aficionados.

    Likewise: did you report these Plugins? If not, are they still live in the repository?

    Please report such Plugin security issues to plugins@wordpress.org, and they will be dealt with immediately.

    It may not be the case that WordPress itself is broken, but I would be hard pressed to state that the WordPress model is in good shape. If anything, the Open Source software ideal is fundamentally flawed in this regard, with too many failings to avoid problems. No matter how strong the core WordPress code may be, out-of-date, orphaned, and poorly written add-ons will forever be its Achilles heel. And that’s a serious problem for anyone who wants his or her site to be bulletproof. WordPress simply can’t deliver that promise.

    FUD

    Yes, it’s true: WordPress itself cannot control nor protect you against code that you add to it.

    The power and flexibility of WordPress derive from its extensible design. However, it’s your software, installed on your server, extended by Themes/Plugins that you choose to install. You are responsible for those choices.

    For those unable or unwilling to take responsibility for such choices, there are hosted/managed WordPress options available.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.