Небезопасное шифрование паролей в NT

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

Существует множество различных алгоритмов обмена ключами по незащищенным каналам [4], но наибольшую популярность завоевала схема «запрос-отклик» (handshake), которая в общих чертах выглядит следующим образом. После успешной установки соединения сервер посылает клиенту случайную последовательность, именуемую «запрос пароля» (challenge). Клиент шифрует «запрос», используя свой пароль в качестве ключа и возвращает полученный результат серверу. Сервер, выполнив аналогичную операцию, сравнивает результат свой работы с «откликом» (response) клиента. Если они совпадают - хорошо, а нет - invalid user.

Важно понимать, что «запрос» шифруется паролем, а не наоборот. В противном случае, в такой операции не было бы никакого смысла - злоумышленник, перехватив запрос сервера и отклик клиента, сумел бы расшифровать пароль. Иначе говоря, если f - функция шифрования, key - ключ, а value - шифруемые данные, то: f(value) —^key-> crypt, а F(crypt) —^key-> value, где F - функция дешифрования. Если key - «запрос», а value -пароль пользователя, то злоумышленник, перехватив «запрос» и crypt, сможет восстановить искомый пароль. Но как все изменится, если key - это пароль, а value - «запрос»! Для того чтобы из crypt извлечь «запрос» (да и зачем его извлекать, когда он и без того известен?), необходимо знать ключ шифрования, а его как раз и требуется найти. При этом функция шифрования специально подобрана таким образом, чтобы, зная исходный и зашифрованный текст, вычислить ключ было невозможно иначе, как с помощью прямого перебора.

Отклик клиента не способен расшифровать никто, даже сам сервер. Но это и не нужно: функция необратимого шифрования позволяет установить идентичность аргументов, но не позволяет по значению функции узнать сами аргументы. Строго говоря, это верно только в том случае, если каждому значению функции f() соответствует только один аргумент. В противном случае возможна такая ситуация, когда x ≠ x1, но f(x) = f (x1).

Значение «запроса», посылаемое клиенту сервером, должно быть не только случайным, но и не повторяющимся и непредсказуемым. Очевидно, что использование временной метки, не отвечает последнему условию и проводит к потенциальной уязвимости системы [5].

В общем случае временная метка равна числу так называемых «тиков», прошедших с момента начала работы сервера (или с момента включения питания компьютера). При хорошем качестве соединения с сервером все временные метки с небольшим разбросом лежат вдоль прямой f(t) = k*t+c, где k и с - некоторые коэффициенты. Подключаясь к серверу через определенные промежутки времени, злоумышленник сможет вычислить коэффициенты k и c, а отсюда, с определенной вероятностью сумеет предсказать «запрос» в любой момент времени t. В этом случае атака может выглядеть приблизительно так: дождавшись начала сеанса аутентификации, злоумышленник от имени сервера посылает жертве предсказанный им «запрос», которым жертва зашифровывает свой пароль, возвращая обратно полученный результат. Разумеется, злоумышленник не в состоянии восстановить искомый пароль, но это ему и не нужно! Последовательными запросами на аутентификацию он добивается получения предсказанной им временной метки и возвращает зашифрованный ею пароль пользователя. Экспериментально установлено, что в большинстве существующих систем разброс выдачи временных меток находится в интервале от одного до нескольких десятков «тиков», следовательно, такие системы могут быть взломаны относительно быстро.

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

Данная атака представляет наибольшую опасность в высокоскоростных локальных сетях. В Internet ее актуальность значительно ниже; здесь непредсказуемые задержки затрудняют точное предсказание временных идентификаторов, снижая вероятность успешного вторжения, но не исключая его.

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

Если злоумышленник сумеет «прикинуться» сервером, он сможет послать клиенту сообщение SMB_COM_NEGOTIATE с флагом, предписывающим передавать пароль в незашифрованном виде. И клиент, поверив, что сервер не поддерживает зашифрованные пароли, выполнит его требование. Задачу злоумышленника значительно облегчает тот факт, что прикладной SMB-протокол реализуется поверх транспортных протоколов, совместимых с интерфейсом NetBIOS, а, устанавливая соединение по протоколу NetBIOS, сервер проверяет имя, сообщенное ему клиентом, а не его сетевой адрес.

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

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

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

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

1) DES(0) ^P1..7-> =H_1..8;
2) DES(0) ^P8..14-> =H_9..16;

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

В среднем злоумышленнику потребуется 1+k+k²+k³+k⁴+k⁵+k⁶+k⁷ операций (вычисление функции DES и сравнение полученного результата с исходным хеш-значением) для подбора пароля, где k максимально допустимое количество символов, использующихся для составления пароля. Это намного меньше ожидаемого количества операций, необходимых для подбора 14-символьного пароля:

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

Таким образом, пароль, состоящий из восеми и более символов, окажется ничуть не сложнее пароля, состоящего всего из семи символов — фактически система запрашивает два 7-символьных пароля и обрабатывает их независимо друг от друга. Стоит заметить, что даже старые версии ОС Unix ограничивали пароль восемью символами, различая при этом заглавные и строчные буквы.

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

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

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

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

Словарный перебор срабатывает часто, но не всегда. Привилегированные пользователи (например, системные администраторы) склонны выбирать бессмысленные пароли наподобие «acsW%9*m$», надежно защищая себя от словарной атаки.

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

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

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

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

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

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

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

#include 
main()
{
	char pswd[10];
	int p=0;
	pswd[0]=?!?;
	pswd[1]=0;

	while(1) {
		while((++pswd[p])>?z?) {
			pswd[p]=?!?;
			p++;
			if (!pswd[p]) {
				pswd[p]=? ?;
				pswd[p+1]=0;
			} 
		}
	p=0;
	printf(«%s
»,&pswd[0]);
	}
}

Суть алгоритма заключается в следующем: первый слева символ пароля увеличиваться до тех пор, пока не превысит максимально допустимое значение. Когда такое произойдет, он «обнуляется», принимая минимально допустимое значение, а символ, стоящий справа от него увеличивается на единицу. В упрощенном виде алгоритм записывается в одной строке на языке Си:

while ((++pswd[p])>MAX_VAL)
 pswd[p++]=MIN_VAL;p=0;

Такая конструкция скрывает рекурсию и тот же алгоритм в рекурсивной форме записи может выглядеть так:

void GetNextPasswd
	(char pswd, int p)
{	pswd[p]++;
	if (!(pswd[p]>MAX_VAL)) return;
	pswd[p]=MIN_VAL;
	Count(pswd,++p);
}

Существует готовая программная реализация описанной атаки, воплощенная в пакете L0PhtCrack 2.5, которая занимается подбором LM- и NT-хешей [4]. Утверждается, что с помощью этой утилиты на 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) операций в секунду, то есть 6823331935125/172800 = 39486874 - почти 40 млн. вычислений функции DES каждую секунду. Ни один из процессоров Intel не обеспечивает пока такой производительности.

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

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