| Цитата |
|---|
| написал: Да, js_error.txt отсутствовал. |
посмотрите лог, там в конце длинных строк идет удаление этого файла:
| Код |
|---|
DY1Il0pO319Pz4K%22));unlink($_SERVER[%22DOCUMENT_ROOT%22].%22/ajax/js_error.txt%22); |
|
Разработчикам |
Заражение сайтов
Заражение сайтов
В логах видел попытки обращения к ним со статусом 404. Похоже появился третий способ записи в js_error.txt - через Referer )) Сейчас буду экспериментировать сам с этими запросами |
|||
|
|
|
Если патчер спрашивает "запускать в режиме просмотра", то скорее-всего у Вас ранняя версия патчера, он проверяет только дыру с unserialize. В последней версии патчера такой галочки нет. Отдельно кнопки: - Сканировать - Удалить скрипт - Исправить выбранные |
|||
|
|
|
а в файлах /ajax/form.php или /form/index.php дыра закрыта у Вас была? вместо: elseif($form_id === 'TABLES_SIZE'): так: elseif($form_id === 'TABLES_SIZE' && false): |
|||
|
|
|
|
в /form/index.php да, исправлено.
В /ajax/form.php строка чуть другая:
попробовал, сайт не сломался, буду мониторить... |
|||
|
|
|
но у Аспро в патчере так:
но мы тупо сразу отключили данный вариант через добавление "&& false", если правильно понял — это возможность использования собственных кастомных форм, код которых хранится в отдельных инклюд-файлах.скорее-всего это мало кто использовал, мы точно нет. сама дыра была в том, что через эти формы "TABLES_SIZE" можно было загружать инклюду из файла в любой дерриктории, в т.ч. текущей, чем и пользовались негодяи — подгружая js_error.txt из текущей директории,или, возможно как пишете Вы, с удаленного сервера (???). после закрытия дыры, инклюду можно загружать только при условии, что она обязательно лежит строго на сервере и в папке /include/ |
|||||||
|
|
|
|
Посмотрел код /ajax/form.php до патча - там была строка
UPD: вижу в логах две попытки атаки - ~в 18:00 и 21:00, но файлы создать не удалось негодяям. Хороший признак) На всякий набросал в cron скрипт - каждые 15 мин. мониторю создание .php файлов в папке сайта, если вдруг что подозрительное появится, в телегу алерт придёт. |
|||
|
|
|
|
нда, в cron задачах появилось:
 Что за напасть такая... |
|||
|
|
|
|
Проверьте файл siteheads.php очень много
Сейчас вроде пока тишина. 1. Почистил index.php и bitrix/footer.php там был код. 2. Удалил все .htaccess (25 штук). Создал базовый набор средствамии битрикс. 3. Сканером проверил все файлы, удалил кучу файлов вида sdfsf654654.php 4. Прогнал файлом fixit.php скачал последнюю версию. ( у меня Аспро Максимум) было 30 ошибок - исправил скрипт, ошибок в работе сайта нет. 5. удалил все siteheads.php - более 20 6. В бан загнал: 45.142.122.46 7. Проверил все агенты - пусто, подозрений нет. 8. Заодно снес все php.ini в каталогах - более 10 штук. |
|
|
|
|
|
И да, сканером битрикс проверил куча файлов с типом опасности no_prolog/ Все что были, в карантин поставил. Вроде пока норм
|
|
|
|
|
|
|||
|
|
|
|
|||
|
|
|
|
В моём случае всё оказалось банально. Сразу же нашел, откуда ноги растут, отписаться забыл.
Во время первого заражения помимо основного сайта увидел, что есть еще два - old.* и test.*, внутри так же оба оказались заражены. Спросил у заказчика, говорит не нужны - снёс. Кроме них был еще один сайт - заглушка техдомена (что-то вроде vm31337.hostername.com), в ней было пусто, кроме голого html файла, мол "это такой-то сервер")) Ну и забил на него... Во время повторного заражения злоумышленники уже и туда напихали!!) А я, помня по старой памяти, что там пусто, даже логи не грепал по этому техдомену! Смотрел содержимое и логи только одного оставшегося основного сайта... Снёс его, сейчас всё благополучно (хотя в логах попытки по прежнему фиксирую). Меня только смущает один момент, прошу помощи. Я сам с битриксом постольку-поскольку, прочитал в этой теме про агенты, что есть такие. Решил глянуть, нет ли у меня в них ничего такого. И обнаружил, что агенты не выполняются с момента первого взлома (хотя активность у всех выставлена "Да"). Подскажите, что могло поломаться и как проверить агенты на легитимность (вдруг туда что-то тоже засунули, мало ли после включения какой backconnect запустится)? |
|
|
|
|
Вот эта запись должна каждую минуту проверять агенты. |
|||||
|
|
|
|
Да, по любому! как раз только что подумал, что мне же в первый раз cron задачи переписали... Всё грохнули и злые добавили
Остается открытым вопрос, как грамотно провести аудит запускаемых агентов? Есть может какой-то перечень легитимных, чтобы свериться? UPD: скачал дамп БД до взлома, сейчас сравню таблицы b_agent |
|
|
|
|
|
|||||
|
|
|
|
Александр Будников, я в 10:34:49 описал где в моем случае была проблема.
Во время второго заражения закинули скрипты в папку техдомена (во время первого заражения проверял - в ней было пусто, ну и благополучно вычеркнул её из всевозможных проверок, в т.ч. чтения логов по техдомену)  |
|
|
|
|
|
|||
|
|
|
|
После удаления всех вирусов обязатьельно меняйте пароли у админских пользователей.
Вирус заменяет пароль на свой у давно не заходивших пользователей-админов и дальше возвращается, логинится и заливает файлы с сессией админа. Еще проверьте директорию /bitrix/fonts/ на предмет сторонних скриптов  |
|
|
|
|
ngx_limit_req_zones = [^"]+ #badstrings = file_put_contents|file_get_contents|base64_decode|js_error.txt failregex = ^<HOST> -.-.*(GET|POST|HEAD).*(file_put_contents|file_get_contents|base64_decode|js_error.txt).* ignoreregex = datepattern = {^LN-BEG} Ваше правило не сработало, только в таком виде все заработало.. |
|||
|
|
|
|
[Definition]
ngx_limit_req_zones = [^"]+ #badstrings = file_put_contents|file_get_contents|base64_decode|js_error.txt failregex = ^<HOST> -.-.*(GET|POST|HEAD).*(file_put_contents|file_get_contents|base64_decode|js_error.txt).* ignoreregex = datepattern = {^LN-BEG} сработало только так |
|
|
|
|
|
Коллеги, проверяйте свои сайты. У нас опять массовые заражения сайтов на АСПРО, первая ласточка была вчера ещё, сегодня ночью уже десятки сайтов. Фиксы все были сделаны.
|
|
|
|
|
|
|||
|
|
|
|
эх, аспро
|
|
|
|
|
|
сегодня заметили новое поведение, возможно это началось и ранее:
из старых дыр попытки атак идут только по двум файлам (остальные из логов пропали): /ajax/error_log_logic.php /ajax/js_error.php плюс появились попытки атак через новые файлы: /bitrix/admin/esol_allimportexport_cron_settings.php /bitrix/admin/esol_import_excel_cron_settings.php /bitrix/admin/esol_export_excel_cron_settings.php /bitrix/admin/kda_import_excel_cron_settings.php /bitrix/admin/kda_export_excel_cron_settings.php и /api/parser/index.php — ??? В основном это файлы от этих разработчиков: и , так что:
чей файл /api/parser/index.php не очень понимаю, если кто знает, напишите. у нас таких файлов нет, плюс доступ к административной части закрыт по IP, но обращения к данным файлам добавили в обработчик, чтобы сразу в стоп-лист банить IP, которые ими интересуются. |
||||
|
|
|
|||
