Критическая уязвимость в MODX Revolution
Сильно в детали лезть не буду, просто скажу, что сейчас любой MODX Revo сайт потенциально уязвим. Дыра позволяет выполнить SQL-инъекции, в том числе с созданием на сайте привилегированных пользователей.
Базовые методы противодействия: подмена дефолтных системных папок (особенно connectors) и, главное — смена префикса таблиц. Так как далеко не все это делают, то можно сказать, большинство сайтов в зоне опасности. Кто хочет ощутить это на себе, может в комментах написать ссылку на сайт.
Если кто на уже рабочем сайте хочет префиксы сменить, я описывал метод здесь.
P.S. И еще заповедь: не пускайте никого в админку, даже с самыми минимальными правами. Это практически 100% гарантия взлома при желании.
Базовые методы противодействия: подмена дефолтных системных папок (особенно connectors) и, главное — смена префикса таблиц. Так как далеко не все это делают, то можно сказать, большинство сайтов в зоне опасности. Кто хочет ощутить это на себе, может в комментах написать ссылку на сайт.
Если кто на уже рабочем сайте хочет префиксы сменить, я описывал метод здесь.
P.S. И еще заповедь: не пускайте никого в админку, даже с самыми минимальными правами. Это практически 100% гарантия взлома при желании.
Комментарии: 340
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
Это запрещает любые запросы в manager, core и connectors без дополнительного логина и пароля, которые проверяет не MODX на PHP, а сам Nginx.
Запрет по IP, конечно, еще лучше.
Fi1osofFi1osofВ общем, проблему я обозначил, а тебе уже решать исправлять ее или нет.
Потому что менять префиксы на всех MODX сайтах мне совершенно не улыбается.
По логам вижу, что ты долго долбился на коннектор от Office, видимо опять что-то с переключением контекстов. Если так — то мне как минимум нужно исправить свои компоненты, которые много где уже установлены.
Fi1osofВпервые серьёзно жалею, что работаю с MODX.
Fi1osofFi1osofПечально.
У меня хоть на важном для меня сайте префиксы изменены, но их длина и сложность не ахти.
Т.е. бежать кругом дистрибутив advanced заливать и менять все и вся…
Fi1osofPS Скрипт смены префиксов видел на modxclub еще утром.
Fi1osofFi1osofРанее расширенные настройки воспринимал как такую возможность, но она не требовалась так срочно, а сейчас оказалось что расширенные настройки при обновлении ни чего не позволяют толком поменять. Печаль (.
Fi1osofВидимо задумывалось как возможность, но не доделано.
Fi1osofРешение. Сделать сниппет с кодом Николая (я где-то год назад давал пример файла с таким же кодом) и перед обновлением вызывать его, чтобы переименовать таблицы с префиксом modx_, а после обновления возвращать опять свой уникальный.
Как мечта — сделать на modhost.pro, чтобы префикс при обновлении или автоматически подцеплялся из файла настроек или запрашивать его у пользователя.
В MODX параметры запроса фильтруются. Может ужесточить правила и вырезать нахрен слова «insert», «update» и «delete» из запроса?
Fi1osofА вырезать из параметров запроса команды sql поможет решить проблему безопасности?
Fi1osofПоможет. Но как отличить опасный запрос от не опасного? К примеру, здесь кто-то захочет найти статьи по запросу «xPDO update», и что ему выдавать? А что делать с запросами uupdatepupdatedupdateaupdatetupdatee? Рекурсивную чистку писать? Короче, это все заморочки лишние.
Но как решение для базовой версии можно сделать такую настройку. Например, сейчас есть такая настройка «Разрешить передачу HTML тегов в POST запросах». А сделать еще типа такой — «Вырезать команды SQL». Если у пользователя простой сайт, то по крайней мере, он будет в безопасности. Поставил MODX и спит спокойно.
А если сайт использует запросы, то граммотный программист должен отключить эту настройку и переименовать таблицы. Как вариант.
Fi1osofFi1osofВообще непонятно, как дальше жить. Думаем закрываться теперь.
Евгения Борисова, помню, в итоге вообще обматерили.
Уверен на 100%, что данной дырой серьёзные пацаны уже давно пользовались.
Интересно, а в том же WP эта дырка закрыта?
Пришлось доказывать на их же сайте.
И, насколько я помню, Евгений еще далеко не всё показал. Не удивлюсь, если и про сегодняшний баг он давно в курсе, просто стимула рассказывать авторам MODX больше нет.
А вот чуть позже Николай залез без админки, и сразу на рабочий проект и написал UPD2 у себя в заметке.
И еще кстати — в текущей заметке этого UPD2 до сих пор нет. Как считаешь, большая ли разница, когда для эксплуатации уязвимости нужен доступ в админку, а когда нет?
Но а так да, всё один в один, прям идентичные ситуации.
Про доступ в админку тут не слова. Лично мне было интересно проверить, но я не рискнул. Страшновато.
Но Николая это не остановило.
Fi1osofХоть бы сообщество ломал, а не магазин, который приносит доход и тебе, в том числе.
Fi1osofОдно дело у меня на сайте пошалить, а другое дело обратить внимание человека, на котором лежит большая ответственность — у многих из нас сайты размещаются на modhost.pro, который работает на MODX, и это вызывает обоснованное беспокойство.
Еще раз: на момент публикации моего комментария не было известно, что для эксплуатации уязвимости не нужен вход в админку.
Достаточно было дописать в заметке, что уязвимость можно эксплуатировать хоть откуда, и всё. Я не просил её доказывать, я не отмахивался от неё. Мы её и по почте обсудили с Николаем — и там он тоже не сказал, что доступ в админку уже не нужен.
Наверное, это недоработка Николая, что он недостаточно рассказал о серьёзности проблемы.
И что, блин? Это вообще теперь не имеет никакого смысла, если любой сайт можно сломать хоть откуда, если у него стандартный префикс таблиц.
Более того, префикс таблиц теперь приравнивается к паролю супер-админа, его нужно хранить за семью печатями! Вот что нужно было написать, а не как сейчас.
Но если ты считаешь, что я отмахнулся от проблемы и повёл себя как мудак — твоё право. У меня нет желания это обсасывать второй день подряд.
С моей стороны вопрос решен, дальше дело за ребятами из MODX.
Fi1osofPS прочел коммент Николя ниже… о получении префикса из системных настроек. Вопрос снят…
Fi1osofНадеюсь, что результат выполнения запроса увидеть никак нельзя, но я уже ни в чём не уверен.
Можно к файлам в connectors перекрыть доступ, но это только, если статический IP у манагеров, админов.
Теперь эта же уязвимость но в другом месте. И опять, все идет по какому-то странному пути — закрывают отображение префикса из конфигов, которые доступны только из админки.
Коли так, то вообще всю админу нужно удалять. Не понимаю, зачем делать проверку на расширения доступные к загрузке, если пользователь может переименовать файл!!! Заливаем .jpg и меняем на .php => PROFIT!
В общем бред, бред и еще раз бред.
Fi1osofFi1osofFi1osofЕсли ты вдруг читал исходную статью, то там я писал устанавливать сложные префиксы. Даже немного математики было:
Ты сейчас вообще php-код приводишь. То есть предполагается, что твой скрипт будет работать на стороне целевого сервера уже? Если у тебя там php твой работает, то какой смысл? Уже все сломано. А если ты им просто фигачишь запросы на целевой сервер, то с учетом задержек даже идеальных 10 мсек с учетом вычислений выше как быстро ты получишь результат?
Fi1osofFi1osofИ здесь опять-таки, спасают кастомные префиксы таблиц.
Fi1osofFi1osofПонятно дело, что он многое сам домыслил и доделал, но сама бага мне была понятна и очевидна, и я про нее говорил Райну тоже, но он действительно отмахнулся, а я не стал развивать тему и ломать им сайт. Так вот, багу не совсем закрыли, точнее, сама архитектура MODX-а такова, что все эти уязвимости во многом являются не багами, а фичами. Это такой механизм безопасности. И уязвимости можно задействовать даже с передачей существующего контекста, если политики не правильно настроены (ведь даже аноним по сути автоматом авторизован в контексте web, а это значит уже НЕ НЕ авторизован). Кстати, что интересно, воспользоваться этим механизмом позволяет как раз JS-компонент MODx, который не сложно подключить даже на фронт сайта просто через редактирование HTML-а, а если можно попасть на входную страницу админки, так вообще проблем нет никаких.
По сути, если ты хочешь дать кому-то права на выборки документов и прочих элементов, давать их надо не на контексты, а на конкретные элементы. Но тут проблема в неудобстве сразу встает — если ты хоть кому-то дал права на какие-то группы элементов, значит все остальные сразу лесом пойдут, то есть придется всем остальным так же права прописывать.
Есть у меня одна хорошая, но довольно сложная статья, которая несколько проливает свет на все это.
А так можно, к примеру, получить список всех сниппетов и плагинов на сайте. Да, модифицировать их не получится, но если проанализировать их кода хорошенько, можно попробовать найти какие-нибудь логические ошибки, особенно там, где используются механизмы формирования ключей для автоматической авторизации пользователей, проведения платежей и т.п.
В общем, точек входа довольно много, можно несколько отдельных статей написать про них, поэтому я не стал много воды лить, я просто привел максимально эффективное на мой взгляд решение. Практически все эти проблемы решаются сменой префиксов таблиц и сокрытием папки коннекторов.
Fi1osofFi1osofА еще есть возможность создания произвольных файлов на сервере.
P.S. Да простит меня неуловимый ДЖО и его разработчики:-)))))
Вообще, грусть-тоска. Я наивно полагал, что работа через xPDO меня как-то защищает. Очевидно, это всё в прошлом и нужно пересматривать все свои дополнения.
Спасибо за PR в pdoTools!
Fi1osofКстати, если поиграться с запросом, можно даже такое получить: SQL injection attempt detected.
Есть или была? Я проверял все процессоры на работу с файлами, они защищены. Но может что-то проморгал.
Это фишка хостера
Fi1osofЭто фишка xPDO.
Тогда расходимся. Безопасность на высоте.
Fi1osofFi1osofFi1osofFi1osofFi1osofС шаблонными интернет-магазинами я не работаю, поэтому тут посоветовать ничего не могу. Ну а вообще Laravel — для всех остальных проектов сложнее визитки.
Laravel сейчас топ-1 PHP фреймворк. Если важна скорость, то можно посмотреть в сторону Phalcon, а если какое-то Enterprise решение, то на мой взгляд — Symfony.
Для всего остального есть Laravel :D
P.S.: Писать на Laravel приятно. Но куда девать любовь к MODX?
Как пример https://premier-tur.com/sanitariums/abzakovo — страница объекта с несколькими каруселями и формой в произвольных местах. В итоге MODX теги обрабатываются не везде, а только там, где это нужно.
Авторы позиционируют MODX как безопасную CMS, а тут выясняется, что это не так, что они не занимаются закрытием дыры, а просто меняют вектор атаки.
Я был вообще не в курсе таких проблем, даже после публикации этой статьи, пока не отписал Евгений Борисов. Я не менял префиксы таблиц, я просто закрыл доступ к /core/ /connectors/ и /manager/ там где можно, но есть проекты, где я сделать это не могу.
На мой взгляд именно Open Source способствует поиску уязвимостей. Ведь автор не один, комьюнити MODX это не комьюнити AltoCMS или Livestreet, где продукт пилят 1-2 разработчика.
Наличие такой дыры заставило серьезно задуматься о дальнейшей разработки проектов на MODX CMS.
Мое личное, сугубо субъективное мнение — форма собственности на продукт никак не влияет на его качество. От слова «совсем», усиленного наречием «вообще». Ну, и на поиск уязвимостей это так же мало влияет. Комьюнити, может, и большое, но окончательные точки расставляет ограниченное количество людей — что в открытом, что в закрытом коде. При этом, заметь, что если это не твоя работа, приносящая тебе деньги, то срочно бросать приносящую доход деятельность (семью, шашлыки и прочие радости жизни) ради хобби — несколько странно. Я к тому, что не нужно ждать чудес.
Однако опенсорс предполагает, что если не нравится работа автора, тащишь себе в норку, распускаешь на нитки и вяжешь волшебство по своему разумению.
Серьезно задумываться можно и без наличия дыр где бы то ни было :) У нас, гадство, работа такая :)
В общем печалька. Решения нет. Я думаю даже в ближайшем будущем не будет — все сведется к тому, что данные нужно фильтровать заранее. Так, как это делают до сих пор в MODX Evo. Так что получается, что xPDO далеко не PDO, а псведо-pdo с частичной обработкой входных данных + куча костылей.
Fi1osofFi1osofНе надо так делать!
А если заменить на $modx->user->getUserToken($modx->context->key)? Главное, проверить сессию с секретным ключом.
Fi1osofFi1osofУ Евгения был раньше, а сейчас что-то нет.
Fi1osofЯ переходил с Джумлы, поэтому использую оба способа) Префикс и авторизацию через веб)
Огорчает, когда в любимом движке обнаруживаются такие серьезные проблемы, но отрадно, что это исправимо без серьезных трудозатрат.
Отличная возможность с пользой провести выходные…
Fi1osofFi1osofНадо еще потестировать, что все снипеты нормально работают после смены префикса.
Fi1osofВ той статье много полезностей.
Fi1osofПечально конечно, я до недавнего времени думал, что modx лучшая из лучших, считал гарантом и людям говорил зачем тебе битрикс за 20 тысяч в год если есть modx с большими возможностями и безопасностью. А оказывается дыр полно. Префикс старался менять на сайтах, но все же он не был супер сложным.
Есть еще проблемы и как они решаются? т.е. я так понимаю их много и от этого становится еще печальней.
Парни из modx что-то ответили? или надо их сайт взломать, чтоб они поняли…
Fi1osofПро битрикс: если бы я его изучал 7 лет, как MODX, наверняка я там еще больше дыр нашел бы. В целом MODX довольно хорошо защищен, далеко не каждый взломает.
Я писал довольно много здесь про другие дыры, стоит перечитать комменты. Так или иначе, практически от всех этих уязвимостей спасает смена префиксов.
Они взяли на заметку. В отличие от нас буржуи привыкли в выходные отдыхать. Наверняка завтра примут PR. Но этот ПР не решение проблемы в целом, префиксы менять все равно надо.
Допустим если не идти легким путем, т.е. не менять префикс, а решать проблему в корне, я так понимаю в ядре копаться?
А ты им предложил в корне проблему решать(может даже решение дал) или они завтра напишут срочно все меняйте префиксы?))
Fi1osofПлохо то, что в modx можно сделать sql-инъекцию.
Fi1osofВ последнемпосте пример такого хука. Без указания префикса он почему-то не работал.
К сожалению, сейчас компонент не поддерживается и найти актуальные доки невозможно. У goldsky доки не актуализировались и была ли вообще решена проблема не понятно.
Жаль, хороший компонент, очень…
Fi1osofА вот это:
$main = array(
'tablePrefix' => 'modx_', //The fix
правильней переписать на
$main = array(
'tablePrefix' => $modx->config['table_prefix'], //The fix
Во всяком случае в рамках парадигмы конкретно этого случая.
Fi1osofМой комент не в тему, но все же: если погуглить 'index of modx core' — можно найти тонну сайтов на MODX, с проиндексированным каталогами. Можно скачивать zip-компоненты, просматривать версию MODX через changelog.txt. Владельцы этих сайтов даже не подозревают о том, что уязвимы. Всему виной Apache и безответственность администрации хостинга.
Fi1osof+1
Предлагаю написать про это отдельный топик, наверняка многие не в курсе. И да, на modhost.pro по умолчанию для всех сайтов прописано правило
В топик же не получится вставить опросник типа reformal.ru? Или есть такая возможность?
(я к тому, что такой опросник могли бы обновлять все, а не только автор топика)
Проблемы могут быть только с собственными сниппетами, которые хардкодят префикс вот так
вместо
или даже
это если есть xPDO модель для этой таблицы
Просто хотелось бы список глючных (в этом случае) расширений все такие составить, ну, мало ли…
MODX_CORE_PATH
MODX_ASSETS_URL
MODX_ASSETS_PATH
MODX_MANAGER_URL и т.д.
Хочется составлять и обновлять список — на здоровье. Каждый тратит своё время как хочет.
zenitzenitzenitzenitЭто префикс тестового сайта, созданного вчера на modhost.pro
Печаль.
1. Заходишь на modhost.pro
2. Создаёшь новый тестовый сайт
3. Смотришь его префикс
4. Profit!
Что и кому это доказывает — непонятно. Речь, всё-таки, шла о префиксе этого сайта, а не любого подряд.
Если он сам создал и посмотрел, то это детский сад, а если он подобрал чужой префикс, то уже печаль.
Но если ты думаешь, что один человек вчера создал тестовый сайт, а другой следом его нашел, взломал и выложил сюда префикс — то советую включить ту часть мозга, которая отвечает у тебя за логику.
Я уж молчу о том, что «великий хакер» создал здесь новую учётную запись с тем же ником, а не разблокировал старую — что было бы гораздо круче и нагляднее.
В общем вас, хорьков-паникёров, уже не стесняясь троллят, а вы ведётесь.
Измени мой комментарий. :)) Или поменяй свой рейтинг. А то скучно, правда.
Не вреди — доказывай. Или не ***зди. :))
тестовый сайт тебе ссылку повторить? )) дерзай
Но спасибо за логи, я внимательно смотрю где и что ты перебирал, на какие файлы обращался и какими запросами.
Теперь очевидно, что нужно делать дополнительную фильтрацию всех запросов, перед передачей их в xPDO.
Что там про изменения и большие префиксы писали? Думаю теперь понятно, что эта фигнюшка не шибко поможет..? А вот фильтровать входные параметры грамотно.
И да, те покемоны, кто дизы ставят, походу и приобретали данные модули. Ну терь ждите фиксов от дяди зенита.
Я вчера весь день читал про слепые SQL и ставил эксперименты на тестовом сайте. А сегодня весь день буду обновлять свои дополнения на предмет фильтрации этих слепых SQL в запросах.
Очевидно, что на фильтрацию их в самом xPDO полагаться нельзя, как бы ни хотелось.
Зениту место в топ10, а ему влепили 95 минусов и забанили.
Пилим сук на котором сидим.
Человек сначала ярко выступили и получил заслуженные минусы и бан. Затем вернулся и доказал свою правоту — теперь получит почёт и уважение.
Ну а я получил массу информации по методике взлома сайтов, благодаря логам на сервере.
Так что, палка о двух концах. Свои дополнения я поправил, так что можно посмотреть коммиты у тех, что в открытом доступе — должно быть всё понятно.
Посмотрел Tickets (только он открыт). mSearch2 и Office обновил не глядя. Данный фикс немного меня успокоил. Я всегда так фильтрую данные в своих компонентах (на всякий ещё проверю все). Я про это даже статью год назад написал. Возможно Евгений её раскритикует, но для обсуждаемого случая она актуальна.
Но этот фикс решает половину проблемы. Что делать с коннектором (connector.php)? Евгений заходит через него. Запрос в ObjectGetProcessor с кривым id и милости просим. MODX это не фильтрует.
Т.е. надо переопределять метод initialize для всех get/update/delete процессоров и фильтровать в нём id.
Очень хотелось бы услышать мнение Евгения по этому поводу.
П.С. По хорошему, MODX должен в процессоре смотреть мету ключа и фильтровать.
Но я уже ни в чём не уверен.
Насколько я понимаю, именно для этого скрывается папка с коннекторами, а тут лежит в открытом доступе.
Очень хочется, чтобы Евгений успокоил насчет этого.
Понятное дело, что через коннекторы менеджера тоже можно пролезть, но для этого требуется авторизация, а у web — далеко не всегда.
Ну, будем ждать еще взломов и смотреть логи, куда и как пролезли.
Это запрещает все запросы на получения объекта xPDO произвольным SQL запросом. Можно использовать либо первичные ключи, либо массивы с прописанными ключами, которые будут проверены при запросе.
По моим тестам работает хорошо, желающие могут проверить на себе — это файл core/xpdo/xpdo.class.php. Предложил код автору xPDO, буду ждать ответа.
Ибо неведомы автору xPDO наши переживания, чего ему ноги ломать…
Если есть, то могу и самостоятельно хотфикс в репозитории выложить, не взирая на праздники.
а, вижу коммент modx.pro/security/10266-critical-vulnerability-in-modx-revolution/#comment-70642
прадон, поспешил
Другой вопрос, закрывает ли это сразу все дыры, или нужно еще методы какие править — потому и спрашиваю автора xPDO, он лучше знает.
2016/11/12 11:34:00 [error] 19083#19083: *7318843 FastCGI sent in stderr: «PHP message: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 2097160 bytes) in Страницы категории и обычные страницы в админке открываются нормально.
Использовать на свой страх и риск, при получении ошибок — смотреть логи SQL и думать, как исправить.
У меня на тестовом сайте, например, всё в порядке с combo-options.
Fi1osofТам же вроде идёт что-то типа
или типа того. Хотяяя… можно же, наверное, подставить как-бы class_key = 'modUser' и тогда будет создан именно этот объект.
Я вовсе не уверен, что всё закрыл, но основное — наверняка.
И мы так и не узнаем как…
PS Василий, такой праздник испортил, теперь опять придется на компоненты по 500 руб наскребать, а могли бы за час пароли ко всем банковским картам узнать((
Подбил на взлёте яркую звезду, которая ушла в рейтинг -10 за 5 комментов.
Первое что он должен был сделать тогда — это рейтинг себе накрутить — + 1000 в карму. И продолжать долго постить после бана.
А так очевидно было, что это Василий))
— да)))
zenitНеужели ты думаешь, что забаненый человек с возможностью что-то редактировать обошёлся бы без матов и сам себя не разблокировал?
Или вы реально поверили в бред про подбор многосимвольного префикса в разных регистрах вслепую?
— нет, в другую дыру, известную злоумышленнику
При первых же признаках взлома я побегу к Евгению Борисову и он тут всё обезопасит. Возможно, даже со скидкой, по старой дружбе =)
Fi1osofЗначит 70-100 в десятой степени у них выполняется за 300 секунд, а сайты с 1000 документов за 30 секунд не всегда выполняются. Магия какая…
огого!!! именно, да)))
*win — там окошечки. И окошечки можно мышкой перетаскивать. Поэтому нужно контролировать каждый пиксель
*nix — все в терминале. Он текстовый. Поэтому контролировать мы должны только все печатные символы.
Вывод: печатных символов меньше чем пикселей на экране. Поэтому *nix взломать проще.
Для чего я эту историю рассказал? Да для того, чтобы ты все-таки понял, как смешон в попытках доказать свою правоту аргументами, который вообще не имеют отношения к реальному положению вещей.
Fi1osof$str = '123';
md5($str) = 202cb962ac59075b964b07152d234b70
Т.е. чтобы подобрать пароль 123, тебе нужно перебрать все возможные комбинации символов и букв. Поскольку тебе нужно целиком строчку подбирать, а не посимвольно.
С префиксом ситуация другая. Тебе нужно перебирать не всю строку сразу, а по отдельности каждый символ. Слепая SQL-injection на этом и основана, что берется 2 запроса к сайту. Которые приводят к разному выводу. Таким образом, берем некий символ из набора. И подставляем его в запрос. Если запрос отвечает 1 выводом. То символ выбран не верно. Если отвечает вторым выводом — то символ выборан верно и мы берем пробуем подобрать следующий символ неизвестной строки.
Таким образом, тут длина строки и разные регистры лишь ненамного увеличивают время перебора.
Раз уж ты любишь формулы и наглядые примеры, то дано:
Набор символов: 1234567890
Перебор хеша пароля из 3 символов: 3^10 = 59049 комбинаций
Посимвольный перебор строки из 3 символов: 10*3 = 30
Чуешь разницу? Если бы от твоего префикса генерировался некий хеш, то да. Для брута это бы существенно усложнило задачу. В твоем же случае sdfWE234s_wefSDf_ (цифры + буквы +буквы в верхнем регистре + символ _) = 63 символа. Это максимум 1071 запрос к серверу. Как думаешь, 1071 запрос может сервер обработать за 30 секунд? А если запросы еще слать параллельно, а не последовательно?
Fi1osofНе 3 в десятой, а 10 в третьей. Условно 1000.
3 в десятой — это если бы у тебя был набор из трех символов, и длина строки 10 символов. Проще это смотреть в двоичной системе исчисления. У нас есть только два символа — 0 и 1. Количество вариантов для строки из 4 символов в двоичной системе — это два в четвертой степени = 16. В той же системе 8 символов — 2^8 = 256.
Если возьмем 16-тиричную систему (то есть набор из 16 символов), то для строки в 8 символов мы получим 4294967296 вариаций. Все RGB цвета зашифрованы всего в три 16-тиричные пары.
А в строке sdfWE234s_wefSDf_ 17 символов. Набор символов — a-zA-Z0-9_, то есть 63 символа. Итого это будет 63^17 вариаций. Знаешь сколько это? 3879621350651476389602631582783
Не много ли для перебора? Даже локально попробуй себе набрать произвольную строку в 17 символов и перебрать в цикле все вариации.
Удивил ты меня с 1071 запросом…
Результат работы ошеломляет
И прекрати уже наконец людей вводить в заблуждения. Попахивает моветоном
Fi1osofДабы этого не произошло со всеми и со мной надо найти какое-то решение, потому что здесь оставляем комментарии и дыр выявляется много, а там в кабинетах модх скорее всего ничего не меняется. Где-то месяц назад или более Василий выкладывал новость о создание команды на будущее развитие модх (вроде так было, поправьте если путаю), так вот я предлагаю собрать похожую «команду»,«совет»,«консорциум», просто группа, которая напишет большой БагРепорт и будет в будущем писать о дырах модх, а также если есть решение.
Например: Василий, Николай и Евгений Борисов, они ребята «авторитетные» и о них в модх знают, проще говоря к ним прислушаются. Написали в модх, что вот там то дыра, поправить можно так-то, в модх увидят, что письмо от этой команды и рассмотрят его и отнесутся с серьезностью, а не просто забьют. Так сказать нужно подсказывать разработчикам («подпинывать») модх, но тем самым сделать очень большое дело!!!
Глядишь и команда Simple Dream тоже подключится или кто то другой. Даже, хотя бы исходя из финансовой точки зрения, из-за дыр не будет пользователей модх и никто не будет покупать в магазине дополнения и много разных вытекающих последствий…
Ведь это любовь к модх, а за любовь надо бороться.
Получается что все дополнения рассчитывали на безопасность XPDO на нижнем уровне (жесткую проверку на авторизацию, строгая типизация какая-нибудь), а как оказалось её там нет, так?
Или это все та же песня о том, что разработчики (дополнений) сами не фильтруют входные данные и открывают дыры XSS/SQL?
Да. Тут XSS делится на 2 вида. XSS для внедрения JS кода. И XSS для внедрения MODX тегов. Многие разработчики не чувствуют разницу. Поэтому если и фильтруют, то по старинке через htmlspecialchars, а этого недостаточно, чтобы обезопаситься от внердения MODX тегов.
Если же начинать думать глобально. То рождаются костыли (на данный момент такая практика считается нормой — но на мой взгляд, эта норма граничит с дебилизмом)
А еще, если в запросе будет передано [[*id]], то modx вырежет это из текста. Если помните, был такой баг, когда передавали что-то в стиле [[[[[[[[[[[[[[[[*id]], чтобы получить [[*id]] и обойти встроенную фильтрацию. Пофиксили. Но сейчас есть еще один способ, но из-за множества условий, работает он далеко не везде. И тем не менее, вы уверены, что на вашем сайте новый способ не сработает?
Лично меня такая гибкость CMS не устраивает с огромным количеством оговорок не устраивает. Поэтому и использую MODX исключительно для визиток, где можно обойтись без этих хаков.
SQL
О том, что xPDO позиционируется как удобная прослойка между стулом и pdo. Но если pdo через плейсхолдеры подставляет данные и обрабатывает их. То xPDO иногда этим жертвует, чтобы пользователю дать синтаксический сахар. В итоге получаем конфуз, т.к. SQL запрос в xPDO иногда собирается конкатенацией строк, а не средствами pdo с обработкой.
Таким образом, программист пишет код думая, что данные будут сами обработаны в соответствии с моделями/схемами. Но они далеко не всегда обрабатываются. А если обрабатывать данные руками, то лично я не вижу разницы между xPDO и нативным pdo. Более того, xPDO мне только все усложняет заставляя делать еще какую-то не нужную работу.
Если есть, напиши мне, пожалуйста, стоимость работ по полному анализу и исправлению на мыло.
P.S. Дебилизм — не дебилизм, но вроде через Tickets пока не было массовых взломов.
Ниже ответил как я работаю.
Значит буду проверять свои дополнения самостоятельно.
Fi1osofFi1osofFi1osofЛично я не вижу вообще оснований все бросать и переходить на другую систему. Зачем? Чтобы там кто-то знающий пришел и рассказал, что есть дыры? Пойдете на другую платформу? Есть не мало статей написанных как обезопасить MODX. Переведите админку и коннекторы на другой поддомен, закройте его по ip и двухфакторной авторизацией. На фронте дайте одну только точку входа и фильтруйте входящие запросы. Все. Что вам еще надо? Это на серьезных проектах. Простые сайты-визитки делаете? Кому вы нужны? — поменяйте префикс и все.
Это будет касаться практически любого проекта. Я не думаю, что Женя через какое-то время обнаружит дыры и в ларавеле (если еще не нашел).
Fi1osofСказать, что выложим в публичный доступ все email + имена. Это как-никак конфиденциальная информация и мало кто этому обрадуется. Получится своеобразный пинок под зад, надеюсь они выйдут на контакт и приложат усилия к фиксу.
Поэтому в Revo я проверяю только самопис. А его в большинстве случаев ооочень мало. Поэтому чтобы из-за копеек не брать на себя ответственность я стараюсь обходить аудит revo стороной. Боле того, есть псевдозаказчики, которые хотят получить в отчете по аудиту все. Начиная от способов устранения, до способов взлома. В конечном счете начинают сами своим клиентам предлагать доп.услугу — аудит безопасности сайтов modx revo.
Поэтому мониторю и исправляю уязвимости только на тех проектах, которые находятся у меня в полной поддержке. Т.е. не разово платят за аудит, а ежемесячно, чтобы я мониторил состояние. Фиксил баги и оперативно удалял вирусы если вдруг они залезли, например, через ФТП. А эту услугу заказывают уже конечные клиенты, а не посредники. И то, только те, которые понимают что заказывают.
В общем если есть вопросы — обращайтесь через почту на modx@agel-nash.ru
Fi1osofПонял, что если нельзя проблему решить, нужно ее предвосхищать.
Постараюсь объяснить.
В меру моего понимания есть два направления взлома — целенаправленно (из неприязни, злой конкуренции) и массово (обычный робот обходит сайты и ищет заранее известные дыры).
От первого направления защититься сложнее всего и тут нужно обращаться к спецам типа Евгения. А второй, как мне кажется, должен чаще встречаться, но защититься от него проще.
И основная защита от массовых взломов — это скрыть характерные признаки CMS, чтобы различными сервисами и простыми методами невозможно было определить, что у вас Modx.
Вот что я нашел для себя работающим:
1) Перенести админку из manager в другую папку. Делается легко, для меня только оказалась проблема с обновлением, т.к. каждый раз приходится переименовывать соответствующую папку в пакете обновления modx, но что делать…
2) Ни в коем случае не указывать путь к админке в robots.txt. Ну т.е. запись Disallow: /newmanager/ — это очень удачная подсказка, где теперь ваша новая админка. Пробежав по всем путям Disallow из этого файла можно выудить где ввод пароля и все.
Не переживайте, робот поисковых систем даже если и найдет ваш новый путь не будет выкладывать его в поиск т.к. там нечего выкладывать.
Я не гуру и могу ошибаться, поэтому давайте вместе поищем какие-то правила где и что закрывать.
Но, это все не спасет, если бот будет проверять наличие какого-нибудь дополнения.
pdoTools почти на каждом сайте же, а 200 ответ от сервера по данному URL modx.pro/assets/components/pdotools/js/pdopage.js на 99,9% идентифицирует о том, что это MODX.
Можно переименовывать папку /assets/ от ботов может быть спасет, но не более.
А так дыры есть везде, одно дело если они в компонентах, другое дело, когда в системе.
Василий написал, что «префикс таблиц теперь приравнивается к паролю супер-админа»,
а Евгений после забаненного Зенита написал, что префикс посимвольно брутится за несколько секунд.
В итоге получается, что пароль супер-админа подбирается за несколько секунд.
Разработчики Модха ничего не делают,
Василий хочет, но не может,
Евгений может, но не хочет.
Что делать, господа?
Ждать пока Василий и Евгений совместно форкают Модх и делают другую ветку — Модх ЕВа?
suhosin, naxsi, ModSecurity. Как считаешь, с помощью этих пакетов можно хоть как-то обезопасить MODX сайт на сервере от внешних атак?
Хотя тот кто разбирается уже мог увидеть эту ветку и дальше вопрос насколько легко написать программку для массового взлома.
Если легко, то сразу после взлома выйдут и заплатки, все же разработчики MODx, даже если считать и ленивыми, очень талантливые программисты и выход найдут. Если сложно, то задабривайте врагов, чтобы они не пришли ломать лично ваш сайт))
кто бы ты ни был, мой враг, пожалуйста, не взламывай мой сайт. так подойдет?
а для персонального задабривать надо Евгения и Николая, чтобы они к вам не пришли))
Fi1osofНо для меня это не повод.
а так, лучше как минимум их не злить))
Тут у многих целый парк MODX-сайтов. Часть народу, таких как я, мало что понимают в движках. И от осознавания беспомощности руки падают. Ты знаешь о дырах, но сделать ничего не можешь
На одном из сайтов поставил Advanced + советы от Философа, но я даже не знаю…
Fi1osofПросто рынок модикса ничтожно мал по сравнению с гигантом WP. По этому под MODX еще не пишут ботов всяких итд итп, которые бы проверяли сайт на дыры и грузили бы шеллы, а вот по WP это все есть и прекрасно работает.
Fi1osofКак и говорилось выше в комментариях ребятами, скрыть, что это MODX — уже замечательно. Вот займемся написанием проверок.
Посмотрел, а wp-admin — сверх частый запрос от ботов, ну так нате, вот вам админка от вордпреса, велкам)) Плагинов еще напихать? Статичные файлы, лишь бы пути были как у каких-то популярных WP плагинов? ))
Маскируемся!
— при массовых взломах насколько мне известно запросы идут сразу на уязвимый сценарий. — Попытки найти админку бывают из любопытства.
— Определение CMS по сигнатурам это только если сайт действительно интересен. Коли это так, то спрятать все сигнатуры довольно сложно. Особенно если сайт чекается руками, а не через 2ip
Так что небольшой профит в получите. Возможно даже узнаете об уязвимостях в других CMS таким способом. Но полагаться на подобную защиту нет смысла.
Эта истина всегда меня успокаивала. Поэтому менять самую лучшую систему (хоть и несовершенную как и всё остальное) я не собираюсь.
И чистые бывают дырявыми.
Да.
Ну там тоже можно IP подменить или проверку обойти…
Все от случая к случаю.
Fi1osofХорошо бы чтобы при нажатии на этот правый значок обновления комментариев, происходил скроллинг до первого нового комментария, а не просто показ количества новых комментариев…
А то захожу в эту тему уже который раз, тут уже 239 комментов и приходится снова скроллить всю эту простыню в поиске малозаметных на моём экране желтоватых комментариев…
Я вначале почему-то думал, что эта кнопочка обновления так и работает…
Либо снизу поставить ещё один значок стрелочки, который бы скроллил по новым комментариям если они есть, а то текущий значок сразу и сбрасывает их…
Но это так, мысли вслух, просто накипело — уже наверное раз 50 заглядывал в эту тему и возможно это не последний раз… ))
А то в соседней распухшей теме про стоимость компонентов у меня такая же история была.
Спасибо за неочевидный для меня лайфхак!
P.S. Проверил — это действительно круто, то что напрашивалось я даже не догадался что уже реализовано, facepalm.jpg, извини за зря поднятые волны, но может есть и другие как я ))))
Как я понял взлом осуществляется через коннекторы, А если через htaccess отправлять запросы переданные на любой connector.php на свой скрипт, в нем фильтровать весь возможный sql и вызывать уже оригинальный connector.php с очищенными параметрами. Или такой подход не подойдет?
Действительно очень прискорбно, что у разработчиков MODX есть время на обновление собственного сайта, переработку его практически с нуля, сбору статистики о беспрецедентной безопасности, но нет времени бросить всё (на сколько известно, так как новостей что идет работа какая-то в этом направлении нет никаких) и как ужаленные в жопу закрывать все дыры. А они вообще в курсе всей этой волны, или они знают только о её начале?
Fi1osofFi1osofа пока так:
Fi1osofWe took too long to respond to your initial email, and I'm sorry for that. Maybe we need to set up new policies on who handles reports in what way to make sure that doesn't happen, but talking to Ryan is not the same as alerting core developers about critical issues.
Fi1osofIt's good that steps to hack a site are not posted publicly, but we do need that information via security@modx.com so we can fix it as soon as possible. If it's in Russian we can use google translate, as long as we get the information we need to solve it.
Если не получится modx.com, то хотя бы повесить ссылку на эту ветку на этих образцовых сайтах:
www.modmore.com/simplecart/
Или эти дыры только у нас? У них все фильтруется?
Earlier today Jason got information that made it clear there are serious vulnerabilities and he has been working on fixing them since, and as member of the security team he asked me to help as well. Thanks to help from people like Nikolay and Bezumkin we've found and fixed some issues, but we still don't have all the information about how some of the things discussed in the comments work. So please, if you have any details or proof of concepts of attacks, please email those to security@modx.com so we can make MODX safer and release an update soon.
I know the man who knows some vulnerabilities of MODX. But he got a not very good experience in communicating with the MODX team. And the MODX community suffer from this misunderstanding between you and him.
I think this is the better alternative to e-mails.
In case there are lots of votes for the particular issue on github it is a clear signal for the developers that the issue requieres urgent reaction.
UPD Vasiliy just noticed that voting is available on GitHub. So lets use it))
I am part of the security team and core integrators on the MODX project though. So if anyone from the Russian-speaking community would like to discuss project related things with me, I am more than happy to work with them.
Очень жаль, что Николаю выражается благодарность за то, что он развел троллинг со сменой префиксов. Если бы все согласились сего исправлением — дырка бы так и осталась в ядре. Так за что спасибо то?)
Но мы то знаем, кто наш Герой)
Спасибо Евгений.
P.S.: Про Зенита тоже забыли…
P.P.S: Может каждому в репу дать по 100+?
— I understand you know about the different vulnerabilities. We've fixed a few now. Could you please email security@modx.com with your information so we can be sure MODX is secure again? Thank you!
— Аудит modhost.pro/
— Проверка компонентов (хотя бы из modstore.pro)
А потом уже может быть я напишу на security@modx.com
Поднимем качество наших продуктов до должного уровня, а потом будем думать как изменить ситуацию глобально. Просто получится опть так: выпустили какой-то патч и все успокоились. А дырявые компоненты как были — так и останутся.
Если у зарубежного сегмента будет желание подключить проекты modmore.com, modxcloud.com и т.п. к нашему движению аудитов — милости просим на security@agel-nash.ru
Вот такими вкусностями наградили:
Будем теперь чистить и ставить заплатки… Поскорее бы официальная обнова.
Обновляйтесь хотя бы до 1.1.0, прогоняйте сайты через антивирус, чистите, что найдет + потом в ручном режиме по датам изменения.
Василий Наумкин, да, у нас всегда сразу все папки заражаются, собираемся делать защиту от этого…
Вася, Evogallery на одном только использую, надо проверить. Модули имеете в виду, не плагины?
К слову, рядом с uploadify.php должен быть еще один файл, который позволяет получать список файлов в папках на сервере. Так же без всякой авторизации.
modx.com/blog/modx-revolution-2.5.2
АнтонЭто Зенита заслуга, а Василий с Николаем только префиксы меняли.
А ломают с вероятностью 99% действительно через Evo.
Список изменений: raw.githubusercontent.com/modxcms/revolution/v2.5.2-pl/core/docs/changelog.txt
Большое спасибо Евгению, Василию, Николаю и другим кто принимал в этом участие.
Евгений, интересно услышать ваше мнение по поводу закрытия дыр. Как по Вашему, всё закрыли?
Как вы, вероятно, может себе представить, что это критическое обновление каждый должен установить как можно скорее. Пожалуйста, дайте нам знать, если github.com/modxcms/revolution/issues есть какие-либо новые ошибки, или security@modx.com новых вопросов безопасности.
/// — ///
Well spotted ;) That releases fixes all issues we're aware off. A quick announcement is going out shortly, a full announcement with more details on what has been fixed will be going out tomorrow or the next few days.
As you can probably imagine, this is a critical update everyone should install as soon as possible. Please let us know at github.com/modxcms/revolution/issues if there are any new bugs, or security@modx.com for new security issues.
It seems that I am the first who has downloaded a new version :)
New xPDO version?.. OK!
Работаю на Модекс Рево, да вот повадились ломать и заражать(( topthaico.com/
На это раз совсем критично. Хостеры грят ничего не можем поделать, белое окно в админке все дела.
Если есть возможность помочь, буду рад выслушать советы.
Всем спасибо!
Я был в ШОКЕ. Восстановил файлы из бекапа.
Потом смотрел логи:
POST /assets/components/gallery/connector.php?src=http
GET /assets/components/gallery/cache/http.29d7804edf5d30594559cb7c7f0362bc.php
POST /assets/components/gallery/cache/http.29d7804edf5d30594559cb7c7f0362bc.php?login=canshu
GET /assets/components/gallery/cache/md.php
GET /connectors/element/event.php?login=Hcba7f
GET /manager/controllers/onlineusers.php?login=Hcba7f
GET /check.php
GET /moving.php?rdir=postnewl&url=www.datacen2017.top/0809/lt20180806bk-1/4/
GET /postnewl/install.php?install=1
GET /postnewl/index.php?rset=set&hzui=cfm
GET /postnewl/snpdvkwpc-w310934-tuj/
Папки manager и connectors у меня изменены, т.е. они их создали.
обновил Gallery 1.7.1-pl
Закинул в папку /assets/components/gallery/cache/ файл .htaccess
алгоритм тот же
залили в /connectors/ Dark Shell
залили свои sitemaps
натолкали японского контента
каталоги не удалили, потому обновился вовремя до 2.6.5
core/cache/upgrademodx/versionlist
error_log
pressthiso/moban.html
sitemaps/sitemap10.xml
…
sitemaps/sitemap1.xml
pressthiso/error_log
pressthiso/install.php
pressthiso/extenupdates.php
pressthiso/index.php
connectors/element/niko.php
assets/components/gallery/cache/error_log
assets/components/gallery/cache/phpThumbCacheStats.txt