Поиск и устранение вредоносного кода на сайте. Рассылка спама.

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

Соблюдение нескольких элементарных правил поможет защитить Ваш сайт:

  • используйте сложные пароли - латинские символы верхнего и нижнего регистра в сочетании с цифрами и сложными символами;

  • не сообщайте авторизационные данные сторонним лицам;

  • устанавливайте модули и шаблоны CMS только с официальных ресурсов разработчика;

  • обновляйте модули только с официальных ресурсов разработчика;

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

  • своевременно обновляйте CMS;

 

Рассмотрим вариант заражения, связанный со взломом сайта.

Одним из самых распространенных последствий взлома сайта, является загрузка вредоносных скриптов на хостинг и внедрение их в кодовую базу этого сайта. Подобные скрипты используются для различных вредоносных действий, таких как рассылка спама, осуществление DDOS/bruteforce атак на другие ресурсы, распространение вирусов, перенаправление посетителей на фишинговые страницы, и выполнение других запрещенных действий. Данная активность приводит к нагрузке веб-сервера, что сказывается на остальных его пользователях. В связи с этим, подобные действия отслеживаются и изолируются  хостинг-провайдером.

 

У владельца сайта возникает два важных вопроса:

1. Что сделать, чтобы хостер разблокировал сайт?

2. Что сделать, чтобы предотвратить подобную ситуацию в будущем?

 

Что сделать, чтобы хостер разблокировал сайт?

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

Пример:

200P Received: from domain by by164.net with local (Exim 4.80.1)

(envelope-from <webmaster@domain.com>)

id 1Wt8ty-0001S7-0i

for cshоrt@аriеsnеt.com; Sat, 07 Jun 2014 08:10:46 +0300

024T To: cshоrt@test.com

027 Subject: Ship Notification

039 X-PHP-Script: domain.com/ for 127.0.0.1

047 X-PHP-Originating-Script: 1586:841rewb3v4x.php

048F From: "Postal Service" <message_id17@domain.com>

030 X-Mailer: CSWMSAutoMailer:reg

052R Reply-To: "Postal Service" <message_id17@domain.com>

018 Mime-Version: 1.0

081 Content-Type: multipart/alternative;boundary="----------140211784653929ED602110"

051I Message-Id: <E1Wt8ty-0001S7-0i@by164.net>

 

Здесь, как и во всех письмах, присутствуют поля “FROM:”, “TO:”,  “SUBJECT:”, из содержимого которых можно определить, отправителя, получателя и тему сообщения.

Иногда (но не всегда) в заголовках присутствуют поля   “X-PHP-Scrip”и “X-PHP-Originating-Script”, которые содержат адрес скрипта, при помощи которого осуществлялась рассылка спама. В данном случае это скрипт под именем 841rewb3v4x.php

Поиск и устранение скрипта можно организовать двумя способами:

  1. Загрузка посредством FTP-доступа файлов сайта на локальный компьютер и поиск вредоносного скрипта при помощи антивируса, либо вручную;

  2. Запросить у хостинг-провайдера доступ к серверу по SSH и выполнить поиск непосредственно на хостинге.

     

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

 

Вначале необходимо подключиться к серверу. Пример подключения:

$ ssh [user]@[domain]

$ user@domain's password: [password]:

 

 

 

После установки соединения следует перейти в локальную директорию сайта, для этого необходимо выполнить следующие команды:

$ cd ~

$ cd ./www/domain.com

 

где domain.com - это название Вашего сайта. Выполняем команду для поиска вредоносного скрипта:

$ find ./ -name "841rewb3v4x.php"

 

В данном случае команда вывела следующий путь к файлу:

./wp-includes/images/smilies/841rewb3v4x.php

 

 

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

<?php

$xYEzDu6r3EZT="GR5yYXp3YH17ejRne3h9cGdgdWBxPDB5dX9xYWQ9NG8ZHjQ0NDQweHt4NCk0Mz

UgIiEsIHAidyIsIyciJSEgIXUnJSBxISMidickIichIyAtIyIgcSclICYhISEgInUhdSEsISInJiMsInAhICEhISEn

JSBxJycgdSclIiAgJyMgInAiJSMtJy0hJCEtISMgcSB2IScnJicsJyEhJiJ2IncgLCImI3UgIiAsIiYjdSJ3IC0hJy

EhIicnJSEtInciIyN1IS0nJiMgI3UiIC";eval(base64_decode("ZXZhbChiYXNlNjRfZGVjb2RlKCJaWFpoYkN

oaVlYTmxOalJmWkdWamIyUmxLQ0pLU0doaFRWZHdNbGRFV1RCT1Ixb3dVRmRLYUdNeVZUSk9Samxy

V2xkT2RscEhWVzlKYkd4MFVtNXdZVlpHYTNkWFJFc="));

?>

 

Для примера, приведен самый распространенный случай исполнения вредоносного кода. Подобная структура файла обозначает, что в файле содержится вирусная сигнатура, которая исполняется посредством функции php eval() и декодируется через base64. Сочетание функции eval(base64_decode самое распространенное во вредоносных скриптах, так как она позволяет исполнять вредоносный код, который находится в закодированном виде, тем самым затрудняя анализ когда. Более подробно об этих функцияx можно прочесть на официальном сайте PHP:

http://php.net//manual/ru/function.eval.php

http://php.net//manual/ru/function.base64-decode.php

 

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

Необходимо зафиксировать дату создания файла, для этого воспользуемся командой ls:

$ ls -la ./wp-includes/images/smilies/841rewb3v4x.php

 

И получим примерно следующий вывод:

-rw-r--r-- 1 user_site user_site 420 Nov 14 2012 ./wp-includes/images/smilies/841rewb3v4x.php

 

 

 

Теперь видно, что дата создание файла “Nov 14 2012”  14 ноября 2012 года.

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

$ find ./ -name "*.php" | xargs ls -la | grep "Nov 14"

 

Вывод:

-rw-r--r-- 1 user_site user_site 420 Nov 14 2012 ./wp-includes/images/smilies/841rewb3v4x.php

-rw-r--r-- 1 user_site user_site 4611 Nov 14 2012 ./wp-content/themes/Video/single_blog.php

-rw-r--r-- 1 user_site user_site 365 Nov 14 2012 ./wp-content/themes/Video/single.php

-rw-r--r-- 1 user_site user_site 4809 Nov 14 2012 ./wp-config.php

-rw-r--r-- 1 user_site user_site 421 Nov 14 2012 ./wp-content/languages/ru_RU.php

 

 

Проверим все эти файлы на наличие функции eval(base64_decode:

$ find ./ -name "*.php" | xargs ls -la | grep "Nov 14" | awk '{print $9}' | xargs grep "eval(base6"

 

Вывод:

./wp-includes/images/smilies/841rewb3v4x.php:eval(base64_decode("ZXZhbChiYXNlNjRfZGVjb2Rl

 

В данном случае повезло, так как зафиксирован только один файл с подобной структурой.

 

Необходимо выполнить поиск всех скриптов на сайте которые используют функцию eval(base64_decode, для этого выполним команду:

$ find ./ -name "*.php" | xargs grep -w "eval(base64_decode"

 

Вывод:

./wp-content/themes/twentytwelve/404.php

./wp-content/themes/yoo_spark_wp/cache/rss.php

./wp-content/themes/yoo_spark_wp/cache/mainik.php

./wp-includes/images/smilies/841rewb3v4x.php

 

 

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

 

Зараженные файлы можно разделить на 2 группы:

1) Файл, который полностью содержит вредоносный код;

2) Файл, в который вставлена строчка вредоносного кода.

 

Если Вы сталкиваетесь с первым типом файла, то его можно удалять.

Если Вам попался второй тип, когда скрипт необходим для работы сайта, но в него вставлена строчка, тогда достаточно удалить данную строку. Самые распространенные случаи, когда строка вставлена в самом начале файла или в самом конце файла, это используется для того, чтобы скрыть вставку начала вредоносного php скрипта <$php код_скрипта  $> в уже существующем скрипте.

 

Как же локализовать проблему и понять каким образом было реализовано первоначальное заражение? В приведенном примере видно, что файл 841rewb3v4x.php имеет такую же дату создания как и системные файл CMS wordpress:

-rw-r--r-- 1 user_site user_site 420 Nov 14 2012 ./wp-includes/images/smilies/841rewb3v4x.php

-rw-r--r-- 1 user_site user_site 4611 Nov 14 2012 ./wp-content/themes/Video/single_blog.php

-rw-r--r-- 1 user_site user_site 365 Nov 14 2012 ./wp-content/themes/Video/single.php

-rw-r--r-- 1 user_site user_site 4809 Nov 14 2012 ./wp-config.php

-rw-r--r-- 1 user_site user_site 421 Nov 14 2012 ./wp-content/languages/ru_RU.php

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

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

 

Существует еще один способ поиска источника рассылки спама и других вредоносных скриптов. Для того, чтобы скрипт осуществлял рассылку, к скрипту должен придти запрос на выполнение из сети интернет. Все запросы логируются и детализируются в лог-файлах веб-сервера. Лог-файлы доступны в директории /logs/

Для проверки логов на наличие обращений к вредоносным файлам необходимо выполнить следующие команды: 

$ cd ~
$ cd /logs/
$ cat ./domain.com.access.log. | grep POST

 

 

вывод:

146.185.239.40 - - [06/Jun/2014:20:05:18 +0300] "POST /wp-includes/images/smilies/841rewb3v4x.php HTTP/1.0" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0" 597662

146.185.239.40 - - [06/Jun/2014:20:08:43 +0300] "POST /wp-includes/images/smilies/841rewb3v4x.php HTTP/1.0" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0" 606836

146.185.239.40 - - [06/Jun/2014:20:12:20 +0300] "POST /wp-includes/images/smilies/841rewb3v4x.php HTTP/1.0" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0" 767144

146.185.239.40 - - [06/Jun/2014:20:15:49 +0300] "POST /wp-includes/images/smilies/841rewb3v4x.php HTTP/1.0" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0" 823242

146.185.239.40 - - [06/Jun/2014:20:19:23 +0300] "POST /wp-includes/images/smilies/841rewb3v4x.php HTTP/1.0" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0" 846859

146.185.239.40 - - [06/Jun/2014:20:22:59 +0300] "POST /wp-includes/images/smilies/841rewb3v4x.php HTTP/1.0" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0" 789467

146.185.239.40 - - [06/Jun/2014:20:26:20 +0300] "POST /wp-includes/images/smilies/841rewb3v4x.php HTTP/1.0" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0" 801159

146.185.239.40 - - [06/Jun/2014:20:29:46 +0300] "POST /wp-includes/images/smilies/841rewb3v4x.php HTTP/1.0" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0" 828098

 

 

Из вывода видно, что POST запросы приходят к файлу

 

/wp-includes/images/smilies/841rewb3v4x.php

Который ранее мы нашли и зафиксировали как зараженный.

 

 

Что сделать, чтобы предотвратить подобную ситуацию в будущем?

 

 

  1. Удалить все файлы с вредоносным кодом. Это очень Важный и одновременно сложный момент. Дело в том, что если у Вас на хостинге несколько сайтов, то очень велика вероятность, что вредоносный код присуствует на всех сайтах. Вредоносный код может распространяться на сайтах в пределах одного аккаунта. Удалить вредоносный код желательно когда сайты недоступны. В момет когда сайты доступны вредоносный код может распространяться и дублировать себя. При удаление вредоносного кода с включенным сайтом, может произойти ситуация когда вредоносный код удален с одного сайта а параллельно с этим второй сайт заново начинает заражать уже очищенный. 

  2. Изменить все пароли. В обязательном порядке необходимо изменить пароли к

    - FTP (SSH) от панели управления хостингом;

    - Административной панели CMS;

    - Пользователям баз данных

     Пароли должны быть сложными, вида “4GgwHss2y45

  3. Проверьте основные функции сайта, а затем сделайте резервную копию через FTP на свой локальный компьютер, чтобы, в случае проблем, восстановить его из проверенной резервной копии.

     

Рекомендации по безопасной работе с сайтом

  1. Очистите кэш браузера и куки перед открытием сайта после лечения

  1. Работайте через SFTP протокол, а не FTP (используйте программу WinSCP и SSH логин/пароль)

  2. Не храните пароли в браузере и FTP клиенте, это опасно.

  3. Проверяйте рабочий компьютер коммерческим антивирусом с обновляемой базой вирусов хотя бы раз в месяц.

  4. Следите за обновлением версии CMS, на которой работает ваш сайт. Регулярно обновляйте CMS и плагины.

  5. Добавьте сайт в панели веб-мастеров Google (http://www.google.com/intl/ru/webmasters) и Яндекс (http://webmaster.yandex.ru). В этом случае Вы своевременно будете информированы об изменениях, происходящих с сайтом. В том числе, касающихся безопасности. 

 

 

При поиске и устранении вредоносного кода на сайте, нужно оперировать всеми возможными источниками информации. Как минимум это:

- Лог файлы веб-сервера

- Лог файлы FTP-сервера

- поиск файлов на сайте с функцией «eval(base64_decode» или «eval()» содержащий закодированный код.

 

 

Хочется отметить, что ActiveCloud не предоставляет услуг по поиску и устранению вредоносного кода на сайте. Код сайта это область компетенции разработчиков сайта.



Если решение вопроса найти не удалось, Вы можете отправить нам заявку:



(34 голос(а))
Эта статья помогла
Эта статья не помогла

Комментарии (0)