• Resolved stubbyd

    (@stubbyd)


    I’m getting the following appear in one of my .htaccess files (it can be one or all three) on a semi-regular basis.

    php_value auto_append_file /home/USERDIR/public_html/Thumbs.db

    When it appears it causes the server to respond with a 500 error. My fix is to remove the line, save and refresh my page view.

    I’m guessing it comes from a plugin or possibly from the theme but don’t even know where to begin to track it down. Any suggestions for tracking it down other than disable / re-enable plugins one by one. Because it only happens semi-frequently that process would take me most of a year or longer to complete and we need access to the websites to be available in the meantime.

Viewing 5 replies - 16 through 20 (of 20 total)
  • Thread Starter stubbyd

    (@stubbyd)

    The site was hacked with an automated hack if I recall correctly.

    I’ll go through the above posts one by one but I believe we cleared out any “issues” back when. I’ve used and use the exploit scanner and whilst it throws up queries on some of the plugins it throws them up whether it’s a clean install or even if that same plugin is used on one of my own personal blogs.

    So that indicates to me that the scanner is picking up on coding that “could” be used but in these cases isn’t. IYSWIM ??

    Anyway, again thank you and I will go through the process …. again ??

    My WordPress site got hit by the same malware and I wanted to share details. The infected files were dated May 7, 2011, about the same time as stubbyd’s report.

    My site was running either WordPress 3.1.1 or 3.1.2 at the time (I believe 3.1.2). User account creation is disabled. The site had these plugins installed at the time:

    • Akismet 2.5.3
    • Blackbird Pie 0.5.1 (installed but disabled)
    • FeedBurner FeedSmith 2.3.1
    • Google Analyticator 6.1.3
    • Google XML Sitemaps 3.2.4
    • Hello Dolly 1.6 (installed but disabled)

    There are no CGI scripts or other custom code located on the server – only WordPress. I did have all WordPress files set with ownership by the Apache user (bad practice, I admit).

    In addition to creating the Thumbs.db payload file and appending the PHP reference above to the end of .htaccess, the malware also modified most PHP files in the root WordPress folder (notably not wp-config.php or a couple others) to include an eval() call to its payload wherever it found a <?php open tag. PHP files in WordPress subfolders fortunately weren’t modified. Themes and plugins were not infected.

    Even better news is that I can’t find any evidence of infection in the WordPress database itself. Simply overwriting all the core WordPress files with stock versions seems to eradicate the malware. I also upgraded WordPress to the latest version (3.1.3) and hardened my file permissions so the Apache user can no longer modify files.

    I’m convinced this is an underpublicized exploit in WordPress or one of the above plugins. If anyone else who got bit can post their WP and plugin versions, it would help narrow it down. I also found a description of this malware on this site, posted in the past week:

    https://www.neubreed.com.au/blog/2011/06/how_clean_after_thumbsdb_wordpress_and_php_auto_append_file_exploit_hack

    I only discovered my site was infected when Google Webmaster tools alerted me, so fortunately major browsers and search engines should be aware of this one by now. Good luck to anyone else who gets bit.

    @stubbyd: have you solved this yet? If not, see the link posted above by @sameprob for how to clean up. It was very helpful for me.

    Thread Starter stubbyd

    (@stubbyd)

    As it happens I’d forgotten about this post and for whatever reason I didn’t see the response from “sameprob”

    However I did read the stuff supplied via “esmi” and it would appear that I concluded on doing the same as “sameprob”.

    Effectively I overwrote all core files (again) and for each plugin that the security scanner said was suspect (a number of them detailed by sameprob) I replaced with fresh versions – since having done that I haven’t seen any further repeats of the problem.

Viewing 5 replies - 16 through 20 (of 20 total)
  • The topic ‘Where to start on this .htaccess issue’ is closed to new replies.