Forum Replies Created

Viewing 15 replies - 46 through 60 (of 172 total)
  • @geester1: What exactly was hacked?

    And what is in those “core” files? There shouldn’t be any in “wp-includes”. They can be backdoor scripts or “core” dumps of some binary (again, there shouldn’t be any).

    I’d like to take a look at those files. You might want to contact me at http://www.unmaskparasites.com/contact/

    Thanks.

    @nicholas: When dealing with malware warning even Google’s own documentation is not clear enough and many webmaster make false assumptions about how Google unblocks sites. As a result many clean sites remain blacklisted for weeks!

    The most usual mistakes are:
    1. waiting for warning to automatically go away (even if Google’s malware scanners find a site clean during a next scheduled scan, without explicit review request from a webmaster, they’ll leave it in their blacklist for at least one more round to make sure the change is permanent)
    2. Using incorrect requests. Many people know that they should request Google to re-check their sites and for some reason find the “site reconsideration request” mentioned in (mt) response. This request deals with SEO problems (e.g. site removed from google’s index or penalized for black-hat tricks). Sometimes it takes several weeks before people realize they should have requested another review in another place.

    That’s why it is important to provide as clear and detailed instructions as possible.

    @kegill: What exactly sucuri reports for your “still viral” sites? The chances are they only report that your sites are still blacklisted by Google. In this case you should just request malware reviews via Google Webmaster Tools (Diagnostics -> Malware)

    @nicholas and MediaTemple webmasters:

    mdhenshaw has quoted MT response about how they cleaned compromised websites. This response contains incorrect information about removing Google’s malware warnings.

    I’d like to correct this misconception.

    1.) Patiently wait for the removal of the Google alert. The Google warning will subside once Google re-crawls/re-indexes your site.

    In reality, site crawling/indexing is not connected with malware warnings. There are malware scanners with their own schedule. If you don’t request a malware review via Webmaster Tools, your site may remain blacklisted for weeks. So request a malware review ASAP!

    https://www.google.com/webmasters/tools/reconsideration?pli=1

    This link is also incorrect. This reconsideration review has nothing to do with malware review. Using this links is a way to delay site unblocking.

    The malware review link is in your Google Webmaster Tools account on the “Malware” page of the “Diagnostics” section. If you use this link and your is really clean, it will be unblocked within a day (usually).

    @nicholas: I hope you can correct your support staff so that they don’t misguide your clients.

    You can read more about dealing with Google’s malware warnings here:
    http://www.unmaskparasites.com/malware-warning-guide/

    @xyclopsoft: There is no need to have the “executable” flag in permissions of .php files. They are executed by web server, not by operating system. “600” – is probably the best choice.

    Anyway, if wp-config.php on a compromised site had 751 permissions, I doubt it could be read from any other account unless that account was in the same group as yours.

    One more request to post wp-config.php permissions. Trying to understand if this only happens to sites where this file is world-readable.

    @entilza72: I’m not a MediaTemple customer and don’t know details of their platform.
    http://weblog.mediatemple.net/weblog/2010/08/06/security-facts/
    In this post they say:

    Vulnerable customer software (blogs, CMS, PHP apps) give attackers access to view and steal database passwords from application configuration files…

    I’m not sure what they exactly mean so just trying to isolate the issue and check whether wp-config.php permissions are to blame. That’s why I ask to share permissions of these files on hacked sites.

    By the way, 500 is not read/write. It is read/execute. Read/write is 600.

    WHOIS: http://www.whois-search.com/whois/mikesmithconsulting.co.uk

    Registration status:
    Renewal required.
    *** This registration has been SUSPENDED. ***

    Hi,

    There have been many similar problems on MediaTemple lately. Can you check permissions of wp-config.php and report them here?

    This file contains mySql passwords in clear text and should not be world-readable. Otherwise, anyone from neighbor accounts can gain access to you WordPress database and modify it however they want to.

    @mchriston: Please monitor your sites for at least a couple of days. This is the hack that returns.

    If it returns, check your file and directory permissions again.

    P.S. I hope you’ve changed passwords anyway.

    >These attacks are exclusive to accounts with WordPress ONLY

    I guess that hackers know WordPress well enough to make it their target. Moreover, it can be compromised via DB

    1. They know where in database to insert a malicious code so that it is executed when visitors view web pages.
    2. They know how to create a WordPress account via direct database writes.
    3. They know how to use that account to modify WordPress theme files (WP built-in theme editor can modify files with 600 permissions because PHP scripts are executed with their owner permissions)

    Summary:

    • The attack vector is mySql database. It looks like hackers don’t steal individual DB passwords – they just have a “root” (or similar) access.
    • Change your theme files’ permissions to 400 (I guess, you don’t modify them yourself every day)

    Good point madjax.

    Let’s think about how hackers could write into WP tables.

    1. The could steal database credentials from wp-config.php files if they are world readable. What are the permissions of the wp-config.php files on your compromised sites? (they should be 600)

    2. Hackers could built backdoor code into WP files (including themes and plugins). When executed in WP context they have access to WP database. But in this case hackers need write permissions for your files. (Could you check the permissions of compromised files?)

    3. Hackers could have “root” access to the whole mySql database (e.g. attacking some RS tech via that myPhpAdmin vulnerability, or some via some other attack). This way they can do whatever they want with every WP database on the compromised server. This can explain how that old WP database without a real WP front end (so no wp-config.php to steal passwords from and no WP files to build backdoor code into) was compromised.

    Any other ideas?

    P.S. Please post your wp-config.php permissions. I wonder if at least some of them are not world readable.

    Hi guys,

    I spent a week end investigating this issue and have gathered quite a few information about it (this thread was very helpful).

    I checked many RackSpace IPs and majority of WordPress blogs on those IPs were affected by this problem. (I only checked for injected scripts in the recent blogposts).

    You can clean up your sites but hackers will reinfect them unless RackSpace indentify and close the security hole. That phpMyAdmin vulneravility could be an initial vector of the attack. RackSpace had upgraded their phpMyAdmin nodes yesterday. However the question is: did hackers create enough backdoor scripts and rogue users in RackSpace databases to continue the attack. I guess will find it out soon.

    You can read more about my investigation here:
    http://blog.unmaskparasites.com/2010/06/14/attack-on-wordpress-blogs-on-rackspace/

    It looks legitimate. It’s just an inline image, base64-encoded to be compatible with HTML. A small icon.

    I’ve seen similar hack when hackers managed to modify the functions.php file of the current theme.

    Forum: Fixing WordPress
    In reply to: 2.9.2 site hacked
    UseShots

    (@useshots)

    Permissions with 5’s, 7’s and “3’s are not required for files since web server doesn’t need the “execution” permissions.

    In case of the dedicated server, you must have your web server working with Apache permissions. In case of GoDaddy, they have something like suexec (I believe) and scripts are executed with your user permissions.

    It this point, if you are right about permissions, it looks like hackers either use some vulnerability in the scripts you use under your account (this would explain why they can create files in your directories), or know some server vulnerability that allows them to gain permissions of any user.

Viewing 15 replies - 46 through 60 (of 172 total)