Статья Уроки форензики. Расследуем взлом веб-сервера с Linux, Apache и Drupal

[tabac]

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

По сценарию злоумышленники взломали веб‑сервер и завладели полным контролем над ним. Специалисты по реагированию на инциденты получили побитовую копию системного диска скомпрометированной машины на базе операционной системы Linux. Загрузим файл образа и начнем его исследовать.

Разделим наше расследование на три этапа:

1. Анализ конфигурационных файлов операционной системы Linux.
2. Поиск точки входа злоумышленников в систему.
3. Поиск методов постэксплуатации в системе.

Используемые утилиты:

1. FTK Imager — инструмент для анализа и получения образов диска.
2. R-Studio — утилита для восстановления данных с диска.
3. Plaso — утилита на Python, предназначенная для генерации времени событий операционной системы.

МОНТИРУЕМ ОБРАЗ ДИСКА​

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

file  Webserver.E01

Файл образа диска Webserver.E01 записан в формате Expert Witness Format (EWF) и содержит побитовую копию данных. Сконвертировать его в цифровую копию диска можно с помощью утилиты EnCase.

Полученный образ диска можешь примонтировать в Linux — для этого ставь утилиты lvm2, ewf-tools, sleuthkit, kpartx и воспользуйся мануалом. Но я покажу другой вариант. Примонтируем исследуемый диск в Windows и извлечем из него необходимые артефакты для расследования инцидента.

Откроем утилиту FTK Imager и примонтируем образ диска. Для этого переходим на вкладку File → Image Mounting. В поле Image File выбираем образ Webserver.e01 и вводим настройки, указанные ниже.

Нажимаем Mount, и исследуемый образ должен примонтироваться. Мы увидим следующую информацию.

Теперь открываем R-Studio и видим примонтированные виртуальные диски.

Нас интересует диск Virtual Storage 1.00 → F, так как его ФС — ext4. Далее выбираем диск F и нажимаем «Сканировать». Утилита R-Studio начнет сканировать адресное пространство диска и искать в нем все файлы, в том числе удаленные. После завершения сканирования переходим в диск F в интерфейсе R-Studio и получим все каталоги и файлы файловой системы.

ИЗУЧАЕМ КОНФИГИ ОС​

Получим информацию о системе, чтобы понимать, какие сервисы установлены, с какой операционной системой работаем и какие пользователи существуют. Эта информация расположена в каталоге /etc файловой системы Linux. Информацию об имени компьютера ты найдешь в файле /etc/hostname (в нашем случае это VulnOSv2). В файле /etc/os-release содержится информация об операционной системе (Ubuntu версии 14.04.4 LTS).

В файле /etc/networks/interfaces хранится сетевой адрес, но в нашем случае для получения IP-адреса в сети организации используется протокол DHCP. В каталоге /etc я обнаружил следующее установленное ПО: Drupal 7, веб‑сервер Apache 2, СУБД MySQL и PostgreSQL, а также почтовый сервис Postfix.

Проанализируем информацию о пользователях. Нас интересуют файлы /etc/passwd и /etc/shadow.

/etc/passwd содержит информацию о пользователях системы: имя пользователя, идентификаторы пользователя и группы, комментарий, описывающий аккаунт, путь к домашнему каталогу и программа, которая каждый раз запускается при входе пользователя в систему. Нас интересуют пользователи, которые могут запускать командную оболочку /bin/bash при входе в систему. Таких пользователей пять: root, mail, php, vulnosadmin и postgres.

В файле /etc/shadow хранятся хешированные пароли пользователей. Доступ к этому файлу имеет только привилегированный аккаунт.

Формат хеша пользовательского пароля:

$id$salt$hashed

Идентификатор алгоритма id=6 соответствует алгоритму хеширования SHA-512. Попробуй сам скопировать выделенную на рисунке строку хеша пароля пользователя mail и пробрутить его утилитой John the Ripper со словарем rockyou.txt:

john hash.txt --wordlist=rockyou.txt

Проанализируем файл /etc/group, чтобы понимать, какие пользователи состоят в группе sudo.

В этом файле содержится 58 групп, а в группу sudo входят пользователи php и mail. Значит, они могут выполнять команды от имени суперпользователя root. Найдем правила о предоставлении доступа для группы sudo. Они описываются в файле /etc/sudoers.

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

Определим версию и конфигурацию сайта на Drupal. Для этого переходим в каталог /var/www/html/jabc, в файле /var/www/html/jabc/includes/bootstrap.inc содержится версия CMS системы. Это Drupal 7.26 — она уязвима, и для нее есть эксплоиты, дающие удаленное выполнение кода. В качестве веб‑сервера установлен Apache 2. Файл его конфигурации расположен в /etc/drupal/7/htaccess.

Итак, на этом этапе мы с тобой выяснили, с какой операционной системой мы имеем дело, какое ПО на ней установлено и какие настройки заданы.

ИЩЕМ ТОЧКУ ВХОДА​

Теперь нам нужно понять, как злоумышленник впервые получил доступ к скомпрометированной системе. Для этого проанализируем логи ОС. Все журналы событий Linux хранятся в каталоге /var/log. Анализ этих файлов и сопоставление со временем начала инцидента позволит нам восстановить полную картину событий.

Первым делом глянем события веб‑сервера Apache. Для этого заходим в каталог /var/log/Apache2. Здесь нас интересуют журналы access.log и error.log, которые содержат события работы веб‑сервера. В файле access.log содержатся запросы к сервису Drupal http://192.168.210.135/jabc/ с IP-адреса 192.168.210.131. 5 октября 2019 года в 13:01:27 (UTC+2) обнаружен POST-запрос к веб‑сервису в параметре name[#markup]. В URL запроса передается закодированная по алгоритму Base64 полезная нагрузка.

В Drupal версии 7.26 содержится уязвимость удаленного выполнения кода CVE-2018-7600, позже получившая название drupalgeddon2. В Metasploit существует модуль drupal_drupalgeddon2, который загружает расширенную многофункциональную нагрузку Meterpreter.

Давай декодируем полезную нагрузку, которая содержится в функции eval(base64_decode()), и посмотрим, что она делает.

Как видно на рисунке выше, код является полезной нагрузкой Meterpreter и содержит IP-адрес 192.168.210.131 и порт 4444 для обратного соединения. Отлично, мы теперь знаем, что злоумышленники проэксплуатировали CVE-2018-7600 в сервисе Drupal версии 7.26 и загрузили в память полезную нагрузку Meterpreter.

Теперь нам нужно найти признаки постэксплуатации. 5 октября 2019 года в 13:17:48 (UTC+2) обнаружен запрос к файлу update.php c параметром cmd=ls.

Этот файл мы исследуем чуть позже, а пока заглянем в auth.log в каталоге /var/log. Это один из самых важных артефактов в Linux. Здесь лежат события аутентификации в системе. Для временных отметок в auth.log используется системное время. В нашем случае временная зона выставлена по Брюсселю (UTC+2).

Начиная с 12:39:26 5 октября 2019 года выполнялся подбор пароля пользователя root службы SSH с IP-адреса 192.168.210.131.

В 13:06:38 в тот же день создан пользователь php с домашней директорией /usr/php. Далее пользователь php добавлен в группу sudo, что позволяет ему выполнять команды от имени администратора.

В 13:09:18 пользователь mail добавлен в группу sudo.

В 13:23:34 пользователь mail зашел c IP-адреса 192.168.210.131, порт 57708 службы SSH.

Эта сессия длилась одну минуту.

Файл /var/log/syslog содержит общие системные сообщения. В частности, в нем можно видеть запросы к серверу DHCP и получение IP-адреса: сервер 192.168.210.254 выделил IP-адрес исследуемому компьютеру 192.168.210.135.

Теперь заглянем в /var/log/lastlog — этот файл содержит информацию о последних сессиях пользователей. Находим два IP-адреса, с которых производилась авторизация в системе.

И наконец, смотрим /var/log/wtmp, этот файл тоже содержит информацию о входе пользователей в систему. Однако он бинарный, поэтому для его чтения используем утилиту utmpdump.

utmpdump wtmp

Файл /var/log/btmp содержит информацию о неудачных попытках входа в систему. Для его чтения также воспользуемся утилитой utmpdump:

utmpdump btmp

В этом файле находим следы попыток неудачного входа пользователя root c IP-адреса 192.168.210.131. Происходит подбор пароля к службе SSH.

Итак, на этом этапе мы с тобой нашли точку входа злоумышленников в систему. 5 октября 2019 года в 13:01:27 (UTC+2) злоумышленники эксплуатировали уязвимость drupalgeddon2 (CVE-2018-7600) в CMS Drupal версии 7.26. Создали пользователя php, добавили пользователей php и mail в группу sudo. Далее авторизовались в системе от пользователя mail. Мы также выяснили, что источником компьютерной атаки был IP-адрес 192.168.210.131.

ИЩЕМ МЕТОДЫ ПОСТЭКСПЛУАТАЦИИ​

Получив доступ к системе, злоумышленник обычно ищет способы закрепиться в ней. Проанализируем действия пользователей root, php и mail, чтобы понять, как это происходило. Информация о выполненных командах хранится в файле .bash_history домашнего каталога каждого пользователя. Действия пользователя root хранятся в файле /root/.bash_history.

От пользователя root выполнены следующие интересные команды:

• rm 37282.c — удаление файла 37282.c;
• vim scripts/update.php — создание файла.

Переходим к пользователю mail.

Пользователь mail выполнил команду sudo su - с целью повышения привилегий, а затем passwd php — для смены пароля пользователя php.

Восстанавливаем стертый файл​

Мы с тобой просканировали виртуальный диск с помощью R-Studio. Теперь найдем стертый файл 37282.c. В R-Studio переходим на вкладку «Инструменты → Найти», выбираем «Файлы» и вводим название файла.

В каталоге /tmp обнаружен файл 37282.c, восстановим его и проанализируем.

Файл создан 5 октября 2019 года в 14:02:18 (UTC+3). Имей в виду, что R-Studio отображает временную метку файлов с учетом твоего системного времени.

Восстановленный файл — это эксплоит для уязвимости CVE-2015-1328, который позволяет локальным пользователям получить root-доступ. Автор его — rebel.

Найдем файл /var/www/html/jabc/scripts/update.php.

5 октября 2019 года в 14:17:48 (UTC+3) злоумышленники создали файл update.php.

Это PHP-шелл, который позволяет получать доступ к системе на постоянной основе. Для выполнения команд злоумышленники отправляют GET-запрос с параметром cmd=.

СТРОИМ ТАЙМЛАЙН СОБЫТИЙ​

У нас накопилось множество временных меток в разных форматах. Системное время операционной системы — Europe/Brussels. Во многих европейских странах остался переход с летнего времени на зимнее. Переход совершается 31 октября. Если события происходят до 31 октября, то формат будет UTC+2 — это летнее время, а после 31 октября — UTC+1. Приведем к общему формату UTC.

• 5 октября 2019 года 11:01:27 злоумышленники проэксплуатировали уязвимость CVE-2018-7600 в CMS Drupal версии 7.26, загрузили оболочку Meterpreter.
• В 11:02:18 загрузили файл 37282.c, скомпилировали систему и повысили свои привилегии до root.
• В 11:06:38 создали пользователя php и добавили его в группу sudo.
• В 11:09:31 добавили пользователя mail в группу sudo.
• В 11:17:48 создали файл update.php с целью сохранения постоянства в системе.
• В 11:23:34 авторизовались в системе под пользователем mail c IP-адреса 192.168.210.131, порт 57708.

Для создания таймлайнов удобно использовать Plaso. Там есть очень удобный скрипт Psteal, который умеет извлекать события из образа диска системы. Вот как его использовать:

python3 psteal.py --source Webserver.E01 -w timeline.csv

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

ВЫВОДЫ​

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

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

Автор rayhunt454
xakep.ru

 

[malderbek]

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