WSG

Рейтинг
6
Регистрация
01.06.2009
hi_jack:
Это самые распространенные варианты. А на самом деле надо искать просто все, что касается $_POST и $_GET и смотреть уже конкртеный код.

А так же отслеживать все поля из заголовка HTTP запроса, в том числе массив $_COOKIE, поля X_FORWARDED_FOR, HTTP_REFERER и т.д. Так же не забыть убедиться, что register_globals = OFF + не забывать рассматривать варианты, когда код выполняется без использования eval() и/или хорошо замаскирован.

Причём это ещё далеко не все способы, спрятать веб-шелл.

Только потом сразу на свой заразный сайт не заходите.

Dr.Web CureIt! попробуйте: http://www.freedrweb.com/cureit/ .

eval(base64 - лишь один из самых простых методов спрятать шелл в коде жертвы, поиска только его крайне недостаточно.

По теме - посмотрите текст этой статьи в базе, вполне возможно что вредоносный код располагается там.

hi_jack:
А вы предлагаете услуги по переписыванию и исправлению всех этих движков??? :))
Хотел бы я посмотреть как вы справитесь, например, с Битриксом и его 30 МБ кода. И сколько это у вас стоит? :)

Ссылка на тему, с расценками и примером отчёта, в подписи. Вы можете заказать хоть Битрикс, хоть Вордпресс, хоть полностью самописный движок. Так же можете заказать проверку, к примеру какой либо части вашего сайта, а не всего сайта целиком.

Мы не переписываем движки - мы ищем в них уязвимости и даём рекомендации по их исправлению (исправляем сами по желанию клиента). И поверьте, при детальном рассмотрении, такие уязвимости находятся в подавляющем числе и коммерческих и некоммерческих движков.

P.S.

Я думаю мы ушли в сторону от основной темы обсуждения.

hi_jack:
О! Конкуренция! Наконец-то! Да вы правы. В более сложных случаях надо анализировать код, но тут есть одно большое НО! Чаще всего оптимизаторы и прочие пользователи пользуются готовыми скриптами сторонней разработки: WP, DLE, Joomlа и т.п. Поэтому можно оставить анализ кода и его исправление именно разработчикам (просто обновиться до последней версии), а самим исправить только последствия.

К сожалению, практически все эти движки на данный момент уязвимы (в том числе и WordPress), просто их уязвимости являются так называемыми 0-day, т.е. разработчики о них ещё не знают, а на хакерских форумах они описываются только в закрытых разделах. А значит и обновление до более новой версии, без детального анализа всей системы в целом, не поможет.

hi_jack:
Вы отчасти правы. Поэтом перед началом я проверяю на сайте наличие руткитов, потом ТС меняет все пароли, удаляет их из своих клиентов, и только потом я приступаю.

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

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

Каковы дальнейшие дествия хакера - он узнаёт, что с взломанного им сайта пропал нужный ему шелл, он снова при помощи той же уязвимости его заливает туда же, или прячет ещё серёзнее. К примеру шелл можно замаскировать куда сложнее, чем eval(base64_decode(....)).

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

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

Мало того - наличие вируса на сайте, по сути это не непосредственная проблема. Наличие вируса - симптом проблем с безопасностью. И пока эти проблемы не решить, подобные симптомы, в той или иной степени будут появляться и в будущем. Я недаром написал пункт 4 парой постов выше.

Итак, сам вирус у вас содердится в коде каждой странички, после закрывающего тега </HTML>, выгляит примерно так <script>var K1Ixr0u="r bLF5OL"; ... </script> (в вашем index.php занимает примерно 13 килобайт, в одну строку).

Так же посмотрел бегло на ваших соседей по хостингу, у некоторых из них вирус так-же присутствует, кое где он располагается до тега </html>, и выглядит так: <script>var TDwknK="6Td6FTd2ETd6ET"; ... </script>, там примерно 5 килобайт в одну строку.

Тут возможно несколько вариантов:

1) У кого нибудь из пользователей хостинга (возможно и у вас) вирус на локальной машине, который дописывает этот скрипт во все доступные на запись файлы, возможно через FTP + у вас на файлы установлены права на запись всеми

2) Вирус записывается непосредственно с хостинга.

В любом случае вам следует:

1) Проверить свой компьютер на вирусы (хотя раз ваш антивирь этот троян опознаёт, скорее всего вы не заражены)

2) Сменить пароль на FTP и т.д.

3) Из всех файлов на сервере удалить код похожий на то, что я описал выше

4) Сменить права на всех файлах на 755 (не поможет, если вирус работает через вас, но может помочь если через соседей)

5) Желательно проверить скрипты сайтов этого хостинга на уязвимости. (Как я понял хостинг вам не принадлежит и вы являетесь одним из клиентов хостинга)

Пишите в личку. Посмотрим что конкретно можно сделать.

Всего: 61