Как стать автором
Обновить

Первая волна пострадавших от уязвимости Exim. Скрипт для лечения

Время на прочтение5 мин
Количество просмотров22K
Всего голосов 34: ↑31 и ↓3+28
Комментарии28

Комментарии 28

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

Можете на гитхабе скрипт разместить?

Кирилл, большое Вам спасибо за скрипт, после ребута симптомов пока больше не видать.
Можно спокойно заниматься переездом на свежую установку — согласен с Вами что так надёжнее…
НЛО прилетело и опубликовало эту надпись здесь

Запускать рутом скрипт, не читая его, да еще и скачанный по http? Отличная идея!

Причем тут рут? вы не можете от пользователя запустить? Если только не будет хватать прав. Да и лучше все равно смотреть так-то да
Странные у вас шутки: как может скрипт, запущенный с правами рядового пользователя победить зловред, имеющий права root?
В идеале на vps лучше по возможности все делать с правами пользователя и использовать рут для особых случаев только. Естественно скрипты проверять. Это хотел сказать
Шестой абзац статьи сразу всё портит в ваших логических построениях: ВСЕ действия, совершаемые скриптом, требуют прав root. Вы, видимо, вообще не ту статью комментировали
Вот к слову о птичках, если не видели на днях пост про запуск без проверки (и распространение без оценки) — рекомендую!
https://habr.com/ru/company/flant/blog/454700/
В статье дается команда
wget lechillka.firstvds.ru/exim_rce_fixer.sh && chmod +x exim_rce_fixer.sh && ./exim_rce_fixer.sh

Чем предложенный мной вариант существено отличается?
Я лишь сократил оригинальный вариант, путем выбрасывания лишней команды.
Прошу прощения, если это было понято превратно.

Заражённый curl не смущает?

Озвучу то, что не было упомянуто в статье, либо не проверяется лечащим скриптом.

Вирус меняет значение на «yes» для следующих параметров в конфиге SSH (/etc/ssh/sshd_config):

PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
UsePAM yes
PasswordAuthentication yes

Если параметр до этого отсутствовал или был закомментирован, то он дописывается в конец конфига.
Не понимая, зачем эти параметры нужны, лучше ничего не трогать, т.к. можете потерять доступ к SSH.

Кроме того вирус выключает SELINUX путём модификации /etc/selinux/config меняя значение с enforcing на disabled.

В процессе вирус может установить, обновить или переустановить следующие пакеты:

openssh-server iptables bash curl wget zip unzip python2 net-tools e2fsprogs vixie-cron cronie

Вирус может создать следующие файлы:

/etc/ld.so.preload
/tmp/.ld.so

Кроме того, стоит проверить содержимое файла /etc/hosts на предмет наличия доменов с подстроками «onion» и «busybox»
Спасибо за дополнение!
Я параметры SELinux и sshd скриптом не трогал — настройки SELinux и ssh у всех разные, выше шанс выстрелить себе в колено.
Что касается hosts, то судя по коду исходного скрипта малвари — он из hosts строки с busybox и .onion вырезает:
[ $(${sudo} cat /etc/hosts|grep -i ".onion."|wc -l) -ne 0 ] && { ${sudo} chattr -i -a /etc/hosts >/dev/null 2>&1; ${sudo} chmod 644 /etc/hosts >/dev/null 2>&1; ${sudo} sed -i '/.onion.$/d' /etc/hosts >/dev/null 2>&1; }

[ $(${sudo} cat /etc/hosts|grep -i "busybox"|wc -l) -ne 0 ] && { ${sudo} chattr -i -a /etc/hosts >/dev/null 2>&1; ${sudo} chmod 644 /etc/hosts >/dev/null 2>&1; ${sudo} sed -i '/busybox$/d' /etc/hosts >/dev/null 2>&1; }

[ $(${sudo} cat /etc/hosts|grep -i ".onion."|wc -l) -ne 0 ] && { ${sudo} echo '127.0.0.1 localhost' > /etc/hosts >/dev/null 2>&1; }

Что касается /etc/ld.so.preload и /tmp/.ld.so, исходный скрипт удаляет первый и делает его симлинкой на второй:
if [ -f /etc/ld.so.preload ]; then
        if [ $(which chattr|wc -l) -ne 0 ]; then ${sudo} chattr -i /etc/ld.so.preload >/dev/null 2>&1; fi
        ${sudo} ln -sf /etc/ld.so.preload /tmp/.ld.so >/dev/null 2>&1
        >/tmp/.ld.so >/dev/null 2>&1
        ${sudo} rm -rf /etc/ld.so.preload* >/dev/null 2>&1

Я не стал удалять /tmp/.ld.so в теле скрипта, так как он всё равно удалится при перезагрузке — создан в /tmp. А перезагружаться обязательно надо — малварь сидит где-то в открытых процессах и, соответственно, в памяти, и записывает себя по новой в крон каждые секунд 30.
Про перезагрузку важный момент, допишу в соседний пост, спасибо.
Т.к. малварь может меняться, а она скорее всего будет меняться, т.к. те кто ее написали тоже читают статьи в Интернет и возможно уже прочитали эту статью. Поэтому самое логичное и правильное в ситуации с заражением — это отключить сервер от Интернет, загрузиться с linux livecd, вытянуть свои данные (сайты, бд и прочее) и отправить сервер под снос. Потом тщательно проверить все что слил с него и залить на новый сервер.

Я двумя руками за перенос на чистую ОС с тщательной ручной проверкой всего, что могли заразить, но делать это с зараженного сервера, у которого 100% CPU выедает майнер — сомнительное удовольствие. Скрипт позволяет привести сервер в околорабочее состояние и вычистить очевидную малварь, чтобы потом уже перетащить данные и не рвать на себе волосы от страшного даунтайма.
Осталось написать скрипт по upgrade-у сервера до более новой версии, чтобы без бессонных ночей, танцев с бубном и разговоров с начальством.
Обновление нужно только exim до патченной версии (или 4.92), это делается одной строчкой (не забудьте перезапуск процессов или ребут).

Обновление же всего сервера тут не при делах — хоть неделю без сна проведите, вряд ли это что-то добавит. И убрать уже проникшую и спрятавшуюся малварь (если такая есть) не поможет.

Только чистая установка.
Также интересен механизм атаки — через что проникает зловред. Ведь во вне сервак вроде как опубликован только почтовыми портами (smtp/pop3/imap) и https для вэбконсоли. не так ли?
Веб тут не при делах, и без веба ломается. Уязвимость почтового сервера exim, подробности опубликованы в оригинальном отчёте (на англ.)

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

Если нет — недельку держат коннект открытым, каждые 4 минуты кидая по байту во избежание таймаута. Нужно чтобы 2-дневный лимит недоставленных писем обойти. Все детали в отчёте, все периоды — для конфига по умолчанию.

А далее — всё, RCE (удаленное выполнение команд), причём от рута. Там уже делают что им захочется.
Если первым пунктом Вы обновляете Exim, то почему потом приходится очищать очередь от писем с эксплойтом?
Вот кстати интересно Вы подметили… обновлённую-то версию гадость из очереди уже не должна зацепить. Т.е. чисто логически это по идее лишний шаг. Любопытное наблюдение!
Честно говоря, да, немного избыточно. Этот шаг должен покрывать довольно маловероятный случай, когда подключены репозитории без патченной версии\Exim ставится не из родных реп и шаги с обновлением, по факту, ничего не обновили.
Отчасти из-за этого же я не стал зашивать killswitch по версии Exim — «лучше перестраховаться».
Мм кстати очень хорошо что Вы подумали о таких случаях.

Те же косяки репозиториев не так уж маловероятны, прямо вот тут рядом в комментах были: и с CentOS и с Debian.

Или вот у человека exim из epel, а epel вообще отключен)

Вообще в связи с этим пара мыслей —
1) м.б. сравнивать версию exim до и после попытки обновления?
exim --version | awk '/version 4.*built/{print $3}'

2) и если не обновилась, и до сих пор попадает в уязвимый диапазон, предупреждать что мол проверьте руками, что там такое?
Дополнительно обнаружил что создаются еще следующие файлы:
/bin/config.json
/bin/httpntp
/bin/ftpsdns
/usr/bin/curlak
/usr/bin/wgetak


Последние два идентичны бинарям curl и wget соответственно, а первые три — конфиг майнера и питоновые скрипты
Зарегистрируйтесь на Хабре, чтобы оставить комментарий