0.00
74 читателя, 45 топиков

Журнал событий переполнен предупреждением

Trying to get property of non-object
« MODX Parse Error »
Error: Unknown: The session id is too long or contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,'
И даже знаю из-за чего: сканируют на уязвимость.
Информация из инета:
It is an information vulnerability, a malicious attacker may alter the cookies and assigns illegal characters to PHPSESSID to expose this PHP
Читать дальше →

Как я сотрудничал с Fi1osof (Николай Ланец)

Особо писать и не о чем) Работа как работа. А вот закончилось не очень.
После того как перестал с ним сотрудничать остался он мне должен около 1000$
Некоторое время отправлял мне по несколько тысяч рублей в месяц после напоминаний. Потом все реже. Потом завтраки) И вот спустя три года мне надоело ждать)))
В конце мая договорились что до 10 июня рассчитается полностью. Но видно опять не
Читать дальше →

MODX.Evolution.updateNotify

Добрый день, не появляется кнопка обновления сайта после установки плагина MODX.Evolution.updateNotify.
OS: Linux 3.10.0
Apache: 2.2.29
Ошибок нет никаких. Как исправить?

Управление менеджерами

Есть задача: «закрыть» определенного менеджера в собственном каталоге.
Чтобы для него были собственные assets/files, assets/images, assets/media.
Настройки пользователя якобы позволяют установить «путь для файл-менеджера» и «путь к файлам». Но здесь начинаются проблемы:
1. Поля не понимают [(base_path)] (хотя в глобальной конфигурации это работает).
2. «Путь к файлам» никак не влияет на вызов KCFinder, который по-прежнему работает с глобальными настройками.

Как обойти/пофиксить проблему и решить первоначальную задачу?

MODx Evo 1.2.1

Вторая волна вируса(повтор того что было в 12.2016). Подвержены все версии EVO до 1.2.1

Симптомы:
— Все странички отдают код главной.

Как лечить:
— 1 заходим в базу данных и удаляем там фейковый плагин с непонятным кодом, обычно это дубль одного из других плагинов. в админке дубль плагина не видно!!!
— 2 Удаляем .htaccess (все равно он заражен иначе б симптома не было)
— 3 ставим заплатку: extras.evolution-cms.com/packages/core/security-fix.html
— 4 Обновляем систему до последней версии, рекомендую вот эту:
modx.com.ua/download/
— 5 проверяем на вирусы с помощью Ai-bolit
— 6 если сайт старый то рекомендую проверить актуальность версий следующих сниппетов: Ditto, eForm, AjaxSearch, evoGallery так как больше всего взломов было через них.

Если хорошо присмотреться вот тут(на главной в админке) то увидим следующее:


Что говорит о том что нужно следить за критическими обновлениями в безопастности и вовремя закрывать дыры, и если в первый раз все было ок это не повод оставлять дыру на будущее

p.s. не забываем про наш канал и чат в телеграм:
t.me/evolutioncmsnews
t.me/evolutioncms

Ребята, это нормально или нет?

Всех приветствую, решил значит я поиграться с API MODx.

Значит задача такая, нужно было вывести у документа Tvs.

Было применено вот такое решение



$parent // Это текущий документ

$title = $parent->getMany('TemplateVarResources');

echo "<pre>";
print_r ($title);



В итоге, получил ВСЕ СОДЕРЖИМОЕ базы… Это нормально или нет? О_o

Что за заражение? Новый способ?

Всем привет.
Недавно почистил сайт от вирусов. Все файлы проверил и базы. Все чисто. Обновился и вперед.
Пользуюсь только Chrome. И вот открываю IE. Вдруг после клика в любое место сайта открывается другой сайт. Опять все проверил на хостинге — все чисто. В Chrome тоже не наблюдается. в IE опять та же хрень.
Открыл сайт в консоли IE F12: После тега body добавляется такая хрень.
<iframe src="http://b.okboost.ru/f0.22701418819717634" style="left: -1000px; position: absolute;"></iframe>


В отладчике загружены ресурсы с таких сайтов bytde.com, cs.qgdzy.top, cashsearch.ru. Куча каких-то js и ajax
Проверил с других компьютеров. Вроде ничего нет. Не кидайте помидоры только. Решил на всякий случай потестировать настройки сайта. Путем теста нашел код, который вызывает работу этой схемы в футере.

Вариант с гавном по клику
<script>
  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','//www.google-analytics.com/analytics.js','ga');

  ga('create', 'UA-***********', 'auto');
  ga('send', 'pageview');

</script>


Правильный вариант
<script>
  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');

  ga('create', 'UA-***********', 'auto');
  ga('send', 'pageview');

</script>

Разница только в https: но почему это наблюдается только на одном моем сайте. Помогите разрешить эти проблему.

Плагин защиты от POST взлома

Увидел тут на форуме, что бывает засыпают POST-запросами.
А что если создать плагин, который бы добавлял к каждой форме скрытое поле и при получении modx'ом, проверял его валидность? Если поле не верное, либо прилетело откуда-то :), то die()?
Набросал, проверил, работает, код плагина под катом.

Ниже плагин TokenPostProtect, события OnWebPagePrerender (пусть будет в конце выполнения плагинов).
Это лишь как пример. Для AJAX надо самому добавлять, можно например придумать что-то вроде замены например #PROTECT# на ?$ProtectFieldName=bin2hex…
bin2hex и hex2bin можно заменить на свои функции… в общем я думаю я идею выразил.
Кто что думает?

if(!defined('MODX_BASE_PATH')){die('What are you doing? Get out of here!');}
$useridP=$modx->getLoginUserID();
$ProtectFieldName='tokenprotect';
$protect["REMOTE_PORT"]=$_SERVER["REMOTE_PORT"];
$protect["ip"]=$_SESSION['ip'];
$keyP="k".$useridP.$_SESSION['ip'];
$e = &$modx->Event;

switch ($e->name) {
case "OnWebPagePrerender":
$Pv=bin2hex(serialize($protect));
$o = &$modx->documentOutput; // get a reference of the output
$o = str_replace("</form>","<input id='$ProtectFieldName' name='$ProtectFieldName' type='hidden' value='$Pv'></form>",$o);	
$modx->documentOutput=$o;
break;
case "OnWebPageInit":
if (count($_POST)>0){
if ($_POST[$ProtectFieldName]!=""){
$Pr=unserialize(hex2bin($_POST[$ProtectFieldName]));
//Если массивы равны
if ($Pr===$protect){
return;	 
}	 
}
// echo "What are you doing ".$_SESSION['ip']."? Get out of here!";
header('HTTP/1.1 500 Internal Server Error');
}
default:
return;
break;
}

Осенне-зимнее обострение по взлому сайтов



Добрый вечер.

В осенне-зимний период участились взломы сайтов и рассылка с них какого-либо спама. Так у меня самыми распространенными видами активности являются:
  • Создание субдиректорий с огромной кучей статических html страниц. В этом случае трафик обычно заграничный идет на страницы. Последний раз просмотры таких страниц шли из Малайзии.
  • Скрытая рассылка спам-сообщение. Из-за чего хостинг блокирует функцию отправки писем и, соответственно, с сайта не уходят заказы, сообщения обратной связи и т.д.

Пробовал поначалу вычищать файлы вручную. Но если вдруг пропускал какой-либо один вредоносный файл, то сайт снова заполнялся этим гуано.

В последнее время целиком перезаливаю MODX и переношу дамп базы данных и шаблоны, картинки и т.д.

Как вы боретесь с данной напастью? Какие методы защиты применяете? В каком месте обычно пролезает эта гадость? Вообщем поделитесь опытом что и как.


UPDATE_1

Спасибо Дмитрию и его evocheck. Обнаружил в базе данных скрытый плагин TransAlias замаскированный на одноименный плагин. В поле plugincode в базе данных был встроен вредоносный код.

Вот как это выглядит

Взломан сайт на MODX Evo 1.1

Сегодня было обнаружено заражение сайта на базе MODX Evo 1.1
Используя /index-ajax.php, был загружен шел в /assets/files,
затем еще несколько бэкдоров по разным каталогам и в файл /index.php
Файл .htaccess также был переписан.
Последствия были устранены и проведены мероприятия для предотвращения подобной ситуации:
— большинство каталогов стали read-only
— каталоги с возможностью записи приобрели deny access to \.php$
— активирован mod_security с установка запрета file php upload
Это все конечно здорово и в случившемся себя нисколько не оправдываю, но!
До сих пор было известно об уязвимости /index-ajax.php версий MODX Evo 1.0.*
Я что-то пропустил? Или об уязвимости Evo 1.1 (index-ajax.php) еще не известно?
Как то меня это напрягает.
Стараюсь security fixes не пропускать, а тут такая ситуёвина…