SSHD-руткит в «дикой природе»

На данный момент многие говорят о SSHD-рутките, который в основном поражает Linux-дистрибутивы основанные на RPM (RPM-based дистрибутивы).

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

На данный момент мы не знаем, как начинается атака – то есть не понятно, как злоумышленник получает root-доступ к системе, который необходим для замены легитимной версии libkeyutils на троянизированную ее версию. Само собой, мы держим руку на пульсе и в случае появления новой информации о направлениях атаки непременно поделимся ей с читателями.

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

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

По завершению распаковки библиотека производит некоторые настройки, которые нужны ей для работы. Происходит разрешение имен (resolve symbols) функций, которые используются в дальнейшем: PEM_write_RSAPrivateKey, PEM_write_DSAPrivateKey, MD5_Init, MD5_Update, и MD5_Final. Как вы можете видеть, все функцию связаны с механизмом аутентификации.

Помимо разрешения имен, библиотека перехватывает (hook) следующие функции: pam_authenticate, pam_start, crypt, а также audit_log_user_message и audit_log_acct_message. Перехватив эти функции, руткит может модифицировать данные SSHD. Видно, что данный руткит работает в режиме user-mode и не влияет на ядро.

Основная функция вредоноса – сбор информации об учетных записях залогиненных пользователей. Заметьте, что руткит может получить имя пользователя, пароль, а также секретные ключи RSA и DSA, и таким образом не имеет значения, какой механизм аутентификации вы используете. Если целевой хост инфицирован, произойдет успешная кража вашей информации. Перехват функций audit_log* производится с той целью, чтобы злоумышленник оставался как можно более незаметным в системе – если атакующий использует пароль, жестко заданный внутри бэкдора, для управления им, логи действий не будут созданы.

Текущая версия руткита поддерживает три команды: Xver, Xcat и Xbnd. Xver выводит версию руткита; Xcat выводит собранную информацию в сеанс злоумышленника, а команда Xbnd позволяет злоумышленнику настраивать перехватчик (listener).

Помимо этого руткит может автоматически передавать собранные учетные записи злоумышленнику. Для этой цели во вредоносе реализован алгоритм создания доменных имен (Domain Generation Algorithm, DGA), создающий случайные доменные имена в зонах .biz, .info и .net (именно в таком порядке). Далее в случае обнаружения действующего домена, отсылается DNS-пакет, содержащий собранные учетные записи в целевой IP-адрес. Если ни один рабочий домен не обнаружен, DNS-пакет отсылается на жестко прописанный IP-адрес, который во всех случаях был одним и тем же (78.47.139.110).

Руткит очень похож на троян Ebury, который был обнаружен еще в 2011 году. На самом деле, я почти уверен, что большинство кода было скопировано оттуда, хотя Ebury патчил сам SSHD, и злоумышленнику необходимо было изменить этот файл.

Нашего «зверя» было проще детектировать и перезаписать посредством патчинга. Хотя библиотека libkeyutils, являющаяся частью пакета keyutils-libs, меняется не так часто, и, таким образом, вероятность того, что она будет автоматически перезаписана сильно ниже.

Если вы используете систему, основанную на RPM, то можете проверить целостность файла следующей rpm-командой:

# rpm -Vv keyutils-libs-1.2-1.el5
........ /lib/libkeyutils-1.2.so
S.5..... /lib/libkeyutils.so.1
........ /usr/share/doc/keyutils-libs-1.2
........ d /usr/share/doc/keyutils-libs-1.2/LICENCE.LGPL

После запуска этой команды будет выполнено множество проверок, самая важная из которых – проверка контрольной суммы MD5. Если ваша библиотека заражена, вы увидите нечто похожее на то, что показано выше. В «чистой» системе на выходе должны отображаться только точки. Помните о том, что RPM-верификация зависит от целостности базы данных пакетов и ядра.

Мы будем следить за развитием событий и по мере поступления новой информации обновлять дневник. Если у вас есть примеры SSHD-руткита или дополнительная информация, в особенности о том, как начинается атака, пожалуйста, сообщите нам об этом.

Я бы хотел еще раз поблагодарить unSpawn за поддержку SANS ISC.

Обновление:

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

Разработчики cPanel также оповестили пользователей о том, что их скомпрометировали. Еще хуже то, что, кажется, один из главных серверов cPanel также был взломан. Это означает, что злоумышленники украли *огромное количество* паролей. cPanel рекомендует поменять пароли, однако, не забывайте, если ваши сервера инфицированы, злоумышленники все равно смогут получить пароли (см. ниже). Поэтому обязательно проверьте ваш сервер и в случае обнаружения руткита удалите его.

Анализируя руткит, я заметил, что он, как и троян Ebury, использует разделяемую память для коммуникации между процессами (Стив также сообщил мне об этом). В ОС Linux вы можете проверить состояние разделяемой памяти при помощи команды ipcs:

# ipcs -m

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x7400845c 1769472 root 600 4 0
0x00000000 2129921 root 644 52 2
0x7400845b 1736706 root 600 4 0
0x00000000 2162691 root 644 16384 2
0x00000000 2195460 root 644 268 2
0x0052e2c1 2228229 postgres 600 10469376 16

Для проверки владельца используйте –p флаг:

# ipcs -mp

------ Shared Memory Creator/Last-op --------
shmid owner cpid lpid
1769472 root 1975 1975
2129921 root 2931 2940
1736706 root 1965 1965
2162691 root 2931 2940
2195460 root 2931 2940
2228229 postgres 4011 6813

Теперь вы можете проверить, взаимодействует ли SSHD с какими-либо сегментами разделяемой памяти – в нормальном состоянии не должен. Если взаимодействует, тогда вы можете более подробно проинспектировать вашу систему.

В довершении ко всему, unSpawn прописал сигнатуру в базу ClamAV (локальная сигнатура, поэтому храните ее в .ldb файле):

RKH_libkeyutils.so.1.9;Target:6;(((0)&(1)&(2))&(((3)&(4)&(5))|((6)&(7)&
(8))));636f6e6e656374;73656e64;736f636b6574;62696e64;746d7066696c65;77616974706964;646c636c6f7365;737472636174;737472637079

Это поможет обнаружению зараженных библиотек. Однако злоумышленники могут хранить библиотеки в различных директориях, поэтому используйте команду find для нахождения всех возможных копий. Например, так:

# find / -name libkeyutils*

Обновление 2:

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

Хотя руткит перехватывает функции PEM_write_RSAPrivateKey и PEM_write_RSAPrivateKey, которые выгружают секретный ключ в файл. Я не уверен, используется ли это сейчас, однако, возможно, также осуществляется перехват функций библиотек, используемых утилитой ssh-keygen. Эта утилита генерирует RSA/DSA ключи и также связана с библиотекой libkeyutils.