Обнаружена закладка в протоколе Kerberos реализации Microsoft

2012-04-01, 20:50 / Argon

Есть у меня коллега, который админит очень большую сеть. В силу бессмысленных и беспощадных причин в этой сети присутствуют машины под управлением Windows 98, на которых выполняются ВНЕЗАПНО критичные приложения.

Что характерно, машины с Win 98 используют аутентификацию в домене Active Directory. Кое-как всё работало, пока не стали обновлять контроллеры домена до Windows Server 2008 R2.

После долгих танцев с бубном было выяснено, что протокол шифрования DES не поддерживается на WS 2008 R2, а машины Win 98 его требуют для аутентификации в домене.

Мой коллега, будучи в душе гиком-крякером, вооружился дебаггером и полез искать разницу в бинарниках LSASS.exe между версиями WS 2008 SP2 (где DES работает) и WS 2008 R2 (не работает).

Как оказалось, код, обрабатывающий DES, был просто закомментирован (безусловным переходом), но остался в бинарнике. В глаза бросилась более интересная особенность: в одном из условных переходов выполнялось сравнение с довольно длинной константой. Методом тыка было установлено, что этот код отвечает за выдачу билетов Kerberos подсистемой KDC.

Дальше – интереснее. Как известно, при аутентификации через Kerberos клиент сначала запрашивает билет на получение билетов TGT у службы Authentication Service, при этом отправляя свой запрос открытым текстом + аутентификатор (штамп времени, зашифрованный долгосрочным ключом пользователя).

Дебаггер показал, что в коде LSASS.exe зашито сравнение штампа времени с константой в формате Time Stamp. Если перевести её в читаемый вид, получится:

1986-09-19 12:05:18 GMT+0

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

После составления Privilege Account Certificate для подавшего запрос пользователя, KDC генерирует Authentication Service Reply, который содержит действительный билет TGT и сессионный ключ, который (внимание!) зашифрован с помощью ключа на основе константы (строки из восемнадцати пробелов), а не реального пароля данного пользователя.

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

В версиях Windows Server до 2008 R2 такого поведения обнаружено не было. Интересно, если Microsoft предоставляет исходники своих ОС специальным службам государств для ознакомления, знают ли они об этой недокументированной особенности?

[update] В ходе дальнейшего исследования была установлена третья константа… Весь описанный выше механизм работает только при условии, что текущая системная дата равна 1 апреля.



3 комментария

Андрей
# Комментарий от 2013-05-15, 14:21

Статья весьма и весьма интересная, но название статьи не однозначное. Больше бы подошло что то по смыслу: «Особенности реализации Kerberos на разных платформах»
Ну как то так.
P.S. Ваш друг пробывал менять рассматриваемые файлы с одной версии сервера на другую на предмет совместимости?

Dart Kane
# Комментарий от 2015-01-25, 17:40

«дата равна 1 апреля»
Ну практически пасхалка)

ivan
# Комментарий от 2015-10-17, 16:35

вообще удивительно, что в 2015 еще где то есть 98

Добавить комментарий