Подробный анализ незаконного получения доступа к компьютерным данным (часть 3)

Published on Февраль 2, 2009 by   ·   Комментариев нет

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам:

Вторую часть мы закончили сбором необходимой информации, требуемой для атаки на сеть жертвы. Теперь давайте приступим к самому незаконному получения доступа к компьютерным данным. Он будет сопровождаться передачей некоторых программ, требуемых для продвижения хакерских стратегий пост-атаки (post-exploitation strategies). Было бы бессмысленно просто взломать компьютер, а затем ретироваться. Обычно целью вредоносных хакеров является не только получение доступа к компьютерной сети, но и его сохранение. А это обычно означает попытку скрыть свое присутствие.

Время повеселиться

Сейчас я буду использовать инфраструктуру Metasploit Framework, чтобы осуществить собственно взлом. Эта инфраструктура действительно хороша тем, что предлагает вам широкий спектр средств атаки, а также, что не менее важно, множество различных опций для выбора вашей полезной нагрузки. Вам не всегда будет нужна реверсная оболочка, или вы не всегда будете использовать VNC. Ваша полезная нагрузка будет часто зависеть от ваших подручных целей, архитектуры сети и ваших конечных задач. В нашем случае мы будем использовать реверсную оболочку. Это всегда выгодно, особенно в случае, когда ваша мишень расположена за маршрутизатором и к ней нет прямого доступа. Например, вы нацелились на веб сервер, но он является одним из нескольких, чья нагрузка сбалансирована. Нет никаких гарантий того, что вы сможете подключиться к нему с помощью прямой оболочки (forward shell), поэтому вам понадобится компьютер, который будет передавать содержимое оболочки обратно к вам. Наконец, я не будут затрагивать принципы использования инфраструктуры Metasploit Framework, так как я рассказывал об этом несколько раз в других статьях. Мы сконцентрируем наше внимание на том, как все выглядит на пакетном уровне.

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

Данные Snort

Для запуска Snort использовался следующий синтаксис:


C:\snort\bin\snort.exe 'r c:\article_binary 'dv 'c snort.conf 'A full

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


==============================================================
Snort processed 1345 packets.
==============================================================
Breakdown by protocol:
TCP: 524        (38.959%)
UDP: 810        (60.223%)
ICMP: 11         (0.818%)
ARP: 0          (0.000%)
EAPOL: 0          (0.000%)
IPv6: 0          (0.000%)
ETHLOOP: 0          (0.000%)
IPX: 0          (0.000%)
FRAG: 0          (0.000%)
OTHER: 0          (0.000%)
DISCARD: 0          (0.000%)
==============================================================
Action Stats:
ALERTS: 63
LOGGED: 63
PASSED: 0

Нас интересует та часть, в которой записано, что 63 предупреждения были вызваны действиями взлома. Мы не будем рассматривать файл alert.ids, который может дать нам более детальную информацию о том, что произошло. Если вы помните, первое, что делал хакер, это использовал Nmap для сканирования сети. Это и было первым предупреждением, возникшим в Snort.


[**] [1:469:3] ICMP PING NMAP [**]
[Classification: Attempted Information Leak] [Priority: 2]
08/09-15:37:07.296875 192.168.111.17 -> 192.168.111.23
ICMP TTL:54 TOS:0x0 ID:3562 IpLen:20 DgmLen:28
Type:8  Code:0  ID:30208   Seq:54825  ECHO
[Xref => http://www.whitehats.com/info/IDS162]

Следуя этому, хакер использовал netcat для перечисления веб сервера в попытке определить его тип. Эта попытка перечисления не вызвала никаких предупреждений в Snort. Мне бы хотелось знать, почему, поэтому давайте посмотрим на отчет пакетов. После трех нормальных TCP/IP приветствий в трех направлениях, обнаружился следующий пакет.


15:04:51.546875 IP (tos 0x0, ttl 128, id 9588, offset 0, flags [DF], proto:
TCP (6), length: 51) 192.168.111.17.1347 > 192.168.111.23.80: P,
cksum 0x5b06 (correct), 3389462932:3389462943(11) ack 2975555611 win 64240
0x0000:  4500 0033 2574 4000 8006 75d7 c0a8 6f11  E..3%t@...u...o.
0x0010:  c0a8 6f17 0543 0050 ca07 1994 b15b 601b  ..o..C.P.....[`.
0x0020:  5018 faf0 5b06 0000 4745 5420 736c 736c  P...[...GET.slsl
0x0030:  736c 0a                                  sl.

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

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


[**] [1:1248:13] WEB-FRONTPAGE rad fp30reg.dll access [**]
[Classification: access to a potentially vulnerable web application] [Priority:
2]08/09-15:39:23.000000 192.168.111.17:1454 -> 192.168.111.23:80
TCP TTL:128 TOS:0x0 ID:15851 IpLen:20 DgmLen:1500 DF
***A**** Seq: 0x7779253A  Ack: 0xAA1FBC5B  Win: 0xFAF0  TcpLen: 20
[Xref => http://www.microsoft.com/technet/security/bulletin/MS01-035.mspx][Xref
=> http://cve.mitre.org/cgi-bin/cvename.cgi?name=2001-0341][Xref => http://www.s
ecurityfocus.com/bid/2906][Xref => http://www.whitehats.com/info/IDS555]

Следом за этой серией предупреждений Snort выдала серию TFTP предупреждений. Как только хакер получил доступ к веб серверу, он начал использовать интегрированного TFTP клиента для передачи четырех файлов: nc.exe, ipeye.exe, fu.exe, msdirectx.exe. После того, как эти файлы были переданы, хакер использовал netcat для отправки оболочки обратно на свой компьютер. На этом этапе он отключил свою другую оболочку, которая была создана в результате первичной атаки, и проделал оставшуюся работу с помощью оболочки netcat. Интересен тот факт, что ни одно из действий, выполненных хакером посредством реверсной оболочки, не было занесено в журнал событий Snort. Это произошло благодаря тому факту, что хакер использовал руткит (программа для сокрытия следов взлома), которую он передал через TFTP, чтобы скрыть обработанную информацию для netcat. Совсем не хорошо, многие, возможно, захотят использовать fu.exe руткит для получения IDS подписи.

Заключение

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

Источник www.windowsecurity.com


Смотрите также:

Tags: , ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)




Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]