Недавно случилось страшное — наш сервер с аптаймом чуть меньше года(после последней миграции) перезагрузился. На сервере развернут собственно сайт и форум phpbb 3.0.12.
В /var/log/auth.log малоинформативное
Oct 6 09:36:21 fsr sudo: pam_unix(sudo:auth): auth could not identify password for [www-data]
Oct 6 09:36:21 fsr sudo: www-data : user NOT in sudoers ; TTY=unknown ; PWD=/ ; USER=root ; COMMAND=...
Не найдя больше никаких подробностей восстановил работу сайта. На следующий день обнаружил более важную информацию
Oct 5 22:55:55 fsr su[18114]: pam_unix(su:auth): authentication failure; logname= uid=33 euid=0 tty=/dev/pts/21 ruser=www-data rhost= user=admin
Oct 5 22:55:57 fsr su[18114]: FAILED su for admin by www-data
Oct 5 22:55:57 fsr su[18114]: - /dev/pts/21 www-data:admin
Oct 5 22:57:50 fsr su[18310]: pam_unix(su:auth): authentication failure; logname= uid=33 euid=0 tty=/dev/pts/21 ruser=www-data rhost= user=admin
Oct 5 22:57:52 fsr su[18310]: FAILED su for admin by www-data
Oct 5 22:57:52 fsr su[18310]: - /dev/pts/21 www-data:admin
Oct 5 22:58:39 fsr su[18384]: Successful su for admin by www-data
Oct 5 22:58:39 fsr su[18384]: + /dev/pts/21 www-data:admin
То есть доступ таки был получен. На этот раз было найдено несколько интересных процессов запущенных от www-data.
ps aux|grep www-dataperl /tmp/bp.pl 31337
/bin/sh -i
import pty; pty.spawn( /bin/sh )Первым делом обновляю форум до последней на данный момент версиии phpBB 3.1.9. После этого прибиваю процессы и жду новых записей в auth.log. Оказалось это совсем не обязательно — через некоторое время прибитые процессы снова появились.
Переходим в /var/www/forum, делаем:
ack-grep -l '\.pl'
Особенно нужно обратить внимание на файлы *.php, помеченные как исполняемые. Привлек мое внимание файл с именем members.php с включенным флагом на исполнение, в котором были встречены и bp.pl и небезызвестный порт 31337. Этого файла нет в списке файлов из архива phpBB. Удаляю файл, в логах nginx и apache были обнаружены постоянные запросы к этому файлу. Делаю grep повторно, о чудо — на этот раз найден исполняемый файл ucpi.php, с аналогичным содержанием. Кстати изначально код эксплоита был найден на github, это сильно помогло.
Процесс обновления phpBB сделан достаточно удобно — основная часть папки обновляется, но есть папки которые переносятся из предыдущей версии проекта. У меня таким образом эксплоиты перекочевали в обновленный форум.
Сейчас кажется проблема решена, но периодически буду посматривать в auth.log, список процессов ну и исходники нужно проверять. Может моё мнение не объективно, но даже для нашего форума это не первое нашествие хакеров и это одна из причин моего прохладного отношения к php в целом и phpBB в частности.
Мне будет интересно узнать насколько эта информация актуальна и насколько сильно распространена данная уязвимость.
Спасибо за внимание.
UPD. Спасибо за теплый прием и поддержку. Ваши отзывы мне реально пригодились! Сервер был успешно отбит. Отдельная благодарность за помощь PaulAtreides.
Комментарии (18)
ExplosiveZ
07.10.2016 17:02+1И почему я не удивлен? В форум даже система обновления встроена, чтобы такого не случалось.
antage
07.10.2016 21:18+4Нужно было отследить по логам, как заливают вебшелл, найти уязвимость и убедиться, что она закрыта в обновленной версии форума. Вы же просто нашли шелл, удалили его, обновились и понадеялись, что снова его вам не зальют. Очень наивно.
gmixo
08.10.2016 19:55Я перемонтиролвал раздел /tmp с noexec. И если честно у меня есть сомнения что для 3.1.9 проблема решена, потому что до того как перемонтировал /tmp процессы так же появлялись. Насколько я понимаю критичен не шелл а то как он доставляется на сервер — как я понимаю это sql инъекция в большинстве случаев.
PaulAtreides
08.10.2016 20:26Не обязательно. Это бывает недостаточная проверка данных при аплоаде или при авторизации.
antage
08.10.2016 21:39Есть много способов. Можно, например, залить gif-картинку с php-кодом и через уязвимость вызвать этот код через
include('имяфайла.gif').
SerafimArts
08.10.2016 01:21Git? Не, не слышал +)
gmixo
08.10.2016 19:51да про git хорошая мысль — просто фактически для форума никаких правок не делалось вот и не было необходимости.
SerafimArts
09.10.2016 03:49+1Да всё равно путь любого проекта в 2016ом году:
1) Развернуть локально (опционально докер\вагрант)
2) Протестить
3) Залить в репу
4) Задеполить на серваке (git checkout -f + git pull если по-минимуму)
Я уж не помню когда последний раз заливал всё по ftp, даже совсем мелкие одноразовые проекты, гит уже привычнее как-то.
nazarpc
08.10.2016 01:27+3Статья о том, что вы не обновляете ПО, я всё правильно понял? А при чем здесь безопасность неактуальных версий PhpBB?
KIBIs
08.10.2016 09:17+1Было как то дело, обратились за помощью при проблеме с сайтами. Хостер часто блокировал сайты из за большого количества рассылок. Оказалось шелл спамбота буквально повсюду себя запихал. Десяток сайтов на modx 5 летней давности, хотя обновления и исправления безопасности выходили для него. Мораль, нужно следить за обновлениями и хотя бы раз в пол года обновляться. Таких проблем бы не случилось.
PaulAtreides
08.10.2016 19:56А к admin чего — пароль набрутфорсили?
gmixo
08.10.2016 19:59Это мне тоже было бы интересно выяснить — какой доступ фактически был получен. Сомневаюсь что пароль реально был использован. Иначе думаю что активность была бы совсем другая.
PaulAtreides
08.10.2016 20:05Выглядит так, как будто доступ был получен.
Ребут из под www-data, знаете ли, не самая тривиальная задача.
Не хотелось бы вас расстраивать, но я боюсь, что ваш сервер с аптаймом почти в год скомпрометирован целиком.
kamtec1
08.10.2016 20:03Я бы не стал надеяться на чистку после апдета. Желательно прогнать греп на base64/shell_exec/eval… на весь форум и прогнать скан типо shelldetector.
Я вас должны быть логи откуда был залит файл или хотя бы посмотреть с какого IP был залит и посмотреть кто заходил на форму с этого же IP ну и так дали…
Апдет поможет если он закраивает дырки но все же есть проблема :( могут найти другие дырки.
Я бы посоветовал закрыть опасные PHP функции .
Exabiche
Полез проверять год в календаре. Слава богу, не 2005.