Правда жизни такова, что сайт рано или поздно могут взломать. После успешной эксплуатации уязвимости хакер старается закрепиться на сайте, размещая в системных директориях хакерские веб-шеллы, загрузчики и внедряя бэкдоры в код скриптов и базу данных CMS.
Для обнаружения вредоносного кода в файлах и базе существуют специализированные решения – антивирусы и сканеры для хостингов. Их не так много, из популярных – это AI-BOLIT, MalDet (Linux Malware Detector) и ClamAv.
Сканеры помогают обнаруживать загруженные веб-шеллы, бэкдоры, фишинговые страницы, спам-рассыльщики и другие типы вредоносных скриптов – все то, что им известно и заранее добавлено в базу сигнатур вредоносного кода. Некоторые сканеры, например, AI-BOLIT, обладают набором эвристических правил, которые позволяют обнаруживать файлы с подозрительным кодом, который часто используется во вредоносных скриптах, или файлы с подозрительными атрибутами, которые могут быть загружены хакерами. Но, к сожалению, даже в случае использования нескольких сканеров на хостинге, возможны ситуации, когда некоторые хакерские скрипты остаются не обнаруженными, что фактически означает, что у злоумышленника остается “черный ход” и он может взломать сайт и получить над ним полный контроль в любой момент.
Современные вредоносные и хакерские скрипты значительно отличаются от тех, что были 4-5 лет назад. Сейчас разработчики вредоносного кода комбинируют обфускацию, шифрование, декомпозицию, внешнюю подгрузку вредоносного кода и используют другие уловки для того, чтобы обманывать антивирусное ПО. Поэтому вероятность пропуска новых “вредоносов” значительно выше, чем раньше.
Что же можно сделать в данном случае для более эффективного обнаружения вирусов на сайте и хакерских скриптов на хостинге? Необходимо использовать комплексный подход: первоначальное автоматизированное сканирование и дальнейший ручной анализ. В этой статье речь пойдет о вариантах обнаружения вредоносного кода без сканеров.
Вначале рассмотрим, что именно следует искать при взломе.
- Хакерские скрипты.
- Чаще всего при взломе загружают файлы, представляющие собой веб-шеллы, бэкдоры, “загрузчики” (uploaders), скрипты для спам-рассылок, фишинговые страницы + обработчики форм, дорвеи и файлы-маркеры взлома (картинки с лого хакерской группы, текстовые файлы с “посланием” от хакеров и т.п.)
- Инжекты (внедрения кода) в существующих файлах.
- Второй по популярности тип размещения вредоносного и хакерского кода – это инжекты. В существующие файлы сайта.htaccess могут внедрять мобильные и поисковые редиректы, в php/perl скрипты инжектировать бэкдоры, в .js и .html шаблоны встраивать вирусные javascript фрагменты или редиректы на сторонние ресурсы. Возможны инжекты и в медиа-файлах, например .jpg или . Часто вредоносный код состоит из нескольких компонентов: сам вредоносный код хранится в exif-заголовке jpg файла, а исполняется с помощью небольшого управляющего скрипта, код которого не выглядит подозрительным для сканера.
- Инжекты в базе данных.
- База данных является третьей мишенью для хакера. Здесь возможны статические вставки <script>, <iframe>, <embed>, <object>, которые перенаправляют посетителей на сторонние ресурсы, “шпионят” за ними или заражают компьютер/мобильное устройство посетителя в результате drive-by атаки.
- Кроме того во многих современных CMS (IPB, vBulletin, modx и др.) шаблонизаторы позволяют исполнять php код, а сами шаблоны хранятся в базе данных, поэтому php код веб-шеллов и бэкдоров может быть встроен непосредственно в БД.
- Инжекты в кэширующих сервисах.
- В результате некорректной или небезопасной настройки кэширующих сервисов, например, memcached, возможны инжекты в закэшированные данные “на лету”. В некоторых случаях хакер может внедрять вредоносный код на страницы сайта без непосредственного взлома последнего.
- Инжекты/инцицированные элементы в системных компонентах сервера.
- Если хакер получил привелегированный (root) доступ к серверу, он может подменить элементы веб-сервера или кэширующего сервера на инфицированные. Такой веб-сервер будет с одной стороны обеспечивать контроль над сервером с помощью управляющих команд, с другой – время от времени внедрять динамические редиректы и вредоносный код на страницы сайта. Как и в случае инжекта в кэширующий сервис, администратора сайта скорее всего не сможет обнаружить факт взлома сайта, так как все файлы и база данных будут оригинальными. Этот вариант наиболее сложный для лечения.
Поиск вручную
В unix сложно найти более ценную пару команд для поиска файлов и фрагментов, чем find / grep.
find . -name ‘*.ph*’ -mtime -7найдет все файлы, которые были изменены за последнюю неделю. Иногда хакеры “скручивают” дату изменения у скриптов, чтобы таким образом не обнаружить новые скрипты. Тогда можно поискать файлы php/phtml, у которых менялись атрибуты
find . -name ‘*.ph*’ -сtime -7Если нужно найти изменения в каком-то временном интервале, можно воспользоваться тем же find
find . -name ‘*.ph*’ -newermt 2015-01-25 ! -newermt 2015-01-30 -lsДля поиска в файлах незаменим grep. Он может искать рекурсивно по файлам указанный фрагмент
grep -ril ‘stummann.net/steffen/google-analytics/jquery-1.6.5.min.js’ *При взломе сервера полезно проанализировать файлы, у которых установлен guid/suid флаг
find / -perm -4000 -o -perm -2000Чтобы определить, какие скрипты запущены в данный момент и грузят CPU хостинга, можно вызвать
lsof +r 1 -p `ps axww | grep httpd | grep -v grep | awk ‘ { if(!str) { str=$1 } else { str=str»,»$1}}END{print str}’` | grep vhosts | grep phpИспользуем мозг и руки для анализа файлов на хостинге
- Идем в директории upload, cache, tmp, backup, log, images, в которые что-то пишется скриптами или загружается пользователями, и просматриваем содержимое на наличие новых файлов с подозрительными расширениями. Например, для joomla можно проверить .php файлы в каталоге images:find ./images -name ‘.ph’Скорее всего, если что-то найдется, то это будет вредонос.
- Для WordPress имеет смысл проверить на скрипты директорию wp-content/uploads, backup и cache каталоги тем.
- Ищем файлы со странными именами
- Например, php, fyi.php, n2fd2.php. Файлы можно искатьпо нестандартным сочетаниям символов,
- наличию цифр 3,4,5,6,7,8,9 в имени файлов
- Ищем файлы с нехарактерными расширениями
- Допустим, у вас сайт на WordPress или Для них файлы с расширениями .py, .pl, .cgi, .so, .c, .phtml, .php3 будут не совсем обычными. Если какие-то скрипты и файлы с данными расширениями будут обнаружены, скорее всего это будут хакерские инструменты. Возможен процент ложных обнаружений, но он не велик.
- Ищем файлы с нестандартными атрибутами или датой создания
- Подозрения могут вызывать файлы с атрибутами, отличающимися от существующих на сервере. Например, все .php скрипты были загружены по ftp/sftp и имеют пользователя user, а некоторые созданы пользователем www-data. Имеет смысл проверить последние. Или если дата создания файла скрипта раньше даты создания сайта.
- Для ускорения поиска файлов с подозрительными атрибутами удобно пользоваться unix командой find.
- Ищем дорвеи по большому числу файлов .html или .php
- Если в каталоге несколько тысяч файлов .php или .html, скорее всего это дорвей.
Логи веб-сервера, почтового сервиса и FTP можно использовать для обнаружения вредоносных и хакерских скриптов.
- Корреляция даты и времени отправки письма (которые можно узнать из лога почтового сервера или служебного заголовка спам-письма) с запросами из access_log помогают выявить способ рассылки спама или найти скрипт спам-рассыльщика.
- Анализ трансфер-лога FTP xferlog позволяет понять, какие файлы были загружены в момент взлома, какие изменены и кем.
- В правильно настроенном логе почтового сервера или в служебном заголовке спам-письма при правильной настройке PHP будет имя или полный путь до скрипта-отправителя, что помогает определять источник спама.
- По логам проактивной защиты современных CMS и плагинов можно определять, какие атаки были выполнены на сайт и сумела ли CMS им противостоять.
- По access_log и error_log можно анализировать действия хакера, если известны имена скриптов, которые он вызывал, IP адрес или User Agent. В крайнем случае можно просмотреть POST запросы в день взлома и заражения сайта. Часто анализ позволяет найти другие хакерские скрипты, которые были загружены или уже находились на сервере в момент взлома.
Намного проще анализировать взлом и искать вредоносные скрипты на сайте, если заранее позаботить о его безопасности. Процедура контроля целостности (integrity check) помогает своевременно обнаруживать изменения на хостинге и определять факт взлом. Один из самых простых и эффективных способов – положить сайт под систему контроля версий (git, svn, cvs). Если грамотно настроить .gitignore, то процесс контроля за изменениями выглядит как вызов команды git status, а поиск вредоносных скриптов и измененных файлов – git diff.
Также у вас всегда будет резервная копия файлов, до которой можно «откатить» сайт в считанные секунды. Администраторам сервера и продвинутым веб-мастерам можно использовать inotify, tripwire, auditd и другие механизмы для отслеживания обращений к файлам и директориям, и контроля за изменениями в файловой системе.
К сожалению, не всегда есть возможность настроить систему контроля версий или сторонние сервисы на сервере. В случае shared-хостинга не получится установить систему контроля версий и системные сервисы. Но это не беда, есть достаточно много готовых решений для CMS. На сайте можно установить плагин или отдельный скрипт, который будет отслеживать изменения в файлах. В некоторых CMS уже реализован эффективный мониторинг изменений и механизм integrity check (Например, в Битрикс, DLE). В крайнем случае, если на хостинге есть ssh, можно сформировать эталонный слепок файловой системы командой
ls -lahR > original_file.txtи при возникновении проблем создать новый слепок в другой файл, а затем сравнить их в программах WinDiff, AraxisMerge Tool или BeyondCompare.
Эпилог
В большинстве случаев разработчики антивирусного ПО и сканеры не поспевают за разработчиками вредоносного кода, поэтому при диагностике и лечении сайтов нельзя полагаться только на автоматизированные программные решения и скрипты. Используя эвристический подход, богатый инструментарий операционной системы и возможности CMS можно находить вредоносный код, который не смогли обнаружить антивирусы и сканеры. Использование ручного анализа делает процесс лечения сайтов более качественным и эффективным.