Атака на Windows NT

O В этой главе:

O Microsoft LAN Manager - история, устройство, недостатки реализации

O SMB протокол

O Реализация локальной регистрации в системе

O Реализация удаленной регистрации в системе

O Уязвимость автоматического входа в систему

O Алгоритмы аутентификации, механизм «запрос-отклик»

O Алгоритмы шифрования паролей

O Алгоритмы хеширования - LM и NT хеш

O Ошибки реализации механизма аутентификации

O Оценка криптостойкости LM-хеша, атака на LM-хеш

O Оценка криптостойкости NT-хеша

O Уязвимость алгоритма шифрования хеш-значения, передаваемого по сети

O Оценка времени, необходимого для подбора пароля Windows NT

O L0phtCrack - программная реализация подбора пароля

O Доступность резервной копии базы SAM

O Анонимный пользователь в Windows NT и нуль сессии

O Атака RedButton

O Атака с помощью Password Policy

O Протокол SNMP, возможность его использования для атаки

O Получение прав администратора с помощью ошибки реализации NtAddAtom

O Служба редиректора

O Именованные каналы и NPFS

O Атака с использованием именованных каналов

O Олицитворение и наследование прав клиента

Летом двухтысячного года состоялся торжественный выпуск операционной системы Windows 2000, объединивший в себе удобства Windows 98 c надежностью [139] Windows NT. Большинство ошибок, существовавших в Windows NT 4.0, сейчас исправлено и на первый взгляд система кажется стабильной и устойчивой [140].

Но не стоит торопиться с заключениями. Вопреки заверением Microsoft, Windows 2000 - просто очередная ОС [141], принципиально ничем не отличающаяся от своих предшественниц. Грандиозные изменения кода, затронувшие всю систему, включая ядро, свидетельствуют: ошибки есть, не может быть, чтобы разработчики не допустили ни одной из них более чем в пяти миллионах строках кода!

Некоторые атаки, описанные ниже, применимы исключительно к Windows NT 4.0 и бессильны против Windows 2000. Между тем, их актуальность остается весьма высокой: массовая миграция на новую систему начнется нескоро. Крупные корпорации в таких вопросах никогда не спешат: если существующее программное обеспечение удовлетворяет их запросам, какой смысл «менять шило на мыло»? Ввод новой системы в эксплуатацию всегда связан с риском возникновения ошибок, влекущих потерю данных и рабочего времени. Корпоративный пользователь скорее согласится мириться с недостатками прежней системы, чем установит «кота в мешке», не прошедшего тестирования у тысяч домашних и мелко корпоративных пользователей.

Однако в ряде случаев Windows NT 4.0 не способна обеспечить надлежащего уровня защищенности [142]. Существует ряд атак, не устранимых никакими средствами администрирования, но позволяющих злоумышленнику получить привилегии администратора!

В Windows 2000 большинство обнаруженных ошибок исправлено (но не все!), и уровень защищенности системы значительно повышен. Поэтому, весь материал, приведенный ниже, можно рассматривать не только как описание дыр Windows NT (Windows 2000), но и как стимул перехода на Windows 2000 (если читатель до сих пор этого не сделал).

Если первые кирпичи здания UNIX закладывались в ту далекую эпоху, когда никакой теории безопасности еще не существовало, то Windows NT изначально проектировалась как защищенная, отказоустойчивая система, стойкая ко всем антиамериканским настроениям.

Дейв Катлер, крестный отец Windows NT, ранее участвующий в создании двух легенд семидесятых - RSX-11M и VMS [143], вложил в NT весь свой талант и опыт, но… похоже, потерпел неудачу. Да, Windows NT построена на передовых технологиях и основана на внутренне непротиворечивой модели безопасности, но теоретическую идиллию разрушают вездесущие ошибки реализации.

Кроме досадных багов, своеобразных программистских описок, исправляемых очередной заплаткой, актуальны и проблемы стыковки различных компонентов операционной системы друг с другом. Их несогласованная работа способна значительно ослабить степень безопасности, но ни один человек не в состоянии удержать в голове миллионы строк исходного кода операционной системы, а с ростом количества разработчиков координировать их действия становится все сложнее и сложнее. Неудивительно, что в Windows NT обнаруживаются серьезные бреши в защите, и существуют способы несанкционированного повышения уровня своих привилегий с «гостя» до администратора. Часть ошибок устраняется правильным администрированием (читай - нечеловеческим ущемлением прав пользователей и отключением всего, что удается отключить [144]), но в силу самой архитектуры Windows NT у злоумышленника всегда останется шанс проникнуть в систему.

Аналогично UNIX, операционная система Windows NT подвержена угрозе срыва стека, точно так для нее актуальна возможность прорыва за пределы процесса, позволяющая пользователю получить доступ к данным и коду другого приложения (включая системные сервисы), наконец, реализация протоколов семейства TCP/IP оставляет желать лучшего и допускает возможность удаленной атаки. Впрочем, ошибки в практике программистов - дело привычное и встречаются они не только у Microsoft, но отличительная черта Microsoft - бег впереди прогресса, приводит к появлению новых версий задолго до того, как разработчики успевают выявить и устранить дефекты старых. Стабильность же UNIX в основном объясняется тем, что за несколько последних лет эта система не претерпела никаких существенных изменений.

Бурное развитие Windows-систем привело к проблемам совместимости, вынуждая разработчиков тянуть за собой воз неудачных решений и откровенных ошибок ранних версий. Взять, к примеру, механизмы аутентификации пользователей в Windows NT. Казалось бы, операционная система, разработанная много позже UNIX, должна учесть ошибки своей предшественницы и превзойти ее в защищенности. На самом же деле все обстоит с точностью до наоборот!

Первые зачатки сетевой поддержки появились еще в MS-DOS 3.1 [145], а уже в 1984 году Microsoft выпустила программный пакет “Microsoft Network” (сокращенно MS-NET). Как не удивительно, но, ряд заложенных в него концепций, дожил и до сегодняшних дней, перекочевав сначала в Microsoft LAN Manager, а затем и в Windows NT. К ним («живучим» концепциям) относятся редиректор (redirector), протокол SMB (Server Message Block) и сетевой сервер (Network Server). Подробнее о каждом из них рассказано ниже, сейчас же больший интерес представляет LAN Manager.

Вопреки распространенному заблуждению это вовсе не самостоятельная сетевая операционная система, а всего лишь расширение к существующим операционным системам - MS-DOS, OS/2, UNIX, Windows 3.1 и Windows 3.11 for Workgroups. Поэтому, все последующие системы Windows 95, Windows 98 и Windows NT были вынуждены поддерживать совместимость с Microsoft LAN Manager, дабы не отсекать многочисленную армию пользователей, работающих с DOS и Windows 3.x (а теперь LAN Manager поддерживает и Windows 2000 для обеспечения совместимости с Windows 95, Windows 98).

Для аутентификации, установления соединений и передачи файлов используется протокол SMB (Server Message Block). Но SMB это не один протокол, а целое семейство диалектов, созданных в разное время для различных операционных систем. В самой ранней реализации протокола, PC Network Program 1.0 (которая была разработана для MS-DOS), отсутствовала поддержка шифрования паролей, и они передавались на сервер открытым текстом! Казалось бы, сегодня об этой архаичности можно забыть [146], ан нет!

Да, все современные сервера работают только с зашифрованными паролями, но большинство клиентов по-прежнему поддерживают ранние спецификации SMB. Если злоумышленник сумеет «прикинуться» сервером, он сможет послать клиенту сообщение SMB_COM_NEGOTIATE с флагом, предписывающим передавать пароль в незашифрованном виде. И клиент, поверив, что сервер не поддерживает зашифрованные пароли [147], выполнит его требование!

На первый взгляд «прикинуться» сервером невозможно. Ведь для этого необходимо не только подделать обратный адрес в заголовке пакета, но и изменить маршрутизацию сетевых сообщений! Сервер пассивен, он не отправляет никаких пакетов клиенту, пока тот сам не инициирует запрос на соединение. Но широковещательная среда локальной сети Ethernet позволяет любому сетевому адаптеру перехватывать все физически проходящие сквозь него пакеты. Достаточно блокировать сервер любой подходящей DOS-атакой (иначе клиент получит сразу два ответа, - как от ложного сервера, так и от настоящего) и вернуть клиенту подложный пакет с требованием пересылки открытого пароля. В глобальных же сетях, основанных на TCP/IP, существует угроза «подмятия» DNS-сервера - злоумышленник может забросать клиента ворохом UDP-пакетов, содержащих обратный адрес подложного сервера. Если клиент примет один из таких пакетов за ответ настоящего DNS, он доверчиво установит соединение с узлом злоумышленника! (Подробнее об этом рассказано в главе «Атака на DNS сервер» [148]). Подобные атаки, получили название “Man in Middle” (Субъект в середине) и достаточно широко распространены.

Очевидное решение - отключить поддержку незашифрованных паролей (если программное обеспечение допускает такую возможность). Но, в отличие от сервера, конфигурируемого администратором, настойка клиента - забота самого клиента. В сетях с большим количеством пользователей (а тем более, в глобальных сетях), никакой администратор не способен уследить за всеми своими подопечными.

Врезка «замечание» *

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

Утилита passprop из комплекта Windows NT Resource Kit позволяет включить блокировку учетной записи администратора. Естественно возникает вопрос, как же он тогда сможет войти в систему? Оказывается, блокировка касается только удаленной регистрации, а с консоли главного контроллера домена PDC вход всегда открыт.

Реализация SMB для Windows for Workgroups уже поддерживала зашифрованные пароли, но все же еще оставалась достаточно ненадежной с точки зрения безопасности. К сожалению, она оказалась интегрирована в Windows 95 и Windows 98, поэтому отказаться от ее поддержки в большинстве случаев невозможно. Конечно, если на всех машинах сети установлена Windows NT, разумно использовать только родную для нее реализацию протокола SMB - NT LM 0.12 (а лучше NT LMv2), которая достаточно надежна, но чаще все же приходится поддерживать операционные системы обоих типов.