Взлом Windows-сетей от Microsoft
 

Вот нашёл давеча на Мелкософте, аффтар Джеспер Йоханссон:

http://www.microsoft.com/rus/Technet...02/hacker.mspx



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

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

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

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


Сеть-мишень

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

Прежде чем я начну атаковать сеть, давайте поговорим о том, с чем мне придется столкнуться. Ясно, что в реальных условиях у хакеров редко бывают в распоряжении полные схемы сетей, но в нашем случае рассмотреть конфигурацию сетимишени лишним не будет (рис. 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) не блокируется. В этом случае достаточно выполнить следующую команду:

Ясно, что 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. По ней одной можно сказать, что сайт предназначен для заказа какойто продукции. Давайте воспользуемся обычной учетной записью, чтобы получить больше информации о системе.


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

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


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

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

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

Вообще если переносишь в Чужие статьи, то надо аакуратно скопипатить. Если не поправишь опус, я его сотру.
Кстати статья внушает уважение. Я многое почерпнул оттуда интересного.

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

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

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

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

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

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

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

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

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

Конечно, было бы лучше, если бы это была доменная учетная запись, но и полученный результат вселяет оптимизм. Чтобы понять, что можно сделать с этой учетной записью, нужно знать коекакие детали работы 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

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

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

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

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

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

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

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

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

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

GetSystemInfo - очень простая программа, которая подключается к системе и запрашивает у нее информацию из раздела реестра HKLM\Software\Microsoft\Windows NT\CurrentVersion. Как видите, система называется PYNWEB. Я все еще не знаю, как ее взломать, но могу попробовать следующее:

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


Заключение

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