LINUX.ORG.RU

Plague: бэкдор на основе PAM для Linux

 , ,


1

2

По информации команды Nextron Systems, в течение года вредоносный модуль под названием Plague оставался незаметным для средств защиты Linux-систем, несмотря на его активное распространение и глубокую интеграцию в критическую часть системы — стек аутентификации. Обнаружить его удалось лишь благодаря анализу артефактов, загруженных на VirusTotal в конце июля 2024 года. Ни один из них до сих пор не распознан антивирусами как угроза, что указывает на крайне высокий уровень маскировки и осторожности разработчиков.

Plague маскируется под легитимный компонент PAM — системы модульной аутентификации, которая играет ключевую роль в управлении доступом ко всем сервисам Linux и UNIX. Встраиваясь в эти процессы, вредоносный код получает те же привилегии, что и штатные модули, и может практически незаметно для системы обходить проверки подлинности. Это открывает злоумышленникам постоянный удалённый доступ через SSH , а также возможность перехватывать логины и пароли пользователей без какого-либо уведомления или следов.

Особое внимание специалисты обратили на то, что Plague разработан с учётом устойчивости к анализу. Он использует антиотладочные методы, скрывает строки и системные вызовы, а также манипулирует переменными окружения, связанными с SSH-подключениями. Вредоносный код удаляет такие переменные, как SSH_CONNECTION и SSH_CLIENT, с помощью функции unsetenv, а историю команд перенаправляет в /dev/null, чтобы исключить запись в файл HISTFILE. Это делает невозможным последующий аудит активности через стандартные журналы оболочки.

Особенность данного модуля — его устойчивость к системным обновлениям. Благодаря глубокому внедрению в PAM-инфраструктуру, Plague сохраняет своё присутствие даже после перезапуска служб и установки новых пакетов. Такой уровень постоянства вкупе с невидимостью делает его крайне опасным, особенно в корпоративной среде, где PAM часто остаётся недосягаемым для регулярных сканеров угроз.

Кроме того, эксперты из Nextron Systems обнаружили сразу несколько версий вредоносного модуля, что указывает на активную фазу разработки и возможное тестирование различных конфигураций на реальных системах. Это может означать подготовку к более масштабной кампании или уже идущую атаку на целевые инфраструктуры.

Plague — это не просто очередной вредонос для Linux, а симптом нового уровня угроз, где атака начинается не с эксплуатации уязвимости, а с подмены доверенных компонентов системы. Такой подход особенно тревожен, учитывая слабую видимость PAM-модулей в стандартных средствах мониторинга и недостаточную защищённость их цепочек загрузки. Учитывая возможность полной эмуляции нормальной работы и полное отсутствие следов, Plague может оставаться невидимым годами — однажды это уже случилось.

>>> Подробности

★★★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 1)

Долго эту портянку сочинял?

Plague — это не просто очередной вредонос для Linux, а симптом нового уровня угроз, где атака начинается не с эксплуатации уязвимости, а с подмены доверенных компонентов системы

Да нет, это всего лишь обычный троян. И чтобы его установить, нужны рут права. Всё это балабольство про некие «особенности» (которые на самом деле дефолтные способы работы троянов) очевидно сочинено маркетологом.

Про то, как бинарник трёт логи шелла чтобы чего-то там скрыть (видимо он работает методом запуска баша в pty и отправки ему команд через сокет) - вообще клоунада.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)

Ну вот а нафигп делали «стек» в такой базовой функции, как логин? Малварь буквально распространилась через обскурность работы PAM, потому что для большинства людей это всё (PAM< polkit, *logind) какое-то ненужно, которое тянется зависимостями.

Bfgeshka ★★★★★
()
Ответ на: комментарий от Bfgeshka

PAM тут разве что при том что у него есть стандартное апи, одинаковое на всех системах, к которому проще подключиться не возясь с каждой отдельно. А так он мог бы прописаться куда угодно с теми же итогами.

Впрочем, те три сущности которые ты перечислил и правда не нужны.

firkax ★★★★★
()

В следующий раз напишут про bash под рутом, который

оставался незаметным для средств защиты Linux-систем, несмотря на его активное распространение и глубокую интеграцию в критическую часть системы

Ecl
()

Более чем наглядная иллюстрация того почему бинарные PAM модули это абсолютное зло. Локальная аутентификация никогда не бывает бутылочным горлышком производительности - там нечего и не за чем оптимизировать и пихать бинарщину: скриптового языка (причём не обязательно тьюринг-полного) хватит за глаза.

zabbal ★★★★☆
()

А в целевую систему, конечно же, он залетает на святом духе.

redeyedanonymous
()

Ну хороший толковый сессионный pam-модуль написали. И чо? А отмониторить каким-либо статическим анализатором типа aide или tripware целостность конфигурации в /etc не? Никак?

gns ★★★★★
()
Ответ на: комментарий от LightDiver

Ну над собой вообще смеяться полезно. :) По крайне мере, если умеешь, то ты точно не тупой.

gns ★★★★★
()
Ответ на: комментарий от Bfgeshka

А как ты иначе апдомен аутентифицироваться будешь?

gns ★★★★★
()
Ответ на: комментарий от gns

Nextron Systems delivers highly flexible solutions for automated forensic analysis and compromise assessment, enabling organizations to uncover what others often miss—such as traces of hacking activity, configuration backdoors, and obfuscated malware—while ensuring seamless analysis across diverse systems, including legacy and edge devices.

По поиску «nextron systems» примерно каждая вторая ссылка вот на эту новость. Очевидно, немцы решили хорошо пропиариться, чтобы продать свои услуги.

Я бы классифицировал новость как спам.

Aceler ★★★★★
()
Ответ на: комментарий от Bfgeshka

Ну вот а нафигп делали «стек» в такой базовой функции, как логин?

Потому, что некоторым хочется:

  • хранить пользователей в LDAP
  • входить в систему по отпечатку пальца, крипто-ключу и др, в том числе сочетая это с паролем
  • шифровать домашнюю директорию паролем пользователя
  • использовать единый механизм «логина» для разных программ, к примеру su, gdm, ssh

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

Поэтому архитектурно всё сделано правильно.

Хотя, полагаю, можно и может быть даже полезно было бы сделать какой-нибудь simple-pam, как бесшовную замену оригинальному проекту, в котором убрать все эти возможности и поддерживать лишь обычный passwd и shadow. Для 99% инсталляций его хватит, а 1% пускай заменяют его на оригинальный pam.

Я бы даже сказал, можно и вовсе без pam обойтись для серверов без графического окружения. Придётся переписать утилиты управления пользователем, и постановить работу ssh только по ключам, но может это и к лучшему.

vbr ★★★★★
()
Ответ на: комментарий от Aceler

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

gns ★★★★★
()
Последнее исправление: gns (всего исправлений: 1)
Ответ на: комментарий от vbr

Для 99% инсталляций его хватит, а 1% пускай заменяют его на оригинальный pam.

s/pam/systemd/g :)

Аутентификация об домен — это весь корпоративный сектор, например. Там не 1%

gns ★★★★★
()
Ответ на: комментарий от vbr

Хотя, полагаю, можно и может быть даже полезно было бы сделать какой-нибудь simple-pam, как бесшовную замену оригинальному проекту, в котором убрать все эти возможности и поддерживать лишь обычный passwd и shadow. Для 99% инсталляций его хватит, а 1% пускай заменяют его на оригинальный pam.

1% инсталляций, вносящие куда-то там средства, хотят чтобы те 99% тестировали нужные им (1%) подсистемы, даже если тем 99% эти подсистемы не нужны. Поэтому будут присовывать всё равно.

А так то при локальных аккаунтах pam вообще не нужен. И никакие simple-pam тоже не нужны. Нужен только парсер /etc/passwd и подобного (оно в libc вроде и так) и сисколлы setuid() setgid() setgroups(). У openssh в конфиге например есть опция UsePAM, туда можно поставить no (что я всегда и делаю).

firkax ★★★★★
()
Ответ на: комментарий от gns

Просто я привык обсуждать новость в комментах к новости ;-)

zabbal ★★★★☆
()
Ответ на: комментарий от LightDiver

А ты переходи на нормальный zsh и потом вместе поржом над этими неудачниками

Пробовал zsh, но там блокирующая проблема в форме реакции на Home/End, которые с разными кодами, захожу я локально или удаленно. Вот как это можно было испортить??

sarumeister
()
Последнее исправление: sarumeister (всего исправлений: 1)
Ответ на: комментарий от gns

s/pam/systemd/g :)

Не вполне согласен. Возможности systemd нужны в любой инсталляции. Возможности pam не нужны в любой инсталляции.

Аутентификация об домен — это весь корпоративный сектор, например. Там не 1%

Не знаю, что такое корпоративный сектор, я за 20 лет ни разу не сталкивался с этими вашими доменами. Где-то может и есть, конечно.

vbr ★★★★★
()
Ответ на: комментарий от firkax

А так то при локальных аккаунтах pam вообще не нужен. И никакие simple-pam тоже не нужны. Нужен только парсер /etc/passwd и подобного (оно в libc вроде и так) и сисколлы setuid() setgid() setgroups(). У openssh в конфиге например есть опция UsePAM, туда можно поставить no (что я всегда и делаю).

Тебе нужен парсер passwd и shadow по минимуму. Потому, что в системе не так мало программ, которые запрашивают пароль пользователя. Этот парсер логично оформить в библиотечном коде и в glibc его явно нет. Вот и получается тот самый simple-pam. API-то логично оставить тем же, что в PAM, чтобы в каждом chfn, chpasswd и тд не писать #ifdef-ами поддержку разных API. Если его вкомпилировать статически (ну или накопипастить), получится последняя опция в моём посте.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 2)
Ответ на: комментарий от Bfgeshka

вот а нафигп делали «стек» в такой базовой функции, как логин?

Потому что надо гонять разные переменные и параметры ядра в зависимости от авторизации. Стандартная авторизация кроме параметров из /etc/passwd ничего не знает и в ядре не выставляет.

Shadow ★★★★★
()

Норм, собираю подобную информацию. Осталось только найти сабж в живом виде.

sparkie ★★★★★
()
Ответ на: комментарий от vbr

Возможности systemd нужны в любой инсталляции.

В любой инсталляции человек обычно не замечает чем и как поднято его окружение. Если оно работает :) Всякие там coredumpctl не всем нужны.

Где-то может и есть, конечно.

Много где есть. Linux вообще страдает от недостатка средств централизованного управления.

gns ★★★★★
()
Последнее исправление: gns (всего исправлений: 1)
Ответ на: комментарий от gns

В любой инсталляции человек обычно не замечает чем и как поднято его окружение. Если оно работает :) Всякие там coredumpctl не всем нужны.

Не, если кто-то запилит systemd-lite, который будет поддерживать синтаксис .service файлов, логгировать всё в текстовые файлы, и тд и тп, т.е. будет являться drop-in заменой systemd для тех самых 99% случаев, то я бы такой проект счёл весьма полезным. systemv init такой заменой, конечно, не является, т.к. требует переработки всех .service-файлов в sh аналоги.

Но просто тут scope куда серьёзней, чем просто написать минимально-достаточную реализацию PAM API. Поэтому такое вряд ли появится.

vbr ★★★★★
()
Ответ на: комментарий от vbr

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

gns ★★★★★
()
Ответ на: комментарий от cdtemp

Понятия не имею - надо спрашивать тех кто этим убожеством до сих пор пользуется. Если они ещё не все от старости умерли.

zabbal ★★★★☆
()
Ответ на: комментарий от vbr

Тебе нужен парсер passwd и shadow по минимуму.

Этот парсер логично оформить в библиотечном коде и в glibc его явно нет.

Парсер passwd в glibc есть, man getpwent. Для shadow, вероятно, нет. Надо посмотреть как в openssh сделано.

Вот и получается тот самый simple-pam. API-то логично оставить тем же, что в PAM

Парсер shadow - это не pam. Там буквально две функции нужны - поставить юзеру пароль и проверить пароль на правильность. Всё остальное либо есть в glibc либо обычно ненужно.

firkax ★★★★★
()

чет пахнуло цру. помните ту историю с бэкдором црушников в ссх для бсд?

bernd ★★★★★
()

Раскажите слоупоку а как его получить? Pam на то и Pam, что модульный, это ж надо его поставить , а потом еще и в /etc/pam.d в нужные места в нужном стеке засунуть

Zlogene ★★
()
Ответ на: комментарий от zabbal

Более чем наглядная иллюстрация того почему бинарные PAM модули это абсолютное зло. Локальная аутентификация никогда не бывает бутылочным горлышком производительности - там нечего и не за чем оптимизировать и пихать бинарщину: скриптового языка (причём не обязательно тьюринг-полного) хватит за глаза.

Да-да, наверное поэтому Polkit оказался такой какахой. (%

mord0d ★★★★★
()
Ответ на: комментарий от gns

Не тот же, он у нас свой и не совместим с линуксовым даже форматом конфигов (не говоря уже о совершенно разных кодовых базах).

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

По API для модулей, насколько я помню, совпадает.

gns ★★★★★
()
Ответ на: комментарий от LightDiver

переходи на нормальный zsh

Где скачать? :-)

Ecl
()
Ответ на: комментарий от firkax

Да нет, это всего лишь обычный троян.

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

И чтобы его установить, нужны рут права.

… или же очередная дырень, кои постоянно появляются, так что недостатка в этом нет.

(которые на самом деле дефолтные способы работы троянов) очевидно сочинено маркетологом.

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

anonmyous ★★
()
Последнее исправление: anonmyous (всего исправлений: 1)
Ответ на: комментарий от anonmyous

Да нет, это просто ты домохозяйка, которая не имеет ни малейшего представления о том, как работают обычные вирусы и как с ними положено бороться. Повторю, это обычный троян. А лечить заражения со скомпрометированным рутом «переустановкой пакетов» и вообще какими бы то ни было действиями изнутри системы будут пытаться опять только домохозяйки, подобные тебе. Так что лучше не пиши ничего тут больше.

firkax ★★★★★
()
Ответ на: комментарий от firkax

как работают обычные вирусы и как с ними положено бороться.

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

А лечить заражения со скомпрометированным рутом «переустановкой пакетов»

Хватит разговаривать с самим собой. Никто не говорил, что его надо так лечить - говорили лишь, что его это не убирает, даже если пакет, при переустановке, заменил какие-либо файлы, где этот вирус сидел. Помимо этого, говорили, что его нельзя ОБНАРУЖИТЬ, как изнутри, так, в общем то, и из вне. Но это вы предпочли вообще проигнорить…

Так что лучше не пиши ничего тут больше.

Чего и вам желаю. :)

anonmyous ★★
()

Прочитал и не понял, а что должно заставить лоров-ца установить себе модуль этот Plague? Или его все засунули в свои дистрибутивы не глядя и не разбираясь что это за модуль? Тогда что заставило засунуть этот модуль дистрибутиво строителей в свои дистрибутивы?

Вот про это вообще ничего не написано.

Vic
()
Последнее исправление: Vic (всего исправлений: 3)
Ответ на: комментарий от Vic

Прочитал и не понял, а что должно заставить лоров-ца установить себе модуль этот Plague?

Как всегда. Типовая новость про «Стррашный Вирус В Этом Вашем Линухе, Не То, Что Наша Ынтырпрайзнав Винда, Где Очень Ынтырпрайзный Антивирус и Врагнипрайдёт!».

А потом где-нибудь мелким шрифтом - «одмин не закрыл в SSH парольный доступ и оставил пароль 123», «на поражённых системах была лохматая версия sshd с CVE-***» и т.п.

redeyedanonymous
()
Ответ на: комментарий от s21mos

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

firkax ★★★★★
()
Ответ на: комментарий от firkax

Ну повтори и в третий раз тогда, что модуль PAM и «любой бинарник» это совершенно одно и то же, что любой протрояненный бинарник может воровать логины и пароли пользователей, что любой бинарник переживет обновление содержащего его пакета… Повторяй это чаще, может для самого себя ты и начнешь звучать убедительно.

s21mos
()
Ответ на: комментарий от s21mos

Кого троянить - выбирает автор трояна (учитывая, разумеется, наличие прав на запись в нужный файл). Если рутовых прав нет, то троянить можно исполняемые файлы, расположенные у юзера в $HOME и иногда ещё что-нить доступное. Такие трояны элементарно вычищаются с помощью захода от рута (но не через su или его клоны! через них троян может перехватить логин и получить рут права вместо тебя, логиниться надо сначала полностью разлогинившись и убедившись что логин/пасс у тебя спрашивает системное приложение).

Если же у установщика трояна были полноценные рут-права, то прописаться он может куда угодно, и прога-жертва практически никак на это повлиять не может (PAM это или что-то другое - не существенно, главное чтобы оно вовремя запускалось и запускало троян). И любые твои попытки его удалить, находясь в той же системе (т.е. под полным его контролем), он прекрасно может пресечь, вне зависимости от того откуда он запустился (главное - что от рута). Таким образом, самое меньшее, что нужно делать при обнаружении у себя вируса с рут-правами - это выключение компа, перетыкивание диска в другой (но так чтобы случайно с него не запуститься) и там уже его препарирование из чистой системы. В худшем же случае он пропишется вовсе не в файловую систему, а куда-нить в биос или например в прошивку жёсткого диска, откуда ты его уже никогда скорее всего не удалишь. Но, к счастью, такое пока что всё-таки требует особой компетенции авторов и встречается редко.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.