Заражение сайтов

Удалил его к чертям, как и ajax/form
Беглый тест ошибок пока не выявил

Доброй ночи!
По поводу нового алгоритма взлома - если я правильно понял логику, то с помощью файла /ajax/error_log_logic.php создаётся лог-файл /ajax/js_error.txt, но внутри его содержимое - это вредоносный PHP.
А потом в файлах /ajax/form.php и /form/index.php с помощью GET-параметра "url" этот js_error.txt просто инклудится (и исполняется соответственно, раз уж внутри PHP).

У себя закрыл так:
1. В error_log_logic.php закомментировал AddMessage2Log (он нужен для какой-то отладки, на рабочем сайте не нужен).
2. В /ajax/form.php закомментировал следующую строчку (это сломает кастомные формы с $form_id = 'TABLES_SIZE', но я у себя только одну такую нашёл "Нашли дешевле", которая не используется). При желании можно не комментировать include, а сделать строгую проверку этого $url_sizes перед ним.3. В /form/index.php закомментировал такую же строчку соответственно.Посмотрим, что будет...

Так а за что вообще эти 2 файла отвечают, кто-то знает? Я оба эти файла киданул в архив и удалил с папок, функционал сайта вроде никак не поменялся.

/ajax/error_log_logic - а этого файла у меня вообще никогда и не было, скорее всего это и спасло от вчерашней утренней атаки

Я использовал этот патч, предварительно локально проверив его работу. У меня он ничего не поломал, применил на 3х сайтах, все ок.

Кто-то еще применял патч? После него были заражения?
Этот патч находит все файлы с уязвимым кодом и меняет его на

$arParams = unserialize(urldecode($_REQUEST["PARAMS"]), ['allowed_classes' => false]);

Может еще что-то добавляет в аспрошных классах, там не смотрел.

-

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

вышла новая версия патча:
дополнительно удаляет (в т.ч. из служебных папок):'/ajax/error_log_logic.php',
'/ajax/js_error.php',
'/ajax/js_error.txt'

и "лечит" /form/index.php и /ajax/form.php
способом 'TABLES_SIZE' && false

посмотрел, что исправляет новый патч от Аспро, получается, что дыру в /ajax/form.php они уже давно закрыли,
в моем случае они за дыру не считают и && false не добавляют,
у них в скрипте идет доп. проверка на присутствие в файле кода:и если код присутствует, то они считают, что /ajax/form.php не дырявый и исправлять его не надо.
Но когда-то давно дыра в файле судя по всему была, раз ее исправляют.

Итого по последним уязвимостям, как понять была дыра и могли сломать (если могли сломать, то скорее-всего сломали):
1. если есть файл /form/index.php — то дыра есть практически наверняка
2. если в файле /ajax/form.php нет кода file_exists($url_sizes) и есть код $form_id === 'TABLES_SIZE' — то дыра есть практически наверняка

И по файлу /ajax/js_error.txt — его присутствие означает, что была попытка взлома, но скорее-всего она была неудачная, т.к. при наличии дыры данный файл должен был бы удаляться после загрузки на сервер вредоносного файла.
Сам файл js_error.txt — это лог ошибок и не является взломом сайта, а только успешная и опасная подготовка к дальнейшему взлому, если на сайте не закрыта дыра.

В любом случае при наличии этого файла:
1) удаляем файл /ajax/error_log_logic.php — именно через него создавался js_error.txt и по мнению Аспро он больше не нужен и его можно удалить
2) удаляем файл /ajax/js_error.txt
3) проверяем наличие дыры (см. выше), если дыры нет — скорее-всего сайт не взломали
4) обязательно смотрим лог!!!

)
мы обработчик написали на OnPageStart
и если запрос к "неправильным" страницам (/form/index.php, /ajax/error_log_logic.php, /js_error.txt и т.п.)
или запрос к любой странице содержащей в адресе *ajax* с параметрами file_get_contents, file_put_contents, base64_decode,
то сразу стоп и IP-адрес в стоп-лист на долгое время.

За два дня две попытки было искать дыру — сразу в бан ушли.

Заодно туда прописали запрет на страницы /wp-admin/ и т.п.
Только сегодня уже более двадцати раз блокировка срабатала на искателей дыр от WordPress.

В своих логах видел, что запрос к этой странице поступает и от обычных юзеров иногда.

здесь затрудняюсь сказать,
сам исходил из последней версии патча от Аспро, у них на удаления стоят следующие файлы из всех директорий (и рабочих и установочных):

раз Аспро их удаляет, значит не особо и нужны они.

если удалять не хочется, то тогда закооментировать строку с AddMessage2Log — это обязательно

да, думал об этом,
но решил перестраховаться и банить с избытком, в т.ч. при  обращении к '/ajax/show_basket_fly.php' и '/ajax/reload_basket_fly.php' (мы их в проектах не используем),
а далее уже разбираться и смотреть логи, кого и почему забанили... и, если что, то вносить правки в логику.

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