Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам:
Вторую часть мы закончили сбором необходимой информации, требуемой для атаки на сеть жертвы. Теперь давайте приступим к самому незаконному получения доступа к компьютерным данным. Он будет сопровождаться передачей некоторых программ, требуемых для продвижения хакерских стратегий пост-атаки (post-exploitation strategies). Было бы бессмысленно просто взломать компьютер, а затем ретироваться. Обычно целью вредоносных хакеров является не только получение доступа к компьютерной сети, но и его сохранение. А это обычно означает попытку скрыть свое присутствие.
Сейчас я буду использовать инфраструктуру Metasploit Framework, чтобы осуществить собственно взлом. Эта инфраструктура действительно хороша тем, что предлагает вам широкий спектр средств атаки, а также, что не менее важно, множество различных опций для выбора вашей полезной нагрузки. Вам не всегда будет нужна реверсная оболочка, или вы не всегда будете использовать VNC. Ваша полезная нагрузка будет часто зависеть от ваших подручных целей, архитектуры сети и ваших конечных задач. В нашем случае мы будем использовать реверсную оболочку. Это всегда выгодно, особенно в случае, когда ваша мишень расположена за маршрутизатором и к ней нет прямого доступа. Например, вы нацелились на веб сервер, но он является одним из нескольких, чья нагрузка сбалансирована. Нет никаких гарантий того, что вы сможете подключиться к нему с помощью прямой оболочки (forward shell), поэтому вам понадобится компьютер, который будет передавать содержимое оболочки обратно к вам. Наконец, я не будут затрагивать принципы использования инфраструктуры Metasploit Framework, так как я рассказывал об этом несколько раз в других статьях. Мы сконцентрируем наше внимание на том, как все выглядит на пакетном уровне.
Вместо того чтобы использовать подход пошагового описания самого процесса взлома с картинками и отрезками кода, мы пойдем другим путем. Мы воссоздадим процесс взлома с помощью 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