Файл: Служба безопасности и аутентификации баз данных (Анализ сетевой защищенности СУБД Oracle).pdf
Добавлен: 29.03.2023
Просмотров: 90
Скачиваний: 1
Система шифрования паролей является достаточно консервативным элементом СУБД, ибо ее малейшее изменение влияет на возможность/невозможность подключения клиентов к базе данных. Таким образом, частое изменение этой подсистемы СУБД нежелательно. Видимо, этот фактор сказался на том, что подсистема шифрования паролей была неизменной много лет. Изменение системы шифрования повлекло бы за собой ряд сообщений ORA-xxxxx, сообщающих об ошибках в системе шифрования и в технической документации были бы упомянуты причины и способы их решения. Судя по отсутствию этих проблем в технической документации и Интернет, можно сделать вывод, что в СУБД Oracle подсистема шифрования паролей была неизменной достаточно длительное время.
До определенного момента о подсистеме шифрования паролей в СУБД Oracle вообще не было ничего неизвестно, несмотря на то, что система шифрования СУБД Oracle не может быть секретной, поскольку эта СУБД эксплуатируется во всем мире, а не только в защищенных ВЦ США. Мои экспериментальные исследования этого вопроса привели к нескольким экспериментально установленным фактам.
Первым фактом стало то, что в СУБД Oracle не различаются строчные и заглавные символы. Затем эксперименты с прослушиванием сетевых пакетов показали, что клиентский пароль не передается на сервер в открытом виде. Следовательно, обработка клиентского пароля осуществляется на клиенте, и для защиты пароля используется какой-то алгоритм шифрования. И, скорее всего, этот алгоритм - DES, поскольку другого общедоступного сертифицированного алгоритма.
Постепенно стало очевидно, что в СУБД Oracle на все инсталляции используется один и тот же ключ, потому что шифрование осуществляется на клиенте, но при этом, клиент может подключаться ко всем базам данных, независимо от аппаратной платформы, битности, версий ОС и версий Oracle. Иными словами, проинсталлировав клиента у себя в ПК под Windows, я могу подключаться к любой базе данных Oracle. Значит, значение ключа не является функцией, зависящей от версии СУБД, типа инсталляции (клиент или сервер), версии ОС. Очевидно, что сам собой напрашивается вывод о том, что ключ является константой, единой на все инсталляции СУБД, а значение этой константы «зашито» в каждом дистрибутиве, и даже конкретно в каждом исполняемом файле sqlplus. Таким образом, взяв один дистрибутив можно было узнать ключ, а, узнав ключ, можно расшифровать и получить в открытом виде пароль!
А вот это уже в голове не укладывалось: подобная криптосистема - это ошибка с точки зрения криптографической защиты, или компания сознательно пожертвовала безопасностью в угоду удобствам эксплуатации? Однако детали этой конструкции были покрыты мраком. Погружаться в декомпилирование кода СУБД не было возможности, поэтому данная проблема так и не нашла своего решения.
Последним штрихом для создания полноценной картины явилось опубликование 18 октября 2005 г. исследования «An Assessment of the Oracle Password Hashing Algorithm» авторов Joshua Wright и Carlos Cid, в котором описан алгоритм шифрования паролей в СУБД Oracle.
Главная атака на пароль состоит в переборе всех возможных паролей указанной длины, вычисление его хеша и сравнение с образцом. Вычисления могут быть произведены противником заранее, на быстродействующей ЭВМ, а затем сохранены в базе данных в виде индексированного дерева, что позволит при необходимости быстро проверить наличие искомого пароля. А поскольку пользователи зачастую выбирают легко запоминающиеся пароли, то тем самым они невольно способствуют злоумышленнику, сокращая пространство возможных значений. Для удобства вскрытия злоумышленник может составить словарь наиболее употребительных паролей. Итак, самое слабое место парольной защиты это низкая энтропия обычных паролей.
Хеш-функция является детерминированной. Будучи примененной к одним и тем же исходным данным, она в результате выдает одно и то же значение. Следовательно, два разных пользователя, выбрав один и тот же пароль, получат в результате одно и то же хеш-значение. Таким образом, пользователь, не обладая глубокими знаниями в области вскрытия шифров, а, зная только свой собственный пароль, сможет просмотреть все хеш-значения и определить других пользователей с таким же, как у него паролем. Чтобы предотвратить подобную уязвимость, каждый пароль имеет ассоциированное с ним случайное число, которое используется совместно с паролем для генерации хеша пароля. Обычно это случайное число побитово складывается с паролем, в результате чего на вход хеш-функции подаются различные данные, даже если пользователи вводят один и тот же пароль. Случайное число достаточной длины позволяет также затруднить атаку на пароли за счет того, что не позволяет противнику заранее вычислить все возможные пароли заданной длины и их хеши и реализовать атаку по словарю.
1.7. Медленный однонаправленный алгоритм.
Медленный однонаправленный алгоритм означает, что хеш-функция не должна вычисляться быстро. Если хеш-функция вычисляется быстро, то хакер тоже ее вычислит быстро, и быстро осуществит перебор паролей. Поэтому медленный однонаправленный алгоритм нужен, чтобы замедлить работу хакеров. Он не сильно затруднит одноразовое вычисление пароля (например, при подключении к БД), но существенно затруднит противнику перебор всевозможных паролей. Наиболее популярное решение здесь - это многократное итеративное использование хеш-функций. Например, в Unix-системах однонаправленная функция шифрования применяется итеративно несколько раз, чтобы обеспечить достаточно большое время отклика.
Устройство системы не должно быть секретом. Секретным элементом должен быть только сменный элемент системы, например, ключ шифрования.
По умолчанию доступ к системе не предоставляется.
Система защиты должна быть дружественной. Даже очень надежная система защиты, которая в значительной мере мешает ему выполнять свои функции, в конце концов, будет отвергнута.
С алгоритмической точки зрения при вскрытии современного шифра со случайным ключом существуют два принципиально различных направления атаки: поиск и использование некоторых уязвимостей алгоритма, и перебор ключей.
Поиск уязвимостей - долгая и кропотливая аналитическая работа, позволяющая делать выводы об исходных данных на основе шифрованных данных и знания алгоритма (криптосистемы).
Перебор ключей - (второе название «силовая атака», brute force - BF) стандартный способ подбора пароля, заключающийся в генерации очередного значения, шифровании его и сравнении полученного результата с имеющимся хешем. Основную роль в переборе ключей играют вычислительные мощности злоумышленника, таким образом, это универсальный способ для взлома различных шифров, поскольку этот способ не зависит от внутреннего устройства шифра.
Ввиду больших затрат времени и вычислительных средств, к перебору прибегают в том случае, когда остальными методами решить проблему не получается. И даже в случае перебора все равно, пытаются максимально сузить перебираемое множество за счет анализа особенностей конкретного алгоритма.
1.8. Силовая атака.
Если аналитическим путем найти уязвимую точку не удастся, то всегда существует метод, называемый силовая атака.
Программные реализации силовой атаки дают на сегодняшний день скорость 830 тыс. хешей в секунду, используя стандартный Pentium-4 с частотой 2.8 ГГц. Если длина пароля 8 знаков и имя пользователя 8 знаков, то злоумышленник вычислит все возможные пароли приблизительно за 39,3 суток, при этом в среднем он будет обнаруживать пароли на 20-день. Следует подчеркнуть, что скорость в 830 тыс. хешей относится только к 8-байтовым паролям. Более длинные пароли требуют большего времени и больших вычислительных ресурсов.
На сайте http://www.red-database-security.com сравниваются несколько инструментов для силовой атаки на пароли Oracle. Каждый из этих программ шифруют username/password и сравнивают с хеш-значением. Разброс значений скорости перебора на Pentium-4 с частотой 3 GHz такой: код SQL генерирует до 500 паролей в секунду, код на С до 1.100.000 паролей в секунду (наилучший результат).
Еще более интересна разработка аппаратного устройства для подбора паролей Oracle. Поскольку базы данных концентрируют в одном месте множество информации, то затраты на разработку специализированных аппаратных средств могут оказаться экономически оправданными.
Еще в 1998 г. была запущена в эксплуатацию специализированная ЭВМ для подбора ключей DES, развивающая производительность до 92 миллиардов ключей в секунду. Она способна найти подходящий ключ DES за несколько десятков часов. Стоимость такого устройства около 250 тыс. долларов.В данном аспекте следует подчеркнуть, что значение 92 миллиарда относится именно к перебору ключей DES, а не к подбору паролей Oracle. Расшифровка хеша Oracle будет происходить немного медленнее, поскольку требует большего числа операций, но, тем не менее, это значение позволяет оценить потенциальную мощность аппаратных средств.
Парадокс дней рождений означает следующее: чтобы с вероятностью 0.5 найти человека, с которым у Вас совпадают дни рождения (совпадают месяц и день, год во внимание не принимается), нужно опросить в среднем 253 человека. А для того, чтобы просто найти двух любых людей с совпадающими днями рождения, в среднем, достаточно опросить 23 человек. Различие в 11 раз для результатов этих задач с очень похожими формулировками и послужило причиной парадокса.
Обладание хешем пароля позволяет выполнить атаку на пароль в оффлайне, когда противник может заранее вычислить хеши паролей для известных логинов типа sys, system и т.д. Используя заранее вычисленные хеши паролей, злоумышленник может при необходимости просматривать эти таблицы в поисках подходящего хеша.
Использование предварительно вычисленных таблиц обычно ограничено множеством алгоритмов, не использующих случайную привязку. Но привязка в СУБД Oracle не мешает злоумышленнику, поскольку он может построить хеши для заранее выбранной учетной записи (логина). Отличным кандидатом будет логин SYSTEM, который существует во всех БД и гарантирует привилегированный доступ.
На стандартном Pentium-4 2.8 ГГц для пароля длиной 8 знаков (217 180 147 158 возможных паролей) предварительные вычисления продолжались в течение недели. В этой конфигурации пароль для этой учетной записи был обнаружен в 98.1% случаев.
Это сильный результат. Но он верен только для паролей длины 8. Принципиально сильным результатом в этом направлении было бы генерация одного пароля для каждого значения хеша. В этом случае, тему безопасности СУБД Oracle можно было бы считать полностью исчерпанной. Однако, это потребует хранилища емкостью 8*264 байт = 134 217 728 Тб- что, по-видимому, никогда не будет реализовано.
1.9. Варианты парольной защиты сервера Oracle.
От DES следует отказаться в силу малой длины ключа и малой длины блока.Малая длина ключа означает успешность силовой атаки за небольшое время, а малая длина блока означает повышенный уровень коллизий.
Если у разработчиков Oracle есть приверженность к алгоритмам шифрования, то можно взять новый, более совершенный алгоритм AES, пришедший в 2000 г. на смену DES'у. Этот алгоритм допускает вариацию длины блока (128, 192, 256 бит), длины ключа 128, 192, 256 бит и количества раундов (чем больше раундов, тем выше качество шифрования и меньше скорость). Алгоритм AES сертифицирован национальным институтом США по стандартизации NIST и АНБ (Агентство Национальной Безопасности США).
Либо можно выбрать сертифицированную криптографически стойкую хеш-функцию, которых к сегодняшнему дню разработано несколько десятков. В России таким стандартом является ГОСТ Р 34.11, в Европе - RIPEMD, в США - SHA, MD5. Они протестированы компетентными организациями (органами) и приняты в качестве государственных стандартов. Для предотвращения коллизий и сведения к минимуму эффекта от парадокса дней рождений современную длину блока можно установить в 256 бит. По современным оценкам этой длины хватит на сотню-другую лет, при сохранении современных темпов развитии вычислительной техники.
- Конкатенацию логина и пароля следует заменить другим преобразованием, например сложением.
Этот пример показывает два факта:
1. Неожиданный способ порождения коллизий. Т.е. если в базе данных заведен пользователь "ora" с паролем "cle", то в процессе силовой атаки мы можем наткнуться на логин "o" с паролем "racle", в результате чего угадать реальную пару логин||пароль будет совсем несложно, потому что для каждого пароля случайной добавкой (солью) является часть его логина. Таким образом, в целях минимизации числа коллизий следует от конкатенации отказаться.
2. Зная имена стандартных пользователей sys, system, outln и т.д., противник имеет возможность заблаговременно сгенерировать словарь. Если не весь словарь целиком, то хотя бы из наиболее часто употребительных паролей. В этом случае задача расшифровывания сводится к задаче поиска в массиве заранее вычисленных значений. А в случае, например, побитового сложения логина и пароля, знание имен стандартных пользователей пользы противнику не принесет.
Есть еще одни вариант - по аналогии с ОС - использовать действительно случайное значения "соли". Однако, тогда эту соль пришлось бы где-то в базе данных хранить, а в данной конструкции разработчики Oracle проблему хранения соли элегантно обошли.