Обнаружена закладка в протоколе 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 апреля.
Рубрика | Размышления |
---|---|
Метки | active directory, ad, windows server |
Опубликовано | 2012-04-01, 20:50; обновлено 2012-04-02, 23:21 |
Комментарии | 3 комментария » | Лента комментариев RSS |
Ссылки | Постоянная ссылка | Обратная ссылка |
3 комментария
Статья весьма и весьма интересная, но название статьи не однозначное. Больше бы подошло что то по смыслу: «Особенности реализации Kerberos на разных платформах»
Ну как то так.
P.S. Ваш друг пробывал менять рассматриваемые файлы с одной версии сервера на другую на предмет совместимости?