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

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

Как это работает? Очень просто. После того как хакер узнал ваш хэш, он находит в памяти своей машины (на которой он - бог и царь, и администратор в придачу) место, откуда берется хэш для аутентификации, и кладет туда ваш хэш. Все! После этого он цинично заходит на все доступные вам ресурсы, и вскрывать ваш сверхустойчивый пароль из 12-16 символов ему совсем необязательно.

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

Сама процедура поиска живо напомнило пародию на кладоискательство. Я читал какие-то пыльные манускрипты по Виндам, тупо таращился на схемы, ходил туда, потом обратно. Но в конечном итоге все свелось к копанию. Как известно, есть те, кто думают, а есть те, кто копают. Мне приходится копать! Вот я и копал, где не попадя. Находил какие-то трубы, провода и прочий мусор. Внутреннее устройство Виндов никогда не оставляло меня равнодушным. Старательность, с которой пароль в открытом виде кодируется и декодируется по простейшему алгоритму, а потом затирается, просто умиляет. Помнится, я ржал до коликов, наткнувшись на список, в котором не было больше ничего, кроме адресов предыдущего и следующего элементов списка. А поиск хэндла! Прежде чем найти хэндл, проводится проверка, что он есть, причем для этого он просто находится! В общем, если бы Сальвадор Дали посидел бы на ночь глядя в отладчике Виндов, то современная культура обогатилась еще несколькими шедеврами. Абстрактный иррационализм от маниакально-депрессивного шизоида. Думаю, теперь мне не избежать визита к психиатру. Но я отвлекся.

Действие происходит в памяти процесса lsass.exe, а именно в библиотеках lsasrv.dll и msv1_0.dll. Вкратце, процедура логона следующая (не спецам описание рекомендую пропустить - лично у меня от него голова болит). Вызывается функция LsapAuApiDispatchLogonUser, откуда вызывается NegLogonUserEx2. После чего происходит забег в пакет аутентификации Кербероса, а потом и в стандартный - в функцию LsaApLogonUserEx2, где и происходит все самое интересное. Сначала вызывается NlpPutOwfsInPrimaryCredential, где пароль в открытом виде преобразуется в хэш функциями SystemFunction006 SystemFunction007. Далее функцией NtAllocateLocallyUniqueId выделяется тот самый пресловутый уникальный идентификатор логоновской сессии. После в функции со скромным названием Lsa с помощью функции LsapCreateLsaLogonSession создается сама сессия. Затем происходит сравнение с хэшом, записанным в реестре в функции MsvSamValidate. После аутентификации в функции NlpMakePrimaryCredential создается аутентифицирующая информация (credential information), которая состоит из логона, домена и двух хэшей (NT и LM). Наконец функцией NlpAddPrimaryCredential эта информация кладется в логоновскую сессию.

Насколько я понял, есть некая таблица, где подряд лежат записи о сессиях (но, вообще говоря, не всегда). Начало этой таблицы лежит в lsasrv.dll по адресу 0x78120. Каждая запись - это кусок памяти размером 0x34, где первые 4 байта - это заголовок (LHTX или SHTX). По смещению 0x10 лежит указатель на хэндл сессии.

Хэндл сессии - это кусок памяти размером 0x24, где первые и вторые 4 байта - это указатель на хэндл сессии в таблице записей о сессиях. По смещению 0x10 лежит указатель на саму логоновскую сессию.

Логоновская сессия - это структура размером 0x80, где в первых 8 байтах лежит уникальный идентификатор логоновской сессии, а по смещению 0x38 - указатель на запись об аутентифицирующей информации (АИ).

Запись об АИ - это структура размером 0xC, в которой по смещению 0x4 лежит идентификатор аутентифицирующего пакета (в нашем случае это 2), а по смещению 0x8 - указатель на контейнер АИ.

Контейнер АИ - это структура размером 0xC, в которой по смещению 0x4 лежит уникодовская строка со словом Primary, а по смещению 0x8 - уникодовская строка с указателем на АИ.

Наконец, АИ - это структура размером 0x30, в которой по смещению 0x0 лежит модифицированная уникодовская строка с именем домена, по смещению 0x8 - модифицированная уникодовская строка с логоном, по 0x10 - NT хэш, а по 0x20 - LM хэш.

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

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