Хакеры спрятали бэкдор прямо в Linux-аутентификации

Sygnia опубликовала расследование Operation Highland — инцидента, где следы активности Velvet Ant в сети жертвы уходят к 2016 году. Речь о почти десятилетнем присутствии в чувствительной инфраструктуре.

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

Главная техническая особенность атаки — подмена доверенных компонентов входа. Вместо отдельного трояна, который можно найти как лишний процесс или файл, злоумышленники модифицировали сам механизм аутентификации Linux, внедряя бэкдоры в модули Linux PAM и бинарные файлы OpenSSH.

PAM, или Pluggable Authentication Modules, — это подсистема, через которую Linux-сервисы проверяют пользователя при входе. pam_unix.so — один из базовых модулей, участвующих в проверке логина и пароля.

OpenSSH — стандартный набор инструментов для удаленного доступа к Linux-серверам. В него входят ssh, sshd, scp, sftp и другие компоненты.

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

Sygnia нашла девять вариантов модифицированного pam_unix.so. Они собраны в разных средах, что указывает на подготовленный процесс сборки под разные системы.

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

В одном из описанных вариантов модуль сохранял введенные учетные данные в скрытый файл /usr/sbin/.ssh.log. Для защиты от лишних следов отдельные строки могли не дублироваться. После обхода аутентификации вредоносный модуль затирал в памяти строку с бэкдор-паролем, чтобы усложнить анализ.

Атакующие также подменяли компоненты OpenSSH. Sygnia описывает модифицированные версии ssh, sshd и scp, а в одном наборе также фигурировал ssh-keygen.

Новые варианты ssh и sshd собирали учетные данные при входящих и исходящих подключениях. Данные сохранялись в зашифрованном виде, например в файле /usr/share/man9/ph/.ph.man. В записях были признаки направления подключения, типа аутентификации, успешности входа, пользователя, адреса и пароля.

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

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

Изоляция критического сегмента осложнила атаку, но не остановила ее. Sygnia описывает многоступенчатую цепочку.

Сначала Velvet Ant закрепилась на интернет-доступных серверах. Для удаленного управления использовалась модифицированная версия GS-Netcat, замаскированная под системную утилиту auditdb и размещенная в /usr/sbin/. Для автозапуска использовались unit-файлы systemd, замаскированные под сервисы Chrome, а на старых системах — изменения в скриптах SysVinit.

Для перемещения внутри сети использовался SOCKS5-прокси на Perl. Он работал как фоновый процесс и маскировался под обычные системные процессы, например smbd -D.

Дальше атакующие использовали Nginx и FastCGI как мост. Измененные конфигурации Nginx направляли специальные HTTP-запросы на бэкенд, где FastCGI-обёртка запускала кастомный бинарник. Тот устанавливал SSH-соединение уже в сторону критического сегмента. Так внешний HTTP-запрос превращался в канал выполнения действий внутри сети, которая не имела прямого интернет-доступа.

Sygnia отмечает: ротацию учетных данных нужно было проводить только после удаления механизма перехвата. Иначе новые пароли будут собраны тем же модифицированным pam_unix.so, ssh или sshd.

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

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

В атаке не было одного яркого признака вроде массового шифрования файлов или шумной эксплуатации известной уязвимости. Злоумышленники изменили компоненты, которые и так есть почти на каждом Linux-сервере. Такой тип закрепления плохо ловится сигнатурами. Вредоносный файл может называться как легитимный, лежать в ожидаемом каталоге и выполнять настоящие функции. Отличие находится внутри бинарника и в поведении, которое не всегда видно обычному мониторингу.

Администраторам Linux стоит проверить целостность компонентов аутентификации. Критичны pam_unix.so, конфигурации /etc/pam.d/, бинарные файлы OpenSSH (ssh, sshd, scp, sftp, ssh-keygen), sshd_config, привилегированные authorized_keys, systemd unit-файлы и старые init-скрипты.

Проверять нужно не только наличие файлов, но и их соответствие доверенному источнику: пакетам дистрибутива, эталонным хешам, чистым образам, внутреннему репозиторию. Для чувствительных систем полезен контроль целостности файлов, который отправляет события во внешнюю систему журналирования.

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

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