Сервер аутентификации Kerberos ( Цербер)

Содержание:

ВВЕДЕНИЕ

Данная работа рассматривает собой технические аспекты работы протокола аутентификации Kerberos (Цербер) актуальной пятой версии. Процесс аутентификации – это процесс идентификации и проверки подлинности пользователя. Под идентификацией понимается процедура предоставления пользователем или процессом сведений о себе. Организация такого процесса реализуется путем создания отдельного сервера аутентификации, услугами которого будут пользоваться другие клиенты и серверы информационной системы. Существование отдельного сервера под нужды аутентификации позволяет реализовывать свои прикладные комплексы со своей системой понятий, но со стандартной процедурой проверки подлинности, что сильно упрощает управление разделения прав доступа пользователей. Выделение особого сервера аутентификации позволяет реализовать собственные прикладные комплексы со своей системой понятий, но со стандартной процедурой проверки подлинности, что существенно облегчает управление правами доступа пользователей. Механизм аутентификации Kerberos позволяет производить взаимную идентификацию клиента и сервера перед установления связи между ними, при этом учитывается тот факт, что первоначальный обмен информацией между клиентом и сервером происходит в открытой среде, где эти пакеты первоначального обмена информацией могут быть перехвачены и скомпрометированы. Фактически рассматриваемый протокол прекрасно подходит для работы в открытых сетях вплоть до уровня WAN сетей.

Протокол был создан в рамках проекта Athena (затем для сетей TCP/IP) в середине 80-ч годов в Массачусетском технологическом университете, причем версии Kerberos с 1 по 3 реализованные изначально для внутреннего использования, являются свободно распространяемым программным продуктом (кроме криптографических модулей), что позволяет разработчикам прикладных систем и системным администраторам работать с «прозрачным» инструментом, работающим понятным и проверяемым способом. Тем не менее рассматривать следует именно пятую версию протокола Kerberos, принятую в качестве стандарта IETF для сети Internet и писанную в RFC 1510. Основным отличием 4-й и 5-й версии является разные алгоритмы шифрования. В v.4 применяются алгоритмы DES с длиной ключа в 56 бит. В v.5 благодаря присоединяемому к шифрованной части блока информации идентификатору типа шифрования, есть возможность использовать RC4, DES алгоритмы, MD5Hash алгоритм хеширования, причем DES алгоритм поддерживает режим CBC – сцепленных шифровальных блоков, и другие.

РАЗДЕЛ 1. Общая информация и принципы работы.

1.1 Основные требования при разработке протокола.

При разработке протокола разработчики руководствовались следующими основными требованиями.

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

Надежность. Недоступность сервера Kerberos должна означать недоступность запрашиваемой службы (сервиса).

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

Масштабируемость. Система должна поддерживать большое (увеличивающееся) количество клиентов и серверов.

1.2 Аутентификация в Windows 2000

В виду того, что свое первое применение в ОЕМ Kerberos нашел в ОС Windows 2000, то и в качестве примера мы будем использовать эту операционную систему. В Windows 2000 поддерживается несколько протоколов, которые позволяют убедиться системе в том, что пытающийся войти в систему пользователь имеет свою учетную запись и соответствующие права. Это как протоколы аутентификации удаленных подключений, так и протоколы аутентификации пользователей, входящих в сеть через Интернет. Внутри же корпоративных сетей, где реализована доменная система управления сетью для проверки пользовательских данных имеется два протокола:

1) Windows NW LAN Manager (NTLM) – протокол, применяемый как стандартное средство сетевой аутентификации в операционной системе Windows NT 4.0. В ОС Windows 2000 он используется для аутентификации серверов и доменов Windows NT 4.0. Так же, NTLM применяется локальной аутентификации на автономных компьютерах. Компьютеры с ОС Windows 3.11, Windows 95, Windows 98, Windows NT 4.0 могут использовать протокол NTLM для сетевой аутентификации в доменах Windows 2000, однако, когда есть выбор в среде Windows 2000 по умолчанию будет использоваться второй протокол- Kerberos

2) Kerberos v. 5 является стандартным средством аутентификации сетевых пользователей в Active Directory домене на компьютерах с ОС Windows 2000 и выше.

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

1. Цербер реализует более эффективную аутентификацию на серверах.

В отличии от процесса аутентификации по протоколу NTLM серверу приложений не нужно подключаться к контроллеру домена каждый раз при проверке каждого пользователя. Kerberos производит аутентификацию за счет проверки «удостоверения», предоставленного клиентом, которое он получает от контроллера домена единожды, после чего может многократно использовать его на протяжении всего сеанса работы в сети.

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

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

4. Одним из основных достоинств механизма взаимной аутентификации, реализуемого протоколом Kerberos, является упрощенное управление доверительными отношениями, что означает, что доверительные отношения между доменами Windows 2000 по умолчанию являются двусторонними и транзитивными, в следствие чего в сетях с множеством доменов не приходится устанавливать множество явных доверительных отношений. Реализуется это как бы сведением всех доменов большой сети в дерево транзитивных отношений взаимного доверия, то есть удостоверение, выданное системой безопасности одного любого домена, может приниматься во всех ответвлениях дерева, если сеть содержит несколько «деревьев», то удостоверение любого из них будет приниматься в любых других «деревьях».

5. Широкая распространенность Kerberos 5, обеспечивает повсеместную совместимость протокола. Благодаря подходу использования стандартных спецификаций, рекомендованных группой IETF, аутентификация клиентов Windows 2000 возможна во всех сетях, поддерживающих Kerberos.

1.3 Основные принципы работы протокола Kerberos

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

Развернем это определение в объектно-прикладную плоскость. Например, двое человек, Алёна часто направляет в адрес Стива некие сообщения, причем Стив использует содержащуюся в них информацию лишь в том случае, когда полностью уверен, что сообщение поступило именно от Алёны. Для этой цели они условились использовать пароль, которые знают только они двое. То есть если из текста сообщения можно сделать вывод о том, что отправитель знает общий пароль, то Стив может точно сказать: сообщение пришло от Алёны. Далее следует понять и решить, каким образом подтвердить своё знание пароля. Самым простым и очевидным решением выглядит включение пароля в текст сообщения в условленном месте, например “Dear, Steve!$SharedPAssword”, и действительно, это было бы идеальным решением при условии, что никто другой не может прочитать их переписку, однако почта передается по сети, что подразумевает наличие других пользователей, среди которых есть некто Эдвард, большой любитель анализировать сетевой траффик своим самописным анализатором пакетов в надежде перехватить чей-либо «общий секрет». Тем самым вся очевидность и удобность вышеизложенного решения сходит на нет, чтобы общий пароль оставался секретным, о нем не следует говорить открыто, нужно опосредованно дать знать напарнику, что он тебе известен.

Вот мы и подошли к сути: данная проблема решается использованием протокола Kerberos с помощью средств криптографии (использованием секретного ключа) и доверенного посредника. Но обо всем по порядку.

1.4 Аутентификация (аутентификаторы)

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

- некий пользователь стучится в сетевую дверь некого сервера и просит разрешения на вход. Чтобы пользователю доказать, что он именно тот, за кого себя выдает и имеет право на вход ему следует предъявить аутентификатором (authenticator), который с учетом рассматриваемой нами темы является зашифрованным с помощью секретного ключа специальным блоком информации. При этом информация, содержащаяся в этом блоке должна меняться при каждом последующем сеансе работы в сети, иначе предполагаемый злоумышленник получает возможность воспользоваться перехваченным аутентификатором (атака повторного воспроизведения). Получив аутентификатор, «привратник» расшифровывает его и проверяет полученную информацию, чтобы убедиться в успешности дешифрования. При условии, что всё прошло нормально, «привратник» удостоверяется, что пользователю, предъявившему аутентификатор известен секретный ключ, а так как это ключ знают лишь двое – один из них «привратник», то вполне справедливо сделать вывод, что стучащийся именно тот человек, за кого себя выдает. Возможен так же механизм взаимной аутентификации. В данном случае используется тот же принцип, но в обратном порядке и с некоторыми модификациями: «привратник» извлекает из исходного блока часть информации, а затем опять шифрует её, получая при этом новый аутентификатор и направляет его стучащемуся в дверь. Тот же расшифровывает полученную информацию и сравнивает её с исходной, если всё совпадает, то вывод получается следующим: если «привратник» расшифровал оригинал, значит он знает секретный ключ.

Итак, вернемся в объектно-прикладную плоскость. Допустим Алёна и Стив условились, что перед тем как пересылать информацию между своими компьютерами, они будут с помощью известного им двоим секретного ключа проверять кто есть кто на разных концах линии связи. Допустим Алёна в данном примере играет роль осторожного гостя, а Стив – бдительного привратника, таким образом процесс аутентификации будет выглядеть следующим образом:

1. Алёна направляет в адрес Стива сообщение, в котором содержится

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

1. Стив получает сообщение и видит, что оно пришло от некого чело

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

Стиву было бы намного проще, если бы его компьютер работал синхронно с компьютером Алёны, поэтому есть смысл предположить, что оба они синхронизируют системное время рабочих станций с сетевым временем, тем самым часы на их машинах идут практически одинаково. Далее уместно допущение, что часы на компьютерах Стива и Алёны никогда не расходятся более чем на 5 минут. При указанных допущениях Стив может сравнивать извлеченное из второго поля аутентификатора значение с текущим системных временем на своей машине и если расхождения составит более пяти минут компьютер согласно протокола автоматически откажется признавать подлинность аутентификатора. В обратном же случае, если расхождение по времени окажется в пределах допустимого значения, то есть менее пяти минут, то можно с большой долей уверенности предположить, что аутентификатор пришел именно от Алёны. Тем не менее, данных выводов не достаточно, нужна полная уверенность, ведь существует возможность перехвата предыдущей попытки Алёны выйти на связь со Стивом и использование её «старого» аутентификатора. Однако, если на компьютере сохранились записи о времени аутентификаторов, присланных от Алёны за последние 5 минут, то Стив способен найти последний и отказаться от всех других сообщений, отправленных одновременно с ним или ранее. Но если второе поле с меткой времени говорит о том, что сообщение ушло в сеть уже после отправки последнего аутентификатора Алёны, то его автором вполне могла быть Алёна.

3. Стив шифрует поле времени из сообщения Алёны при помощи их общего ключа и прикрепляет его в собственное сообщение в направлении Алёны. Следует отметить, что Стив возвращает Алёне не всё содержимое её аутентификатора, а только шифрованную метку времени. При отправке всего сразу у Алёны бы возникли подозрения, что кто-то вероятно притворившись Стивом попросту скопировал его аутентификатор из её исходного сообщения и без модификации оного отправил назад. В полученном письме содержится лишь часть информации, что свидетельствует о том, что получатель исходного аутентификатора смог расшифровать его содержимое, обработать его и правильным образом (общим ключом) зашифровать обратно. Использование метки времени обусловлено тем, что это поля является уникальным идентификатором сообщения Алёны. Алёна получив ответ от Стива расшифровывает его, и сравнивает метку времени с данными времени указанными в исходном аутентификаторе. При совпадении этих данных, Алёна может быть уверена, что её аутентификатор дошел до кого-то кто знает их со Стивом общий секретный ключ, смог расшифровать его и извлечь данные о времени, учитывая тот факт, что ни Стив, ни Алёна свой ключ никому не передавали, то справедлив вывод, что именно Стив получил аутентификатор Алёны и ответил на него. Механизм взаимной аутентификации представлен на рисунке 1.

Рисунок 1.

Теперь, когда ясен механизм простой взаимной аутентификации вроде того, что описан выше, мы сталкиваемся со следующей проблемой. В примере со Стивом и Алёной мы не упомянули место, в котором они договариваются о секретном ключе для своей переписки. Нет, конечно люди могут встретиться где-нибудь в парке и обсудить все детали, но в сетевой картине договариваются машины. В дальнейшем мы будем под Алёной подразумевать клиентскую программу, а под Стивом сетевую службу на сервере. При подобном раскладе очевидно, что клиентская программа и серверная служба сами по себе встретится не могут, тем более если у Алёны-клиента есть задача посылать сообщения на несколько серверов появляется еще одна проблема – для каждого из них придется обзавестись отдельным секретным ключом. Да и Стиву - серверу потребуется столько ключей, сколько у него клиентов. То есть если каждой клиентской программе для поддержания связи с каждой сетевой службой требуются уникальный ключ, и такой же ключ нужен каждой службе для каждого клиента, то задача обмена ключами становится достаточно острой проблемой. Эту проблему как раз-таки и решает рассматриваемый нами протокол Kerberos.

Из самого названия протокола понятно, что он задуман для решения проблемы управления ключами. Персонаж греческой мифологии Цербер – это огромный трёхголовый пёс, охраняющий врата в царство мёртвых. Проводя аналогию можно увидеть соответствие трех голов Цербера трём участкам безопасной связи: клиент, сервер и доверенный посредник. Роль посредника между ними играет центр распределения ключей Key Distribution Center, далее KDC, который в контексте данной работы, будучи установленным на отдельной машине является сервером аутентификации Kerberos (Цербер) для отдельного домена.

KDC являет собой специальную службу, запущенную на физически защищенном сервере, где она ведет базу данных с информацией по учётным записям всех главных абонентов безопасности (security principal) своей области ответственности. Под областью ответственности в сетях Windows 2000 и выше подразумевается домен, в дальнейшем, для удобства мы будем использовать этот термин. В базе данных KDC по мимо данных о каждом абоненте безопасности хранится и криптографический ключ, известный только абоненту и службе KDC. Этот ключ называется долговременным и используется для установления связи между пользователем системы безопасности и центра распределения ключей. Чаще всего при реализации протокола Kerberos долговременные ключи генерируются на основе пароля пользователя. Когда клиенту требуется обратиться к серверу, он сначала направляет запрос в KDC, который в свою очередь направляет каждому участнику предстоящего сеанса связи копии уникального сеансового ключа (session key), с коротким периодом действия. Назначение такого ключа в проведении аутентификации клиента и сервера. Копия ключа, направляемая на сервер шифруется при помощи долговременного ключа этого сервера, а направляемая клиенту соответственно с помощью долговременного ключа клиента.

Рисунок 2. Теоретическое управление ключами

В теории, для работы в качестве доверенного посредника KDC достаточно направлять сеансовые ключи как показано выше – непосредственно абонентам безопасности. Однако же на практие реализовать такую простую схему очень ресурсозатрано и как следствие очень сложно. В этом случае, серверу пришлось бы хранить свою копию сеансового ключа в памяти до попытки клиента связаться с ним. Причем сервер обслуживает множество клиентов, поэтому ему придется хранить ключи всех клиентов, которые могут связаться с ним. При таких условиях функция управления ключами перетянет на себя значительную часть вычислительной мощности сервера, что в свою очередь ограничивает возможность масштабирования сети. Так же следует принять во внимания возможные коллизии при прохождении сетевого траффика: вполне возможно, что запрос от клиента, получившего сеансовый пароль, поступит на сервер раньше, чем сеансовый ключ от KDC, тем самым сервер будет вынужден ждать с ответом, пока не получит свою копию ключа, что еще больше нагружает сервер. Поэтому при реализации протокола Kerberos используется иная схема управления ключами – с помощью сеансовых мандатов.

РАЗДЕЛ 2. Система мандатов.

2.1 Сеансовые мандаты

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

Рисунок 3. Схема аутентификации с использованием сеансового мандата.

Следует отметить, что в данном случае функции центра распределения ключей ограничиваются генерацией сеансового мандата и службе KDC более нет нужды отслеживать статусы доставки сообщений соответствующим адресатам. В случае же если какое-либо из сообщений попадет не по адресату, - ничего страшного не случится, так как расшифровать клиентскую копию сеансового ключа может только тот, кто владеет долговременным ключом клиента, а расшифровать сеансовый мандат способен тот только тот, кто владеет долговременным ключом сервера. Итак, получив ответ от KDС, клиентская машина извлекает из полученного блока сеансовый мандат и свою копию сеансового ключа, который помещает в безопасное хранилище в области оперативной памяти. В момент возникновения необходимости связаться с сервером, клиент посылает ему блок информации состоящий из сеансового мандата, который зашифрован долговременным ключом этого сервера и клиентского аутентификатора, зашифрованного с помощью сеансового ключа, полученного от KDC при первоначальном обращении к нему. Собственно, сам сеансовый мандат в комплексе с аутентификатором и является удостоверением, по которому сервер доподлинно определяет «личность» обратившегося к нему клиента.

Рисунок 4. Взаимная аутентификация клиент-сервер.

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

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

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

2.2 Мандат на выдачу мандатов

Ранее отмечалось, что обычно долговременный ключ пользователя создается на основе его пароля. Когда Алёна проходит регистрацию, клиент клиент Kerberos, установленные у неё на машине, обрабатывает её пароль с помощью функции хэширования, при помощи одного из алгоритмов DES-CBC-MD5 или других. В результате на выходе получаем криптографический ключ. В KDC получившейся долговременный ключ Алёны хранится в базе данных с учетными данными пользователей. Получая запрос от клиента, KDC заглядывает в свою базу данных и находит в ней учетную запись нужного пользователя, в нашем примере Алёны, далее извлекая соответствующий пользователю долговременный ключ.

Процесс вычисления одной копии ключа по пользовательскому паролю и извлечения другой его копии из базы данных выполняется единожды за сеанс, при первом входе пользователя в сеть. После получения пользовательского пароля и вычисления долговременного ключа клиент Kerberos на машине пользователя запрашивает сеансовый мандат и сеансовый ключ, котырые впоследствии и используются во все последующих транзакциях с KDC в течении текущего сеанса работы в сети. Для установления первичного сеанса связи с KDC, при первом обращении KDC отвечает специальным сеансовым мандатом, так называемый мандат на выдачу мандатов (ticket-granting ticket), или TGT мандат. Как и обычный сеансовый мандат, TGT имеет копию сеансового ключа для связи службы с клиентом (KDC-клиент). Манндат TGT шифруется при помощи долговременного ключа центра KDC, а клиентская копия сеансового ключа посредством долговременного ключа пользователя.

Ответ от KDC на первоначальный запрос клиента, расшифровывается и из него извлекается клиентская копия сеансового ключа с использованием своего долговременного ключа пользователя из своей кэш-памяти. Как правило, после этого долговременный ключ, полученный из пользовательского пароля можно удалить из памяти, так как он больше не нужен, потому что вся последующая связь центра KDC с клиентом будет шифроваться с помощью сеансового ключа. Как и все остальные сеансовые ключи, он имеет временный характер и действителен до истечения срока действия мандата TGT или до момента выхода пользователя из системы. В связи с этим такой ключ называется сеансовым ключом регистрации (logon session key). Сам по себе мандат TGT почти ничем не отличается от обычного. Перед обращением к той или иной службе, клиент сначала обращается к своей кэш-памяти удостоверений и ищет там сеансовый мандат для этой конкретнйо службы. При его отсутствии, клиент находит там же TGT мандат, извлекает оттуда сеансовый ключ регистрации, компонует с его помощью аутентификатор, который высылает вместе с TGT обратно в центр KDC, причем одновременно с этим высылается запрос на сеансовый мандат для нужнуго сервера и службы. По факту выходит, что организации защищенного доступа к KDC не имеет отличий от организации такого доступа к любому другому серверу домена, ведь требуемой набор остается тем же: аутентификатор, сеансовый ключи и мандат (в случае с KDC – мандат TGT). Со стороны же KDC, TGT мандаты позволяют ускорить обработку запросов на получение мандатов. Центр KDC обращается к долговременному ключу пользователя лишь однажды, когда предоставляет клиенту мандат TGT, во всех дальнейших транзакциях с этим клиентом центр распределения ключей расшифровывает мандаты TGT при помощи своего долговременного ключа и извлекает из него сеансовый ключ регистрации, который и используется для проверки аутентификатора клиента.

2.3 Аутентификация за пределами домена

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

Для описания приципа междоменной аутентификации для примера рассмотрим простую сеть в составе двух доментов «Москва» и «Саратов». Допустим, что администраторы этих двух доменов являются сотрудниками одной фирмы или существует иная веская причина требующая уравнять в правах доступа пользователей одного домена с другогим доменом. В любом случае наладить аутентификацию между доменами будет не трудной, для этого следует договориться о едином междоменном ключе, который в Windows 2000, например, генерируется автоматически, когда между доменами устанавливаются доверительные отношения). В момент создания ключа, служба выдачи мандатов каждого домена регистрируется в KDC другого домена в роли главного абонента безопасности, после этого служба KDC, а именно служба выдачи мандатов каждого из доменов начинает рассматривать службу выдачи мандатов второго домена в качестве еще одной своей службы. В результате клиент, прошедший аутентификацию и получивший определенные права в системе, получает и возможность запрашивать и получать сеансовые мандаты для неё.

Далее рассмотрим процесс при котором пользователь с учетной записью в домене «Москва» запрашивает доступ с службе из домена «Саратов». Клиент Kerberos на машине пользователя направляет запрос в KDC своего домена, где просит выдать сеансовый мандат на сервер расположенный в другом домене. Центр KDC, аточнее её служба выдачи мандатов проверяет свою базу данных абонентов безопасности и видит, что такого сервере среди абонентов нет, поэтому служба отправляет клиенту не сеансовый мандат, а мандат переадресации (referal ticket),который из себя представляет TGT мандат зашифрованный междоменным ключом, общим для центров KDC доменов «Москва» и «Саратов». Клиент же, по получении этого мандата переадресации, использует его для подготовки следующего запроса на на сеансовый мандат. Отличие в том, что в этот раз запрос направляется в KDC того домена, где находится абонентская запись искомого сервера, в нашем случае домена «Саратов». Его служба выдачи мандатов принимает попытку расшифровать TGT мандат из домена «Москва» при помощи своей копии междоменного ключа, при успехе этой попытки, KDC домена «Саратов» отправляет обратившемуся клиенту сеансовый мандат для доступа к соответствующей службе своего домена.

Схема переадресации запросов может быть порядочно усложнена в таких сетях, где развернуто более двух доменов. Казалось бы, всё просто, в теории центр KDC каждого домена может наладить связь с каждым центром KDC других доменов, договорившись каждым о б использовании индивидуального междоменного ключа. Однако не сложно представить насколько количество и сложность таких связей возрастет и на сколько сложно будет выстроенно управление ими. Kerberos имеет решение и для этой проблемы: клиент каждого домена можует получить доступ к серверу другого домена через один и более промежуточный сервер, каждый из которых выдаст ему мандат переадресации.

Для более наглядного описания обратимся к уже известным нам доменам «Москва» и «Саратов», а так же добавим третий домен «Арвендейл». В центре KDC домена «Москва» отсутствует междоменной ключ для KDC домена «Саратов», но центры распределения ключей обоих доменов уже установили связь с доменом «Арвендейл». Когда клиентской машине из домена «Москва» понадобится сервер из домена «Саратов», её запрос будет пару раз переадресован. Во-первых, клиент сначала обратится в центр KDC своего домена, далее пакет попадет на промежуточный сервер «Арвендейл», а уже затем пакет направляется в KDC домена «Саратов», которому известен сеансовый ключ нужного сервера, то есть выходит, что клиент посылает сеансовый мандат три раза в три разные службы KDC. Пошагово вышеописанный процесс выглядит так:

1. Пользователь-клиент запрашивает у центра распределения ключей домена «Москва» мандат на доступ к службе сервера «Саратов». Служба KDC «Московоского» домена возвращает клиенту мандат переадресации в KDC домена «Арвендейл», зашифрованный общим для доменов «Москва» и «Арвендейл» междоменным ключом.
2. Клиент направляет запрос в службу KDC домена «Арвендейл» с вопросом о выдаче сеансового мандата на доступ к серверу домена «Саратов». Центр распределения ключей домена «Арвендейл» возвращает клиенту мандат переадресации в KDC домена «Саратов», зашифрованный междоменным ключом, общим для доменов «Арвендейл» и «Саратов»
3. В итоге клиент обращается в KDC домена «Саратов» с запросом на сеансовый мандат для доступа к серверу, находящемуся в зоне ответственности этого домена. Центр KDC домена «Саратов» отправляет в адрес клиента сеансовый мандат на доступ к нужному серверу.

2.4 Подпротоколы.

2.4.1 AS Exchange

Далее будет уместно разобрать три существующих подпротокола протокола Kerberos. Первый из них применяется центром распределения ключей для отправки клиенту сеансового ключа регистрации и TGT мандата. Называется он Authentication Service Exchange (обменный сервис аутентификации), так же допустимо применение в сокращенной форме – AS Exchange. Следующий, второй подпротокол использующийся для отправки служебных сеансовых ключей и сеансовых ключей самого центра KDC называется Ticket-Granting Service Exchange (служба обмена мандатами). Последний, третий подпротокол, Client/server Exchange (клиент-серверный обмен) нужен клиенту для пересылки сеансового мандата доступа к сервисам.

Для лучшего понимания схемы взаимодейтсвия подпротоколов следует обратиться к нашим старым знакомым в следуещем качестве: Алёна – пользователь сети, а Стив – сервер.

Рисунок 5. AS Exchange подпротокол.

Центр KDC получая запрос KRB_AS_REQ, ищет в своей базе данных соответствующий учетной записи Алёны её долговременный ключ, расшифровавыет с помощью него блок данных предварительной аутентификации и проверяет метку времени, хранящуяся в нем. При успешной провереке, служба KDC делает закономерный вывод, что информация в блоке предварительной аутентификации была зашифрована долговременным ключом Алёны, что значит это информация поступила от клиента, имя которого содержится в первой части блока. После успешной проверки личности Алёны, центр распределения ключей формирует удостоверение, подтверждающее, что клиентская программа протокола Kerberos на её машине имеет право направить запрос в службу выдачи мандатов. Этот процесс состоит из двух шагов:

1. Центром KDC формирует сеансовый ключ регистрации и шифрует его с помощью долговременного ключа Алёна.
2. Центр формирует TGT мандат включая туда еще одну копию сеансового ключа регистрации, данные авторизации Алёны. Вместе с этой информацией KDC шифрует TGT мандат своим долговременным ключом. Затем зашифрованный сеансовый ключ регистрации вместе с TGT мандатом собирается в пакет Kerberos Authentication Service Reply (KRB_AS_REP) – ответ службы аутентификации Kerberos, который отправляется клиенту.

Получив это сообщение, клиент применяет свой долговременный ключ

для расшифровки сеансового ключа регистрации и помещает его в свою кэш-память удостоверений вместе с так же извлеченным TGT мандатом.

2.4.2 TGS Exchange

Клиентская программа Kerberos, установленная на машине Алёны, посылает запрос на получение удостоверения на доступ к службе на сервере Стив в виде сообщения KRB_TGS_REQ (Kerberos Ticket-Granting service request - запрос к сервису выдачи мандатов Kerberos) в адрес KDC. В этом сообщении заключена информация об имени пользователя, аутентификатор, зашифрованный сеансовым ключом регистрации Алёны, TGT мандат, полученный при взаимодействии по подпротоколу AS Exchange, а так же имя службы, к которой запрашивается доступ.

Рисунок 6. Подпротокол TGS Exchange

Получив блок информации KRB_TGS_REQ, центр дистрибуции ключей используя свой секретный ключ расшифровывает TGT мандат и достает из него сеансовый ключ регистрации Алёны, который в свою очередь используется для расшифровки аутентификатора Алёны. При успешной проверке её аутентификатора, центр KDC извлекает из TGT мандата регистрацинные данные Алёны и создает сеансовый ключ общий для клиента Алёны и сервера Стива. Первую копию этого сгенерированного ключа KDC шифрует сеансовым ключом регистрации Алёны, а другую копию вместе с информацией об авторизации Алёны помещает в сеансовый мандат, который шифрует долговременным ключом сервера Стива. После этих манипуляций блок информации который и является по сути удостоверением Алёны включается в пакет KRB_TGS_REP (Kerberos Ticket-Grating Service Reply – ответ службы выдачи мандатов Kerberos) и отправляется обратно на рабочую станцию Алёны. Служба Kerberos на компьютере Алёны получив этот пакет, расшифровывает его своим сеансовым ключом регистрации и получает таким образом сеансовый ключ доступа к запрашиваемой службе и помещает его в свою кэш-память удостоверений, извлекаемый далее сеансовый мандат на доступ к службе так же сохраняется в кэш-памяти.

2.4.3 CS Exchange

Сервис Kerberos, установленный на клиентской машине Алёны посылает запрос к серверу Стив, для чего направляет сообщение KRB_AP_REQ (Kerberos Application Request – запрос уровня приложений Kerberos). Это сообщение сообщение представляет собой аутентификатор Алёны, зашифрованный сеансовым ключом для сервера Стива, мандат, полученный посредством протокола TGS Exchange, а так же флаг, свидетельствующий о желании клиента произвести процесс взаимной аутентификации, причем наличие или отсутствие данного флага определяется общей конфигурацией Kerberos, по умолчанию он устанавливается без участия пользователя и без каких-либо дополнительных запросов.

Рисунок.7. Подпротокол CS Exchange

Сервер Стив, приняв сообщение KRB_AP_REQ, расшифровывает мандат и получает из него данные авторизации Алёна и сеансовый ключ, которым далее расшифровывает аутентификатор Алёны. При условии, что метка времени, содержащаяся в аунтификаторе, успешно проходит проверку, то сервер проверяет наличие флага взаимной аутентификации. При его обнаружении, Стив шифрует поле времени из аутентификатора Алёны сеансовым ключом, полученным ранее, включает полученный результат в блок данных KRB_AP_REP (Kerberos Application Reply – ответ уровня приложений Kerberos) и отправляет его обратно на машину Алёны. Клиент Kerberos рабочей машины Алёны получив пакет KRB_AP_REP расшифровывает аутентификатор Стива при помощи сеансового ключа и сравнивает извлеченную метку времени с исходной, которую направляла в первом запросе. При их совпадении делается вывод, что линк установлен с искомой службой, и можно приступать к совместной работе.

РАЗДЕЛ 3. Содержимое мандатов. Ины механизмы аутентификации. Уязвимости.

3.1 Мандаты в деталях

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

Таблица 1 – Структура мандата

Название поля	Описание
	В первых трёх полях содержится «несекретная» информация, пересылаемая открытым текстом и, соответственно, не подвергаемая процедуре шифрования. Эти поля необходимы клиенту для управления мандатами, хранящимися в кэш-памяти.
tkt-vno	Версия мандата (номер версии формата мандата). Для актуальной версии протокола Kerberos за номером 5 в этом поле указывается цифра 5.
Realm	Название домена, где был создан мандат. Центр распределения ключей генерирует мандаты только для серверов и клиентов «родной» области, поэтому в этом поле фактически указывается имя области «домена» где расположен сервер с развернутым на нем KDC.
Sname	Имя сервере для которого сгенерирован мандат
Flags	Флаги мандата
Key	Сеансовый ключ
Crealm	Клиентский домен
Cname	Называние клиента
Transited	Список доменов с развернутым сервером Kerberos, с помощью которых осуществлялась аутентификация клиента, которому выдан мандат. Иначе, основываясь на самом названии – список транзитных областей (доменов).
Authtime	Время первичной аутентификации клиента. Это поля заполняется в момент генерации центром KDC TGT мандата и в дальнейшем при генерации мандатов на основе TGT временная метка из поля authtime TGT мандата копируется в поле authtime генерируемого мандата.
Starttime	Время вступления мандата в силу.
Endtime	Время окончания срока действия мандата.
renew-till	Необязательное поле. Максимальное значение поля endtime, задаваемое флагом RENEWABLE.
Caddr	Не обязательное поле. Здесь указывается один или несколько адресов, из которых может использоваться этот мандат. При отсутствии информации в этом поле мандатом можно воспользоваться из любого адреса.
Authorization-data	Необязательное поле. Атрибуты, определяющие привилегии клиента, интерпретируемые службой к которой клиент обратился.

Содержимое поля flags имеет длину равную 32 битам и соответственно флаги этого поля имеют логический тип данных, true или falser (1 или 0 соответственно) Содержимое поля flags адресуется побитно. Включение и выключение флагов здесь производится изменением значения (0 или 1) соответствующего бита. Для администратора сервера Kerberos интерес представляют основные 5 флагов приведенные в таблице ниже.

Таблица 2 – Флаги мандата

Флаг	Описание
FORWARDABLE	Данный флаг свидетельствует о том, что на основании этого TGT мандата TGS может генерировать новый TGT мандат с иным сетевым адресом. (флаг содержится только в TGT мандатах).
FORWARDED	Флаг FORWARDED указывает на то, что данный TGT мандат был переадресован или сгенерирован Указывает на то, что данный TGT мандат был переадресован или генерирован на основе другого TGT мандата.
PROXY	Данный флаг свидетельствует о том, что сетевой адрес, указанный в данном мандате отличается от адреса, в TGT мандате, на основании которого он сгенерирован.
RENEWABLE	Разрешается периодическое обновление времени действия мандата сервером выдачи мандатов. Используется в сочетании с информацией, содержащейся в поляк endtime и renew-till.
INITIAL	Указывает на первичность данного мандата на выдачу мандатов. Поле содержится только в TGT мандатах, полученных от сервера аутентификации AS.
PRE-AUTHENT	Флаг предварительной аутентификации указывает на то, что перед выдачей мандата AS сервер уже аутентифицировал клиента. В протоколе версии MIT предварительная аутентификация осуществляется по шифрованной метке даты-времени.
MAY-POSTDATE	Сообщает KDC о том, что на основании этого мандата на выдачу мандата может быть выдан отсроченный или недействительный сеансовый мандат. При получении клиентом от AS сервера TGT мандата с данным флагом, то в дальнейшем он может использоваться такой мандат для запроса мандата с флагами POSTDATED или INVALID
POSTDATED	Указывает на то, что данный мандат просрочен.
INVALID	Указывает на недействительность мандата в данный момент времени и на необходимость подтверждения в TGS перед использованием. Использование этого флага может быть полезно при выполнении длинных пакетных заданий на сервере, которые периодически требуют мандат. Клиент сразу может получить требуемое количество мандатов для соответствующего сеанса с распределенными значениями времени, при чем все мандаты кроме первого недействительны. Если в ходе выполнения пакетного задания наступает момент времени, когда необходим новый мандат, клиент подтверждает в TGS следующий подходящий по времени мандат. При реализации такой схемы клиенту нет необходимости повторно использовать TGT мандат для запроса сеансового мандата.

3.2 Ограничение доступа к данным мандата

Необходимость в знании клиентом некоторой части информации, содержащейся в как в обычных сеансовых мандатах так и TGT мандатах обусловленна необходимость управления своей кэш-памятью удостоверений. Клиенту необходимо знать часть информации, содержащейся как в обычных мандата, так и в TGT мандатах, чтобы управлять своей кэш-памятью удостоверений. Когда центр распределения ключей, при помощи подпротоколов AS Exchange или TGS Exchange, возвращает мандат и сеансовый ключ, упаковывая клиентскую копию сеансового ключа в блок данных, где уже могут быть заполнены паля authtime, endtime, flags, renew-till, starttime, причем вся эта структура шифруется при помощи долговременного ключа клиента и включается в пакет KRB_AS_REP или KRB_TGS_REP и направляется на рабочую станцию клиента.

3.3 Срок «жизни» мандата

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

Когда клиент запрашивает в центре распределения ключей мандат на доступ к службе, он имеет возможность указать конкретное время начала его действия. Если он этого не сделал или попытался указать время, которое по системным часам сервера KDC уже прошло, то KDC указывает в поле starttime свое текущее системное время. При этом независимо от того указал ли время начала действия мандата пользователь или KDC, запрос обязательно должен содержать в себе время прекращения его срока действия. При получении такого запроса служба KDC прописывает значние поля endtime суммируя наибольший срок дейтсвия мандата, беря этот параметр из политики безопасности Kerberos, со значением поля starttime. Для этого она суммирует наибольший срок действия мандата, предусмотренный политикой Kerberos, со значением поля starttime, а затем проводит сравнение полученного результата со временем прекращения действия мандата, указанным в запросе клиента. Если они не совпадают, в поле endtime заносится то время, которое наступит раньше.

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

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

3.4 Обновляемые TGTмандаты

Один из элементов защиты сеансовых ключей это частая их смена. В настройках политики Kerberos предусматривается относительно небольшой срок жизни сеансовых мандатов. Есть иной способ и заключается он в использовании обновляемых мандатов. Таким образом получается использовать переодическое обновление сеансовых ключей без нужды запрашивать новый сеансовый мандат. При условии, что настрйоками политики Kerberos разрешено применение обновляемых мандатов, то центр KDC в каждый генерируемый мандат включает флаг RENEWABLE и два срока жизни мандата – первый из них ограничевает срок действия текущего экземпляра мандата, а второй определяет в течении какого времени этот мандат может быть обновлен. Поле endtime описывает срок действия текущего экземпляра мандата. Как и в случае с необновляемыми мандатами, значение вышеуказанного поля равняется сумме значения из поля starttime и значения наибольшего срока действия мандатов, установленного политикой Kerberos. При использовании обновляемого мандата, клиент предоставляет в центр KDC обновляемый мандат для его обновления до времени указанного в поле endttime. Одновременно с ним в KDC направляется и новый аутентификатор. Получив мандат, который следует обновить, центр KDC проверяет общий срок его жизни, указанный в поле renew-till, заданным при первоначальной генерации мандата. То есть если время, указанное в поле renew-till еще не наступило, то центр KDC генерирует новый экзмемпляр мандата, где меняется сеансовый ключ и сдвигается время endtime. Такие возможности дают администратору инструменты для предусмотрения в политике Kerberos достаточно частое обновление мандатов. Частая смена сеансовых ключей в процессе обновления мандатов резко снижает риск их компрометирования, при этом администратор так же может установить наоборот, довольно длительный «срок годности» мандата – неделю, месяц или больше. По истечении этого срока мандат полностью приходит в негодность и обновлению не подлежит.

3.5 Делегирование аутентификации

Использование протокола Kerberos в многоуровневых клиент-серверных информационных системах сопряженно с определенным сложностями. Так, клиент может подключаться к серверу, который подключается к серверу более высокого уровня. Для этого первому серверу понадобится мандат на подключение ко второму, причем такой мандат должен ограничивать доступ первого сервера ко второму лишь тем функционалом, на который клиент имеет права. Для этого в протоколе предусмотрен специальный механизм под названием «делегирование аутентификации». Упрощенно, клиент разрешает серверу № 1 провести свою аутентификацию для сервера № 2. Для этого он уведомляет центр распределения ключей о том, что данный конкретный сервер имеет право представлять клиента.

Делегирование аутентификации реализуется двумя способами. Во-первых, клиент получает мандат на подключение к серверу высшего уровня, а затем передает его ближайшему серверу. Мандаты, полученные таким образом называются представительскими или proxy мандатами. Основное препятствие для реализации первого варианта — это необходимость клиенту знать имя сервера высшего уровня. Для преодоления этого препятствия и существует второй способ делегирования аутентификации. В этом случае клиент передает на ближайший сервер свой TGT мандат, который тот использует для запроса своих мандатов. TGT мандаты полученные по удостоверению клиента называются передаваемыми (forwarded). Политикой Kerberos определяется какой из вышеописанных способов будет использоваться.

3.6 Известные уязвимости

Основная критическая уязвимость, просуществовавшая, представьте себе, аж 21 год получила поэтическое название «Лира Орфея» (Orpheus’ Lyre). Согласно всё той же греческой мифологии Аполлон подарил Орфею лиру, звуки которой обладали чудесными свойствами: с помощью неё возможно было укрощать диких животных, перемещать горы и леса. Более того её звуки способны были усыплять трёхглавого пса Цербера, охраняющего вход в Аид, в честь которого и назван протокол.

Рассматриваемая уязвимость на самом деле явила себя еще в 1996 году, но описана публично и закрыта только в июле 2017 года. Лира Орфея затрагивает две из трех реализаций протокола: Microsoft Kerberos для операционных систем семейства Windows и Heimdal Kerberos для *nix-based систем, включая MacOS. Оригинальная реализация Массачусетского технологического университета не подвержена уязвимости.

Уязвимость была обнаружена исследователями безопасности Джеффри Альтманом (Jeffrey Altman), Виктором Духовны (Viktor Duchovni) и Нико Вильямсом (Nico Williams). Согласно их объяснениям, найденная ошибка всего в двух строчках кода может быть использована злоумышленником, находящимся в позиции «man-in-the-middle» для хищения полномочий и повышения с их помощью привилегий для обхода шифрования, используемого в Kerberos. «Изначальным криптографическим пороком» протокола, по словам исследователей, было обилие открытого незашифрованного текста в мандатах, из которого злоумышленником могут извлекаться метаданные для последующего использования в атаке. То есть, до исправления уязвимости, в своей работе Kerberos системы метаданные извлекались не из аутентифицированного и зашифрованного блока данных отклика KDC, а из не аутентифицированного открытого текста. Таким образом атакующий в позиции человека-по-середине (между клиентом и сервером) может выдать себя за некую службу для клиента.

Для более подробного описания уместно будет привести пример из жизни, к примеру, возьмем билет на самолет. Есть у нас билет до Москвы, где пункт назначения четко пропечатан, но при предъявлении при регистрации на рейс на Хабаровск я настаиваю, что в билете пункт назначения – аэропорт города Хабаровска. И сотрудник на стойке регистрации мне верит.

Так и программное обеспечение Kerberos в функции _krb5_exctract_ticket() получает значение имени службы и домена в KDC-REP из незашифрованной части мандата kdc_rep.ticke.sname и kdc_rep.ticket.realm, а должно из шифрованной части ent_part (encrypted part).

Рисунок 8. Уязвимый код

В настоящее время корпорация Microsoft выпустила обновление безопасности закрывающее эту дыру безопасности под обозначением CVE-2017-8495. Версии с открытым исходным кодом в поддерживаемых и обновляемых*nix системах так же исправлены.

Вторая уязвимость лишь опосредованно касается протокола Kerberos. Она применима лишь в том случае, когда Kerberos для обеспечения аутентификации с устаревшими ОС, или в случае невозможности по какой-либо причине произвести аутентификацию посредством Kerberos, передает процесс аутентификации NTLM (NT Lan Manager). Эта уязвимость под кодом CVE-2017-8563 описывает на самом деле два варианта атаки. Обе варианта позволяют злоумышленнику похитить учетные аутентификации NTLM в момент аутентификации клиента при подключении к «расшаренной» сетевой папке и передать их на сервер.

В первом варианте, LDAP (Lightweight Directory Access Protocol, облегченный протокол доступа к папкам) позволяет злоумышленнику с привилегиями уровня SYSTEM использовать входящие NTLM-сессии и производить LDAP-операции, например, обновление доменных записей под привилегиями администратора.

Второй вариант касается защищенного административного режима при работе посредством удаленного доступа (RDP Restricted admin mode) в Windows системах. Данный «баг» позволяет скомпрометировать пользователя RDP- сессии, подключающегося к скомпрометированной системе. Уязвимость имеет место в связи с тем, что защищенный административный режим при использовании в сессии удаленного доступа позволяет передать процесс аутентификации в процессе установления соединения NTLM системе. Так как сценарии использования RDP ограничены пользователями с высокими привилегиями доступа, эти учетные данные находятся в «зоне риска» и могут «утечь» на сторонний сервер и использоваться в последствии для создания несанкционированных учетных данных атакуемого домена. Для избегания подобного рода опасностей рекомендуется добавлять подпись в SMB и LDAP пакетах при настройке Group policy (политиках групп), а также использовать анализатор трафика для мониторинга NTLM трафика на предмет аномалий.

Рассмотрев вышеописанную пару уязвимостей протокола, очевидно, что по большей части протокол Kerberos уязвим только при сценарии передачи процесса аутентификации «дырявому» NTLM.

ЗАКЛЮЧЕНИЕ

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

Источники

1. Пол Даклин. Статья «Окно безопасности «Orpheus Lyre» (перевод)/ [Информационный сайт «Naked security» компании Sophos]. 19.07.2017, URL: https://nakedsecurity.sophos.com/ru/2017/07/19/windows-security-hole-the-orpheus-lyre-attack-explained/
2. Kerberos (протокол)/ Национальная библиотека им. Н.Э. Баумана.// Электронная библиотека, 08.06.2016, URL: https://ru.bmstu.wiki/Kerberos_(%D0%BF%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB)
3. Нестеров С.А. Информационная безопасность : учебник и практикум для СПО / Москва: Юрайт, 2018. — 321 с.
4. Керберос/ Энциклопедия теоретической и прикладной криптографии// Электрон. б-ка, 10.12.2013, URL: http://cryptowiki.net/index.php?title=%D0%9A%D0%B5%D1%80%D0%B1%D0%B5%D1%80%D0%BE%D1%81
5. CVE-2017-8563 Windows Elevation of Privilege Vulnerability/ Центр реагирования на угрозы безопасности корпорации Microsoft, 11.07.2017, ред. 13.07.2017, URL: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-8563
6. Баг в протоколе Kerberos, существовавший более 20 лет, устранен для Windows и Linux./Период. издание Xakep//Электрон. версия, 17.07.2017, URL: https://xakep.ru/2017/07/17/orpheus-lyre/