Форензик кейс взлома серверов под управлением Linux

В этой статье мы детально разбираем большой кейс с атакой на целую ферму машин под управлением Linux. Нас ждет взлом веб-сервера, заражение майнером, эскалация root из виртуального контейнера и создание ячейки ботнета, которая рассылала спам. Уже не терпится узнать подробности? Тогда поехали!

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

• Как сделать дамп оперативной памяти в Linux
• Как снять образ жесткого диска в Linux
• Дамп сетевого трафика в Linux
• Дистрибутивы для криминалистического анализа
• Как взламывали Сбербанк

Предыстория инцидента

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

Меня попросили помочь разобраться в аномальном поведении администрируемых заказчиком систем и выявить причины. Если же обнаружатся факты взлома — пресечь каналы несанкционированного доступа и обезопасить хостера от повторных атак.

Сами серверы находились в дата-центре, поэтому вопрос о физическом несанкционированном доступе однозначно снимался.

Вот основные жалобы, с которыми обратился заказчик:

• ОС и отдельные демоны работали нестабильно, система часто спонтанно перезагружалась, в syslog шло много критичных ошибок, не зависящих от действий системного администратора;
• часто сменялись пики и падения на графиках загрузки ввода-вывода и сетевого трафика;
• IP-адреса из выделенного пула часто попадали в черные списки;
• при работе легитимных администраторов с системой соединение SSL часто обрывалось по разным сценариям;
• периодически сбрасывались настройки пакетного фильтра iptables на значения по умолчанию.

В работе системы наблюдались и другие, более мелкие аномалии. Причем проверки на предмет наличия вирусов и руткитов такими известными утилитами, как rkhunter, chkrootkit и ClamAV, результата не дали.

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

Все это давало основание предполагать, что причиной происходящего было сознательное вмешательство третьих лиц в работу машин.

Однако попытки самостоятельных поисков, такие как анализ журналов, безопасное конфигурирование iptables, перенос прикладных сервисов в chroot, использование длинных и сложных паролей, парсинг сетевого трафика с помощью Wireshark и подобных утилит, никаких следов хакерского взлома не выявили.

Поиск артефактов

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

Извлекаем данные из оперативной памяти

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

Как вариант, вы всегда сможете скачать и установить пакет из исходников.

После этого нам надо сгенерировать volatility profile, который зависит от версии ядра операционной системы. Чтобы не терять время зря, можно воспользоваться приложенным к статье готовым скриптом (см. врезку со скриптами ниже), который соберет профиль в автоматическим режиме.

После того как профиль сгенерирован и выбран, запуск утилиты в общем виде выглядит так:

К примеру, запуск Volatility с вызовом команды pslist для получения списка процессов будет таким:

Аналогичный результат можно получить и другой командой:

Теперь попробуем выстроить карту процессов с флагами разрешений и списком сегментов:

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

Извлечение и просмотр истории команд bash:

Наконец, проверка файловых операций с целью поиска следов возможной модификации руткитом выглядит так:

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

Анализ образа жесткого диска

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

Ниже мы будем использовать как bash-скрипты, так и нативные утилиты для сбора данных. Часть скриптов была позаимствована из замечательной книги Linux Forensics (Philip Polstra, 2015). Основная задача заключается в том, чтобы собрать необходимую информацию и экспортировать ее в отдельную базу MySQL, создавая таким образом «электронный архив цифровых доказательств».

Вспомогательные скрипты:

• create-profile.sh — скрипт для генерации volatility profile;
• get-histories.sh — поиск истории вводимых команд системной оболочки bash;
• get-logfiles.sh — сбор и каталогизация всех логов системы;
• get-logins.sh — сбор данных о фактах авторизации в ОС и неудачных попыток логона.

Поиск файлов с установленными битами SUID и SGID:

Список последних модифицированных, открытых и созданных файлов в системе:

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

И команда для дистрибутивов на основе Debian, с помощью debsums:

Поиск и просмотр скрытых файлов и директорий:

Ручной просмотр заданий сron:

Для поиска удаленных файлов, построения timeline-шкалы активности, анализа метаданных и поиска по ключевым словам отлично подойдет уже знакомая программа Autopsy из пакета The Sleuth Kit. К сожалению, в нашем случае применение Autopsy никаких значимых результатов не принесло. Что ж, тем интересней.

Поиск артефактов в PCAP-дампе

Задачей анализа было максимально подробно выяснить, какие сетевые соединения поднимались, идентифицировать порты, используемые протоколы, тип передаваемых данных, аномальные значения флагов в TCP-датаграммах. На основании этих данных можно попытаться определить вероятные факты несанкционированного подключения к C&C, DNS-туннелирования и подобной подозрительной активности.

Основные надежды в этом расследовании я связывал с Xplico. Это часть Network Forensic Analysis Tool (NFAT), большого фреймворка, предназначенного как раз для анализа сетевого трафика. Из особенностей утилиты можно отметить возможности извлечения email (протоколы POP, IMAP и SMTP), всего содержимого HTTP, данные звонков VoIP (SIP), файловых доступов FTP, TFTP и много других полезных фич. В общем, довольно крутая штука!

По умолчанию я считаю, что Xplico уже присутствует в вашей системе. Запускаем веб-интерфейс:

Далее в браузере переходим по адресу http://localhost:9876. Базовые настройки для авторизации:

Теперь создаем задание (case) и добавляем к нему комментарии. Загружаем наш файл PCAP и запускаем сессию для анализа. Потребуется некоторое время, так что можно идти пить кофе. Если парсинг прошел успешно, то мы получаем статистику и вывод в графическом режиме всех технических данных. После этого по признакам компрометации мы ищем факты «аномального» поведения.

На первый взгляд сетевой дамп выглядел хорошо. Даже слишком хорошо. А это, как вы догадываетесь, повод для первых сомнений.

Анализ артефактов, собранных с живых систем

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

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

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

Дополнительные инструменты поиска артефактов

В профилактических целях и для оценки общего состояния защищенности нашей системы был использован широко известный Nmap с плагинами NSE Vulns CVE. Он незатратен по ресурсам, прост в использовании, да еще и скорость работы впечатляет. Но для нас главное то, что Nmap эффективно показывает все проблемы с обновлениями. Удобно, что сканирование можно запустить с одной машины, указав в качестве цели отдельный хост или целую подсеть. Таким образом было найдено несколько критических уязвимостей, которые сыграли ключевую роль в этой истории.

Следующим этапом мы прогнали Loki (Simple IOC and Incident Response Scanner). Очень толковый сканер для обнаружения самых незаметных индикаторов компрометации.

Loki использует базу данных Yara и проводит поиск бинарного кода по регулярным выражениям, хеш-суммам, точкам обратной сетевой связи с C2 и тому подобным прекурсорам. С помощью Loki и одного кастомного AV-движка удалось обнаружить часть двоичного кода майнера, бинарники для создания ботнета и веб-оболочку, залитую на хакнутый веб-сервер. Ого!

Для оценки безопасности веб-сервера и его составляющих, кроме ручных проверок, применялись автоматические тесты из арсенала WASS. Конкретно в нашем случае это были w3af, Wapiti и sqlmap. Отчет показал наличие LFI-уязвимости в движке PHP, слабую защищенность конфигурации сервера Apache и вероятность дампа MySQL базы данных.

Для оценки hardening security state операционных систем Linux, работающих на серверах нашего хостинга, мы пользовались целым набором утилит аудита Linux. Для дополнительной уверенности в ход была пущена программа Tiger (The UNIX Security audit and intrusion detection tool). И, как оказалось, у многих машин hardening index едва дотягивал до 35 баллов из 100. Думаю, комментарии излишни.

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

Как это было на самом деле

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

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

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

Враг внутри

Все началось с того, что в хостинге на подставное лицо был арендован VPS под управлением CentOS 7. Как выяснилось впоследствии, установленный дистрибутив имел непропатченную уязвимость Dirty Cow, о которой можно даже почитать на отдельном сайте. Напомню, уникальность этой уязвимости заключается в том, что с помощью готовых инструментов хакер не только получает полный доступ к локальной машине, но и может выйти за пределы контейнера (если это слой визуализации) и попасть на машину-гипервизор с привилегиям суперпользователя!

Далее, вероятнее всего, преступники использовали разные утилиты постэксплуатации (к примеру, MimiPenguin) для сбора паролей от учетных записей. Как выяснилось в ходе нашего расследования, по беспечности администраторов root-пароль на всех системах был один и тот же (!). Таким образом, поломав одну машину, хакеры могли без особых усилий залогиниться на другие.

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

Помимо этого, стараясь скрыть следы своего присутствия при вероятном анализе сетевых соединений, хакеры не стали устанавливать в систему RAT. Вместо этого они завернули все свои подключения внутрь DNS-туннеля (вероятней всего, с помощью утилит, подобных Iodine или dns2tcp). Параллельно, видимо для каких-то своих целей или подстраховки, злоумышленники подняли несколько VPN-соединений на безликие серверы в азиатском регионе.

Соответственно, обладая всеми привилегиями, хакеры периодически чистили системные логи. Для этого существуют такие программы, как Wardriver Log Cleaner или Log Killer. Далее с помощью простенького, но обфусцированного скрипта на Python (библиотека Opy или ее аналог), помещенного в планировщик cron, они очищали цепочки правил iptables к состоянию «по умолчанию».

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

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

Веб под прицелом

Взлом внутреннего веб-сервера, в недрах которого была база данных клиентов и локальная CRM, оказался вторым вектором атаки, никак не связанным с эксплуатацией Dirty Cow. Если кратко, то в движке PHP была найдена LFI-уязвимость. С ней можно открыть или запустить любой файл на сервере в обход политик разграничения доступа. В результате реализации этой атаки был получен доступ к системной директории /proc/self/environ, что, по сути, служит путем к запуску любого процесса в хостовой системе, в том числе к получению доступа в /etc/passwd.

Далее, эксплуатируя непропатченное ядро Linux, злоумышленники эскалировали привилегии до суперпользователя (использовались относительно свежие уязвимости CVE-2018-1000001 и CVE-2018-1068). После этого для получения абсолютного контроля над системой хакер залил на сервер самописный SUID и с помощью модификации прав на создание, чтение и запуск локальных файлов накатил веб-оболочку под названием b374k.

Таким образом, b374k мог теперь успешно функционировать через ранее залитый SUID даже после возможного патча ядра ОС. Почувствовав себя свободнее, злоумышленники приступили к правке конфигурационных параметров веб-сервера Apache, добавили скрипты и модифицировали PHP-код некоторых страниц. В результате у них появилась возможность дампа базы данных пользователей и добавления ссылок на сторонние сайты с вирусным ПО.

Майнеры поневоле

После детального анализа дампа оперативной памяти и последовательного разбора всех системных и пользовательских процессов было обнаружено несколько «тяжелых» задач, потреблявших значительные ресурсы CPU и RAM. При этом файлы, принадлежащие этим процессам, появились относительно недавно и не соответствовали каким-либо зависимостям в установленном ПО.

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

Зомби-апокалипсис

По всей видимости, производительность оборудования и количество гигахешей злоумышленников не удовлетворили, и они решили переориентироваться на рассылку спама и проведение DoS-атак из подконтрольного ботнета. После исследования жестких дисков скомпрометированных машин на нескольких из них были обнаружены следы инструмента Ufonet, которая служит для объединения подконтрольных машин в пул для генерации DoS-трафика, а также устнаовленные версии конструктора ботнета BYOB (Build Your Own Botnet).

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

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

Этим и объясняются частые перебои с обслуживанием корпоративной почты клиентов, отказ в доставке писем и внесение IP-адресов в список спамеров и неблагонадежных ресурсов интернета.

Подводим итоги

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

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

Если нет возможности пользоваться универсальными комбайнами вроде Nessus, Nexpose или Qualys, то всегда стоит рассмотреть, может, и не такие навороченные, но вполне работоспособные open source альтернативы. Например, упомянутый Nmap с плагинами.

Кроме того, к столь печальным последствиям привело и отсутствие средств централизованного аудита ИБ и мониторинга событий. Причем даже не так важно, коммерческая ли это SIEM-система или свободное решение на базе Zabbix, ELK или OSSIM. Главное, чтобы была возможность вовремя обнаружить IoC, незамедлительно среагировать на них и оперативно приостановить развитие атаки.

Также стоит отметить халатное отношение к обеспечению базового уровня защищенности Linux-систем (в западной литературе известно как security hardening).

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

Заключение

Сегодня мы с вами размотали запутанный и серьезный форензик кейс взлома серверной фермы под управлением Linux. Вы увидели, какие утилиты используются для сбора данных, создания дампов, поиска артефактов, выявления следов хакерских инстрментов и восстановления сценария взлома. Теперь вы знаете некоторые секреты, техники и приемы, которые используют эксперты-криминалисты в своем нелегком (но интересном) труде.