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

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

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

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

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

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

Монтируем образ диска

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

Файл обра­за дис­ка 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=6 соот­ветс­тву­ет алго­рит­му хеширо­вания SHA-512. Поп­робуй сам ско­пиро­вать выделен­ную на рисун­ке стро­ку хеша пароля поль­зовате­ля mail и проб­рутить его ути­литой John the Ripper со сло­варем 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. Ана­лиз этих фай­лов и сопос­тавле­ние со вре­менем начала инци­ден­та поз­волит нам вос­ста­новить пол­ную кар­тину событий.