Вступление 

Мы рассказываем об этом потому, что:

• в сутки Яндекс детектирует среднем более 1400 новых заражений сайтов;
• всего Яндексу известно более 230k заражённых хостов, к-рые недополучают из-за заражения примерно 100m показов в сутки;
• с 24.05.2011 по 18.04.2012 было более 130 случаев заражения сайтов, которые знают все;
• даже известные сайты в основном попадают под обычные, массовые заражения, которые легко предотвратить и устранить, если следовать рекомендациям, приведённым ниже.

Безопасность веб-сайтов нужна:

• по общим причинам;
  • пользователям – чтобы не терять деньги (кража, мошенничество), ценные данные, время на лечение компьютеров, репутацию;
  • интернету – чтобы существовать (быть полезным для людей), без DDoS’ов, накрутки, спама;
  • злоумышленникам – чтобы пойти заниматься чем-нибудь полезным;
• из финансовых соображений:
  • сайту – чтобы его трафик, пользователи ( →деньги) не доставались другим:
    • не редиректить на другие сайты;
    • не заражать компьютеры пользователей;
    • не показывать чужих ссылок и рекламы;
    • предупреждения о заражении = – 99% трафика, поисковый спам = – 100% трафика;
  • поисковой системе – чтобы было, чем отвечать на запросы пользователей:
    • заражённые, испорченные, перенаправляющие сайты – это плохой ответ.

Как предотвратить заражение сайта 

• не дать злоумышленникам взломать сайт и разместить на нём malware;
• не размещать блоков с malware и вредоносных редиректов самим;
• не давать размещать malware пользователям в UGC.

Как помешать злоумышленникам  

• контролировать ввод данных пользователями:
  • закладывать контроль при разработке, причём не только на уровне javascript, но и на уровне серверного ПО:
    • проверять на стороне сервера, входят ли значения каждого параметра, которые принимает сервер, в допустимые списки и интервалы, допустим ли их размер;
    • обязательно проверять полученные от пользователя данные перед выполнением в eval, прямой вставкой в SQL-запросы, преобразованием типов, сохранением на сервере;
    • не оставлять параметров, нужных для отладочного режима, экспериментов с новой или отключенной функциональностью;
    • рассчитывать, что параметры могут быть отправлены серверу не только со страниц и из форм, которые сайт загружает в браузер пользователю, но и другими способами, и надёжно определить, откуда именно они отправлены, невозможно;
  • использовать WAF (Web Application Firewall) для защита от атак XSS, Injection;

• контролировать операции (Insecure Direct Object References):
  • защита от IDOR, CSRF, закрытие доступа к консолям администрирования, резервным копиям, SVN;
  • проверять все возможные URL и GET-запросы.

• обновлять CMS и серверное ПО, использовать минимум «кустарных» модулей, отключать лишнее, следить за новостями об уязвимостях своей CMS:
  
  • следить за обновлением и ограничением доступа к серверному ПО – OpenX, phpMyAdmin;
  • использовать дистрибутивы CMS из проверенных источников (в «nulled» дистрибутивы часто встраивают бэкдоры и вредоносные мобильные редиректы);

   

• использовать сложные пароли от веб-серверного ПО (FTP, SSH, админ-панели хостинга, CMS):
  • не менее 11 символов: буквы, цифры, специальные символы, чтобы было легче запоминать, можно взять обычное слово и «разбавить» его цифрами и символами;

• следить за тем, чтобы компьютеры людей, работающих с сервером (вебмастер, администратор, контент-менеджер, менеджер по продажам и т.д.) были не заражены, установить на них антивирусы (под Mac сейчас тоже достаточно много вирусов), обязательно обновлять антивирусы, операционную систему и программы;

• убрать данные, на каком ПО работает ваш сервер (ОС, веб-сервер, CMS), чтобы не позволять найти его с помощью поисковых dork-запросов;

• анти-кликджекинг – чтобы злоумышленники не могли использовать ваш сайт в качестве фона, и накладывать на него сообщения наподобие «чтобы попасть – отправьте платную SMS»:
  • встраивать в свою страницу JavaScript-проверки наподобие:
    

    if (top.location != window.location) top.location = window.location
    или
    top.location = 'http://example.com'

  • выдавать HTTP-Header:

    X-FRAME-OPTIONS SAMEORIGIN
    или
    X-FRAME-OPTIONS DENY

• хостингам – регулярно проверять свои сайты, например, например через Safe Browsing API Яндекса или API Яндекс.Вебмастера.

Как не заразить сайт самому, по незнанию  

• блоки и реклама – только от проверенных партнёрских программ:
  • избегать «уникальных предложений» (подозрительно высокая плата за счётчики и блоки, монетизация мобильного трафика) – вместо денег отсутствие трафика и потеря позиций в поисковых системах;
  • использовать партнёрские программы со скрытыми блоками – опасно;
  • блоки и реклама – только от проверенных систем;
  • по возможности принимать только статический контент, а именно ссылки и картинки. Не принимать подгружаемые <script> и <iframe>. .swf, .jar и ActiveX принимать только в виде исходного кода, но не в скомпиллированном виде, перед компилляцией проверять;
  • о новых партнерских системах – искать отзывы, проверять, какой контент через них приходит; пример заражения из-за распространения вредоносного кода партнёрской системой – traffbiz.ru;

• дистрибутивы CMS, виджеты, библиотеки – из проверенных источников (например, c официальных сайтов CMS):
  • дистрибутивы CMS из сомнительных источников, виджеты и сторонние библиотеки обязательно нужно проверять на распространение вредоносного кода:
    • как минимум сканировать их обычными антивирусами;
    • пример распространения версии CMS с встроенным backdoor'ом – DLE nulled by Zloy;
  • в wordpress-темах часто встречается подгрузка блоков с вредоносным кодом и ссылками для чёрного SEO – внимательно изучайте код шаблонов перед тем, как ставить их в CMS:
  • радио-виджеты для ucoz также могут быть заражены;

• контроль служебного доступа:
  • отбирайте доступ у тех, кто выполнял в ней разовые работы, у предыдущих владельцев, у тех, кто сейчас с ней не работает, в т.ч. у специалистов по маркетингу и у руководителей (понадобится – сделать легко);
  • если у вас статический сайт, то некоторые партнёрские системы просят FTP-доступ, чтобы ротировать на нём баннеры; у одной из таких партнёрских систем произошла утечка базы FTP-доступов, в результатов несколько десятков тысяч сайтов заразилось, поэтому лучше не давать сторонним системам доступ к директориям сайта по FTP без крайней необходимости;
  • та же ситуация с различными фрилансерами – периодически приходят жалобы на заражения после их работы (особенно если с ними расстались в плохих отношениях); обращайте внимание на репутацию людей, которых привлекаете к работе, отбирайте у них доступ после того, как работа окончена;

• выбирайте качественный хостинг – системы некоторых хостеров заражены, см. http://safesearch.ya.ru/replies.xml?item_no=449.

Как не дать заразить сайт пользователям через UGC  

• антиробот – можно использовать для этого специальные плагины к CMS, например BotScout, и/или сделать такую проверку самостоятельно, на основании различных списков ip-адресов ботов, например с myip.ms;

• валидация данных:
  • не давайте возможности вставлять javascript в <script>, тегах, гиперссылках;
  • не позволяйте вставлять <iframe>, <object>, <embed>, а также подгружать jar, swf, pdf, для которых сайт сам будет генерировать подобные теги;
  • лучше всего поддерживать конечный список разрешённых HTML-тегов;

   

• проверять ссылки, например, через Safe Browsing API Яндекса, обращайтесь за доступом: и рекомендациями по подключению на safesearch@yandex-team.ru;

• проверять загружаемые файлы, например с помощью virustotal.com Public API.

Как устранить заражение 

• вовремя узнать;
• остановить веб-сервер;
• найти браузерное malware, чтобы было легче найти причину, по которой его выдаёт веб-сервер;
• найти и удалить веб-серверное malware;
• устранить причины заражения;
• запустить веб-сервер снова.

Как вовремя узнать о заражении  

• наблюдайте за аномалиями в трафике сайта, статистике переходов на него и с него, например по Яндекс.Метрике;
• если пользуетесь системой контроля версий – регулярно сравнивайте то, что опубликовано, с тем, что должно быть;
• если пользуетесь браузерами от Яндекса, Opera, Яндекс.Интернет, Firefox с Яндекс.Баром – при просмотре своего сайта увидите предупреждения;
• сообщения в Я.Вебмастере http://webmaster.yandex.ru/;
• читайте email, которые приходят на стандартные адреса веб-сайта, а также email, указанные в его whois:
  • при заражении присылаем на них уведомления;
  • используются адреса info@, webmaster@, admin@, abuse@, administrator@, contact@, postmaster@, support@;
  • проблему спама, который приходит на стандартные адреса, можно решить с помощью Почты Яндекса для домена;
• сделайте книгу отзывов, в которой пользователи смогут пожаловаться, что сайт заражён;
• если ваш сайт является крупным и известным, ищищте на форумах сообщения «<DNS-имя> заражён», например с помощью Яндекс.Подписок и Поиска по блогам;
• системы мониторинга сайтов, такие как http://www.dasient.com/product-services/web-malware-protection/, http://verity.paladiononline.com/;
• читайте блог http://safesearch.ya.ru/, мы пишем в нём об актуальных заражениях.

Как найти браузерное malware  

• посмотреть детали заражения в Яндекс.Вебмастере, вкладка «Безопасность»;

• найти самостоятельно:
  • подготовить тестовый стенд:
    • Windows XP на виртуальной машине, IE+FF+Chrome+Opera без cookies и истории посещений;
    • Желательно IE7 и версии Sun Java, Acrobat Reader, Adobe Flash, выпущенные 2–3 года назад;
  • открыть свой сайт:
    • разными браузерами, с поисковой машины и напрямую, через прокси-сервер и напрямую, с обычным и с мобильным user-agent, можно использовать Firefox User Agent Switcher;
    • несколько раз, каждый раз смотреть, что загружается, например с помощью fiddler или HttpAnalyzer;
    • выданные сервером файлы глазами и проверять антивирусом;
    • признаки браузерного malware;
      • появление в коде страницы «лишних» тегов <iframe>, <script>, <object>, <embed>;
      • подгрузка данных/перенаправление на хосты в доменных зонах cz.cc, .in, .cn, .pl, прямых ip и dyndns-сервисов;
      • подделка под известные сайты: google-analylics.com, yandes.ru;
      • javascript c eval, unescape, document.write, document.location, document.URL, window.location, window.navigate, переопределение элементов DOM;
      • посторонний код в js-библиотеках;
      • длинные нечитаемые скрипты;
      • лишние операции со строками (переопределение, замена подстрок, смещение символов, конкатенация);
    • после каждого просмотра страницы – revert к исходному образу;

• если не смогли найти вредоносный код или удалить его – обратитесь в тех. поддержку Яндекса, email – в статьях Помощи.

Как найти веб-серверное malware  

• где искать:
  • в серверных скриптах, например:

  <?php header(“Location: evil.com” ?>

  • в шаблонах CMS:
    
    • особенно если SEO-ссылки или вредоносный код в конце страниц дублируюсь, лучше пояснить: как искать, в каких файлах;
  • в настройках веб-сервера или интерпретатора:
    • в .htaccess – настройки для mod_rewrite, php_value auto_append_file "\tmp\evil.txt";
    • особенно если серверный редирект, в т.ч. работающий только для мобильных, а также если до или после обычного блока <html>;
  • если сайт статический:
    • на соседнем сайте shared-хостинга, а также, вероятнее всего, утечка реквизитов доступа, либо заражение всего сервера;

• признаки серверного malware:
  • посторонний код:
    
    • дата модификации совпадает с временем заражения или позже;
    • не соответствует версии из системы контроля версии или из резервной копии;
  • обфусцированный код – нечитаемый, неструктурированный, закодированный;
  • использует характерные функции:
    • eval, assert, create_function;
    • base64_decode, gzuncompress, gzinflate, ob_start, str_rot13, preg_replace;
    • file_get_contents, curl_exec.

     

Как устранить причины заражения  

1. в 90% случаев на сервере есть веб-шелл, который обязательно надо отыскать; можно найти по характерным php-функциям или антивирусом;
2. проверить антивирусом, например kaspersky.yandex.ru, рабочие станции всех, кто работает с веб-сервером;
3. остановить веб-сервер;
4. обновить ПО;
5. сменить пароли: root, FTP, SSH, админ-панели хостинга, CMS; удалить везде лишних пользователей;
6. серверное malware можно удалить только после этого, иначе его быстро восстановят;
7. в течение нескольких недель пристально следить.

Если нашли что-то интересное

Отправьте вредоносный код, который нашли, специалистам Яндекса на анализ. Этим вы поможете и себе, и другим вебмастерам. Как это сделать, написано здесь.

Рис.1. Общее количество  заражённых и вылеченных сайтов Troj/JSRedir-GS

Рис.2. Количество новых сайтов, на которых обнаружено заражение Troj/JSRedir-GS, в день

1. обновляйте CMS;
2. после установки CMS в обязательном порядке удаляйте с веб-сервера её конфигурационные скрипты;
3. обязательно изменяйте пароли, которые СУБД использует по умолчанию, используйте сложные пароли;
4. используйте Web Application Firewall, например http://www.modsecurity.org/.

Серверный вредоносный код злоумышленники всегда дописывают в конец файлов functions.php, которые используются в темах CMS WordPress.

Рис.3. Пример серверного вредоносного кода Troj/JSRedir-GS

Особенность Troj/JSRedir-GS в том, что клиентский вредоносный код выдаётся в веб-браузер, только если пользователь не авторизован в CMS и время на заражённом сервере на момент выполнения скрипта успешно делится на два. Эти два условия – первая ступень защиты вредоносного кода от обнаружения и удаления вебмастером. Потому что обычно вебмастер авторизован в CMS, а выполняющийся с перерывами скрипт обнаружить сложнее.

Вредоносный код, отображаемый на страницах заражённой CMS, обфусцирован (рисунок 4) и для анализа нуждается в деобфускации (рисунок 5).

Рис.4. Браузерный вредоносный код Troj/JSRedir-GS в обфусцированном виде

Рис.5. Браузерный вредоносный код Troj/JSRedir-GS после деобфускации

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

Если подстрока найдена, пользователь перенаправляется на страницу h**p://googosearch.biz/search.php?ty=1&terms=<keyword>, где <keyword> — это ключевое слово, полученное в результате перехода на заражённый сайт с поисковой выдачи.

Ссылки с googosearch.biz, скорее всего, ведут на сайты, предлагающие установить программное обеспечение. Цели для перенаправления выбираются в зависимости от ключевых слов, по которым пришёл пользователь.