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

Вредоносный редирект на *.org.in, или когда безопасность сайта зависит не только от вебмастера

16 марта 2012, 19:38

Сегодня мы расскажем об очень любопытном и опасном методе распространения вредоносного кода с заражённых веб-сайтов.

Впервые он был зафиксирован, когда антивирусная система Яндекса обнаружила в конце 2010 года редирект на вредоносный ресурс вида hxxp://nrho.org.in/index.php?src=74&surl=victim-site.ru&sport=80&suri=/. В настоящее время этот вид заражения является весьма актуальным.

Представляющий опасность код – вредоносный редиректор – выдаётся не всегда, а только при соблюдении нескольких условий, так что получить его для анализа довольно сложно. Cудя по тому, что заражённые сайты сгруппированы по серверам и хостингам, заражение происходит на уровне хостинговой платформы. Это значит, что обычный вебмастер, контролирующий только директорию своего сайта, не может его устранить.
 

Характерные особенности данного вида заражения

Домен 3-го уровня (nrho для nrho.org.in), на который происходит редирект, представляет собой случайный набор алфавитных символов и меняется не реже одного раза в день.
Редирект использует следующие GET-параметры:
  • src – идентификатор источника редиректа. связан с ip-адресом сайта-жертвы (когда несколько различных сайтов используют один ip-адрес по схеме shared-хостинга src для обоих будет одинаков);
  • surl – доменное имя сайта-жертвы;
  • sport – используемый порт сайта-жертвы;
  • suri – путь к скрипту на сайте-жертве, с которого был осуществлен редирект.

Чтобы сайт на заражённом сервере выдал данный вредоносный редирект нелегко, необходимо выполнение сразу всех приведённых ниже условий:
  1. Уникальный ip-адрес (редирект не сработает при повторном визите на зараженный сайт).
  2. Переход на зараженный ресурс со страницы поисковой выдачи.
  3. Браузер Internet Explorer ниже 8 версии.
  4. Некоторые дополнительные условия. Например, заданный или случайный временной промежуток.

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

Мы предполагаем, что данный редирект происходит на стороне хостинг-провайдеров, о чем говорят следующие факты:
  1. Заражённые сайты не похожи друг на друга ни по каким техническим критериям – зараженные сайты используют различные CMS, ОС, программные компоненты веб-сервера.
  2. По данным, которые мы получили от веб-мастеров зараженных ресурсов, они используют самые разные реализации услуги хостинга – от арендуемых физических серверов, до shared-хостинга, в случае которого веб-мастера не имеют root-привилегий на сервере и не могут редактировать бинарные компоненты веб-сервера.
  3. Передача GET запросом в явном виде информации о сайте источнике, вероятно, обусловлена выполнением редиректа вне контекста конкретного веб-приложения (возможно, на одном из промежуточных серверов или интернет-шлюзе).
  4. Многократные попытки найти подозрительный код, или хотя бы что-либо общее, на сайтах-жертвах не увенчались успехом.
  5. Большинство зараженных сайтов используют услуги одних и тех же хостинг-провайдеров.

Приблизительно половина всех регистрируемых случаев описанного вредоносного редиректа происходит с сайтов, обслуживаемых одним украинским хостинг-провайдером, название которого мы не разглашаем. Заметим, что первые случаи характерного редиректа были замечены также на сайтах этого хостинга, о чем свидетельствует значение параметра src в запросах к вредоносному ресурсу.

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

Если значение переменной src действительно отражает количество уникальных ip-адресов зараженных серверов, то было заражено по меньшей мере 174 сервера, на каждом из которых может размещаться сразу несколько различных сайтов.

Вредоносный и обратный редирект

В случае соблюдения условий, приведённых выше, сайт на заражённом хостинге выдаёт пользователю вредоносный редирект.
Редирект имеет вид:

GET http://victim-site.ru/ HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/xaml+xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, application/x-ms-application, */*
Accept-Language: ru
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
Host: victim-site.ru
Proxy-Connection: Keep-Alive
Referer: http://yandex.ru/yandsearch?text=%D0%A1%D0%BF%D0%B0%D1%81%D0%B8%D0%B1%D0%BE+%D0%B7%D0%B0+%D0%B2%D0%BD%D0%B8%D0%BC%D0%B0%D0%BD%D0%B8%D0%B5+%D0%BA+%D0%B1%D0%BB%D0%BE%D0%B3%D1%83+%D0%AF%D0%BD%D0%B4%D0%B5%D0%BA%D1%81.%D0%91%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D1%8B%D0%B9+%D0%BF%D0%BE%D0%B8%D1%81%D0%BA%21&lr=213

HTTP/1.1 302 Found
Date: Mon, 12 Mar 2012 16:32:25 GMT
Server: Apache/2
Location: http://nrho.org.in/index.php?src=74&surl=victim-site.ru&sport=80&suri=/
Content-Length: 335
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<title>302 Found
</head>
<h1>Found
<p>The document has moved here.
<hr>
<address>Apache/2 Server at victim-site.ru Port 80
</body>

При этом, в ряде случаев происходит редирект обратно на страницу сайта-жертвы. Таким образом злоумышленник реализует технику периодического прерывания цепочки заражения. Эта техника используется для того, чтобы избежать скорой реакции антивирусного ПО и разметки сайта как заражённого в результатах поиска.
Обратный редирект имеет вид:

GET http://nrho.org.in/index.php?src=74&surl=victim-site.ru&sport=80&suri=/ HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/xaml+xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, application/x-ms-application, */*
Accept-Language: ru
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
Host: nrho.org.in
Proxy-Connection: Keep-Alive
Referer: http://yandex.ru/yandsearch?text=%D0%A1%D0%BF%D0%B0%D1%81%D0%B8%D0%B1%D0%BE+%D0%B7%D0%B0+%D0%B2%D0%BD%D0%B8%D0%BC%D0%B0%D0%BD%D0%B8%D0%B5+%D0%BA+%D0%B1%D0%BB%D0%BE%D0%B3%D1%83+%D0%AF%D0%BD%D0%B4%D0%B5%D0%BA%D1%81.%D0%91%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D1%8B%D0%B9+%D0%BF%D0%BE%D0%B8%D1%81%D0%BA%21&lr=213

HTTP/1.1 302 Found
Server: nginx/0.8.54
Date: Mon, 12 Mar 2012 16:40:37 GMT
Content-Type: text/html
Connection: close
Cache-Control: no-store, no-cache, must-revalidate
Expires: Mon, 12 Mar 2012 16:40:37 +0000
Location: http://victim-site.ru/
Vary: Accept-Encoding
Content-Length: 0

Цепочка заражения

В случае обратного редиректа браузер производит такую последовательность запросов:



В остальных случаях, вместо редиректа на сайт-источник, пользователю выдается html-файл, содержащий вредоносный JS-код, и последовательность имеет вид:



Рассмотрим цепочку заражения подробнее.

Шаг 1. JS-редирект (index.php)

В результате серверного редиректа браузер направляется на страницу с вредоносным JavaScript-редиректом, index.php. Этот js-код детектируется антивирусом Sophos как Troj/JSRedir-DM. Именно этот вердикт обычно видят в панели Яндекс.Вебмастера администраторы зараженных ресурсов.

JS-редирект (index.php) в обфусцированном виде:



Алгоритм деобфускации привязан к браузеру посетителя. Код генерируется таким образом, что деобфускация произойдет неверно в случае несовпадения значений navigator.userAgent и HTTP-заголовка User-Agent. В результате цепочка заражения будет прервана, что, безусловно, также призвано затруднить детектирование вредоносного кода.

JS-редирект (index.php) после деобфускации:


Шаг 2. Заражение (для Microsoft Internet Explorer 6)

JS-редирект из index.php ведёт пользователя на index2.php.

Партнерская реклама + перенаправление на эксплоит-пак index2.php:


index2.php открывает в браузере пользователя новое окно с URL hxxp://dating-portal.net/aff.php?tt=0&t=onunload и перенаправляет пользователя на эксплойт-пак index5.php.

Эксплоит-пак (index5.php):
Код эксплойт-пака обфусцирован.

Эксплоит-пак (index5.php) после деобфускации:




Эксплойт-пак загружает в браузер пользователя эксплойт (index6.php).

Экплоит (index6.php):
Деобфусцируем его.

Экплоит (index6.php) после деобфускации
Этот эксплоит реализует сохранение и запуск на компьютере посетителя файла svcgost.exe, выдаваемый скриптом index4.php .

Шаг 3. Действия в системе пользователя

После запуска на компьютере позльзователя файл svcgost.exe (MD5 6d7b145ef5dd0ab8471500b638975727).
копирует себя в системный каталог с именем FIX_KB111952.exe.

Эта вредоносная программа обладает поведением trojan-downloader (предназначена для загрузки других вредоносных программ из удаленных источников). Тело трояна упаковано и использует противодействие динамическому анализу. Данная вредоносная программа обращается к ресурсу bober.org.in и загружает с него:
  1. Троянскую программу Trojan.Win32.Smardf.tbx по классификации Лаборатории Касперского, MD5 0c2c4a7cc380ffa2f17b44749a1cceffшироко известную антивирусам, работающим на virustotal.com. Данная программа регистрируется в качестве расширения (BHO) к браузеру Internet Explorer c именем fastsrch.dll. Описание похожей вредоносной программы можно найти здесь.
  2. Троянскую программу семейства Carberp, MD5 3d4e1acd2372b19bcd3bd3403c07f4a5, подробнее можно прочитать здесь.Основная цель этой программы – реквизиты для доступа к банковским и платежным системам. Она также вполне известна.
  3. Кроме того, на зараженной тестовой системе была замечена массированная рассылка почтовых спам-сообщений и сканирование компьютеров локальной сети.

 

В случае, если вы обнаружили на своём сайте признаки описанного заражения, рекомендуем вам сделать следующее:

  1. Обратитесь в поддержку Яндекс.Вебмастера за консультацией.
  2. Попытайтесь воспроизвести заражение в безопасных условиях ( при использовании виртуальной среды ), следуя указаниям из статьи.
  3. Напишите в техническую поддержку своего хостинг-провайдера с подробным описанием проблемы и ссылкой на эту статью для детального расследования инцидента.


Команда Безопасного поиска Яндекса будет крайне признательна за любую информацию об этом виде заражения. Подозрительный код, конфигурационные файлы, а также журнальные файлы присылайте на анализ по адресу virus-samples@yandex-team.ru.

 

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

42 комментария

норм :-(

И модуль проверки ссылок Яндекс-версии Антивируса Касперского... увы! не совместим с Firefox 11.0

:(

Комментарий удалён

Работает, работает... вопрос КАК?

До тех пор пока ты не поймал root-kit вирусы в паре с баннером. Когда твой ПК блокируется и тебе предлагают отправить СМС для разблокировки.

 

Обнаружить такие вирусы (найти тело вируса) в системе не реально

Согласен, но лишь отчасти.

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

 

К сожалению средний обыватель на знаком с этими тонкостями, а тот кто более-менее продвинутый, просто не имеет времени на это.

 

Антивирусные решения, как раз помогают избавиться от паранои, сэкономить время и защитить свои данные. 600 руб/год - не большие деньги.

 

Слух о том, что вирусы пишут сами антивирусники ходит давно. Действительно их прибыли напрямую связаны с вирусной активностью. Но подобные заявления очень серьезные, требующие доказательной базы. Распространение вирусов карается УК.

Еще не было доказано ни одного случая вирусной активности разработчиком которой являлся представитель антивирных воротил. Как правило создателей опасных вирусов находят, и все они "обиженные на весь мир" бедные программисты, которых как раз не взяли работать в престижную IT компанию.

Поделюсь своими наблюдениями...

Ещё в 1987 году был известен антивирус Касперского. Тогда мы решили им воспользоваться для защиты своих компьютеров в компании. Он тогда уже продавался, но было решено его перед покупкой проверить, и заодно самим научиться им пользоваться. Нашли бесплатную версию с ограниченным временем действия, начали устанавливать на тестовый компьютер.

Сначала всё шло нормально, и он правильно "встал", доложил, что готов к битве с "врагами"...

Запустили... И тут всё пошло иначе.

1. Первым делом, "Каспер" скопировал тестовый вирус с дискеты на наш компьютер.

2. Затем он стал проверять комп, но тут обнаружился предыдущий "Доктор Веб", который в превеликим ликованием Касперского, был убит насмерть. Конкурент был повержен!

3. Далее "Каспер" заявил, что в смертельной битве сам пострадал не меньше конкурента, и удаляется "на покой"...

4. И после этого, тестовый вирус от Касперского, беспрепятственно стал уничтожать всё нажитое непосильным трудом... Битва титанов антивирусного софта завершилась победой тестового вируса!

 

Прошло много лет, но теперь на моих компах работает "Dr.WEB" - а "Каспер" считается "софтом нон грата"...

все указывает на hostpro.com.ua :)

что же именно на них указывает?

stanislav.verkhovetsky
22 марта 2012, 10:15

как минимум второй скриншот ;)

а вы из Яндекса или из HostPro?;-)

Не работаю ни в одной из этих 2-х организаций

"Заражение" применительно к сайту или серверу называется взломом. Зачем плодить мифы о вирусах, "заражающих" сайты?

Заражение применительно к сайту – размещение на сайте вредоносного кода, способного заразить компьютеры посетителей. Для того, чтобы это произошло, сайт не обязательно взламывать. Иногда вебмастер сам этот код размещает, или ставит на свои страницы блоки партнёрских сетей, к-рые его распространяют, или посетители сайта вставляют код в UGC.

Что же до вирусов, заражающих сайты, то:

1) взлом и размещение malware– часто массовый, автоматизированный процесс, который выполняется ботами ботнетов, к-рые принадлежат к malware;

2) пароли от админ-панелей, CMS, FTP, SSH злоумышленники часто добывают с заражённых компьютеров вебмастеров.

В результате взлома не обязательно происходит заражение. Часто после взлома на страницах размещают поисковый спам, фарму, иногда (сравнительно редко) – просто занимаются компрометацией и вандализмом.

В данном конкретном случае на сайте явно не размещается даже загрузчик вредоносного кода. Судя по приведенным заголовкам обмена, можно предположить, что в access_log сайта-жертвы нет этого запроса, а отвечал не Апач...

Комментарий удалён

 

Считать как угодно и высказывать своё мнение – ваше право. А вот могли бы вы обосновать свою позицию, в т.ч. своё общее суждение о профессионализме? Лучше фактами с числами.

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

Сбить наш детект у злоумышленников вряд ли получится. Если ужесточат правила выдачи вредоносного кода – только станут меньше заражать пользователей, а это для нас хороший результат.

Тоже без обид, но фактов в этих высказываниях нет, да и логика мягко говоря не очевидна. Просто суждения. Что же до вредоносного кода – чтобы вебмастер смог найти и удалить его серверную часть, ему нужно как минимум показать клиентскую, лучшее средство – осведомлённость. Рассказывать о технологиях детектирования больше, чем уже рассказали, предоставлять данные или делать что-либо ещё, только чтобы кому-то что-то доказать  – нет, не станем.

Да как тебе не понятно, что этот код используется для внутренней статистики яндекса.

 

Вы правы. Эти счетчики более похожы на снифферы ( скрывать скрипт используя её как картинку. И ещё заметил такой же вид счетчика используется на всех проектах Mail.Ru Group

 

Как эти счётчики используются — пользователь просто не знает. Но в настройках браузера загрузку всего такого можно отменить. Ну посетители этого блога точно смогут справиться с этим легко.

Есть же умные люди - их бы мозги, да в нужном направлении повернуть!

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

>Мы предполагаем, что данный редирект происходит на стороне хостинг-провайдеров


Ну зачем так позориться ? Это же классика жанра. Ничего нового :

обычно вставки кода очень короткие, в виде скачки еще немного html с передачей параметров из $_REQUEST. Специальный сервер анализирует и выдает html-код эксплоита под конкретный IP и браузер. Либо не выдает, если посетитель хакерам не интересен как платформа.

Если снять весь трафик в tcpdump - скорее всего увидите поток внешних запросов к серверу редиректов.Еще можно через перегруженные функции php отловить подобное в локальном отладчике или писать в журналы на зараженном сервере.


Эти схемы уже много лет применяются и я прямо удивлен вашей реакцией.

Спасибо, кэп!

А вообще хороший тон - читать статьи перед публикацией комментариев к ним.

 

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

Многие клиенты свято верят в заклинание "chmod 777" и чтобы изменить чужие файлы на сервере совсем не обязательно влиять на работу системного ПО. 

Если доводы аналитиков Яндекса кажутся вам неубедительными - оставьте в этом блоге свои контакты.

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

 

Поделитесь потом с сообществом своими открытиями.

Не вижу никакой конкретики. Просто подробно описано заражение посетителей, но не сайтов. Где тут "доводы аналитиков" ?

 

Оно и понятно  : задача Яндекса выкинуть сайт из поиска, а не очистить его от вирусов.

Любой нормальный сайтовладелец, например я, знает об очистке и распространении гораздо больше.

Схема старая. А новое то, что вредоносное ПО распространяют группы сайтов. Которые хостятся  на определённых серверах и хостингах, а больше ничего общего между ними нет. Про это в статье написано, читайте.

Здравствуйте!
Перестал открываться сайт http://fro196.narod.ru/ .
На запрос о причинах получил ответ службы поддержки:
"При проверке Вашего сайта антивирусный комплекс Яндекса обнаружил вредоносный код. Пожалуйста, проверьте Ваши файлы, удалите вредоносный код и сообщите нам."
Но я не владелец, а пользователь сайта. Владелец не отвечает.
Может ли Яндекс самостоятельно решить проблему?

Сайты на Народе обычно заражаются так: компьютер вебмастера такого сайта заражается, malware отправляет логин и пароль злоумышленникам, они обходят своими ботами сайты на Народе и дописывают вредоносный код в их страницы.

Соответственно, даже если Яндекс удалит вредоносный код, сайт всё равно довольно скоро заразят снова. Так что именно вебмастер должен 1) вылечить свой компьютер 2) сменить свой пароль 3) удалить вредоносный код. Подробнее написано здесь.

Всё это не решает проблему.

Вот ответ из Службы поддержки Яндекса:

"К сожалению, данную проблему может решить только владелец указанного сайта."

Получается, если владелец исчез или какая другая причина, то любой вредонос может шкодить и нету на него управы пользователям сайта. Жаль, что Яндекс так устроен( Хороший был сайт.

ps: Владелец нашёлся, сайт заработал. Спасибо)

к сожалению, сайт http://fro196.narod.ru/  опять исчез (
появляется вот такая страница :

uCoz
Error 410
WEBSITE DELETED
The website that used to be located here is now deleted due to violation of the User Agreement.
Contact our Support Team for the details.

Что это значит? Как его вернуть?
Получил ответ из техподдержки:

"Данный ресурс  был обнаружен программой-антиспамом и определен как doorway.

От Вас ожидается удаление всех материалов, которые могут быть расценены как нарушающие пользовательское соглашение".

Что это значит и как с этим бороться?
Сайт заработал. Спасибо техподдержке!

Вот с этим полностью согласен! как правило мы зачастую зря пренебрегаем правилами элементарной безопасности на своих сайтах. Но как правило это только по началу. Почаще сохраняться и повнимательнее относиться к паролям и доступу - и будет нам счастье!

спасибо! очень полезно

все пролечено, все в порядке. Когда сайт снова появится в нормальном виде (без предупреждений об угрозе и опасности при его посещения) в результатах поиска Яндекса?

Жду уже 2 дня. Когда все обновится в Яндексе? 

как лечили? 

Уже 3 день бьюсь с этой заразой, воспроизвести не удается, найти тоже... осталось только сниффер трафика на сервер запустить, и послать яндексу приглашение, так как sucuri его не видет... только Яндекс как то умудряется переслаться на вредоносный сайт...

 

Хотя sucuri, на локальном компьютере, блокирует сайт с пометкой 

·         Mal/HTMLGen-A (но в прошлом году он с там же вердиктом google аналитику заблокировал)

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

 Че делать то? 

хех, сниффером редирект нашелся... 

но найти гада все еше не могу... 

o_O деактивировали наконец

Исправьте статью уже, я вам прислал данные по вирусу, то что тут написано а именно выводы 1, 2 и 5 не согответствуют действительности

Помогите, правду ли пишут? меня недавно взломали :-(теперь паранойя.

Базовая защита компьютера от вирусов