Цитата |
---|
написал: будут ещё обновления которые недоступны на предыдущих |
Не надо сверлить зубы через задний проход дрелью от Сваровски
07.03.2023 17:14:28
Не надо сверлить зубы через задний проход дрелью от Сваровски
|
|||
|
|
08.03.2023 09:41:26
|
|||
|
|
08.03.2023 09:48:03
хм ... а сайт с такими же симптомами (процесс в памяти, изменение index.php .htaccess) который мне не так и не удалось вылечить тоже с Аспро модулем |
|||
|
|
08.03.2023 14:56:23
|
|||
|
|
08.03.2023 15:14:57
Как вариант, с которым встретились тоже - не было закрытия обработчика php в /upload/ каталоге. загрузили файл и через него понеслась ) |
|||||||
|
|
08.03.2023 16:44:36
|
|||
|
|
08.03.2023 16:51:58
Если бы взломан был какой-то один сайт, то я бы не могла предположить, что проблема в Аспро, но сейчас речь идёт о десятках сайтах, разработкой которых мы занимались. Они расположены на разных серверах (большая часть на одном выделенном, но на отдельных тоже есть), часть сайтов регулярно обновлялась, часть была со старыми версиями Битрикс. На текущий момент, единственная закономерность, которую я обнаружила, это то, что все взломанные сайты были или с модулем аспро, или находились в той же папке, под тем же пользователем, что и другой сайт на Аспро. К слову, у нас есть сайт, на котором мало того, что Битрикс постоянно обновляем, так ещё и Аспро:Максимум обновляем, последнее обновление было установлено около 2-3 недель назад, так вот, на нём с htaccess всё нормально, явных вирусов нет, но как и в предыдущих случаях есть папка /pub/ и странный вариант файла .access.php в корне. |
|||
|
|
08.03.2023 22:14:28
для атаки используются модули vote spread fileman html_editor_action.php
летом была волна, были статьи как закрыться ищите в логах упоминания обращений к этим файлам. |
|
|
|
09.03.2023 00:07:26
Второй сайт на АСПРО, к слову, цел. Сервера под оба сайта одинаковые, самособранные панели на Ubuntu. На сломанном более старая версия php - 7.0, на уцелевшем 7.4 и 8.1. 7.0 вроде же признана небезопасной, может там собака порылась? |
|||
|
|
09.03.2023 04:11:38
На последнем исследуемом пациенте те же симптомы плюс к тому /upload/ не закрыта, но с загрузкой файла сомневаюсь - это ручная работа, что врят ли. Тут скорее всего робот + дыра в безопасности. |
|||
|
|
09.03.2023 08:13:05
Всем привет, функциональность сайты не потеряли после:
по крайней мере пока. так что пока то что мы делали: 1. бекапили бд 2. бекапили upload 3. чистили от мусора и вирусов upload, скаченный 4. восстанавливали VDS из резервной копии до аттак 5. накатывали данные. пока что всё ок. ЗЫ: мелочей по потерям данных - не наблюдалось. полет пока нормальный. |
|||
|
|
09.03.2023 10:33:15
Хотелось бы задать такой вопрос, что за файл site_checker_ded80a36890bbff236cfe4f4 и нужен ли он на сайте?
|
|
|
|
09.03.2023 11:28:10
|
|||
|
|
09.03.2023 13:28:00
Обнаружил эту проблему на сайте со старой версией битрикса. Предположительная точка входа: /bitrix/tools/html_editor_action.php
Бэкдоры были оставлены: 1. /bitrix/tools/spread.php, там вредоносный код:
Этот файл можно удалить, он не используется системой. 2. bitrix/modules/main/bx_root.php
Этот файл нужен, надо удалить вредоносный код. Плюс множественные бэкдоры вида 3036c2400ce7.php После обновления советую проверить сайт модулем bitrix.xscan: |
|||||
|
|
09.03.2023 14:20:19
По своему опыту:
Если .htaccess и index.php после изменения сразу восстанавливаются, то сервер ребутить необязательно, нужно найти процесс(ы) хакера и убить их:
|
|||||||||||
|
|
09.03.2023 14:55:42
Ребята, а подскажите пожалуйста. Ситуация аналогичная с темой тут. Клиент подхватил вирус. Я сайт себе не выкачивал. Подключался через WinSCP к серверу, смотрел файлы. Потом (7 марта) я заходил на сервер к совершенно другому клиенту, выполнял работы на его сайте (Правил файлы стилей шаблона и искал файлы которые занимают много места (Так-же подключался к консоли через эту же программу при помощи PuTTY, Использовал команды df, du, ncdu)). Сегодня захожу на сайт и вижу, что он подхватил такой же вирус. Самый ранний файл, который я нашел это в корне сайта /ec6f306ecab6.php созданный через час/полтора после выполнения мною работ на сайте.
Мог ли я как-то подцепить этот вирус с первого сайта и заразить им второй. Проверил еще 1 сайт, с которым уже было установлено соединение, там вирус не обнаружен. Другие сайты я не открывал, т.к. опасаюсь что могу еще что-то заразить. Сейчас сканирую свой ПК на вирусы Касперским, пока ничего не обнаружено Дополню, что возможно в момент работы с файлами на сервере, где находится сайт №2 я подключался серверу с сайтом №1, на котором был вирус. Точно не помню был ли факт подключения но все же решил это упомянуть И еще дополню: На хостинге на втором сайте были переопределены параметры PHP, нужны были для прохождения "проверки системы":
|
|||
|
|
09.03.2023 15:27:20
Друзья! Столкнулись с той же самой проблемой взлома. Можете посоветовать технических специалистов, которые занимаются лечением? Буду невероятно признательна.
|
|
|
|
09.03.2023 16:10:57
Приношу почтение, за сим и прощаюсь.
*** Ubi nill velis, ibi null vales... |
|||
|
|
09.03.2023 16:33:46
+7 (916) 122-28-43 (WhatsApp, Telegram) |
|||
|
|
09.03.2023 16:41:21
нет, не мог |
|||
|
|
09.03.2023 17:39:49
Если вас ломали ранее и вы не сменили ключ подписи данных "signer_default_key" в базе данных, то независимо от того какое у вас ядро, старое или самое последнее, вычищали систему или накатили с нуля, вас могут ломать используя его. Так как система безопасности движка полагается на этот ключ при работе в "тонких местах" и не предполагает наличия этого ключа у взломщика.
В PDF документе "Уязвимости и атаки на CMS Bitrix", есть раздел "Методы атак", а в частности "RCE via PHP Object Injection ( signer_default_key )" где подробно описывается один из возможных вариантов использования этого ключа. Сколько других вариантов ещё существует и используется, предположить невозможно. По логам это отследить будет трудно, так как запросы могут приходить на любой эндпоинт, или через $_COOKIE. Именно поэтому, "signer_default_key" нужно менять в обязательном порядке. |
|
|
|
09.03.2023 17:41:27
|
||||
|
|
|||