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

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