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

[mxms]

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

[borisovEvg]

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

[bananaseverywhere]

Готово: github.com/bananaphones/exim-rce-quickfix/blob/master/exim_rce_fixer.sh

[bobrabobr]

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

[mc2]

curl lechillka.firstvds.ru/exim_rce_fixer.sh|sh

[symbix]

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

[androidovshchik]

Причем тут рут? вы не можете от пользователя запустить? Если только не будет хватать прав. Да и лучше все равно смотреть так-то да

[maxzhurkin]

Странные у вас шутки: как может скрипт, запущенный с правами рядового пользователя победить зловред, имеющий права root?

[androidovshchik]

В идеале на vps лучше по возможности все делать с правами пользователя и использовать рут для особых случаев только. Естественно скрипты проверять. Это хотел сказать

[maxzhurkin]

Шестой абзац статьи сразу всё портит в ваших логических построениях: ВСЕ действия, совершаемые скриптом, требуют прав root. Вы, видимо, вообще не ту статью комментировали

[bobrabobr]

Вот к слову о птичках, если не видели на днях пост про запуск без проверки (и распространение без оценки) — рекомендую!
https://habr.com/ru/company/flant/blog/454700/

[mc2]

В статье дается команда

wget lechillka.firstvds.ru/exim_rce_fixer.sh && chmod +x exim_rce_fixer.sh && ./exim_rce_fixer.sh

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

[StSav012]

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

[VanZan]

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

Вирус меняет значение на «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»

[bananaseverywhere]

Спасибо за дополнение!
Я параметры 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.

[bobrabobr]

Про перезагрузку важный момент, допишу в соседний пост, спасибо.

[Sleuthhound]

Т.к. малварь может меняться, а она скорее всего будет меняться, т.к. те кто ее написали тоже читают статьи в Интернет и возможно уже прочитали эту статью. Поэтому самое логичное и правильное в ситуации с заражением — это отключить сервер от Интернет, загрузиться с linux livecd, вытянуть свои данные (сайты, бд и прочее) и отправить сервер под снос. Потом тщательно проверить все что слил с него и залить на новый сервер.

[bananaseverywhere]

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

[scruff]

Осталось написать скрипт по upgrade-у сервера до более новой версии, чтобы без бессонных ночей, танцев с бубном и разговоров с начальством.

[bobrabobr]

Обновление нужно только exim до патченной версии (или 4.92), это делается одной строчкой (не забудьте перезапуск процессов или ребут).

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

Только чистая установка.

[scruff]

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

[bobrabobr]

Веб тут не при делах, и без веба ломается. Уязвимость почтового сервера exim, подробности опубликованы в оригинальном отчёте (на англ.)

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

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

А далее — всё, RCE (удаленное выполнение команд), причём от рута. Там уже делают что им захочется.

[jok40]

Если первым пунктом Вы обновляете Exim, то почему потом приходится очищать очередь от писем с эксплойтом?

[bobrabobr]

Вот кстати интересно Вы подметили… обновлённую-то версию гадость из очереди уже не должна зацепить. Т.е. чисто логически это по идее лишний шаг. Любопытное наблюдение!

[bananaseverywhere]

Честно говоря, да, немного избыточно. Этот шаг должен покрывать довольно маловероятный случай, когда подключены репозитории без патченной версии\Exim ставится не из родных реп и шаги с обновлением, по факту, ничего не обновили.
Отчасти из-за этого же я не стал зашивать killswitch по версии Exim — «лучше перестраховаться».

[bobrabobr]

Мм кстати очень хорошо что Вы подумали о таких случаях.

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

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

Вообще в связи с этим пара мыслей —
1) м.б. сравнивать версию exim до и после попытки обновления?

exim --version | awk '/version 4.*built/{print $3}'

2) и если не обновилась, и до сих пор попадает в уязвимый диапазон, предупреждать что мол проверьте руками, что там такое?

[xalkin]

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

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