Тайна Duqu: часть шестая

В последние несколько недель мы занимались исследованием инфраструктуры серверов управления, используемых Duqu.

Широко известен факт, что первоначально обнаруженные образцы Duqu использовали C&C в Индии, размещенный на площадке хостинговой компании WebWerks. Впоследствии был выявлен еще один сервер Duqu — базирующийся в Бельгии, у хостера Combell Group Nv.

«Лаборатория Касперского» в настоящий момент обнаружила более 12 различных вариантов Duqu. Среди них есть те, которые соединялись с серверами в Индии, в Бельгии, но также и с другими серверами — двумя во Вьетнаме и одним в Голландии. Кроме них, много других серверов были использованы авторами Duqu в организации всей сетевой инфраструктуры. Некоторые их них использовались как основные прокси-сервера, другие были предназначены для скрытия следов.

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

Прежде чем продолжить рассказ, мы должны сказать, что мы все еще не знаем, кто стоит за Duqu и Stuxnet. Хотя нам удалось захватить и проанализировать некоторые из серверов, атакующим удалось замести свои следы достаточно эффективно. 20 октября 2011 года, спустя три дня после публичного оглашения информации об обнаружении Duqu, они провели крупную операцию по «зачистке». Атакующие очистили каждый сервер, который они использовали как минимум с 2009 — в Индии, Вьетнаме, Германии, Великобритании и так далее. Тем не менее, несмотря на эту массовую акцию по скрытию следов, мы все же можем пролить некоторый свет на то, как работала сеть Duqu.

Server «A» — Вьетнам

Server «A» был расположен во Вьетнаме и использовался для управления одним из вариантов Duqu, обнаруженном нами в Иране. Это был Linux сервер, работающий под управлением CentOS 5.5. Интересно, что все C&C Duqu, которые были нами найдены, работали именно под CentOS — версий 5.2, 5.4 или 5.5. Мы не знаем, является ли это просто совпадением или атакующие имели особую тягу (эксплойт?) к CentOS 5.x.

Когда мы приступили к анализу образа диска сервера, первое что мы обнаружили, это что «root» каталог и каталог системных логов «/var/log/» имеют признак модификации 2011-10-20 18:07:28 (UTC+3).

Тем не менее, обе папки были практически пусты. Несмотря на изменение даты / времени у корневого каталога, в нём не было файлов, которые были изменены хотя бы приблизительно близко к этой дате. Это указывает на то, что определенная операция (вероятно удаление / очистка) была совершена 20 октября, примерно в 18:07:28 GMT+3 (22:07:28 Hanoi time).

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

Использовав брутфорс-сканирование slack (неиспользуемого) space в разделе «/», нам удалось восстановить части файла sshd.log. Это было довольно неожиданно и это отличный урок о работе Linux и устройстве файловой системы ext3; удаление файла не означает того, что не останется никаких следов или кусков файлов из прошлого. Причиной этого является то, что Linux постоянно перераспределяет часто используемые файлы для уменьшения дефрагментации. Благодаря этому можно найти части старых версий файлов, даже если они были тщательно удалены.

Как можно увидеть из приведенного выше лога, пользователь root дважды входил в систему с одного и того же IP-адреса 19 июля и 20 октября. Последний логин очень близок к времени модификации корневого каталога, что указывает, что именно этот человек осуществил очистку системы — бинго!

Итак, что же конкретно делал данный сервер? Мы не могли ответить на этот вопрос, пока не проанализировали Server «B» (читайте ниже). Тем не менее, и здесь мы нашли еще кое-что интересное. 15 февраля 2011 года исходные коды openssh-5.8p1 были загружены на сервер и установлены в систему. Это был пакет «openssh_5.8p1-4ubuntu1.debian.tar.gz» с MD5 86f5e1c23b4c4845f23b9b7b493fb53d (stock distribution). Мы можем предположить, что ранее на сервере работал openssh-4.3p1, включенный в оригинальный дистрибутив CentOS 5.2.

19 июля 2011 года пакет OpenSSH 5.8p2 был скопирован в систему. Он был скомпилирован, и бинарные файлы располагались в /usr/local/sbin). Этот пакет OpenSSH также совпадает с официальным.

Дата 19 июля является важной, поскольку она указывает, когда новый OpenSSH 5.8p2 был скомпилирован в системе. Сразу после этого атакующие зашли в систему, возможно для проверки того, что всё работает, как следует.

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

Для этого нашего конкретного сервера, некоторые пики сразу вызывают подозрения: 15 февраля и 19 июля, когда устанавливались новые версии OpenSSH; 20 октября, когда была произведена очистка сервера. Кроме того, мы видим пики 10 февраля и 3 апреля, когда происходили еще какие-то действия. Мы обнаружили несколько падений сервиса «dovecot» в те дни, хотя мы не можем быть уверены в том, что они были вызваны действиями атакующих («dovecot» remote exploit?) или просто нестабильностью работы.

Конечно, для сервера «A» остаются без ответа три важных вопроса:

• Как изначально атакующие смогли получить доступ к серверу?
• Для чего конкретно использовался данный сервер?
• Почему атакующие заменили стандартный OpenSSH 4.3 на версию 5.8?

Мы ответим на некоторые из этих вопросов в конце.

Server «B» — Германия

Этот сервер находился в немецком дата-центре и принадлежал болгарской хостинговой компании. Именно он использовался атакующими для подключения к вышеописанному вьетнамскому C2. Данные также указывают на то, что он также использовался как C2-сервер Duqu в прошлом, хотя мы не смогли обнаружить конкретный вариант Duqu, который с ним работал.

Так же, как и сервер в Вьетнаме, этот был тщательно очищен 20 октября 2011 года. Каталоги «root» и «etc» имеют временные метки об удалении/модификации данных в эту дату. Сразу же после того, как была произведена очистка, атакующий перезагрузил сервер и снова вошел в систему для того, чтобы убедиться, что все улики и следы были удалены.

Снова при помощи сканирования slack space в разделе «/» мы смогли восстановить части файла sshd.log. Вот некоторые из важных записей оттуда:

Прежде всего, дата — 18 ноября. К сожалению, sshd.log не содержит год события. Из-за этого мы не можем быть уверены, был это 2010 или 2009 год (но, мы точно знаем, что это не был 2011). Однако, тем не менее, нам удалось найти другой лог-файл, который указывает, что эти события датированы 2009 годом:

То, что вы видите выше — это фрагмент logwatch-записи, которая указывает дату ошибки, которая произошла 23 ноября 2009, когда пользователь root подключился с того же IP-адреса, который мы видели 19 ноября в sshd.log.

Два других сообщения также крайне важны — это ошибки в sshd, показывающие что при попытках перенаправления трафика для портов 80 и 443, они уже были заняты. Таким образом, мы знаем, как эти сервера использовались — это были прокси, которые перенаправляли при помощи sshd все запросы на порты 80/443 на настоящий сервер атакующих, местоположение которого остается неизвестным.

Полная картина схемы работы выглядит примерно так:

Отвечая на вопросы

Итак, как же эти серверы были взломаны первоначально? Одной сумасшедшей идеей является теория о существовании 0-day уязвимости в OpenSSH 4.3. При поиске «openssh 4.3 0-day» в Google можно найти несколько очень интересных ссылок. Вот одна из них:

Пост от пользователя jon-f, датированный 2009 годом, указывает о возможном 0-day в OpenSSH 4.3 для CentOS; он даже опубликовал некоторые логи работы эксплойта — впрочем, они зашифрованы и крайне тяжело анализируются.

Может ли это быть нашим случаем? Зная Duqu-группу и их бесконечный набор 0-day эксплойтов, означает ли это, что у них также есть Linux 0-day против OpenSSH 4.3? К сожалению, мы не знаем этого.

Если мы посмотрим на sshd.log от 18 ноября 2009 года, мы можем получить некоторые интересные намёки. Пользователь root, с IP-адреса в Сингапуре, пытался войти в систему несколько раз, пока, наконец, ему это удалось:

Обратите внимание, как пользователь root пытается войти в 15:21:11, несколько раз не может и спустя 8 минут 42 секунды успешно входит в систему. Это больше похоже на попытки подбора пароля, чем на использование 0-day. Вероятно, root пароль все-таки был взломан.

Тем не менее, остается третий вопрос: Почему атакующие заменяли OpenSSH 4.3 на версию 5.8? На сервере в Германии мы смогли восстановить части файла .bash_history, в которых видны события сразу после «взлома» сервера:

Интересными являются команды «yum install openssh5», а затем «yum update openssh-server». Видно, что практически сразу они пытались установить другой пакет. У них должна была быть очень веская причина так беспокоиться о замене OpenSSH 4.3 на версию 5.

Кстати, мы видим, что атакующие не очень хорошо знакомы с командой iptables и синтаксисом командной строки. Кроме того, они не очень уверены в формате sshd_config, так что им приходится открыть руководство по нему («man sshd_config»). То же самое им приходится делать потом еще и для стандартного FTP-клиента Linux.

Выводы

В настоящее время мы захватили и проанализировали только часть из всех известных C&C-серверов Duqu. Тем не менее, мы установили важные факты о том, как работала их инфраструктура:

1. C&C-серверы Duqu работали, как минимум, с ноября 2009 года.
2. Много серверов было взломано по всему миру, во Вьетнаме, Индии, Германии, Сингапуре, Швейцарии, Великобритании, Голландии, Южной Корее и так далее. Большинство взломанных систем работали под управлением CentOS Linux. Взломанные системы были как 32-битными, так и 64-битными.
3. Серверы, вероятно, были взломаны путем брутфорса пароля администратора (мы не верим в теорию существования 0-day в OpenSSH 4.3, это было бы слишком ужасно).
4. Атакующие испытывают странную тягу к замене OpenSSH 4.3 на версию 5, сразу же как только они получают контроль над сервером.
5. Глобальная операция по «зачистке» состоялась 20 октября 2011 года. Атакующие очистили каждый из серверов, которые они использовали долгое время. К несчастью, самый интересный сервер в Индии, был очищен всего лишь за несколько часов до того, как хостинговая компания согласилась сделать образ диска. Если бы образ был сделан чуть раньше, мы бы обладали гораздо большей информацией.
6. Настоящий сервер управления Duqu остается неизвестным, так же как и личности атакующих.

Мы также хотим спросить у администраторов Linux и экспертов в OpenSSH — почему необходимо обновлять OpenSSH 4.3 до версии 5.8, как только вы взломали машину с работающей версией 4.3? Что делает версия 5.8 такого особенного по сравнению с 4.3?

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

«Лаборатория Касперского» благодарит компании PA Vietnam, Nara Syst и болгарскую киберполицию (CyberCrime unit) за их неоценимую помощь в этом расследовании. Все это было бы невозможно без их поддержки и усилий.