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

Как бороться с вредоносным редиректом на сайты *.in

В одной из прошлых статей мы рассказывали о вредоносных редиректах на сайты в зоне *.org.in. Некоторое время назад, как видно на графике, число заражённых серверов резко выросло. Нам удалось разобраться, как происходит заражение.


 

Рисунок 1. Число вредоносных редиректов за последний месяц.
 

Заражение веб-сервера

За время, прошедшее с момента предыдущей публикации, мы провели дополнительные исследования и выяснили новые подробности заражения.
Во всех случаях злоумышленники взламывали сервер, после чего подменяли исполняемый файл веб-сервера на заражённый. Для маскировки они изменяли дату и время создания заражённого файла на соответствующие атрибуты оригинального файла. Однако, как правило, оригинальный и заражённый файлы были разного размера.
Мы получили несколько заражённых образцов, один из которых является исполняемым файлом веб-сервера Nginx (SHA256: 36A22D244BCAEE9D7C7AC3EB9E3A1F53A79AEE288CDA03D8B6F74003AD497375) .
По данным сервиса VirusTotal.com на 27.07.2012, эти вредоносные файлы не обнаруживаются ни одним антивирусным движком. Эти файлы также не детектируются ни одним из известных антируткитов для *nix. При отсутствующем Nginx подменяется исполняемый файл веб-сервера Apache. Что интересно, ни одного заражённого сервера под управлением ОС Microsoft Windows мы не зафиксировали.

Большинство зараженных серверов является VDS/VPS и выделеннными серверами различных хостинг-провайдеров. Новых заражений известных виртуальных хостингов этим вредоносным кодом с момента последней публикации мы не обнаружили.

Заражение компьютера посетителя сайта

Практически сразу после публикации предыдущей статьи вредоносный редирект видоизменился. Сейчас перенаправление происходит на адреса в зоне *.in, а сам GET-запрос имеет следующий вид:

hxxp://gntlny.in/index.php?time=071515061706613228&src=17&surl=victim.site&sport=80&key=4CDE34F2&suri=/victim.page

Видим, что в него добавлено два новых параметра – key и time. Несмотря на изменения, javascript-редиректор определяется антивирусом Sophos как Troj/JSRedir-DM.

Как и прежде, вредоносная страница устанавливает cookie, время действия которого – одни сутки:

HTTP/1.1 200 OK
Server: nginx/1.0.13
Date: Thu, 19 Jul 2012 07:51:16 GMT
Content-Type: text/html
Connection: close
Cache-Control: no-store, no-cache, must-revalidate
Expires: Thu, 19 Jul 2012 07:51:15 +0000
Set-Cookie: page1=1342684275; expires=Sat, 18-Aug-2012 07:51:15 GMT; path=/; domain=.smjijn.in
Set-Cookie: src=125; expires=Sat, 18-Aug-2012 07:51:15 GMT; path=/; domain=.smjijn.in
Set-Cookie: gpr=18; expires=Sat, 18-Aug-2012 07:51:15 GMT; path=/; domain=.smjijn.in
Set-Cookie: tkr=07190751641225387; expires=Sat, 18-Aug-2012 07:51:15 GMT; path=/; domain=.smjijn.in
Set-Cookie: tkri=2e492d254559bc67024b2fc829df63c5; expires=Sat, 18-Aug-2012 07:51:15 GMT; path=/; domain=.smjijn.in
Set-Cookie: tkrb=c6831f1b7ad22a41fe8649d6261ce5d6; expires=Sat, 18-Aug-2012 07:51:15 GMT; path=/; domain=.smjijn.in
Vary: Accept-Encoding

Цепочка заражения имеет вид:


Рисунок 2. Цепочка заражения.


В результате серверного редиректа браузер перенаправляется на страницу с вредоносным Javascript-редиректом index.php. Код обфусцированного редиректа не изменился:


Рисунок 3. JS-редирект в обфусцированном виде.


Алгоритм обфускации привязан к браузеру пользователя (при неверном значении User Agent деобфускация невозможна), что несколько затрудняет обнаружение вредоносного кода.


Рисунок 4. JS-редирект после деобфускации.


Браузер перенаправляется на страницу index2.php, которая открывает новое окно с адресом hxxp://dating-portal.net/aff.php?tt=0&t=onunload и перенаправляет пользователя на страницу скачивания эксплойт-пака main.php.


Рисунок 5. Часть кода страницы index2.php (открытие нового окна и редирект на эксплойт пак).


Следует отметить, что ранее злоумышленники использовали неизвестный эксплойт-пак, отдающий всего 2 вида эскплойтов для браузеров IE с 6 по 8 версию, теперь же вместо него используется популярный эксплойт-пак Blackhole.

Эксплойт-пак загружает в браузер пользователя несколько эксплойтов для широко известных уязвимостей, например:
https://www.virustotal.com/file/ea55f1849893a8e3c3ab488e4d80e1e17f646dcb5647f56ff50fa26bf0afb7f8/analysis/1342763356/ ;
https://www.virustotal.com/file/8699be5447dd8ba5e530dac02310ac34fd6134d955dbf666804ec804bae3a170/analysis/ .
Результатом является загрузка и запуск даунлоадера info.exe, который устанавливает на компьютер вредоносные программы, чтобы производить на нём действия, выгодные злоумышленникам.
https://www.virustotal.com/file/9792f4dddd000c65c80b6348e8ee6dbfce6a32cdd35791fae5ff96cfac6c5e5e/analysis/1342763481/

 
Как не допустить заражения сервера и вылечить его


  1. Пользуйтесь дистрибутивами веб-серверного ПО из первоисточников, по возможности собирайте его из оригинального исходного кода самостоятельно.
  2. После установки и обновления компонентов веб-сервера снимайте с них контрольные суммы и регулярно проверяйте, не изменились ли ваши файлы без вашего ведома. Как это сделать – написано, например, здесь. Помните, что контрольные суммы нужно снимать не только с директорий сайтов, но и с директорий, в которых лежат файлы веб-сервера.
  3. Вовремя обновляйте ваше веб-серверное ПО, чтобы в нём было меньше известных уязвимостей. Тщательно закрывайте неиспользуемые порты и сервисы. Используйте сложные логины и пароли. Не допускайте заражения рабочих станций, которые используются для работы с веб-сервером. Обо всём этом написано в соответствующем разделе Яндекс.Помощи.
  4. Чтобы вовремя узнавать о заражении своего сайта и быть в курсе актуальных векторов атак на веб-серверы, рабочие станции и мобильные устройства, можете воспользоваться нашим сервисом Яндекс.Вебмастер.

 

Мы хотим сказать отдельное спасибо за сотрудничество вебмастерам и системным администраторам, вместе с которыми мы разбирались в причинах заражения. Бороться с вредоносными программами лучше вместе! Если у вас есть любой подозрительный код, конфигурационные файлы и логи, относящиеся к данному виду заражения и не только, присылайте на анализ по адресу virus-samples@yandex-team.ru .

 

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

28 комментариев
Удалённый пользователь
28 января 2016, 03:11

(+1)

Вы молодцы, полезное дело делаете.

Антон Матвеев
28 января 2016, 03:11

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

В целом же опять вы не допилили вирус, серверную часть тоесть, заражения клиентских компьютеров  не исследовал.

 

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

 

В чём причина заражения - понятно, что делать, чтобы его избежать - тоже понятно. Если вы продвинулись дальше, то ждём ссылку на вашу статью ;-) .

Антон Матвеев
28 января 2016, 03:11

Нет, мне вот не поняно как он бинарники изменяет в плане каким образом происходит взлом... По вашем данным nginx и apache на всех серверах одинаковые версии имеют? И все работают с root правами? А если не понятно как он производит взлом то не понятно как от него защитится. Тоесть причина не понятна, понятно только что делать чтобы его дезактивировать...

Статью напишу на этих выходных... ссылку скину.

Как показало расследование заражения одного крупного хостера, злоумышленники именно подменяли исполняемый файл apache или nginx. При этом, если мне не изменяет память, бинарник был собран из пропатченных исходников на этом же (взломанном)  серваке. Зараженный и оригинальный файл существенно отличались по размеру. Параметры компиляции были различными.

 

Нет, мне вот не поняно как он бинарники изменяет в плане каким образом происходит взлом...

 

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

 

И все работают с root правами?

 

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

 

Статью напишу на этих выходных... ссылку скину.

Буду рад почитать и обсудить.

 

Антон Матвеев
28 января 2016, 03:11

 

бинарник был собран из пропатченных исходников на этом же (взломанном)  серваке. 

 

Тогда это меняет дело.

 

По твоему все серваки ломаются одним и тем же методом?

По моему там вариантов много, но я в серьез не рассматривал вариант брута хешей, или паролей. Как то это слишком приметивно. 


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



 

заражения клиентских компьютеров  не исследовал

 

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

 

всетаки не заменяет файл как вы предположили, а просто добавляет себя в существующий бинарник

 

Мы не предположили. Читайте внимательнее.

Антон Матвеев
28 января 2016, 03:11
"Не исследовали" и "не опубликовали" это разные вещи, порой между собой не связанные.

Это я не исследовал их )))

 

Касательно исследований Яндекса я вообще не знаю что сказать, зачем было скрывать (если они знали) решение этой проблемы до того момента как ее не опубликовали? Я потратил дня 2 только для того чтобы выяснить что виновато в редиректе. И еше 1 для того чтобы убрать эту хрень. Не говоря уже об анализе трафика и логов. А многие админы, неделями пытались ее деактивировать, общались с яндексом и в результате переезжали на другие сервера. 

И теперь вы хотите сказать что Яндекс всё это время был в курсе того как избавится от этой заразы? :-O

 

Касательно взлома сервера действительно все возможно, просто не ясно зачем было nginx заражать, если с таким же успехом заражается апатч. Тоесть вы думаете что заражение производится по большей части в ручном режиме? 

 

P.S. Я не *nix\BSD админ, поэтому мне пришлось приложить значительные усилия для выявления вируса, а получается я потратил время почти в пустую...

 

 просто не ясно зачем было nginx заражать, если с таким же успехом заражается апатч

 

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

 

а получается я потратил время почти в пустую

Если вы кому-то помогли в удалении вируса, то время точно не было потрачено впустую.

Антон Матвеев
28 января 2016, 03:11
Если вы кому-то помогли в удалении вируса, то время точно не было потрачено впустую.

Если я изобритал велосипед значит время в пустую.:-) Обидно за потраченое время o_O

 

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

Админам надо было обращаться к нам за помощью. Все, кто обратился за помощью, ее получили и вылечили свои сервера.

Антон Матвеев
28 января 2016, 03:11

А вы кто? И как к вам обратится интересно?

Я точно знаю что у 2 людей с которыми я общался по поводу вируса была переписка с яндексом, в течении 2-х недель. 

Антон Матвеев
28 января 2016, 03:11

;-( и как до этого дожны были додуматься люди общавшиеся с поддержкой яндекс веб-мастера?

Это правда. Мудохались с этой заразой около недели. Из индекса вылетали страницы с завидной регулярностью. Перепроверили что можно, и даже то что нельзя - безрезультатно. Стали грешить на глюки яндекса... Саппорт стандартно отписывался ссылкой на первоначальную статью по вирусу на safesearch. Если бы там был хотя бы намек на то, что причина в заражении бинарников - не пришлось бы мигрировать кучку серверов к другому хостеру и нести связанные с этим издержки. Ну да бог с ними. Новый хостер лучше, дешевле, а за миграцию дали приемую :) Но Если знали в чем причниа, чего стоило опубликовать? Или это такой маркетинговый ход...

Всё проще, знать прямой email не нужно. В Я.Вебмастере, в правой колонке, всегда есть ссылка "Задать вопрос о сайте службе поддержки". Щёлкаете - открывается форма. Если сайт заражён - содержимое формы отправляется сотрудникам, которые могут показать на правильный раздел help'а или пост (нового не так уж много, почти обо всём уже давно написали, читайте), а в особых случаях - проконсультировать.

 

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

 

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

Спойлер прикрутите а то страшно ссылки писать. Или чтоб ссылки не кликабельными были. Кто то топнет то сам виноват будет

Антон Матвеев
28 января 2016, 03:11

а чего это за Troj/JsRedir-IF новый? теперь определяется вместе с Troj/JsRedir-DM...

Не по теме, но... что за дрянь такая http://ivanov.in ? Постоянно лезет на комп.

Антон Матвеев
28 января 2016, 03:11

каким образом лезит на комп, это как проявляется? 

Ну не то чтобы лезет :))) , но в NoScript среди недоверенных постоянно. Куки я чищу, flash-куки тоже. Откуда эта нечисть взялась не понимаю.

Антон Матвеев
28 января 2016, 03:11

И чем она вам мешает? 

Хм... Не столько мешает, сколько раздражает – тем, что непонятно откуда и зачем взялось.

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

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

 

 

А что скажет уважаемый нами исследователь о подобной практики взлома в зоне .RU  и .РФ - или эти зоны доменные больше не интересуют Яндекс

Читайте внимательнее. Заражаются сайты в том числе в зоне .ru и .рф. Малварные сервера располагаются в зоне .in.

Антон Матвеев
28 января 2016, 03:11

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

за каждый день число уникальных хостов, с которых зафиксирован данный вид редиректа

Антон Матвеев
28 января 2016, 03:11

спасибо...