Служба безопасности и аутентификации баз данных

Содержание:

Введение

Системы управления базами данных, в особенности реляционные СУБД, стали доминирующим инструментом хранения больших массивов информации. Сколько-нибудь развитые информационные приложения полагаются не на файловые структуры операционных систем, а на многопользовательские СУБД, выполненные в технологии клиент/сервер. В этой связи обеспечение информационной безопасности СУБД, и в первую очередь их серверных компонентов, приобретает решающее значение для безопасности организации в целом.
Для СУБД важны все три основных аспекта информационной безопасности - конфиденциальность, целостность и доступность. Общая идея защиты баз данных состоит в следовании рекомендациям, сформулированным для класса безопасности C2 в "Критериях оценки надежных компьютерных систем". В принципе некоторые СУБД предлагают дополнения, характерные для класса B1, однако практическое применение подобных дополнений имеет смысл, только если все компоненты информационной структуры организации соответствуют категории безопасности B. Достичь этого непросто и с технической, и с финансовой точек зрения. Следует, кроме того, учитывать два обстоятельства. Во-первых, для подавляющего большинства коммерческих организаций класс безопасности C2 достаточен. Во-вторых, более защищенные версии отстают по содержательным возможностям от обычных "собратьев", так что поборники секретности по сути обречены на использование морально устаревших (хотя и тщательно проверенных) продуктов со всеми вытекающими последствиями в плане сопровождения.

На данный момент самой распространенной версией СУБД Oracle является 9i, за ней следует 8i и 10g. Существуют версии для различных ОС, но самыми распространенными являются Windows и Linux.

Глава 1. Анализ сетевой защищенности СУБД Oracle.

1.1. Анализ безопасности TNS Listener’a.

Listener Oracle - компонент сетевого доступа к системам Oracle, который принимает клиентские запросы и направляет их для обработки в соответствующий серверный процесс. Плохо сконфигурированный незащищенный Listener предоставляет нарушителю различные способы осуществления атак. Атакой на TNS Listener можно получить детальную информацию об атакуемой системе (имена баз данных (SIDs), версию СУБД, пути к log-файлам, версию ОС, на которой установлена СУБД, переменные окружения(ORACLE_HOME, …)), произвести атаку отказа в обслуживании, выполнить SQL- команды от имени DBA, получить удаленный доступ к системе.

Listener Oracle контролируется утилитой lsnrctl. Утилита lsnrctl имеет команды: status, version, start, stop, set (Password, Log_file, Current_listener, Trc_status).Для осуществления атаки типа отказ в обслуживании можно также использовать утилиту lsnrctl. С помощью команды stop удаленный неавторизированный пользователь может остановить TNS Listener.

Для того, чтобы защитить TNS Listener нужно использовать следующие параметры: PASSWORD –этот параметр отвечает за установку пароля на подключение к TNS Listener’у . В том случае , если пароль установлен, выполняются только команды status и version, что дает информацию о версии Listener’a, установочной директории и операционной системе (по умолчанию не установлен), ADMIN_RESTRICTIONS – этот параметр во включенном состоянии запрещает любые изменения конфигурационного файла удаленно (по умолчанию установлен в OFF), LOCAL_OS_AUTHENTICATION – этот параметр во включенном состоянии позволяет управлять TNS Listener’ ом только локально, (по умолчанию установлен в OFF до версии 10g).

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

1.2. Подключение к СУБД.

Обычно в СУБД для идентификации и проверки подлинности пользователей применяются либо соответствующие механизмы операционной системы, либо SQL-оператор CONNECT. В случае СУБД Oracle оператор CONNECT имеет следующий вид: CONNECT пользователь[/пароль] [@база_данных];

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

Для подключения к СУБД Oracle необходимо знать IP- адрес сервера, порт TNS Listener’a, имя базы данных (SID), имя пользователя и пароль.

Подобрать имя базы данных (SID) можно поиском информации в сторонних приложениях, например Oracle Application Server (порт 1158), SAP web-management (порт 8001/tcp). Так же имя базы данных может быть стандартным, например «ORCL», состоять из малого количества символов, являться словарным словом, частично или полностью совпадать с DNS/NETBIOS – именем хоста, а так же его можно узнать по ссылке из другой СУБД.

Подбор SID – первое, что обычно предпринимают в случае, если стандартным способом получить SID не удалось.

1.3. Подбор SID по словарю.

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

При подборе SID по словарю решающее значение имеет скорость. С этой целью было проведено два теста по измерению скорости работы приведенных выше утилит (Таблица «Результаты сравнения скоростей работы утилит по перебору SID»):

– Первый тест – замер времени перебора списка стандартных SID (~600 слов);

– Второй тест – замер времени подбора известного SID “ORCL” методом полного перебора

Утилита	Скорость перебора	Время проверки по списку стандартных SID	Время перебора SID “ORCL”
Ora‐brutesid	90 SID/сек	Опция не реализована	114 минут
Ora‐getsid	88 SID/сек	7 сек.	Опция не реализована
Oscanner	80 SID/сек	8 сек.	Опция не реализована
Sidguesser	71 SID/сек	10 сек	Опция не реализована
Sidguess	11 SID/сек	58 сек.	Программа не смогла завершить работу

. Таблица «Результаты сравнения скоростей работы утилит по перебору SID»

Исходя из результатов полученных тестов, наилучшие результаты по подбору по словарю показала утилита Ora‐getsid, а наихудшие результаты по перебору по словарю показала утилита sidguess.

1.4. Подбор SID методом полного перебора (Brute force).

В случае если подбор по словарю не дает желаемого результата, логично перейти к подбору SID методом полного перебора. Что касается скорости подбора методом полного перебора, то наилучшие результаты показала утилита ora brutesid. С помощью нее все 4символьные SID можно перебрать примерно за 3 часа; в случае если SID содержит 5 символов, то его придется перебирать порядка 3-х суток, что вполне осуществимо.

По проведенным тестовым запускам утилиты ширина пропускного канала незначительно влияет на скорость перебора, так как основное время занимает инициализация соединения. Учитывая эти особенности, можно запустить параллельно несколько экземпляров утилиты на разные СУБД.

Статистика проведения тестов на проникновение в крупных компаниях показывает: в 13% случаев SID является стандартным, в 19% – состоит из 3-х и менее символов и в 34% случаев – из 4-х символов.

Распределение стойкости SID

Таким образом, в среднем в 2-х случаях из трех (66%) возможно получение SID базы данных, для чего потребуется не более 3-х часов (время перебора всех 4-х символьных значений). Если учитывать возможность перебора SID по словарю, то вероятность увеличивается.

Существуют сервлеты, на которые нет ссылок с главной страницы. Один из таких сервлетов – это сервлет Spy, который можно использовать для получения SERVICE_NAME базы данных. Для этого необходимо обратиться напрямую к этому сервлету по ссылке http://hostname:5560/servlets/Spy, в результате чего в одной из вкладок мы можем получить SERVICE_NAME базы данных.

SID через Application Server , SID через Application Server 2, в 90% случаев SID можно легко подобрать( SID подбором), SID подбором.

Ниже будут представлены три варианта получения SID при наличии доступа к различным сервисам атакуемого сервера:

Получение SID, имея учетную запись в ОС, на которой установлена СУБД; Получение SID, имея учетную запись на FTP сервере в ОС, на которой установлена СУБД; Получение SID, имея учетную запись в MsSQL сервере в ОС, на которой установлена СУБД.

Все предельно просто в случае, если пользователь, под именем которого мы подключились к серверу, имеет права на чтение файлов из директории ORACLE_HOME/NETWORK/admin, т.к. SID можно получить из конфигурационного файла tnsnames.ora. Этот файл предназначен для определения сетевого имени сервиса, по которому можно обращаться к БД, и хранит такие данные, как SID или SERVICE_NAME базы данных.

1.5 Получение SID при наличии учетной записи на ftp сервере.

В случае если у нас нет аккаунта, предоставляющего удаленный доступ на атакуемый сервер, но есть аккаунт на доступ к ftp‐сервису, установленному на этот сервер, то это дает возможность получения SID в случае, если ftp‐аккаунт имеет доступ на чтение на директорию $ORACLE_HOME.

Для получения SID мы можем прочитать файл tnsnames.ora, как указано в предыдущем разделе. Если доступ на чтение этого файла запрещен, что часто рекомендуется в документах по защите СУБД Oracle, то SID можно получить через список директорий. В различных версиях СУБД пути несколько отличаются. Ниже будут приведены три пути, по которым можно найти SID базы данных на примере СУБД Oracle 10g R2.

Первый способ – это вывести список директорий папки ORACLE_HOME\..\admin\:

C:\oracle\product\10.2.0\oradata >dir. Том в устройстве C не имеет метки.

Серийный номер тома: 8CFF-37FB Содержимое папки C:\oracle\product\10.2.0\admin

Название директории ORCL102 в данном случае является SIDом базы данных.

Второй способ – это вывести список директорий папки $ORACLE_HOME\..\oradata\:

C:\oracle\product\10.2.0\oradata>dir. Том в устройстве C не имеет метки.

Серийный номер тома: 8CFF-37FB Содержимое папки C:\oracle\product\10.2.0\oradata

Название директории ORCL102 в данном случае является SIDом базы данных.

И третий способ – вывести список директорий папки $ORACLE_HOME, содержащий папку, в названии которой будет фигурировать IP‐адрес сервера и SID, разделенные символом нижнего подчеркивания.

Содержимое папки E:\oracle\product\10.2.0\db_1 28.01.2008 17:30 <DIR> admin 28.01.2008 17:30 <DIR> assistants 19.06.2008 16:53 <DIR> BIN В данном случае SIDом базы данных является строка ORCL102.

Чтобы избежать нарушений безопасности, следует придерживаться следующих рекомендации по защите SID:

• Сменить SID баз данных на случайный набор из не менее 8 символов
• Максимально ограничить доступ к файлам tnsnames.ora, оставив права на чтение лишь пользователю от имени которого запускается СУБД
• Ограничить доступ к системам через которые можно узнать SID, или модифицировать информацию, выводимую этими системами

1.6 Парольная политика.

Парольная политика СУБД может иметь следующие слабые стороны:

Множество системных учетных записей со стандартными паролями

Некоторые не блокируются после установки. Множество приложений которые

интегрируются с СУБД имеют свои стандартные системные учетные записи.

По умолчанию не установлено ограничений на длину и сложность пароля. Перебор

паролей к учетным записям в большинстве случаев не блокируется .Базы данных обычно

содержат большое количество учетных записей.

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

С хранением и передачей пароля связаны основные проблемы:

Если передавать пароль в открытом виде, то его можно узнать, слушая пакеты по сети. Хранить пароль в сервере в открытом виде тоже небезопасно, т.к. его можно подсмотреть. Таким образом, пароль приходится шифровать. Вопрос об алгоритме шифрования паролей в СУБД Oracle практически не освещен в русскоязычной литературе и Интернет, хотя имеет важное значение для безопасного хранения данных в базе данных.

Система шифрования паролей является достаточно консервативным элементом СУБД, ибо ее малейшее изменение влияет на возможность/невозможность подключения клиентов к базе данных. Таким образом, частое изменение этой подсистемы СУБД нежелательно. Видимо, этот фактор сказался на том, что подсистема шифрования паролей была неизменной много лет. Изменение системы шифрования повлекло бы за собой ряд сообщений 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*2⁶⁴ байт = 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 проблему хранения соли элегантно обошли.

«Двухэтажную» конструкцию Oracle полезно превратить в «трехэтажную». Такая конструкция существенно усложнит для криптоаналитика атаку с накоплением, основанную на парадоксе дней рождений, а также атаку с анализом промежуточных ключей.

Кроме того, «трехэтажная» конструкция замедлит скорость вычисления хеша, что замедлит скорость силовой атаки, и тем самым повысит стойкость криптосистемы. Это стандартное требование к хеш-функциям, гласящее, что «хеш-функция должна вычисляться медленно». Если хеш-функция вычисляется быстро, то хакер тоже ее вычислит быстро, и быстро осуществит перебор паролей. Медленный однонаправленный алгоритм не сильно замедлит одноразовое вычисление пароля, при подключении к БД, но существенно затруднит противнику перебор всевозможных паролей. Наиболее популярное решение - это многократное итеративное использование хеш-функций. Например, в Unix-системах однонаправленная функция шифрования применяется итеративно несколько раз, чтобы обеспечить достаточно большое время отклика.

• Не игнорировать различие между заглавными и строчными символами. В этом

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

После вышеописанных изменений криптосхему корпорации Oracle следует подвергнуть сертификации. Это повысит доверие к ПО Oracle. Для такого популярного продукта как СУБД Oracle официальное признание и подтверждение его надежности со стороны компетентных организаций является важным моментом, как при его эксплуатации, так и при продвижении на рынке. В худшем случае, слабое звено будет выявлено, и заменено более стойким.

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

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

Глава II. Анализ внутренней безопасности СУБД Oracle.

Главный источник угроз, специфичных для СУБД, лежит в самой природе баз данных. Основным средством взаимодействия с СУБД является язык SQL - мощный непроцедурный инструмент определения и манипулирования данными. Хранимые процедуры добавляют к этому репертуару управляющие конструкции. Механизм правил дает возможность выстраивать сложные, трудные для анализа цепочки действий, позволяя попутно неявным образом передавать право на выполнение процедур, даже не имея, строго говоря, полномочий на это. В результате потенциальный злоумышленник получает в свои руки мощный и удобный инструментарий, а все развитие СУБД направлено на то, чтобы сделать этот инструментарий еще мощнее и удобнее.

Обычно в СУБД применяется произвольное управление доступом, когда владелец объекта передает права доступа к нему (чаще говорят - привилегии) по своему усмотрению. Привилегии могут передаваться субъектам (отдельным пользователям), группам, ролям или всем пользователям.
Группа - это именованная совокупность пользователей. Объединение субъектов в группы облегчает администрирование баз данных и, как правило, строится на основе формальной или фактической структуры организации. Каждый пользователь может входить в несколько групп. Когда пользователь тем или иным способом инициирует сеанс работы с базой данных, он может указать, от имени какой из своих групп он выступает. Кроме того, для пользователя обычно определяют подразумеваемую группу.
Роль - это еще один возможный именованный носитель привилегий. С ролью не ассоциируют перечень допустимых пользователей - вместо этого роли защищают паролями. В момент начала сеанса с базой данных можно специфицировать используемую роль (обычно с помощью флагов или эквивалентного механизма) и ее пароль, если таковой имеется.

Привилегии роли имеют приоритет над привилегиями пользователей и групп. Иными словами, пользователю как субъекту не обязательно иметь права доступа к объектам, обрабатываемым приложениям с определенной ролью.
Отметим, что в СУБД Oracle под ролью понимается набор привилегий. Такие роли служат средством структуризации привилегий и облегчают их модификацию.
Совокупность всех пользователей именуется как PUBLIC. Придание привилегий PUBLIC - удобный способ задать подразумеваемые права доступа.

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

2.1.Повышение привилегий

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

Внедрение SQL-кода (SQL injection) — один из распространённых способов взлома сайтов и программ, работающих с базами данных, основанный на внедрении в запрос произвольного SQL-кода.

Внедрение SQL может дать возможность атакующему выполнить произвольный запрос к базе данных (например, прочитать содержимое любых таблиц, удалить, изменить или добавить данные), получить возможность чтения и/или записи локальных файлов и выполнения произвольных команд на атакуемом сервере.

Атака типа внедрения SQL может быть возможна из-за некорректной обработки входящих данных, используемых в SQL-запросах.

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

2.2. Принцип атаки внедрения SQL.

Допустим, серверное ПО, получив входной параметр id, использует его для создания SQL-запроса. Рассмотрим следующий PHP-скрипт:

# Предыдущий код скрипта.$id = $_REQUEST['id'];

$res = mysql_query ("SELECT * FROM news WHERE id_news = $id");

# Следующий код скрипта...

Если на сервер передан параметр id, равный 5 (например, так: http://example.org/script.php?id=5), то выполнится следующий SQL-запрос:

SELECT * FROM news WHERE id_news = 5

Но если злоумышленник передаст в качестве параметра id строку -1 OR 1=1 (например, так: http://example.org/script.php?id=-1+OR+1=1), то выполнится запрос:

SELECT * FROM news WHERE id_news = -1 OR 1=1

Таким образом, изменение входных параметров путём добавления в них конструкций языка SQL вызывает изменение в логике выполнения SQL-запроса (в данном примере вместо новости с заданным идентификатором будут выбраны все имеющиеся в базе новости, поскольку выражение 1=1 всегда истинно).

2.3. Внедрение в строковые параметры.

Предположим, серверное ПО, получив запрос на поиск данных в новостях параметром search_text, использует его в следующем SQL-запросе (здесь параметры экранируются кавычками):

search_text = $_REQUEST ['search_text'];

res = mysql_query ("SELECT id_news, news_date, news_caption, news_text, news_id_author

FROM news WHERE news_caption LIKE ('%search_text%')");

Сделав запрос вида http://example.org/script.php?search_text=Test мы получим выполнение следующего SQL-запроса:

SELECT id_news, news_date, news_caption, news_text, news_id_author FROM news

WHERE news_caption LIKE ('%Test%')

Но, внедрив в параметр search_text символ кавычки (который используется в запросе), мы можем кардинально изменить поведение SQL-запроса. Например, передав в качестве параметра search_text значение ')+and+(news_id_author='1, мы вызовем к выполнению запрос:

SELECT id_news, news_date, news_caption, news_text, news_id_author FROM news

WHERE news_caption LIKE ('%') AND (news_id_author='1%')

Язык SQL позволяет объединять результаты нескольких запросов при помощи оператора UNION. Это предоставляет злоумышленнику возможность получить несанкционированный доступ к данным.

Рассмотрим скрипт отображения новости (идентификатор новости, которую необходимо отобразить, передается в параметре id):

res = mysql_query("SELECT id_news, header, body, author FROM news WHERE id_news = " . _REQUEST['id']);

Если злоумышленник передаст в качестве параметра id конструкцию -1 UNION SELECT 1,username,password,1 FROM admin, это вызовет выполнение SQL-запроса

SELECT id_news, header, body, author FROM news WHERE id_news = -1 UNION SELECT 1,username,password,1 FROM admin

Так как новости с идентификатором -1 заведомо не существует, из таблицы news не будет выбрано ни одной записи, однако в результат попадут записи, несанкционированно отобранные из таблицы admin в результате инъекции SQL.

2.4. Расщепление SQL-запроса.

Для разделения команд в языке SQL используется символ ; (точка с запятой), внедряя этот символ в запрос, злоумышленник получает возможность выполнить несколько команд в одном запросе, однако не все диалекты SQL поддерживают такую возможность.

Например, если в параметры скрипта \id = _REQUEST['id']; res = mysql_query("SELECT * FROM news WHERE id_news = id");

злоумышленником передается конструкция, содержащая точку с запятой, например 12;INSERT INTO admin (username, password) VALUES ('HaCkEr', 'foo'); то в одном запросе будут выполнены 2 команды

SELECT * FROM news WHERE id_news = 12;

INSERT INTO admin (username, password) VALUES ('HaCkEr', 'foo');

и в таблицу admin будет несанкционированно добавлена запись HaCkEr.

Предположим, что код, генерирующий запрос (на языке программирования Паскаль), выглядит так: statement := 'SELECT * FROM users WHERE name = "' + userName + '"; Чтобы внедрение кода было невозможно, требуется брать в кавычки все строковые параметры. В самом параметре заменяют кавычки на \", апостроф на \', обратную косую черту на \\ (это называется «экранировать спецсимволы»). Это можно делать таким кодом:

statement := 'SELECT * FROM users WHERE name = ' + QuoteParam(userName) + ';';

function QuoteParam(s : string) : string; { на входе — строка; на выходе — строка в кавычках и с заменёнными спецсимволами }var i : integer; Dest : string; begin Dest := '"'; for i:=1 to length(s) do case s[i] of '''' : Dest := Dest + '\'''; '"' : Dest := Dest + '\"'; '\' : Dest := Dest + '\\';

else Dest := Dest + s[i]; end; QuoteParam := Dest + ; end;

Для PHP фильтрация может быть такой: <? query = "SELECT * FROM users WHERE user='".mysql_real_escape_string(user)."'

2.5. Фильтрация целочисленных параметров.

Возьмём другой запрос:statement := 'SELECT * FROM users WHERE id = ' + id + ';';

В данном случае поле id имеет числовой тип, и его нельзя брать в кавычки. Поэтому «заковычивание» и замена спецсимволов на escape-последовательности не проходит. В таком случае помогает проверка типа; если переменная id не является числом, запрос вообще не должен выполняться. Например, на Delphi для противодействия таким инъекциям помогает код: id_int := StrToInt(id);

statement := 'SELECT * FROM users WHERE id = ' + IntToStr(id_int) + ';';

В случае ошибки функция StrToInt вызовет исключение EConvertError, и в его обработчике можно будет вывести сообщение об ошибке. Двойное преобразование обеспечивает корректную реакцию на числа в формате $132AB (шестнадцатеричная система счисления). На стандартном Паскале, не умеющем обрабатывать исключения, код несколько сложнее. Для PHP этот метод будет выглядеть так: query = 'SELECT * FROM users WHERE id = ' . intval(id).

Для внесения изменений в логику выполнения SQL-запроса требуется внедрение достаточно длинных строк. Так, минимальная длина внедряемой строки в вышеприведённых примерах составляет 8 символов ("1 OR 1=1"). Если максимальная длина корректного значения параметра невелика, то одним из методов защиты может быть максимальное усечение значений входных параметров.

Например, если известно, что поле id в вышеприведённых примерах может принимать значения не более 9999, можно «отрезать лишние» символы, оставив не более четырёх: statement := 'SELECT * FROM users WHERE id = ' + LeftStr(id, 4) + ';';

2.6. Использование параметризованных запросов.

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

• на Delphi — свойство TQuery.Params;

Например var sql, param : string; begin sql := 'select :text as value from dual';

param := 'alpha'; Query1.Sql.Text := sql; Query1.ParamByName('text').AsString := param;

Query1.Open; ShowMessage(Query1['value']); end;

• на Perl — через DBI::quote или DBI::prepare;
• на Java — через класс PreparedStatement;
• на C# — свойство SqlCommand.Parameters;
• на PHP (при работе с MySQL) — функции mysql_escape_string, mysql_real_escape_string, addslashes.
• на Parser — язык сам предотвращает атаки подобного рода.

2.7. Обход Oracle dbms_assert.

Используя специально сформированные параметры (в двойных кавычках) можно обойти проверку правильности пакета dbms_assert и внедрить SQL код. Уязвимость можно эксплуатировать в большинстве версий Oralce (8.1.7.4 – 10.2.0.2), исправление появилось только в июле 2006 года.
Для защиты пакетов Oracle PL/SQL от большого количества SQL инъекции, Oracle разработал новый пакет пол названием dbms_assert в Oracle 10g Release 2. Этот пакет был ретропортирован с Oracle Critical Patch Update (CPU) в октябре 2005 года на все поддерживаемые базы данных (с 8.1.7.4 до 10.1.0.5).

По порядку:

DBMS_ASSERT - PL/SQL пакет, который содержит следующие функции:
ENQUOTE_LITERALENQUOTE_NAMENOOPQUALIFIED_SQL_NAMESCHEMA_NAMESIMPLE_SQL_NAMESQL_OBJECT_NAME
Подробное объяснение этих функций и их использовании может быть найдено в статье.
Если удастся обойти проверку правильности пользовательских данных одной из этих функций, то станет возможным выполнение нападений SQL инъекции против множества уязвимых PL/SQL процедур и функций, которые легко обнаружить в полностью залатанных версиях Oracle (8.1.7.4 до 10.2.0.2 с CPU July 2006), используя поиск нужной строки в распакованном PL/SQL коде. О способах распаковки PL/SQL (+ простой PoC), было рассказано Пете Финнигангом на конференции Black Hat 2006.
Начнем с некоторыми простыми PL/SQL примерами.
Процедура PL/SQL принимает параметр TABLENAME и привязывает этот параметр к динамическому SQL оператору. Этот SQL оператор будет выполнен непосредственно при запуске. Уязвимое решение без dbms_assert:

CREATE OR REPLACE PROCEDURE test1 (TABLENAME IN VARCHAR2) ISBEGINdbms_output.put_line(' SQL=select count(*) from all_tableswhere table_name='''|| TABLENAME||'''');EXECUTE IMMEDIATE 'select count(*) from all_tables wheretable_name='''|| TABLENAME ||'''';END test1;/Procedure created.
Теперь мы используем обычное имя таблицы в качестве параметра:
SQL> exec test1('CAT');SQL=select count(*) from all_tables where table_name='CAT'PL/SQL procedure successfully completed.
Так как этот параметр не проверяется¸ мы можем внедрить PL/SQL код, например “or 1=1--"
SQL> exec test1('CAT'' or 1=1--');SQL=select count(*) from all_tables where table_name='CAT' or1=1--'PL/SQL procedure successfully completed.
Решение с dbms_assert (все еще уязвимо): Теперь мы можем проверить пользовательские данные с dbms_assert.qualified_sql_name. Oracle использует этот подход несколько раз во внутреннем PL/SQL коде.
CREATE OR REPLACE PROCEDURE test2 (TABLENAME IN VARCHAR2) ISVERIFY_TAB VARCHAR2(64);BEGINVERIFY_TAB := DBMS_ASSERT.QUALIFIED_SQL_NAME(TABLENAME);dbms_output.put_line('ASSERT result='||VERIFY_TAB);dbms_output.put_line('SQL=select count(*) from all_tableswhere table_name='''|| VERIFY_TAB ||'''');EXECUTE IMMEDIATE 'select count(*) from all_tables wheretable_name='''||VERIFY_TAB||'''';END test2;/Procedure created.
Мы передаем нашу таблицу CAT как параметр, и все работает как и ожидалось:
SQL> exec test2('CAT');ASSERT result=CATSQL=select count(*) from all_tables where table_name='CAT'PL/SQL procedure successfully completed.
Теперь давайте попытаемся внедрить дополнительный код. На сей раз dbms_assert.qualified_sql_name отобразит ошибку, и динамический код не будет выполнен.
SQL> exec test2('CAT'' or 1=1--');BEGIN test2('CAT'' or 1=1--'); END;*ERROR at line 1:ORA-06502: PL/SQL: numeric or value errorORA-06512: at "SYS.DBMS_ASSERT", line 206ORA-06512: at "USER1.TEST2", line 5ORA-06512: at line 1
Теперь вводим название объекта в двойных кавычках в нашу процедуру:
SQL> exec test2('"CAT'' or 1=1--"');ASSERT result="CAT' or 1=1--"SQL=select count(*) from all_tables where table_name='"CAT' or1=1--"'PL/SQL procedure successfully completed.
И, как не странно, это работает..
dbms_assert.qualified_sql_name пропускает проверку правильности, если параметр заключен в двойные кавычки. Если вы используете DBMS_ASSERT.sql_object_name, вы должны создать сначала объект, например CREATE TABLE " ' or 1=1-- ".
Злоумышленник может использовать эту методику (двойные кавычки около параметров), чтобы обойти dbms_assert. Об этой уязвимости, и некоторых связанных ошибок безопасности, было сообщено компании Oracle в Апреле 2006 года.

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

Заключение

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

1. Установить пароль на доступ к сервису TNS Listener

2. Использовать не словарные, трудно угадываемые имена баз данных (SID)

3. Провести анализ используемых учетных записей: удалить или отключить неиспользуемые и сменить стандартные пароли системных учетных записей

4. Включить блокирование учётных записей после многократного ввода

неправильного пароля

5. Установить последние критические обновления, или хотя бы ограничить доступ пользователям на запуск потенциально опасных процедур

6. Проанализировать привилегии и роли пользователей и оставить только

самые необходимые, руководствуясь хорошо известным принципом наименьших привилегий

7. Отключить возможности доступа пользователей Oracle к файловой системе

8. Ограничить доступ к СУБД Oracle по IP-адресам, разрешив доступ только с веб - сервера, если база данных используется в связке с веб - сервером, или только с подсети пользователей СУБД

Литература

1. Castano S., Fugini M., Martella G., Samarati P. Database Security. - Addison-Wesley, 1995.
2. Manola F.A. A Personal View on DBMS Security. - in DATABASE SECURITY: Status and Prospects. C.E. Landwehr (Editor). Elsevier science Publishers B.V. (North Holland). IFIP, 1988, p. 23- 34.
3. Polk T.W., Bassham L.E. Security Issues in the Database Language SQL. - NIST Special Publication 800-8.
4. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 1989. 
5. Кириллов В.В. Структуризованный язык запросов (SQL). – СПб.: ИТМО, 1994
6. Ладыженский Г.М. Системы управления базами данных - коротко о главном. - Jet Infosystems, 1995.
7. Материалы сайта “Сервер информационных технологий”. WEB: www.citforum.ru
8. Материалы сайта «хакер» WEB: www.xakep.ru
9. Материалы сайта «диджитал секьюрити» WEB: www.dsec.ru
10. Материалы сайта «Оракл для начинающих» WEB: oraclestart.blogspot.com
11. Материалы сайта «Oracle FA» WEB: www.orafaq.com

Процессе установки СУБД со стандартным SID

Распределение стойкости SID

SID Application Server

SID подбором

Получение SERVICE_NAME через Oracle XML DB

SID через Application Server 2