В большинстве случаев т.н. “вредоносных редиректов” осуществляющихся путём взлома .htaccess, которые я в последнее время видел (если не во всех), после очистки файла .htaccess вредоносный код добавляется снова в течение 30 минут.
Это делается при помощи т. н. “бекдоров”, которые хакеры поместили в код скриптов сайта. До сих пор все они были php-файлами, загруженными в папки сайта хакерами. Владельцы сайтов сообщали, что бэкдор был php файлом, названным w17481866w.php/wp-hxnqb.php расположенным в корневой папке сайта.
На WordPress сайтах использовались такие файлы как:
/wp-includes/js/tinymce/plugins/media/jquery.autogrow.php /wp-includes/js/tinymce/plugins/wpgallery/img/site.php /wp-includes/js/tinymce/plugins/wpgallery/img/hodoo.php /wp-includes/core.php
|
/wp-includes/js/tinymce/plugins/media/jquery.autogrow.php /wp-includes/js/tinymce/plugins/wpgallery/img/site.php /wp-includes/js/tinymce/plugins/wpgallery/img/hodoo.php /wp-includes/core.php |
Во всех приведённых примерах я до сих пор видел base64-кодированный php скрипт, так что утилита для поиска файлов, содержащих base64 должна быть полезной в обнаружении таких файлов.
08/28/2012 — Редиректы на google.com (или bing.com) на сайтах Joomla Этот хак встречается на сайтах использующих старые версии Joomla. Редиректы изменяются каждые несколько часов, иногда они перенаправляют на сайт с вредоносным содержимым, с которого оно скачивается незаметно для пользователя, после чего он перенаправляется на google.com. Несколько часов спустя они перенаправляют на другой контролируемый хакером сайт и ничего не скачивается, после чего посетитель перенаправляется на Гугл (или Бинг), а ещё несколько часов спустя они перенаправляют непосредственно на google.com. Это условный редирект на основе ссылающейся страницы, являющейся поисковой системой, Google или Bing. Во всех случаях, которые мне встречались это был хак файла .htaccess, и во всех случаях он включал наличие на сайте бекдора. На сайтах которые я видел, бекдоры располагались в папках типа /images/stories/ или images/banners.
Проанализируйте ваши логи доступа на наличие примерно таких запросов:
Проанализируйте ваши логи доступа на наличие примерно таких запросов:
[04/Sep/2012:15:20:17 -0600] «POST /images/banners/.lib_l9ium8.php HTTP/1.1» 500 3950 «-» «Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0»
|
[04/Sep/2012:15:20:17 -0600] «POST /images/banners/.lib_l9ium8.php HTTP/1.1» 500 3950 «-» «Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0» |
Имена файлов формировались по шаблонам вроде .cache_bqwn68.php .cache_boacfm.php .cache_ja3loa.php (за некоторыми исключениями, когда имена файлов были немного более неясными – story.php, sitemap.php, 0day.php)
Проверьте сайт на наличие файлов именованых по этим шаблонам, и если вы найдете любой подозрительный файл — проверьте его на наличие какого-либо обфусцированного PHP-кода, ктороый начинается примерно вот так:
preg_replace(«/.*/e»,»\x65\x76\x61\x6c\x20\x28\x20\x67\x7a\x69\x6e\x66\x6c\x61\x74\x65\x20\x28\x20\x62\x61\x73\x65 .
|
preg_replace(«/.*/e»,»\x65\x76\x61\x6c\x20\x28\x20\x67\x7a\x69\x6e\x66\x6c\x61\x74\x65\x20\x28\x20\x62\x61\x73\x65 . |
Последние три сайта которые я смотрел, кроме прочего имели хак в файлах JavaScript сайта. Вредоносный код был размещен в конце этих файлов. Это была строка скрипта, создающего на странице сайта iframe:
document.write(»);
|
document.write(»); |
09/13/2012 На многих сайтах я встречаю множество файлов .htaccess с вредоносным содержимым, которые расположены в разных директориях сайта. Вам необходимо проверить все папки сайта. Так, один из сайтов содержал 42 зараженных файла .htaccess в дополнение к тому, который находился в корневой папке.
Один владедец сайта на WordPress также смог найти бекдор изучая лги сервера. Его рекомендации –
Кроме того, анализируя логи сервера, запросы к wp-raikc.php приходили парами с интервалом в секунду или две. Каждый из них имел одинаковое значение user agent (“Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0″).
Они все были POST запросами к wp-raikc.php и все выполнялись успешно. Каждая пара имела чередующиеся номера 391 и 286. И наконец, около половины запросов приходило с IP-адреса в следующем формате: 188.120.*.*
Пример из моего access.log:
188.120.*.* — — [06/Feb/2012:16:22:29 -0800] «POST /dotProject/wp-raikc.php HTTP/1.1» 200 391 «-» «Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0» 188.120.*.* — — [06/Feb/2012:16:22:30 -0800] «POST /dotProject/wp-raikc.php HTTP/1.1» 200 286 «-» «Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0»
|
188.120.*.* — — [06/Feb/2012:16:22:29 -0800] «POST /dotProject/wp-raikc.php HTTP/1.1» 200 391 «-» «Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0» 188.120.*.* — — [06/Feb/2012:16:22:30 -0800] «POST /dotProject/wp-raikc.php HTTP/1.1» 200 286 «-» «Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0» |
(IP-адрес скрыт на случай, если компьютер, которому он принадлежит использовался как прокси)
Итак, моя рекомендация состоит в том чтобы анализировать логи вашего сервера.
Один владелец сайта предоставил содержимое бекдора, внедрённого в его сайт. В этом случае бекдор был в виде отдельного php-файла в корневой директории сайта.
Файл содержал следующий код: