Was recently hacked and could use advice on some code I found

[coresash]

Hi,

 

I was recently subject to URL injection. I cleaned all the directories that were inserted into my FTP but I think other code has been pushed into my htaccess file. Would like one of you to offer an opinion if possible. "Common.php", in the first block of code, was a .php file that was inserted during the attack. I've since deleted this file but am loathe to mess around in .htaccess until someone tells me what all this is actually doing.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (google|yahoo|aol|bing|crawl|aspseek|icio|bot|spider|nutch|slurp|seznam) [OR]
RewriteCond %{HTTP_REFERER} (google|aol|yahoo|msn|search|bing)
RewriteCond %{REQUEST_URI} /$ [OR]
RewriteCond %{REQUEST_FILENAME} (html|php|htm)$ [NC]
RewriteCond %{REQUEST_FILENAME} !common.php
RewriteCond /var/sites/c/coresashwindows.co.uk/public_html/common.php -f
RewriteRule ^.*$ /common.php [L]
</IfModule>


# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

# validate X-UA-Compatible meta tag
Header set X-UA-Compatible "IE=Edge,chrome=1"

# hide config.php
<Files wp-config.php>  
   order allow,deny  
   deny from all  
</Files>  

# protect individual files
<Files .htaccess>  
   order allow,deny  
   deny from all  
</Files>  

# protect from sql injection
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]

# protect directory browsing
Options All -Indexes


# BEGIN GZIP
<ifmodule mod_deflate.c>
AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/x-javascript application/javascript
</ifmodule>
# END GZIP

# compress text, html, javascript, css, xml:
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

# Or, compress certain file types by extension:
<files *.html>
SetOutputFilter DEFLATE
</files>


#Expire Header
<FilesMatch "\.(ico|jpg|jpeg|png|gif|js|css|swf)$">
ExpiresDefault "access plus 2 hours"
</FilesMatch>

# Turn on Expires and set default to 0
ExpiresActive On
ExpiresDefault A0
 
# Set up caching on media files for 1 year (forever?)
<filesMatch "\.(flv|ico|pdf|avi|mov|ppt|doc|mp3|wmv|wav)$">
ExpiresDefault A29030400 
Header append Cache-Control "public"
</filesMatch>
 
# Set up caching on media files for 1 week
<filesMatch "\.(gif|jpg|jpeg|png|swf)$">
ExpiresDefault A604800
Header append Cache-Control "public"
</filesMatch>
 
# Set up 2 Hour caching on commonly updated files
<filesMatch "\.(xml|txt|html|js|css)$">
ExpiresDefault A604800
Header append Cache-Control "proxy-revalidate"
</filesMatch>
 
# Force no caching for dynamic files
<filesMatch "\.(php|cgi|pl|htm)$">
ExpiresActive Off
Header set Cache-Control "private, no-cache, no-store, proxy-revalidate, no-transform"
Header set Pragma "no-cache"
</filesMatch>

#ETag
FileETag none

# Enable compression: mod_deflate configuration for Apache 2.x
<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
# Don’t compress
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary
#Dealing with proxy servers
<IfModule mod_headers.c>
Header append Vary User-Agent
</IfModule>
</IfModule>


#Deny access from IPs attack
order allow,deny
deny from 78.149.123.255
deny from 82.45.152.152
deny from 79.135.120.106
deny from 109.230.251.120
deny from 46.205.96.168
deny from 109.145.194.4
deny from 195.33.27.190
deny from 109.157.227.138
deny from 71.40.108.83
deny from 91.224.160.25
allow from all 

To provide a little background, the URL injection makes spam websites appear in search results as if they were part of my domain. Since I deleted all the root files on my FTP (toe, love, health etc) these are all now 404ing. See an example of the links that have been generated below.

 

 

Doing a site:coresashwindows.co.uk obviously reveals a large amount of indexed webpages.

 

If possible I'd just like an evaluation of that .htaccess file and any other opinions on what steps to take after the hacking attack.

 

Tim

 

 

[Jacques1]

Um, I think you're missing the point.

 

This spam stuff may be annoying, but the real problem is that somebody somehow managed to gain access to your server. And maybe they still have. So the first step is to find out what exactly happened (are the logs still intact?).

 

Then get rid of FTP and replace it with a secure protocol like SCP or SFTP. Really, sending unencrypted traffic around the Internet is reckless. Also make sure you have a very strong password. Even better, get rid of the password as well and use public-key authentication. 

 

Then worry about the links.

[coresash]

Thanks but we think the problem was our own very out of date version of WordPress. There does not appear to be any further interference or insertion of any files into the ftp.

[KevinM1]

If you think someone injected code into your .htaccess file, then it should be considered compromised. Which means you don't just keep it, but you delete it and replace it with a clean copy (you do have a locally saved version of your site, right?).

 

Furthermore, Jacques is correct. FTP is NOT a secure way to transfer files. And if the hacker had access to your host, then you should assume that they have access to your FTP credentials. Change those immediately and use a more secure file transfer method (one of the options Jacques suggested above will suffice).

 

Finally, WordPress is notorious for being insecure. You need to keep on top of all their updates, and be weary of plugins. Ideally, you shouldn't use WP at all as it's a train wreck under the hood.

 

If you're serious about security you won't just say "I don't see anything else weird, so I must be good now." You'll work to plug the holes that created the issue to begin with.