Курс лекций «Проблемы безопасности в информационных технологиях»


Глава 4. Защита ОС в сетевом окружении



жүктеу 4.51 Mb.
бет20/44
Дата13.09.2017
өлшемі4.51 Mb.
түріКурс лекций
1   ...   16   17   18   19   20   21   22   23   ...   44

Глава 4. Защита ОС в сетевом окружении


При работе с единственным сервером/ресурсом можно заставить пользователя выполнять требования системы безопасности, например, такие как использование сложного пароля (если используется парольная аутентификация). Но в случае, когда пользователю необходимо работать со множеством ресурсов/серверов, задача многократно усложняется. Иметь единственный и одинаковый для всех ресурсов пароль? Чревато потерей доступа ко всем серверам в случае его утраты. Серьёзной проблемой могут в этом случае стать разные политики на разных серверах: один сервер может требовать смены пароля раз в месяц, другой – раз в полгода, третий – раз в три месяца и т.п. Где у пользователя какой пароль, когда он менялся, когда потребуется его сменить в ближайшее время (не пропустить!) и на каком сервере, ручная синхронизация, соблюдение разных правил формирования пароля – всё это быстро превратится в головную боль. Решением будет простейший, примитивный пароль. Хорошо бы ещё, чтобы такой пароль допускали политики на всех требуемых серверах.

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

Ещё одна проблема, логично вытекающая из распределённой природы работы со множеством удалённых ресурсов – сетевые коммуникации. Используя протоколы, передающие пароли в открытом виде, пользователь очевидно рискует – его пароль может быть перехвачен. Но не только при передачи паролей возникают риски, когда пользователь работает в сети. Сетевой пакет может быть сфальсифицирован, подделан, в результате чего злоумышленник, например, сможет повысить свои привилегии и получить права администратора. Известен случай, когда в ранних версиях Netware любой пользователь мог послать серверу пакет от имени supervisor-а (администратора), получив который, сервер делал отправившего пакет злоумышленника эквивалентным по безопасности supervisor-у, т.е. пользователь в итоге получал максимальные права. Решением было ввести т.н. «подпись» пакетов, предотвращающую их подделку.

Иногда в истории можно обнаружить просто удивительные по своей нелепости решения в части сетевой авторизации. Одно из таких решений принадлежит фирме Microsoft в её реализации по предоставлению дисковых ресурсов в ОС семейства Windows for Workgroup/95/98/Me. В отличие от Windows семейства NT, в Windows 95 доступ к ресурсу (share) был не персонифицирован, вместо этого на ресурс ставился пароль и тот, кто его знал, получал доступ к папке по сети. Для простых решений – вполне годится, но в части безопасности тут было одно большое ‘но’: при подключении к ресурсу клиент(!) мог указать серверу(!) длину пароля! Кому из разработчиков пришла в голову такая «светлая» мысль – неизвестно, но на практике это означает, что любой, даже довольно длинный пароль в таком варианте взламывается за секунды простым прямым перебором! Алгоритм прост и понятен: клиент, подключившись к серверу, указывает ему, что длина пароля =1, после чего перебирает все возможные 28=256 комбинаций (максимум), до первого совпадения. После этого серверу сообщается, что длина пароля теперь =2 – и перебор повторяется для второго символа. И так, посимвольно, за полиномиальное время, вместо ожидаемого экспоненциального, подбирается весь пароль. Фантастическая небрежность!

Когда эта «технология» была обнаружена и осознана, то естественно, появились и программы, эксплуатирующих эту уязвимость. Доходило до смешного – солидная фирма GFI встроила возможность подбора пароля для сетевых ресурсов Windows 95 в свой знаменитый сетевой сканнер LANguard, и Microsoft обращалась к GFI с просьбой исключить эту возможность из следующих версий LANguard. GFI пошла навстречу, подбор паролей убрали, но в старых версиях LANguard эта функция, естественно, так и осталась. А решения по безопасности от Microsoft тех лет сильно напоминали «ограду» дома, изображённую на картинке ниже:


Рис.47 Прочность цепочки определяется её самым слабым звеном

Безопасность при работе в доменах Windows NT


Решая проблему удобного доступа ко множеству ресурсов, компания Microsoft разработала решение для централизованной аутентификации и авторизации в сети масштаба предприятия на базе ОС Windows NT. Необходимо было реализовать несколько новых по тем временам технологий, в частности, single sign-on (SSO) – единый пароль, и One user – one password.

One user – one password (один пользователь – один пароль) означает, что у пользователя должен быть только один пароль, дающий ему возможность доступа ко всем ресурсам сети. Технология single sign-on (единый вход) подразумевает, что этот пароль указывается только один раз – при входе пользователя в сеть.

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

Протокол NTLM работает по принципу challenge-response (запрос-ответ), описанному выше. Это означает, что ни пароль, ни его хеш никогда не передаются «как есть», вместо этого они используются для генерации ответа (response) на случайный запрос (challenge). Аутентифицирующая сторона сравнивает полученный ответ с ответом, вычисленным локально.

В семействе протоколов NTLM могут использоваться 2 типа хешей: LM (Lan Manager) хеш, унаследованный от предыдущих реализаций Lan Manager и NT (New Technology) хеш, созданный для протокола NTLM. Соответственно, при входе пользователя в систему, как правило, от пароля берутся и хранятся оба этих хеша. Первая версия протокола NTLM для совместимости поддерживала оба ключа (NT или LM ключом обычно называют соответствующий хеш пароля). В более поздних реализациях используется только NT ключ, однако по-умолчанию LM хеш все равно создаётся при входе и помещается в хранилище LSA.

LM ключ получается из пароля в 8-битной OEM кодировке (cp866 для России) с помощью алгоритма DES2. Поскольку DES обладает относительной стойкостью к атакам известного открытого текста, он может быть использован в качестве криптографической хеш-функции, если в качестве открытого текста использован какой-либо известный текст, а в качестве ключа – хешируемое слово. Известный текст может быть либо случайным (в таком случае он называется salt – соль, и хранится вместе с паролем), либо предопределённым, в таком случае он называется Magic Word – заклинание. В классической реализации crypt() в Unix использовался первый подход, в Windows используется магическое слово KGS!@#$%3. При использовании в качестве генератора хеш-функции DES генерирует 64 битный хеш по 56 битному тексту.

Поскольку DES позволяет получить хеш лишь от 7-символьного блока (7*8=56), то реально используется пароль не более, чем из 14 символов (более короткий пароль дополняется нулями), который разбивается на два блока по 7 символов, от каждого из которых независимо вычисляется хеш. В итоге получается 128-битный хеш, «склееный» из двух частей.




Рис.48 Алгоритм вычисления LM-хеша
Недостатки алгоритма очевидны. Независимое вычисление двух блоков позволяет и их независимый взлом, т.е. реально каждый 64 бита хеша можно одновременно атаковать с целью восстановления пароля. Требуемое количество попыток подбора уменьшается примерно в 1015 раз. Усугубляет ситуацию и то, что для генерации LM ключа пароль не чувствителен к регистру символов и символы всегда используются в верхнем реестре.

Пусть f – некая хеш-функция, а x1..7y8..14 – введённый пользователем пароль. Тогда LM-хеш будет равен f(x) + 264·f(y). Т.к. область допустимых значений функции f лежит в интервале целых неотрицательных чисел 264-1, то поиск пароля сводится к решению двух уравнений (P – пароль, H – значение LM-хеша): P1..7




  1. DES(0) H1..8

  2. DES(0) H9..16

Это делает очень эффективной атаку на восстановление пароля методом последовательного перебора (не более 7 символов из очень ограниченного алфавита). Причем длинный пароль может быть легче восстановлен, чем более короткий. Например, для пароля из 12 символов, сначала за считанные секунды подбираются последние 5 символов, после чего делается предположение о структуре пароля и первые 7 символов пароля подбираются по более ограниченному алфавиту. В настоящее время известны очень быстрые реализации DES с использованием 64-битной арифметики, что делает его абсолютно непригодным для криптографии. В общем случае, восстановление пароля по LM-хешу на современной технике вопрос не более, чем нескольких дней. Кроме того, фиксированное магическое слово позволяет использование таблицы заранее посчитанных значений ключей, что делает возможным восстановление пароля по LM-хешу в реальном времени.

Если пользователь ввёл пароль менее семи символов, тогда P8..14=0, а DES(0) 0xAAD3B435B5140EE – константа! Т.е., если старшие восемь байт LM-хеша равны этой константе, то можно сразу определить, что пароль состоит из семи или менее символов.

NT ключ вычисляется с помощью стандартного алгоритма хеширования MD4. Хеш MD4 берется от пароля, записанного в 16-битной кодировке Unicode с последовательностью байт low endian (т.е. первым байтом идет номер символа в странице). Пароль вычисляется с учётом регистра. MD4 имеет несколько криптографических проблем, самой большой из них является маленькое время вычисления хеша, что позволяет перебирать достаточно большое количество комбинаций в единицу времени, упрощая, например, атаку по словарю или подбор слабой комбинации символов. Кстати, хеш пароля, с точки зрения протокола NTLM, абсолютно равнозначен самому паролю, возможность получения хеша означает возможность полного использования пароля.

Осознавая недостатки протокола NTLM, некоторые из которых носят принципиальный характер, Microsoft сегодня в итоге предлагает другое решение для аутентификации в сетевом окружении – протокол Kerberos. Протокол NTLM (всех версий) на сегодня предлагается полностью запрещать в виду его небезопасности. Это лишает возможности работать в домене машины со старыми версиями ОС Windows: 95, 98, Me, но кардинально и полностью решает проблему уязвимостей в NTLM.






Достарыңызбен бөлісу:
1   ...   16   17   18   19   20   21   22   23   ...   44


©kzref.org 2019
әкімшілігінің қараңыз

    Басты бет