Как найти бэкдор на взломанном сайте и отследить источник

Ситуация такова:

На одном из сайте с самописным кодом на РНР был загружен web-shell, помимаweb-shell`а оставлены бэкдоры.

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

Вопросы в следующем:

1. Какие есть известные механизмы обнаружения бэк-доров?
2. С помощью каких инструментов можно отследить изменения в скриптах сайта (существующие скрипты, появление новых и т.д.). Вариант ответа: проверка целостности постоянная выявляет только факт модификации. Необходимо отследить именно откуда возникли изменения, т.е. кто их инициализировал. Может быть есть подходящие реализации honey-pot`ов…

Спасибо!
  • Вопрос задан
  • 14807 просмотров
Решения вопроса 1
KEKSOV
@KEKSOV
Буквально вчера занимался подобной проблемой на сайте знакомых с Joomla.

1. Зайдите по ssh и сделайте архив всего сайта, скачайте его к себе на машину.
2. Натравите на архив Касперского или Sophos (опыт показал, что они отлично выявляют зловреды, хотя и не все)
Все обнаруженные уязвимости вычистите прямо на сайте через vi. Если обнаружится, что eval запихали в EXIF картинок, то их просто надо пересохранить и залить обратно на сайт.

Пока антивирус делает свое дело, займитесь следующим:
1. Проверьте .htaccess на наличие левых редиректов. В моем случае все пользователи отправлялись на страницу phpinfo.php c какой-то порнухой.
2. Поищите код, который не найдут антивирусы:
2.1 В некоторых файлах встроена конструкция, позволяющая сохранить файл в произвольное место на сайте. В моем случае это находилось при помощи команды
find. -type file | grep php | xargs grep -l "<?php if (@"

2.2 Поищите и проанализируйте файлы, которые обращаются к exif
find. -type file | grep php | xargs grep -l exif_read_data

2.3 Найдите картинки с троянами
find. -type file | grep jpg | xargs grep -l eval

2.4 Поищите preg_replace, который потом выполняет код
find. -type file | grep php | xargs grep -l preg_replace.*\/e

3. Анитивирусы наверняка найдут какие-то файлы. Загляните в них на хостинге, как правило там идет закодированная хрень и проверка каких-нибудь паролей. Вот эти самые проверки могут дать дополнительные ключи для поиска. В моем случае я нашел еще ряд файлов при помощи команд
find. -type file | grep php | xargs grep -l 2970d43d7bf4115cdc60e2453bf48b52
find. -type file | grep php | xargs grep -l security_code

4. Внимательно проанализируйте файлы, которые находятся рядом с файлами бекдоров, скорее всего именно в них и находится уязвимость.
5. Слейте дамп базы и поищите в нем eval, preg_replace и прочие прелести
6. После зачистки всей дряни снова сделайте бекапный архив сайта

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

На сервере, где хостятся мои знакомые есть только cvs, им и воспользуемся. Аналогичные действия можно сделать и при помощи git или svn.

1. Вышли в домашнюю директорию
cd

2. Создали пустую директорию для нашего репозитория
mkdir cvsroot

3. Заинитили репозиторий
cvs -d ~/cvsroot init

4. Перешли в директорию, где находится корень сайт. Пусть у вас есть такая структура /home/myusername/mysite/htdocs. Тогда
cd ~/mysite/htdocs

5. Делаем первичный импорт в репозиторий
cvs -d ~/cvsroot import htdocs initial_import initial

6. Сейчас будем удалять старый сайт и забирать его из репозитория
cd ~/mysite
mv htdocs htdocs.bak
cvs -d ~/cvsroot checkout www

7. Добавляем в .htaccess правило, защищающее служебные файлы
RedirectMatch 404 /CVS(/|$)

8. Что это нам дает? Возможно быстрой проверки измененных файлов
cd ~/mysite/htdocs
cvs -qn update

Если все было сделано правильно, то ответ будет
M .htaccess

9. Записываем наши изменения в репозиторий
cvs -q commit -m update

Далее, включаем в cron команду cvs -q commit -m update, да хоть бы и раз в минуту (если сайт сильно посещаемый), включаем лог файлы и ловим изменения, которые происходят в системе. Определив время и изменившиеся файлы, по логам смотрим что, кто, куда и как делал.
Ответ написан
Пригласить эксперта
Ответы на вопрос 10
charliez
@charliez
На сайт, в скриптах которого есть уязвимость, обычно заливают ремотшеллы. Как их искать — на хабре есть хорошая статейка на эту тему: habrahabr.ru/post/188878/
Ответ написан
@maxic
php — ищем в коде: eval, base64
Ответ написан
nazarpc
@nazarpc
Open Source enthusiast
Включите/посмотрите access логи веб-сервера
Ответ написан
@artishok
кратко
Возможно вирус залезает с компьютера по фтп?
Ответ написан
UZER2006
@UZER2006
В таком случае либо уязвимость в вашем движке, либо компрометация всего сервера на хостинге.
Ответ написан
OnYourLips
@OnYourLips
1. Нужно посмотреть список файлов, отличающихся от стабильного билда из системы контроля версий.
2. Логи httpd/sshd.
Ответ написан
charliez
@charliez
Выявить — как произошли изменения, можно только лишь сопоставляя время изменения файлов с access.log — в случае, если взламывают через уязвимость в скриптах или используя ранее залитые вредоносные скрипты.
Ответ написан
DeVitoz
@DeVitoz
Для начала проверяем локальную машину на вирусы :--) Потом, меняем все пароли какие только есть: на ftp, админку хостинга, админку сайта, phpmyadmin и т.п. Короче все-все-все пароли. <urgant-mode>Можно даже замки в квартире сменить :--)</urgant-mode> Если используете s/ftp-клиент, лучше не сохранять в нем пароли вообще.
После этого ищите в php-скриптах не свои или незнакомые javascript'ы. Можно например по запросу "<script" или еще как-то придумаете, точно так же ищите по слову «eval». Не мешает посмотреть что творится в .htaccess, а если он не один, то во всех. Там тоже иногда разная подозрительная шняга хранится. Обращайте внимание на даты редактирования файлов — это облегчит поиск. Так же по возможности запретите редактирование файлов которые не должны редактироваться. Еще можете попросить хостеров чтобы они выдали инфу по подозрительной активности файлов. Некоторые хостеры сразу предоставляют список зараженных файлов :--)
Это конечно на вскидку, но обычно хватает.
Ответ написан
foxmuldercp
@foxmuldercp
Системный администратор, программист, фотограф
1. проверяем файлы «движка», сравнивая их с оригинальной версией файлов движка той же версии, при установке, если это известный движок, вроде вордпресса/битрикса. Если взломали сам движок — сравние файлов это покажет.
2. тоже самое с файлами плагинов/тем/скриптов если между вашими и файлами из дистрибутивов есть различия, это будет видно.
3. глубокая проверка Ваших хостов на вирусы.
4. глобальная мена паролей на админки — сайта, фтп, вебморды аккаунта в панели управления у хостера.
Ответ написан
Lux_In_Tenebris
@Lux_In_Tenebris
2. С помощью каких инструментов можно отследить изменения в скриптах сайта (существующие скрипты, появление новых и т.д.). Вариант ответа: проверка целостности постоянная выявляет только факт модификации. Необходимо отследить именно откуда возникли изменения, т.е. кто их инициализировал.

в user-mode ничего не поможет, не считая анализа логов веб-сервера, только аудит

Пингвин под колпаком: Аудит системных событий в Linux
Аудит в Linux, часть первая
Understanding Linux Audit
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы