Лечение всех js-файлов на сервере или определение метода шифрования в выходной день

[Afinogen]

В таких случаях еще неплохо git помогает, сразу видно измененные файлы, если конечно клиент его использует)

[bustEXZ]

А в чем проблема поставить на сервере права на файлы только чтение? Ведь ничто тогда не сможет их редактировать + использовать версионирование

[i86com]

Зависит от клиента. Если клиент — технически подкованный и может сам потом его снять — отлично. Если нет, то он может очень резко отреагировать на фразу:
«Я тут у вас поработал, все файлы закрыл от изменений. Теперь чтобы что-нибудь поменять, вам нужно будет сначала связаться со мной, чтобы я поставил права.»

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

[andkln]

php chmod( ) может временно установить нужные права на запись. И это только верхушка айсберга, делающего подобные методы предосторожности малоэффективными.

[Fedcomp]

/sarcasm да вы что, а как же вордпресс через админку то обновлять?

[3al]

Бэкапы — это для данных, а код, независимо от бэкапов, должен быть в системе контроля версий, а всякие регэкспы — не дают никакой гарантии: вредоносный код может быть в разных вариациях, причём не обязательно во всех файлах.

[Decker]

Самое неприятное в этой ситуации — это то что не удалось определить источник появления вредоносного кода на сервере. В моей практике было две похожих поучительных ситуации. В одной модификация файлов произошла из-за критической уязвимости в CMS, в другой — пароль от FTP хостинга оказался скомпрометирован. Во-втором случае все было проще, пароль от FTP был сохранен в FTP-клиенте на ПК одного из контент-менеджеров на домашней машине. После того как он подцепил вирус, все пароли ушли злоумышленникам. Далее, через какой-то промежуток времени бот зашел на этот FTP и дописал свой код в каждый десятый PHP файл на сервере. В результате, те же самые редиректы, только чуть по-другому, плюс три разных backdoor'а (варианты php shell'а) оставленных для доступа в любое время. Резервной копии у людей, естественно не было, поэтому в обоих случаях все решилось развертыванием «чистого» ядра CMS, плюс полуавтоматическим анализом всех остальных *.php не входящих в состав ядра с удалением вредоносного кода. Плюс полной сменой паролей ко всему — FTP, MySQL, SSH, CMS и т.п. Периодически наблюдаем в логах попытки бота достучаться на FTP и HTTP-запросы к уже очищенным зараженным файлам. Мораль очень проста — достаточно было пропустить хоть одну «лазейку», чтобы все повторилось по новой.

[Deosis]

Так как код вируса постоянно меняется (полиморфный), то возможно скоро появится вариант с «length/(1+2)» и ваш скрипт не сработает.
При этом если в обычном коде используется длина строки, то что мешает вирусу заменить часть кода на "(length/3)*3" и ваш скрипт вместо вируса выпилит клиентский код?

[moxy]

В вашем первом предложении содержится хорошая подсказка для тех, кто создает такое. Однако, я решал конкретную задачу по устранению зловреда, особенностью которого было ".length/3". Конечно могло оказаться так, что в файле этот кусок кода может использоваться в чистом коде, но я не нашел ни одного файла, который содержал бы эту особенность больше одного раза.

[moxy]

Моей целью было излечение файлов, а не написание универсального антивиря, и т.к. я смог этого достигнуть, то я даже не задавался целью создать полиморфные версии этого зверя и лечить его по новой.
Но ваши замечания полезные!