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

https://t.me/hacker_frei

rayhunt454 

Содержание статьи

• Монтируем образ диска
• Изучаем конфиги ОС
• Ищем точку входа
• Ищем методы постэксплуатации
• Восстанавливаем стертый файл
• Строим таймлайн событий
• Выводы

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

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

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

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

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

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

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

Преж­де чем начать извле­кать дан­ные из обра­за дис­ка, давай раз­берем­ся, с каким обра­зом мы име­ем дело и как его пра­виль­но ана­лизи­ровать. Для это­го вос­поль­зуем­ся ути­литой 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.

INFO

О том, как работа­ет эта уяз­вимость, читай в статье «Дру­пал­геддон-2. Под­робно раз­бира­ем новую уяз­вимость в Drupal».

Да­вай декоди­руем полез­ную наг­рузку, которая содер­жится в фун­кции 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 необ­ходимо отве­тить на ряд воп­росов, но я намерен­но показал лишь про­цесс решения и не буду давать тебе готовые отве­ты. Можешь пов­торить про­цесс и самос­тоятель­но отве­тить на воп­росы для зак­репле­ния матери­ала.

Читайте ещё больше платных статей бесплатно: https://t.me/hacker_frei