Расследование вторжений и ликвидация последствий

#security #forensics #russian

Однажды, на главной странице Web-сервера вашей компании может появиться надпись «pwn3ed by31337 H@x0rz Gr0uP». Что вы будете делать?

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

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

You'll hear companies say, I've never been hacked, when what they really mean is, I've never detected that I've been hacked

Bruce Schneier

Простые истины

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

Как вы узнаете о произошедшем взломе? Установлено ли на серверах вашей организации программное обеспечение контроля целостности файловой системы и файлов операционной системы? Как контролируется изменение конфигурации активного сетевого оборудования? Отработаны ли механизмы выявления незаконных подключений в сети организации?

Иногда, организации узнают о взломе их Web-серверов только из новостей. Если взлом не прошел с таким шумом, часто системные администраторы могут не знать о нем несколько месяцев или не узнать вовсе. Бывает, первые подозрения появляются, только когда система приходит в нерабочее состояние.

Расследование взлома

Организация столкнулась с проблемами, возникшими на основном почтовом сервере, работавшем под управлением операционной системы Solaris 8. Проблема состояла в том, что системные администраторы не могли зарегистрироваться в системе. При перезагрузке на консоли сервера выводились следующие сообщения:

INIT: Command is respawning too rapidly. Check for possible errors.
id:  SV "/usr/bin/srload -D -q"

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

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

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

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

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

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

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

В любом случае, ваше следующее действие снятие копии жесткого диска.

Для снятия копии жесткого диска существует целый ряд утилит. Самый простой способ использование утилиты dd, доступной как для Unix-систем[2], так и для Windows[3]. Если в системе применяется зеркалирование дисков, в качестве резервной копии может использоваться один из элементов зеркала дисков. Так же существует целый ряд специализированного программного обеспечения и аппаратно-программных комплексов, позволяющих создать копии жестких дисков.

После этого можно попытаться получить данные непосредственно на работающей системе.

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

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

При сканировании портов системы, была обнаружена работа несанкционированно запущенного сервера OpenSSH на порту 6007/tcp.

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

Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at xxxx-yy-zz 18:36 XXX
Interesting ports on aaa.bbb.ccc.ddd:
(The 1632 ports scanned but not shown below are in state: closed)

PORT      STATE SERVICE
7/tcp     open  echo
9/tcp     open  discard
13/tcp    open  daytime
19/tcp    open  chargen
21/tcp    open  ftp
23/tcp    open  telnet
37/tcp    open  time
53/tcp    open  domain
79/tcp    open  finger
110/tcp   open  pop3
111/tcp   open  rpcbind
512/tcp   open  exec
513/tcp   open  login
514/tcp   open  shell
540/tcp   open  uucp
898/tcp   open  sun-manageconsole
3306/tcp  open  mysql
6007/tcp  open  X11:7
7100/tcp  open  font-service
8888/tcp  open  sun-answerbook
32771/tcp open  sometimes-rpc5
32772/tcp open  sometimes-rpc7
32773/tcp open  sometimes-rpc9
32774/tcp open  sometimes-rpc11
32775/tcp open  sometimes-rpc13
32776/tcp open  sometimes-rpc15

Nmap run completed -- 1 IP address (1 host up) scanned in 0.797 seconds

$ telnet aaa.bbb.ccc.ddd 6007
Trying aaa.bbb.ccc.ddd ...
Connected to aaa.bbb.ccc.ddd.
Escape character is '^]'.
SSH-1.5-1.2.25
Connection closed by foreign host.

Следующий шаг расследования изучение жесткого диска взломанной системы.

Создадим еще одну резервную копию диска и смонтируем ее на заведомо чистой системе. В большинстве Unix-подобных систем монтирование образов файловых систем осуществляется с помощью механизма loopback mount. Для Windows требуется применение сторонних утилит[4].

Учитывая обнаруженные проблемы с входом в систему, в первую очередь расследователей заинтересовала системная утилита login, ответственная за вход в систему. Выяснилось, что утилита /usr/bin/login отсутствует в системе, однако был обнаружен файл /sbin/xlogin, вызвавший подозрения.

Файл был проверен по Solaris fingerprint database, сервису, поддерживаемому компанией Sun Microsystems и позволяющему сравнивать криптографические сигнатуры изучаемых файлов с сигнатурами, имеющимися в базе данных Sun.

$ md5 xlogin
MD5 (xlogin) = 916c0ea68db53ffdb5fb9af65549ad8c
Results of Last Search
916c0ea68db53ffdb5fb9af65549ad8c - - 1 match(es)
        * canonical-path: /usr/bin/login
        * package: SUNWcsu
        * version: 11.8.0,REV=2000.01.08.18.12
        * architecture: sparc
        * source: Solaris 8/SPARC
        * patch: 111085-02

Таким образом, было подтверждено, что файл xlogin представляет собой резервную копию системного файла /usr/bin/login. Вероятно, взломщик хотел установить троянскую копию login, по всей видимости, для сбора паролей. Для этих целей он скопировал оригинальный файл в /sbin/xlogin а затем удалил /usr/bin/login.

Восстановить удаленный файл /usr/bin/login к сожалению не удалось. Успешное восстановление этого файла могло бы дать дополнительную информацию о действиях взломщика. Неудача при восстановлении объясняется тем, что файл уже был переписан. Возможно, если бы резервная копия была снята раньше, данные удалось бы восстановить.

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

Тем не менее, можно выделить ряд общих принципов:

Проверка файлов значительно облегчается, если администраторы заранее установили систему анализа целостности файловой системы, например Tripwire или AIDE. При отсутствии такого ПО, на Unix-подобных системах можно воспользоваться механизмом анализа целостности установленных пакетов, входящих в некоторые системы, например RedHat package manager (rpm Va), Debian package (debsums), SYSV package (pkgchk).

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

В результате анализа файловой системы, был обнаружен каталог /usr/lib/libXa, где находилось ПО, использованное взломщиком. В частности, были обнаружены троянские версии программ ps, netstat, ls и ряда других, обеспечивавших скрытие присутствия взломщика в системе. Так же был обнаружен скрипт, отвечавший за установку троянских программ, в котором содержалась ошибка, приводившая к удалению /usr/bin/login.

Анализ скрипта так же позволил обнаружить каталог /dev/cua//, где были установлены программы для работы с IRC psyBNC и Eggdrop. В конфигурации Eggdrop была найдена ссылка на канал IRC, где общалась команда взломщиков. За недостатком времени, наблюдение за ними не производилось[5].

Целью сбора информации о взломе является необходимость понять, как взломщику удалось нарушить безопасность системы. Это определяет направление поиском и их продолжительность.

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

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

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

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

Пользователи почтового сервера могли осуществлять интерактивное подключение к почтовой системе. Этим воспользовался взломщик. После этого он использовал уязвимость в Solaris priocntl[6] для получения доступа суперпользователя.

После этого взломщик установил rootkit, psyBNC и Eggdrop.

Восстановление работоспособности

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

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

Теперь попытаемся ответить на вопрос, почему взлом оказался успешным?

Безопасность системы складывается из трех компонент:

В рассматриваемой ситуации, если бы при планировании было учтено, что использование протокола POP3 небезопасно, и он должен быть защищен посредством SSL или VPN, взломщик не имел бы возможности получить пароль прослушиванием трафика. Учет проблем безопасности на клиентах позволил бы снизить вероятность установки троянской программы. Разделение базы аутентификации почтовых пользователей и интерактивных подключений, лишило бы взломщика возможности получить доступ к системе.

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

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

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

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

Описание алгоритмов противодействия атакам и создание команды по ликвидации последствий инцидентов информационной безопасности (в состава отдела ИТ или как отдельной организационной структуры), несомненно, позволит сократить затраты на восстановление и время, необходимое для восстановления. Существование такой команды[7] и принципы ее работы должны быть описаны в политике информационной безопасности организации основном документе, регламентирующем управление информационной безопасностью.

[1] Подробнее о написании политики безопасности можно узнать в RFC2196, Site Security Handbook, http://www.faqs.org/rfcs/rfc2196.html

[2] Утилита dd обычно поставляется с дистрибутивом любой Unix-подобной операционной системы, исходные тексты так же доступны в составе GNU Fileutils по адресу http://www.gnu.org/software/fileutils/fileutils.html

[3] Версия для Windows доступна для загрузки по адресу http://uranus.it.swin.edu.au/~jn/linux/rawwrite/dd.htm а так же в составе Cygwin

[4] Существует целый ряд программных продуктов для Windows, позволяющих получить доступ к файловой системе на образе диска. Достаточной функциональностью обладает утилита FileDisk, доступная для бесплатной загрузки по адресам http://www.acc.umu.se/~bosse/ или http://www.insidewindows.info/

[5] Эксперимент по наблюдению за командой взломщиков script-kiddie проводился командой проекта Honeynet. Отчет доступен по адресу http://www.honeynet.org/papers/motives/index.html и в книге Know Your Enemy, написанной участниками этого проекта.

[6] http://www.securityfocus.com/bid/6262

[7] Руководство для такой команды создано в Университете Карнеги-Меллон, документ можно бесплатно загрузить по адресу http://www.sei.cmu.edu/publications/documents/03.reports/03hb002.html