Алгоритм
Как описано в документации, в СУБД Oracle для создания паролей может использоваться следующий набор символов:
цифры '0123456789', буквы 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ' символы !"#$%&()`*+,-/:;<=>?_.
Поскольку все символы преобразуются к верхнему регистру, то мощность алфавита паролей равна 10+26+21=57 символов. В результате допустимых паролей может быть
Эксперименты показали, что в качестве пароля могут выступать вообще любые символы:
SQL> create user yu identified by "Пудовченко"; User created.
SQL> create user yu2 identified by "
Ключевым моментом здесь является то, что синтаксис сервера Oracle позволяет конструкции с двойными кавычками, между которыми может находиться любой символ.
В базе данных пароли пользователей хранятся в виде 8-байтовых хешей в таблице SYS.USER$.
В [] этот алгоритм описан так:
Конкатенировать логин и пароль пользователя (обозначим эту операцию ). Преобразовать полученную строку к верхнему регистру (UPPER(ЛогинПароль)). Если в ОС используется однобайтовая кодировка, то преобразовать каждый символ в двухбайтовый, заполнив старший байт нулями (0x00). Зашифровать получившуюся строку (дополняя ее нулями до длины блока), используя алгоритм DES в режиме CBC с фиксированным ключом, значение которого есть 0x0123456789ABCDEF. Зашифровать получившуюся строку еще раз с помощью DES-CBC, но используя последний блок предыдущего шага как ключ шифрования.
Графически это выглядит следующим образом:
Обозначим шифрование строки Х на ключе K как DES(X,K). Тогда, в аналитической форме уравнение шифрования выглядит так:
H = DES(UPPER(ЛогинПароль), DES(UPPER(ЛогинПароль), K))(1)
Если обозначить UPPER(ЛогинПароль) =Х, то уравнение станет совсем простым:
H=DES(X,DES(X,K)) (2)
Обратную операцию (расшифрование H на ключе K) обозначим так: X=DES-1(H,K).
Алгоритм шифрования DES определен для 56-битового ключа, но не во всех версиях СУБД Oracle выдерживается значение 56 бит. В силу ограничений экспортного законодательства США в 80-90 гг., запрещающего продавать за рубеж ПО и аппаратуру, содержащие стойкие криптографические алгоритмы, длина ключа для экспортных версий СУБД Oracle искусственно занижалась до 40 бит, что облегчает правительству США чтение шифрованной информации. Признание этого факта содержится, например, в «Oracle Database Advanced Security Administrator's Guide» страница 1-4: «Prior versions of Oracle Advanced Security provided three editions: Domestic, Upgrade and Export, each with different key length. Oracle Advanced Security 10g Release 2 (10.2) contains a complete complement of the available encryption algorithms and lengths, previously only available in the Domestic edition. … The U.S. government has relaxed its export guidelines for encryption products. Accordingly, Oracle can ship Oracle Advanced Security with its strongest encryption features to all of its customers» В последние годы экспортный контроль Гос. Департаментом США был значительно ослаблен, поскольку производители ПО и электроники стали нести слишком большие потери (упущенная выгода), из-за этих ограничений.
Анализ
С алгоритмической точки зрения при вскрытии современного шифра со случайным ключом существуют два принципиально различных направления атаки: поиск и использование некоторых уязвимостей алгоритма, и перебор ключей.
Поиск уязвимостей - долгая и кропотливая аналитическая работа, позволяющая делать выводы об исходных данных на основе шифрованных данных и знания алгоритма (криптосистемы).
Перебор ключей - (второе название «силовая атака», brute force - BF) стандартный способ подбора пароля, заключающийся в генерации очередного значения, шифровании его и сравнении полученного результата с имеющимся хешем. Основную роль в переборе ключей играют вычислительные мощности злоумышленника, таким образом, это универсальный способ для взлома различных шифров, поскольку этот способ не зависит от внутреннего устройства шифра.
Ввиду больших затрат времени и вычислительных средств, к перебору прибегают в том случае, когда остальными методами решить проблему не получается. И даже в случае перебора все равно, пытаются максимально сузить перебираемое множество за счет анализа особенностей конкретного алгоритма.
В дальнейшем будем предполагать, что злоумышленник знает логин пользователя, хеш H и ключ шифрования K.
Если бы криптосистема в Oracle строилась на однократном шифровании, при котором H=DES(X,K), то при известных H и K она бы мгновенно теряла стойкость, поскольку X=DES-1(H,K), и все параметры правой части известны.
В Oracle ситуация сложнее, и при наших допущениях если требуется вычислить пароль Х, то уравнение будет выглядеть так:
Х = DES-1 (H, K ) (3)
Заметим, что для обратной операции требуется промежуточный ключ K . Т.е., чтобы вычислить значение Х, в данном уравнении недостает значения K =DES(Х, K), которое является промежуточным ключом и не хранится нигде. А вычислить DES(Х, K) нет возможности, потому что X есть ЛогинПароль и пароль, по условиям задачи неизвестен.
Написанное выше означает, что, даже зная ключ шифрования K, можно только вычислить всевозможные значения DES(ЛогинПароль,K) для всевозможных значений пароля, а затем найти в этом множестве подходящее значение. А сделать это можно путем перебора всех возможных паролей, т.е. фактически только путем силовой атаки!
Вот в чем основной фокус криптографической конструкции в Oracle: для вычисления секретного пароля Х необходимо вначале вычислить промежуточный ключ DES(ЛогинПароль,K) для всевозможных значений пароля. Иными словами, теоретическая сложность взлома этой криптосистемы при отсутствии реальных уязвимостей, приближается к сложности силовой атаки на этот шифр.
Такая криптографическая конструкция - удачный пример однонаправленной функции, для которой неизвестна обратная. В итоге остается только перебирать вероятные пароли, сравнивая получившийся результат с образцом.
Однако говорить о том, что криптосистема Oracle является идеальной криптосистемой, еще рано. Для того чтобы быть уверенными в ее идеальности, следует исследовать ее особенности на предмет выявления закономерностей, позволяющих понизить ее криптостойкость. С точки зрения криптографии, использованная в Oracle конструкция имеет два потенциально интересных направления анализа (атаки):
Изучение свойств промежуточного ключа. Несмотря на то, что DES достаточно хороший алгоритм, можно ожидать, что подмножество порожденных значений K' будет небольшим, а также будет обладать специальными свойствами. В результате, из 264 теоретически возможных значений K', в действительности может реализоваться только малая часть. Из значений K' вместе со значением Х можно составить базу данных, чтобы в дальнейшем K' брать из БД и подавать на вход второго узла DES.
Потенциально интересной будет атака с накоплением DES(X,K) с одной стороны, и DES-1(H,Y) с другой, где Y - некоторое случайное значение (вероятное значение промежуточного ключа). В этом случае возможно как распараллелить эту атаку, так и понизить ее сложность.
Атака по словарю и парадокс дней рождений
Парадокс дней рождений означает следующее: чтобы с вероятностью 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 Тб- что, по-видимому, никогда не будет реализовано. Реальной уязвимости для длинных паролей не продемонстрировано.
Что могли знать разработчики в 1993 г. о хеш-функциях?
Исторические дискуссии о хеш-функциях восходят к 1953 г. (IBM) и описаны у Д.Кнута в его «Искусстве программирования», изданной в 1973 г.
В 1977 г. хеш-функции были классифицированы как независимый класс криптографических приложений в работе J. Carter M. Wegman "Universal classes of hash functions". В 1978 году М. Рабин (M.Rabin) ввел в употребление понятие однонаправленной хеш-функции, построенной из алгоритма шифрования. Десятилетие с 1980 заполнено работами Р.Меркля (R.Merkle), Домгард (Damgård), Райвест (R.Rivest) и ежегодными конференциями Eurocrypt.
В результате к 90 году появились наиболее известные из хэш-функций - MD2, MD4, MD5 и SHA, которые были оформлены в виде стандартов RFC. Так, в августе 1989 автором J. Linn выпущен документ RFC 1115, в котором были описаны два алгоритма: Message Authentication Code и RSA-MD2 Message Digest Algorithm.
RFC1115 продержался 3 года и в апреле 1992 ему на смену пришел RFC 1319, в котором была описана новая обновленная версия MD2.
Хеш-функции семейства MD (message digest) разработаны B.S. Kaliski и Роном Райвестом в 1989-м, 90-м и 91-м году соответственно и утверждены в качестве стандартов, например RFC 1319, "The MD2 Message Digest Algorithm". (http://www.rsasecurity.com/rsalabs/node.asp?id=2253)
Тогда же, в апреле 1992 г. появился RFC 1320 «The MD4 Message-Digest Algorithm», который заменил собой RFC 1186 от октября 1990 The MD4 Message Digest Algorithm.
Так что недостатка в информации у Боба Болдуина не было.
На сегодняшний день криптографами разработаны следующие хеш-функции: MAC, MASH, MDC, RIPEMD, SHA, MD2, MD4, MD5, детальную информацию о них можно найти в [] и в Интернет.
Российское законодательство требует использования российских алгоритмов шифрования и генерации хеш-значения для ПО, использующегося в государственных организациях. На сегодняшний день таким стандартом является ГОСТ Р34.11-94, разработанный совместно ГУБС ФАПСИ и ВНИИС, принятый и введёный в действие Госстандартом России 23.05.94. Размер хеш-значения 256 бит.
Ниже приведён текст Боба Болдуина:
From: Bob Baldwin -
Date: Thurs, Jul 8 1993 5:49 pm
Dave Trahan wants to know the Oracle password algorithm so he can check for weak passwords. When I was the project lead for Trusted Oracle I designed the new password algorithm that is used in versions 6, 7, and later. I presented the details at a Bay Area Trusted System Symposium so I am not revealing any information that is not already in the puiblic domain. Here are some of the details as I remember them.
Design Goals: 1. Must work with all terminals. ===> Some terminals do not have lowercase letters, so the password algorithm ignores differences between upper and lower case!!! The passwords "Tiger" and "tiger" map to the same value.
2. Must support usernames and passwords that include non-ascii characters. The username and password are converted to 16 bit per character representation before any processing is done. Ascii characters have the high byte zeroed.
3. If different users have the same password, then the one-way hash value (encrypted value) for the passwords will be different.
4. Long passwords are supported. I believe that usernames and passwords can both be 40 chars.
Implementation: 1. Upshift password, convert to 16bits per character, and place result left justified in an 80 byte array of zeros.
2. Using DES in cipher block feedback mode compute the CBC checksum for the 80 byte password array using a fixed secret password (you can find it in the code if you look hard enough). The result is used as the key for the next step ignoring parity bits to produce the a 56 bit key from the CBC.
3. Upshift password, and convert to 16bits per character, and place result left justified in an 80 byte array of zeros.
4. Using DES in cipher block feedback mode compute the CBC checksum for the 80 byte username array using the key generate in step 2.
5. Convert the CBC checksum from step 4 into a printable string with the obvious algorithm.
--Bob Baldwin Director of Development We provide the best solutions Los Altos Technologies, Inc. to our customers key security bald...@lat.com problems.
Доступ к хешам через линки БД
В словаре БД имеются
| USER_DB_LINKS | Database links owned by the user |
| ALL_DB_LINKS | Database links accessible to the user |
| DBA_DB_LINKS | All database links in the database |
| V$DBLINK | Synonym for V_$DBLINK |
| GV$DBLINK | Synonym for GV_$DBLINK |
| LINK$ | таблица, на которую ссылаются все вышеприведенные представления. |
Представления DBA_DB_LINKS и ALL_DB_LINKS являются безопасными, потому что в них отсутствует информация о паролях. В остальных четырех таблицах поле пароля присутствует, что может служить источником утечки информации. Если в системе баз данных применяются линки, то злоумышленник, получивший доступ к одному серверу может переходить от одной базы данных к другой.
Доступ к хешам паролей через sys.user$
Пароли пользователей хранятся в таблице sys.user$, над которой построен ряд стандартных представлений. Как сама sys.user$, так и представления могут быть использованы для получения хешей паролей. Представление DBA_TAB_COLS позволяет найти такие столбцы:
SQL> select owner, table_name from dba_tab_cols where column_name = 'PASSWORD'; SYS USER$ SYS USER_HISTORY$ SYS LINK$ SYS KU$_ROLE_VIEW SYS KU$_DBLINK_VIEW SYS DBA_USERS SYS KU$_10_1_DBLINK_VIEW SYS KU$_USER_VIEW SYS EXU8PHS SYS USER_DB_LINKS SYS EXU8ROL SYS KU$_PSW_HIST_LIST_VIEW WKSYS WK$_AUTHBASIC WKSYS WK$AUTHBASIC WKSYS WK$$AUTHBASIC
Потенциальными подозреваемыми будут аккаунты, имеющие доступ к этим столбцам.
Существует скрипт who_can_access.sql Питера Финигана (Pete Finnigan), позволяющий найти пользователей, имеющих доступ к этим объектам. Скрипт можно взять .
Таким образом, можно определить пользователей, получивших права SELECT ANY DICTIONARY или SELECT ANY TABLE. Привилегия SELECT ANY TABLE работает только в случае если o7_dictionary_accessibilty=TRUE
Чтобы получать информацию о пользователях, обращавшихся к учетным записям можно включить аудит на DBA_USERS
SQL >audit SELECT on dba_users;
Audit succeeded.
Злоумышленник, тем не менее, может обратиться к таблице Sys.user$ напрямую, на которую аудит установить невозможно:
SQL >audit select on sys.user$; audit select on sys.user$ * ERROR at line 1: ORA-00701: object necessary for warmstarting database cannot be altered
Но это единственная таблица, которой не повезло больше остальных. На остальные системные таблицы, содержащие столбец PASSWORD, аудит успешно устанавливается:
SQL >audit select on sys.link$; Audit succeeded. SQL >audit select on sys.user_history$; Audit succeeded. SQL >audit select on sys.dba_users; Audit succeeded. SQL >audit select on sys.KU$_ROLE_VIEW; Audit succeeded. SQL >audit select on sys.KU$_DBLINK_VIEW; Audit succeeded. SQL >audit select on sys.KU$_10_1_dblink_view; Audit succeeded. SQL >audit select on sys.KU$_USER_VIEW; Audit succeeded. SQL >audit select on sys.exu8phs; Audit succeeded. SQL >audit select on sys.user_db_links; Audit succeeded. SQL >audit select on sys.exu8rol; Audit succeeded. SQL >audit select on sys.KU$_psw_hist_list_view; Audit succeeded.
Источники и литература
| 1.обратно | Joshua Wright, Carlos Cid (18. Oct. 2005) An Assessment of the Oracle Password Hashing Algorithm |
| 2.обратно | Брюс Шнайер, Прикладная криптография, Издательство «Триумф» 2003 г. |
| 3.обратно | R. Morris, K. Thompson "Password security: A case history", Communications of ACM, v.22, n. 11, Nov. 1979., pp. 594-597. |
| 4.обратно | Л. Дж. Хоффман "Современные методы защиты информации"(М.: Сов. радио, 1980). |
| 5.обратно | Э. Танненбаум. «Современные операционные системы». М. СПб, Питер, 2002. |
На этом можно было бы и закончить, но у этой истории появилось .
| 1(обратно к тексту) | Хеш-функция - это преобразование, вычисляющее из данных произвольной длины некое значение (свертку) фиксированной длины, обычно от 64 до 256 бит. Простейшими примерами хеш-функций являются контрольные суммы, например, CRC32. Хеш-функции бывают криптографические и программистские. Криптографический хеш отличается от программистского двумя свойствами: необратимостью и свободностью от коллизий. |
Хеш-функции должны удовлетворять следующим требованиям:
Аргумент хеш-функции может быть строкой бит произвольной длины; Значение H(M) должно быть строкой бит фиксированной длины; Хеш-функция должна быть необратимой. Необратимость означает, что если известно хеш-значение X, то вычислительно сложно подобрать M такое, что H(M) = X, т.е. это требование означает, что сложно подобрать пароль по его хеш-значению. Свободность от коллизий означает, что вычислительно сложно подобрать такие m1 m2, что H(m1) = H(m2), т.е. когда для разных паролей получается одно и то же хеш-значение.
| 1.обратно | Joshua Wright, Carlos Cid (18. Oct. 2005) An Assessment of the Oracle Password Hashing Algorithm |
| 2.обратно | Брюс Шнайер, Прикладная криптография, Издательство «Триумф» 2003 г. |
| 3.обратно | R. Morris, K. Thompson "Password security: A case history", Communications of ACM, v.22, n. 11, Nov. 1979., pp. 594-597. |
| 4.обратно | Л. Дж. Хоффман "Современные методы защиты информации"(М.: Сов. радио, 1980). |
| 5.обратно | Марлен Терьо, Аарон Ньюмен «Oracle. Руководство по безопасности», Издательство Лори, 2004 г. |
| 6.обратно | Bob Baldwin. (1993, July 9). , Usenet Newsgroup comp.databases.oracle |
| 7.обратно | Журналы «Конфидент» № 6/97, 3/98. |
| 1(обратно к тексту) | Системы защиты обычно имеют недружественный характер, поэтому здесь следует соблюдать компромисс между строгостью системы и удобством пользователей. Если например, повысить минимальную длину пароля до 20 знаков, следует ожидать, то мониторы пользователей будут увешаны списками паролей, а техподдержка будет перегружена звонками типа "не могу войти в …". В результате, в серьезной и строгой системе информационной безопасности самым слабым звеном окажется человеческий фактор. |
История парольной защиты
Одними из первых, кто понял, что в ИС не обязательно хранить сами пароли, были Роджер Нидхам и Майк Гай []. Достаточно, чтобы ИС могла отличать достоверные пароли от недостоверных. В современных ИС для этой цели хранится хеш пароля, т.е. результат применения к паролю хеш-функции.
Исторически были выработаны следующие принципы парольной защиты [,,]:
Выбор сложных паролей. Главная атака на пароль состоит в переборе всех возможных паролей указанной длины, вычисление его хеша и сравнение с образцом. Вычисления могут быть произведены противником заранее, на быстродействующей ЭВМ, а затем сохранены в базе данных в виде индексированного дерева, что позволит при необходимости быстро проверить наличие искомого пароля. А поскольку пользователи зачастую выбирают легко запоминающиеся пароли, то тем самым они невольно способствуют злоумышленнику, сокращая пространство возможных значений. Для удобства вскрытия злоумышленник может составить словарь наиболее употребительных паролей. Итак, самое слабое место парольной защиты это низкая энтропия обычных паролей.
Использование случайного числа-привязки (соль). Хеш-функция является детерминированной. Будучи примененной к одним и тем же исходным данным, она в результате выдает одно и то же значение. Следовательно, два разных пользователя, выбрав один и тот же пароль, получат в результате одно и то же хеш-значение. Таким образом, пользователь, не обладая глубокими знаниями в области вскрытия шифров, а, зная только свой собственный пароль, сможет просмотреть все хеш-значения и определить других пользователей с таким же, как у него паролем. Чтобы предотвратить подобную уязвимость, каждый пароль имеет ассоциированное с ним случайное число, которое используется совместно с паролем для генерации хеша пароля. Обычно это случайное число побитово складывается с паролем, в результате чего на вход хеш-функции подаются различные данные, даже если пользователи вводят один и тот же пароль. Случайное число достаточной длины позволяет также затруднить атаку на пароли за счет того, что не позволяет противнику заранее вычислить все возможные пароли заданной длины и их хеши и реализовать атаку по словарю. Медленный однонаправленный алгоритм. Медленный однонаправленный алгоритм означает, что хеш-функция не должна вычисляться быстро. Если хеш-функция вычисляется быстро, то хакер тоже ее вычислит быстро, и быстро осуществит перебор паролей. Поэтому медленный однонаправленный алгоритм нужен, чтобы замедлить работу хакеров. Он не сильно затруднит одноразовое вычисление пароля (например, при подключении к БД), но существенно затруднит противнику перебор всевозможных паролей. Наиболее популярное решение здесь - это многократное итеративное использование хеш-функций. Например, в Unix-системах однонаправленная функция шифрования применяется итеративно несколько раз, чтобы обеспечить достаточно большое время отклика.
Устройство системы не должно быть секретом. Секретным элементом должен быть только сменный элемент системы, например, ключ шифрования.
По умолчанию доступ к системе не предоставляется.
Система защиты должна быть дружественной. Даже очень надежная система защиты, которая в значительной мере мешает ему выполнять свои функции, в конце концов, будет отвергнута.
История вопроса
Оказывается, в Интернете имеется системы парольной защиты СУБД Oracle:
«… Когда я был руководителем проекта Trusted Oracle, то я спроектировал алгоритм, который использовался в версиях 6, 7 и более старших. Я представил детали на симпозиуме Bay Area Trusted System, и после этого я не слышал, о том, чтобы они была опубликована где-либо еще. Вот некоторые детали, которые я помню.
Цели проектирования:
Должен работать со всеми терминалами.
Некоторые терминалы оснащены только заглавными буквами, поэтому парольный алгоритм должен игнорировать различие между заглавными и обычными вариантами. Пароли Tiger и tiger должны восприниматься как один и тот же пароль. Имена пользователей и пароли должны допускать не-ascii кодировку.
Символы имен и паролей конвертируются в 16-битовые значения, перед дальнейшей обработкой. У ASCII-символов старший байт 0. Если различные пользователи используют один и тот же пароль, то хеш-значения таких паролей должны различаться. Должны поддерживаться длинные пароли.
По моему мнению, логин и пароль могут быть по 40 знаков каждый.
Боб Болдуин,
Директор департамента разработки компании Los Altos Technologies, Inc. bald...@lat.com»
Наконец-то стало понятно, почему в СУБД Oracle игнорируется различие заглавных/строчных букв: «Некоторые терминалы оснащены только заглавными буквами… ». Однако все равно странно, почему разработчикам Unix'ов такие терминалы не попадались? ;-) Или почему наличие таких терминалов нисколько не помешало им использовать заглавные/строчные буквы как различные символы? Хотя присутствие 26 дополнительных символов принципиально ничего не изменит в защите, но тем не менее очевидно, что их присутствие увеличит затраты злоумышленника на реализацию силовой атаки, а это всегда хорошо!
Цель 3 - «Если различные пользователи используют один и тот же пароль, то хеш-значения таких паролей должны различаться» хорошая идея, которая в СУБД Oracle обрела весьма своеобразную реализацию. Очевидно, что реализация значения привязки в СУБД Oracle злоумышленнику ничем существенным помешать не может.
И еще одна неувязочка: у Болдуина, судя по его ответу, длина логина и пароля может достигать 40 знаков, но в реальной БД это не так. В реальной жизни при длине пароля 31 знак и более возникает ошибка ORA-00972: identifier is too long:
SQL >alter user sys identified by a234567890123456789012345678901; alter user sys identified by a234567890123456789012345678901 * ERROR at line 1: ORA-00972: identifier is too long
SQL >create user a234567890123456789012345678901 identified by x; create user a234567890123456789012345678901 identified by x * ERROR at line 1: ORA-00972: identifier is too long
В объяснении ошибки говорится:
| Cause: | The name of a schema object exceeds 30 characters. Schema objects are tables, clusters, views, indexes, synonyms, tablespaces, and usernames. |
| Action: | Shorten the name to 30 characters or less. |
Длинные парольные фразы не такая уж редкость. Многие руководства по безопасности рекомендуют выбирать фразу или предложение в качестве пароля, а с приходом в нашу жизнь кодировки Unicode такие фразы легко оказываются более 30 байт. С учетом современных реалий было бы полезно разрешить пользователю ввести фразу достаточно большой длины, например, до 256 знаков.
Эквивалентная длина хешей и паролей
Еще один момент касается соизмеримой длины паролей и хешей.
Дело в том, что длина паролей в Oracle может достигать 30 знаков, а длина хеша фиксирована и равна 8 байт, т.е.64 бита. Таким образом, на одно хеш-значение приходится приблизительно 1052/1019=1033 возможных паролей в Oracle.
Давайте прикинем эффективную длину пароля, в зависимости от длины хеш-значения. Возможных значений хеш-функции 264, следовательно, надо решить уравнение 57х=264. В результате получаем х≈11. Этот факт показывает, что практически для всех паролей длиной больше 11 знаков будет существовать более короткий пароль. Следовательно, в результате силовой атаки злоумышленник обнаружит один из кратчайших паролей. Но, поскольку хеш короткого и длинного паролей одинаковы, то пароли можно считать неразличимыми. Следовательно, при длине пароля более 11 знаков увеличение длины пароля не увеличивает время безопасности СУБД, т.е. необходимое злоумышленнику для его нахождения.
Интересно также узнать, а что если Oracle решит отказаться от принудительного преобразования символов к верхнему регистру, то, как это повлияет на эффективную длину? Оказывается в этом случае х≈10! Разница всего в 1 знак.
Для современных хеш-функций минимальная длина хеш-значения обычно находится на уровне 128 бит. Что в этом случае?
А в этом случае 2128 ≈ 5722 ≈8320, что означает, что для хеш-значений 128-битовой длины потребуется 22 знака из 57-знакового множества, либо 20 знаков для 83-знакового (т.е. 20 знаков, если отказаться от преобразования к верхнему регистру).
Ну и, наконец, 30-символьному паролю должен соответствовать хеш длиной
175 бит, если сохраняется Upper() (57 знаков); 191,25 бит, если отказаться от Upper() (83 знака).
Краткое введение
Парольная защита является наиболее распространенным способом аутентификации пользователей в современных информационных системах (ИС). Пользователь вводит пароль, сервер сравнивает значение, введенное пользователем с тем, что хранится у него в памяти и в зависимости от результата сравнения разрешает или отвергает подключение пользователя.
С хранением и передачей пароля связаны основные проблемы:
Если передавать пароль в открытом виде, то его можно узнать, слушая пакеты по сети. Хранить пароль в сервере в открытом виде тоже небезопасно, т.к. его можно подсмотреть.
Таким образом, пароль приходится шифровать.
Вопрос об алгоритме шифрования паролей в СУБД Oracle практически не освещен в русскоязычной литературе и Интернет, хотя имеет важное значение для безопасного хранения данных в базе данных.
Система шифрования паролей является достаточно консервативным элементом СУБД, ибо ее малейшее изменение влияет на возможность/невозможность подключения клиентов к базе данных. Таким образом, частое изменение этой подсистемы СУБД нежелательно. Видимо, этот фактор сказался на том, что подсистема шифрования паролей была неизменной много лет, по моим оценкам - около 15. Изменение системы шифрования повлекло бы за собой ряд сообщений ORA-xxxxx, сообщающих об ошибках в системе шифрования и в технической документации были бы упомянуты причины и способы их решения. Судя по отсутствию этих проблем в технической документации и Интернет, можно сделать вывод, что в СУБД Oracle подсистема шифрования паролей была неизменной достаточно длительное время, где-то последние 15 лет.
До определенного момента о подсистеме шифрования паролей в СУБД Oracle вообще не было ничего неизвестно, несмотря на то, что система шифрования СУБД Oracle не может быть секретной, поскольку эта СУБД эксплуатируется во всем мире, а не только в защищенных ВЦ США.
Мои экспериментальные исследования этого вопроса привели к нескольким экспериментально установленным фактам.
Первым фактом стало то, что в СУБД Oracle не различаются строчные и заглавные символы. Затем эксперименты с прослушиванием сетевых пакетов показали, что клиентский пароль не передается на сервер в открытом виде. Следовательно, обработка клиентского пароля осуществляется на клиенте, и для защиты пароля используется какой-то алгоритм шифрования. И, скорее всего, этот алгоритм - DES, поскольку другого общедоступного сертифицированного алгоритма, существовавшего на протяжении последних 15 лет в США нет.
Постепенно стало очевидно, что в СУБД Oracle на все инсталляции используется один и тот же ключ, потому что шифрование осуществляется на клиенте, но при этом, клиент может подключаться ко всем базам данных, независимо от аппаратной платформы, битности, версий ОС и версий Oracle. Иными словами, проинсталлировав клиента у себя в ПК под Windows, я могу подключаться к любой базе данных Oracle. Значит, значение ключа не является функцией, зависящей от версии СУБД, типа инсталляции (клиент или сервер), версии ОС. Очевидно, что сам собой напрашивается вывод о том, что ключ является константой, единой на все инсталляции СУБД, а значение этой константы «зашито» в каждом дистрибутиве, и даже конкретно в каждом исполняемом файле sqlplus. Таким образом, взяв один дистрибутив можно было узнать ключ, а, узнав ключ, можно расшифровать и получить в открытом виде пароль!
А вот это уже в голове не укладывалось: подобная криптосистема - это ошибка с точки зрения криптографической защиты, или компания сознательно пожертвовала безопасностью в угоду удобствам эксплуатации? Однако детали этой конструкции были покрыты мраком.
Погружаться в декомпилирование кода СУБД не было возможности, поэтому данная проблема так и не нашла своего решения.
Последним штрихом для создания полноценной картины явилось опубликование 18 октября 2005 г. исследования «An Assessment of the Oracle Password Hashing Algorithm» авторов Joshua Wright и Carlos Cid, в котором описан алгоритм шифрования паролей в СУБД Oracle.
Пароли и OEM Grid Control
OEM Grid Control - основное средство, предлагаемое корпорацией для мониторинга и управления базами данных Oracle. Этот инструмент способен мониторить и управлять не только БД, но и OAS, хосты и сети между всем этим, способен подключаться к металинку за новым ПО. OEM Grid Control (OEMGC) хранит
пароли к базам данных (системные пользователи, наделенные наиболее сильными привилегиями), пароли к хостам (чтобы подключаться, когда БД не стартована) логин и пароль на металинк.
Злоумышленник, получивший доступ к этому средству, автоматически получит информацию и средство управления всеми БД, листенерами, OAS'ами, хостами и доступом на металинк. Таким образом, OEM Grid Control - один из наиболее интересных для злоумышленника участков и наиболее сильная болевая точка ИС на основе Oracle.
OEMGC'у соответствует схема SYSMAN. Пароли хранятся в таблицах
MGMT_CREDENTIALS2, MGMT_ARU_CREDENTIALS (металинк) MGMT_VIEW_USER_CREDENTIALS.
Вообще-то, таблиц больше, чем три:
select object_name,object_type from dba_objects where object_name like '%CREDENTIAL%' and owner = 'SYSMAN'
OBJECT_NAME OBJECT_TYPE ----------------------------------- ------------ EM_CREDENTIAL PACKAGE MGMT_CREDENTIAL PACKAGE MGMT_ARU_CREDENTIALS TABLE MGMT_COLLECTION_CREDENTIALS TABLE MGMT_CONTAINER_CREDENTIALS TABLE MGMT_CREDENTIALS TABLE MGMT_CREDENTIALS2 TABLE MGMT_CREDENTIAL_SETS TABLE MGMT_CREDENTIAL_SET_COLUMNS TABLE MGMT_CREDENTIAL_TYPES TABLE MGMT_CREDENTIAL_TYPE_COLUMNS TABLE MGMT_CREDENTIAL_TYPE_COL_VALS TABLE MGMT_CREDENTIAL_TYPE_REF TABLE MGMT_ENTERPRISE_CREDENTIALS TABLE MGMT_HOST_CREDENTIALS TABLE MGMT_JOB_CREDENTIALS TABLE MGMT_TARGET_CREDENTIALS TABLE MGMT_UPDATE_CREDENTIALS_DATA TABLE MGMT_VIEW_USER_CREDENTIALS TABLE
Любой пользователь с правами DBA имеет доступ к этой информации. Узнать пароли можно так:
Логин + пароль для БД, ОС и листенера:
select credential_set_column, sysman.decrypt(credential_value) from sysman.MGMT_CREDENTIALS2
Логин + Пароль на металинк:
select sysman.decrypt(aru_username),sysman.decrypt(aru_password) from sysman.MGMT_ARU_CREDENTIALS
15-байтовое случайное число - пароль пользователя MGMT_VIEW, который используется для работы OEMGC, учетная запись создается как expired & locked: select view_username,sysman.decrypt(view_password) from sysman.MGMT_VIEW_USER_CREDENTIALS
Шифрование/расшифрование этих паролей производится командами sysman.encrypt() и sysman.decrypt(). В БД эти функции присутствуют в виде wrap-кода, но любой желающий может восстановить их текст с помощью трассировки. Рассмотрим их подробнее:
FUNCTION ENCRYPT( PLAIN_TEXT IN VARCHAR2 ) RETURN VARCHAR2 IS CIPHER_TEXT RAW( 32767 ); BEGIN CIPHER_TEXT := DBMS_CRYPTO.ENCRYPT( SRC=>UTL_I18N.STRING_TO_RAW( PLAIN_TEXT, 'AL32UTF8' ), TYP=>DBMS_CRYPTO.ENCRYPT_3DES + DBMS_CRYPTO.CHAIN_CBC + DBMS_CRYPTO.PAD_PKCS5, KEY=>GETEMKEY() ); RETURN RAWTOHEX( CIPHER_TEXT ); END;
FUNCTION DECRYPT( CIPHER_TEXT IN VARCHAR2 ) RETURN VARCHAR2 IS RAW_TEXT RAW( 32767 ); BEGIN RAW_TEXT := DBMS_CRYPTO.DECRYPT( SRC=>HEXTORAW( CIPHER_TEXT ), TYP=>DBMS_CRYPTO.ENCRYPT_3DES + DBMS_CRYPTO.CHAIN_CBC + DBMS_CRYPTO.PAD_PKCS5, KEY=>GETEMKEY() ); RETURN UTL_I18N.RAW_TO_CHAR( RAW_TEXT, 'AL32UTF8' ); END;
Функции sysman.encrypt() и sysman.decrypt() используют алгоритм 3DES в режиме СВС с дополнением строки до требуемой длины блока по методу PAD_PKCS5.
Принципиальным моментом в encrypt/decrypt является функция вызова ключа GETEMKEY(). Выглядит она примерно так:
FUNCTION GETEMKEY RETURN RAW IS DES_KEY RAW( 64 ) := NULL; BEGIN SELECT SEED INTO DES_KEY FROM MGMT_EMCRYPTO_SEED WHERE ROWNUM = 1; RETURN ( DES_KEY ); END;
Так какой это ключ? Вот какой:
SELECT SEED FROM MGMT_EMCRYPTO_SEED WHERE ROWNUM = 1;
Таблица MGMT_EMCRYPTO_SEED состоит из одного столбца и одной строки и содержит, по-видимому, случайное для каждой БД число. Таким образом, ключ является константой.
SQL >desc sysman.MGMT_EMCRYPTO_SEED Name Null? Type ----------------------------------------- -------- ------------ SEED RAW(64)
SQL >select * from sysman.MGMT_EMCRYPTO_SEED; SEED ---------------------------------------------------------------- 1FCFB6FBD7E14B384C3EDB7B8694EA891FCFB6FBD7E14B384C3EDB7B8694EA89 1 row selected.
Выводы:
ключ хранится в БД в открытом виде в таблице MGMT_EMCRYPTO_SEED. для шифрования используются общедоступные функции encrypt/decrypt. кто имеет доступ к словарю БД, тот имеет большой доступ ко всему остальному. на три таблицы можно установить аудит.
Пароли в трассировочных файлах
Получить пользовательские пароли можно из трассировочных файлов.
Так, например, если установить трассировку пользовательской сессии, то можно увидеть, как пользователь выполняет:
SQL >alter system set wallet open identified by 'tiger';
В этот момент в трассировочном файле нечувствительно для работающего пользователя появляется:
===================== PARSE ERROR #4:len=51 dep=0 uid=0 oct=49 lid=0 tim=536326851182 err=28357 alter system set wallet open identified by 'tiger' =====================
Подмена пакетов
Разрешение имен в БД Oracle производится в следующей последовательности:
Если имеется объект с таким названием в текущей схеме, то используется он Если имеется приватный синоним с таким названием в текущей схеме, то используется он. Если в БД имеется общедоступный синоним с таким названием, то используется он.
Описанная система имеет тот недостаток, что злоумышленник может произвести подмену пакетов, без ущерба для работоспособности объектов схемы. Для этого в текущей схеме создается новый пакет, с таким же именем, как и вызываемый (например, dbms_crypto), который делает некоторые дополнительные действия (например, вызов процедуры utl_http, utl_mail, utl_smtp и т.д.) а затем вызывает настоящий dbms_crypto. В результате пользователь может и не заметить подмены, компиляция всех объектов схемы будет происходить успешно, а пароли будут утекать в Интернет.
Пароли к схемам можно получить из файла логов http-web-access.log или путем включения трассировки
Бороться с подменой пакетом можно
путем полной адресации объекта, например SQL > exec SYS.dbms_crypto …
также путем отнимания привилегий на потенциально опасные пакеты UTL_MAIL, UTL_SMTP, UTL_TCP, UTL_HTTP, UTL_FILE, DBMS_RANDOM:
REVOKE EXECUTE ON UTL_SMTP FROM PUBLIC; REVOKE EXECUTE ON UTL_TCP FROM PUBLIC; REVOKE EXECUTE ON UTL_HTTP FROM PUBLIC; REVOKE EXECUTE ON UTL_FILE FROM PUBLIC; REVOKE EXECUTE ON DBMS_RANDOM FROM PUBLIC;
Обнаружение потенциальных злоумышленников производится запросом:
SELECT * FROM DBA_TAB_PRIVS WHERE PRIVILEGE = 'EXECUTE' AND GRANTEE = 'PUBLIC' AND TABLE_NAME IN('UTL_SMTP','UTL_TCP','UTL_HTTP','DBMS_RANDOM') ;
SELECT GRANTEE AS USERNAME, PRIVILEGE, ADMIN_OPTION FROM DBA_SYS_PRIVS WHERE ( PRIVILEGE LIKE '% ANY %' OR PRIVILEGE LIKE '%DATABASE LINK%' OR PRIVILEGE LIKE '%UNLIMITED%' OR PRIVILEGE = 'BECOME USER' OR ADMIN_OPTION = 'YES' ) AND GRANTEE NOT IN ( 'SYS', 'SYSTEM', 'OUTLN', 'DBSNMP', 'DBA', 'CONNECT', 'RESOURCE', 'EXP_FULL_DATABASE', 'IMP_FULL_DATABASE', 'AQ_ADMINISTRATOR_ROLE', 'OEM_MONITOR', 'CTXSYS', 'IFSSYS', 'IFSSYS$CM', 'MDSYS', 'ORDPLUGINS', 'ORDSYS', 'TIMESERIES_DBA', 'WKSYS', 'SYSMAN', 'OLAPSYS', 'OLAP_DBA', 'EXFSYS', 'SCHEDULER_ADMIN', 'WMSYS', 'SI_INFORMTN_SCHEMA', 'JAVADEBUGPRIV', 'MDDATA', 'RECOVERY_CATALOG_OWNER' ) AND GRANTEE NOT IN ( SELECT USERNAME FROM DBA_USERS WHERE ACCOUNT_STATUS != 'OPEN' ) ORDER BY 1, 2 ;
А обнаружение потенциальных Троянов производится запросом: SELECT * FROM DBA_SYNONYMS WHERE OWNER = 'PUBLIC' AND NOT TABLE_OWNER IN ('SYS','SYSMAN','SYSTEM','WMSYS','EXFSYS','ORDSYS','MDSYS', 'XDB');
DES и режим CBC
DES - один из наиболее популярных шифровальных алгоритмов, разработан компанией IBM и Правительством США в 1977 г. для защиты коммерческой информации. Таким образом, DES - поддержанный на государственном уровне симметричный алгоритм.
Алгоритм DES использует случайный 56-битовый ключ шифрования, это означает 256= 72 057 594 037 927 936 возможных ключей, приблизительно 7,2*1017 значений. Размер блока шифрования 64 бит. Открытый текст разбивается на блоки по 64 бит и подается на вход DES, в результате чего получается шифртекст. Алгоритм DES имеет 4 режима работы. Один из них Cipher Block Chaining (CBC).
CBC - это режим шифрования с обратной связью, при котором перед вычислением очередного шифрованного блока открытый текст складывается побитно по модулю 2 с предыдущим шифртекстом. В режиме СВС над открытым текстом и предыдущим шифртекстом выполняется операция XOR и тем самым каждый предыдущий шифрблок используется для модифицирования очередного блока открытого текста.
Если без обратной связи шифрование DES производится так:
| Блок 1 | Блок 2 | Блок 3 | Блок 4 |
 | | | |
| Шифртекст 1 | Шифртекст 2 | Шифртекст 3 | Шифртекст 4 |
где ↓ означает шифрование DES, то в режиме СВС так:
| Блок 1 | Блок 2 | Блок 3 | Блок 4 |
 | | | |
| Шифртекст 1 | Шифртекст 2 | Шифртекст 3 | Шифртекст 4 |
где
В режиме шифрования без обратной связи все одинаковые исходные открытые тексты будут зашифрованы одинаково, что дает возможность противнику угадать открытый текст, даже не прибегая к его расшифровыванию, а просто накапливая шифрблоки и соответствующие им открытые тексты. Сцепление добавляет в блочный шифр механизм обратной связи, и, таким образом, результат шифрования этого блока зависит не только от его значения и значения ключа, но и от предыдущих блоков этого сообщения. При шифровании в режиме СВС одинаковые блоки открытого текста превращаются в различающиеся друг от друга блоки шифртекста только в том случае, если различались предшествующие блоки. Однако два одинаково начинающихся сообщения будут зашифрованы одинаково.
Для того чтобы два одинаковых сообщения после шифрования выглядели по-разному, вводится понятие вектора инициализации, или по-криптографически - синхропосылка. Это и есть та самая «соль», которая делает хеши сообщений непохожими друг на друга:
| Синхропосылка | Блок 1 | Блок 2 | Блок 3 | Блок 4 |
| | | | |
| Шифртекст 0 | Шифртекст 1 | Шифртекст 2 | Шифртекст 3 | Шифртекст 4 |
На сегодняшний день общепризнанно минимальной длиной ключа для симметричных алгоритмов является 128 бит, а размер блока 256 бит. (На этот счет имеются работы автора данной статьи [журнал Конфидент 3/98, 6/98] и в )
Стойкость несимметричных алгоритмов используемых в Oracle (RSA, Diffie-Hellman) основывается на задаче факторизации больших чисел, поэтому минимальная граница для них совершенно другая - 2048 бит, а лучше 4096.
позволяющий найти пользователей, имеющих доступ
Скрипт who_can_access.sql Питера Финигана (Pete Finnigan), позволяющий найти пользователей, имеющих доступ к этим объектам. Получен отсюда.
who_can_access: Release 1.0.3.0.0 - Production on Thu Apr 20 12:53:15 2006 Copyright (c) 2004 PeteFinnigan.com Limited. All rights reserved.
NAME OF OBJECT TO CHECK [USER_OBJECTS]: dba_users OWNER OF THE OBJECT TO CHECK [USER]: sys OUTPUT METHOD Screen/File [S]: FILE NAME FOR OUTPUT [priv.lst]: OUTPUT DIRECTORY [DIRECTORY or file (/tmp)]: EXCLUDE CERTAIN USERS [N]: USER TO SKIP [TEST%]:
Checking object => SYS.DBA_USERS ====================================================================
Object type is => VIEW (TAB) Privilege => SELECT is granted to => User => CTXSYS (ADM = NO) Role => SELECT_CATALOG_ROLE (ADM = NO) which is granted to => Role => OLAP_USER (ADM = NO) which is granted to => User => SYS (ADM = YES) Role => DBA (ADM = YES) which is granted to => User => ABS (ADM = NO) User => SYS (ADM = YES) User => SYSMAN (ADM = NO) User => YU (ADM = NO) User => ABS_TYPES (ADM = NO) User => SYSTEM (ADM = YES) Role => IMP_FULL_DATABASE (ADM = NO) which is granted to => User => SYS (ADM = YES) Role => DBA (ADM = NO) which is granted to => User => ABS (ADM = NO) User => SYS (ADM = YES) User => SYSMAN (ADM = NO) User => YU (ADM = NO) User => ABS_TYPES (ADM = NO) User => SYSTEM (ADM = YES) Role => OLAP_DBA (ADM = NO) which is granted to => Role => DBA (ADM = NO) which is granted to => User => ABS (ADM = NO) User => SYS (ADM = YES) User => SYSMAN (ADM = NO) User => YU (ADM = NO) User => ABS_TYPES (ADM = NO) User => SYSTEM (ADM = YES) User => OLAPSYS (ADM = NO) User => SYS (ADM = YES) User => SH (ADM = NO) Role => EXP_FULL_DATABASE (ADM = NO) which is granted to => Role => DBA (ADM = NO) which is granted to => User => ABS (ADM = NO) User => SYS (ADM = YES) User => SYSMAN (ADM = NO) User => YU (ADM = NO) User => ABS_TYPES (ADM = NO) User => SYSTEM (ADM = YES) User => SYS (ADM = YES) User => PERFSTAT (ADM = NO) User => SYS (ADM = YES) User => IX (ADM = NO)
Таким образом, можно определить пользователей, получивших права SELECT ANY DICTIONARY или SELECT ANY TABLE.
Привилегия SELECT ANY TABLE работает только в случае, если o7_dictionary_accessibilty=TRUE
Математическая модель стойкости парольной защиты
Пусть в информационной системе (ИС) имеется злоумышленник, который в некоторый момент времени начинает атаку на эту ИС путем подбора пароля для какого-либо учетной записи.
Для того чтобы гарантированно подобрать пароль, ему придется выполнить SL попыток, где S - это мощность алфавита, из которого выбираются символы пароля, а L - длина пароля. Если каждая попытка требует ввода C символов (логин + пароль), а злоумышленник вводит символы со скоростью R знаков в секунду, то на каждую попытку ввода пароля требуется C/R секунд. Если в системе предусмотрена задержка D секунд, срабатывающая при вводе неверных реквизитов, то время на одну попытку потребуется C/R+D секунд.
В результате общее время, необходимое, чтобы перебрать всевозможные пароли, выражается формулой
где (D+C/R) определяет полное время, затрачиваемое нарушителем на одну попытку подбора пароля, SL - общее количество возможных паролей.
Можно математически доказать, что, в среднем, время, которое потребуется злоумышленнику до того момента, когда он найдет правильный пароль, в два раза меньше
Коэффициент ½ появился потому, что величина SL(D+C/R) есть максимальное время, т.е. время перебора злоумышленником всех возможных значений. А вот среднее значение (математическое ожидание случайной величины, в течение которого система защиты не поддается взлому) равно половине максимального времени для равномерно распределенных случайных величин. Отсюда и коэффициент ½.
Если злоумышленник производит ряд случайных попыток в течение времени t, то вероятность взлома системы защиты за это время есть отношение t/T:
Таким образом, администратор обладает простым и эффективным средством для определения вероятности взлома, в зависимости от конкретных параметров, установленных в конкретной системе.
Предположим, что необходимо вычислить минимальную длину пароля при прочих фиксированных параметрах, чтобы злоумышленник за время t не смог подобрать пароль с вероятностью большей, чем некоторое малое p. Тогда, так как SL = (t*R)/(P*(D+C/R)* C), то можно записать
Попробуем рассчитать нижнюю границу для Тб для СУБД Oracle, для чего сделаем несколько реальных предположений. Пусть нарушитель работает со скоростью 100 символов в секунду (R). Длина логина пусть будет 3 и 6 знаков (SYSTEM и SYS), длина пароля 8 знаков, а задержка отсутствует. В результате, получаем, что злоумышленник будет трудиться
| System | 6 | 8 | 123 668 лет |
| Sys | 3 | 8 | 194 336 лет |
| 1(обратно к тексту) | Не во всех версиях СУБД Oracle выдерживается значение 56 бит. В силу ограничений экспортного законодательства США в 80-90 гг., запрещающего продавать за рубеж ПО и аппаратуру, содержащие стойкие криптографические алгоритмы, длина ключа для экспортных версий СУБД Oracle искусственно занижалась до 40 бит, что облегчает правительству США чтение шифрованной информации. Признание этого факта содержится в "Oracle Database Advanced Security Administrator's Guide" страница 1-4: "Prior versions of Oracle Advanced Security provided three editions: Domestic, Upgrade and Export, each with different key length. Oracle Advanced Security 10g Release 2 (10.2) contains a complete complement of the available encryption algorithms and lengths, previously only available in the Domestic edition. … The U.S. government has relaxed its export guidelines for encryption products. Accordingly, Oracle can ship Oracle Advanced Security with its strongest encryption features to all of its customers" В последние годы экспортный контроль Гос. Департаментом США был значительно ослаблен, поскольку производители ПО и электроники стали нести слишком большие потери (упущенная выгода), из-за этих ограничений. |
Разведка паролей
Прежде, чем приступать к добыванию хеш-значений, лучше попробовать найти пароли сразу в открытом виде. Чаще всего пароли находятся в следующих местах:
На сервере
В файлах истории команд shell (bash_history) В скриптах shell В файлах логов В двоичных дампах В трассировочных файлах
В Application Server'е
В файлах конфигурации JDBC В трассировочных файлах На клиентских ПК
В ярлыках на рабочем столе В командных файлах В конфигурационных и инициализационных файлах ( connections.ini) В трассировочных файлах
В виде хеш-значений пароли можно получить из следующих источников:
Из таблицы sys.user$. К этой таблице имеют доступ
все, кто обладают привилегией DBA все, кто обладают привилегией SELECT ANY DICTIONARY В версии 8i все, кто обладают привилегией SELECT ANY TABLE если значение параметра o7_dictionary_accessibility=true
Из табличного пространства SYSTEM (датафайл system01.dbf)
Права на него по умолчанию rw-r----- т.е. читать может не только владелец-пользователь, но и вся и группа. Из файла паролей orapwSID, который находится в каталоге $ORACLE_HOME/dbs, права на него также rw-r-----
Из файлов экспорта и бэкапов RMAN'a. Из архивных логов
Из нешифрованного TNS трафика. Несмотря на то, что СУБД Oracle не передает пароль по сети в открытом виде, тем не менее, хеш пароля проходит по сети и может быть перехвачен злоумышленником. В ОС Солярис, это можно проверить, перехватывая все пакеты, исходящие с Вашего локального ПК и входящие на порт 1521 сервера: snoop -vx from source_IP to dest_IP port 1521 > file
В Linux это можно проверить с помощью tcpdump.
Возможность шифрования трафика включена в опцию Oracle Advanced Security.
Типичные ошибки, относящиеся к паролям, укажут правильное направление атаки:
| ORA_28000: The account is locked Логин заблокирован. | Подождать в течение PASSWORD_LOCK_TIME и повторить попытку или попросить администратора сменить пароль |
| ORA-28001: The password has expired Истек срок действия пароля. | При возможности сменить пароль самостоятельно или обратиться за этим к администратору. |
| ORA-00988: Missing or invalid password(s) Пароль не набран, либо набран неверно | Используйте двойные кавычки, например alter user scott identified by "!alex" |
| ORA-01017: Invalid username/password; logon denied Введен неверный логин или пароль, доступ запрещен. | Проверьте правильность вводимых реквизитов. |
Рекомендации по повышению безопасности
С учетом результатов данной статьи становится понятно, что в системах с повышенными требованиями к безопасности для обеспечения надежной аутентификации следует использовать более сильные средства, чем парольная защита СУБД Oracle. Рекомендации естественно вытекают из описанных выше уязвимостей.
Придерживаться принципа минимума привилегий при назначении ролей и выдаче привилегий.
Усилить политику безопасности при выборе паролей, ограничив снизу минимальную длину пароля 10-12 знаками. Эти действия реализуются путем настройки профиля и выполнения скрипта utlpwdmg.sql. Скрипт utlpwdmg.sql рекомендуется изменить, с тем, чтобы применять в нем свои технологии генерации паролей.
Запретить удаленное подключение как DBA (файл init.ora, spfile.ora). remote_os_authentication=FALSE
Несмотря на наличие бреши, связанной с sys.user$, установить аудит SELECT-выражений выполняемых над таблицами, содержащими столбец PASSWORD:
audit select on sys.link$; audit select on sys.user_history$; audit select on sys.dba_users; audit select on sys.KU$_ROLE_VIEW; audit select on sys.KU$_DBLINK_VIEW; audit select on sys.KU$_10_1_dblink_view; audit select on sys.KU$_USER_VIEW; audit select on sys.exu8phs; audit select on sys.user_db_links; audit select on sys.exu8rol; audit select on sys.KU$_psw_hist_list_view;
Настройка IP-адресов, с которых возможно подключение к БД (файлы sqlnet.ora, protocol.ora):
tcp.validnode_checking = YES tcp.excluded_nodes = {list of IP addresses} - список запрещенных IP-адресов tcp.invited_nodes = {list of IP addresses} - список разрешенных IP-адресов
Настроить шифрование TNS-трафика. Использовать создание защищенного канала при установке соединения, например, алгоритм Диффи-Хеллмана.
В ОС Unix настроить список IP-адресов, с которых возможно подключение к серверу:
файлы hosts.allow, hosts.deny
Обеспечить подключение к серверу только по SSH.
Максимально ограничить доступ потенциального злоумышленника к хешам паролей.
Настроить права на файл паролей pwSID.ora и файл system.dbf так, чтобы исключить доступ всех пользователей, кроме владельца софта (обычно это учетная запись oracle в ОС). Т.е. члены группы dba не смогут просмотреть этот файл.
Настройка аудита в ОС.
В системах с повышенными требованиями к безопасности следует обратить внимание на привилегии пользователей, которые имеют доступ к БД через Интернет и не использовать привилегированных пользователей для web-приложений.
Не забывать про важность организационных мер (ограничение круга лиц, которые имеют доступ к серверу и ОС, к root, к бэкапам, подписка о неразглашении, меры наказания), которые являются не менее серьезным барьером, чем парольная защита.
Силовая атака
Если аналитическим путем найти уязвимую точку не удастся, то всегда существует метод, называемый силовая атака.
Так, можно, игнорировав значение H, непосредственно приступить к вычислениям X=DES-1(K',K), взяв генератор случайных чисел в качестве источника K'(расшифровываем некоторое случайное значение K' на ключе K, затем сравниваем результат с Х). Эта атака позволяет сэкономить на операции Х = DES-1 (H, K') и таким образом ускорить процесс.
По данным [], программные реализации силовой атаки дают на сегодняшний день скорость 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 паролей в секунду (наилучший результат). При этом, время, необходимое для полного перебора паролей распределяется так:
5-символьные пароли - 10 секунд
6-символьные пароли - 5 минут
7-символьные пароли - 2 часа
8-символьные пароли - 2,1 дня
9-символьные пароли - 57 дней
10-символьные пароли - 4 года
Еще более интересна разработка аппаратного устройства для подбора паролей Oracle. Поскольку базы данных концентрируют в одном месте множество информации, то затраты на разработку специализированных аппаратных средств могут оказаться экономически оправданными.
Еще в 1998 г. была запущена в эксплуатацию специализированная ЭВМ для подбора ключей DES, развивающая производительность до 92 миллиардов ключей в секунду. Она способна найти подходящий ключ DES за несколько десятков часов. Стоимость такого устройства около 250 тыс. долларов. Более подробную информацию можно получить по адресу.
В данном аспекте следует подчеркнуть, что значение 92 миллиарда относится именно к перебору ключей DES, а не к подбору паролей Oracle. Расшифровка хеша Oracle будет происходить немного медленнее, поскольку требует большего числа операций, но, тем не менее, это значение позволяет оценить потенциальную мощность аппаратных средств.
Средство СУБД Oracle по управления паролями в БД
Управление устареванием паролей в СУБД Oracle реализуется через использование profile с помощью операторов create profile и alter profile. Они обеспечивают возможность проверки качества (сложность) пароля и настройку политики устаревания паролей. Администраторы могут использовать для этой цели profile пользователя в БД и встроить в него свою функцию проверки качества пароля, чтобы заставить пользователей принимать более сильные пароли.
Приемлемая длина пароля зависит от количества вычислительных ресурсов, доступных злоумышленнику и длительности его сеанса связи. Предполагая, что злоумышленник обладает современным аппаратным взломщиком DES, организации требуется не менее 12 знаков пароля, чтобы обеспечить срок его устаревания в 60 дней при проведении злоумышленником силовой атаки. В излагается математический аппарат, позволяющий оценить вероятность взлома Вашей парольной защиты.
Процедура проверки качества пароля - это функция на PL/SQL в схеме SYS, принимающая на входе логин пользователя, старый пароль и новый пароль, и возвращающая TRUE, в зависимости от качества выбранного пользователем пароля. Простейший пример такой функции
SQL> CONNECT / AS SYSDBA; Connected.
SQL> CREATE OR REPLACE FUNCTION sys.password_verify 2 (username varchar2, password varchar2, old_password varchar2) 3 RETURN boolean IS 4 BEGIN 5 IF length(password) < 12 THEN 6 raise_application_error(-20000, 'Password less than 12 characters'); 7 END IF; 8 RETURN(TRUE); 9 END; 10 /
Эта функция выдает ошибку, если длина нового пароля менее 12 знаков. Эта функция не выполняет никаких других проверок пароля. Реальная функция проверки пароля должна быть, конечно, гораздо сложнее.
После создания такой функции ее необходимо ассоциировать с профилем. По умолчанию, в СУБД Oracle всегда существует профиль DEFAULT. С ним и будем ассоциировать:
SQL> ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION password_verify;
SQL> connect scott/tiger Connected. SQL> ALTER USER scott IDENTIFIED BY "scott" REPLACE "tiger"; ALTER USER scott IDENTIFIED BY " scott " REPLACE "tiger" * ERROR at line 1: ORA-28003: password verification for the specified password failed ORA-20000: Password less than 12 characters SQL> ALTER USER scott IDENTIFIED BY "abcdefghijkl" REPLACE "tiger"; User altered.
Всем пользователям присваивается профиль с ограниченным сроком действия пароля. Если пароль не меняется, то дается ограниченный период, в течение которого будут выдаваться предупредительные сообщения. Если пароль не меняется в течение дополнительного периода, то логин будет заблокирован. Разблокировать пароль сможет только член группы ДБА командой alter user account unlock;
Это средство также полезно, когда нужно заставить всех пользователей поменять их пароли.
Управление историей хранения паролей реализуется с помощью параметров password_reuse_max и password_reuse_time. Эти параметры не позволяют пользователю завести для себя два пароля и менять их поочередно. Бывают пользователи, которые, только что сменив пароль на какой-нибудь новый, тут же повторно меняют его на старый. Эти параметры запрещают пользователю вернуться к одному из старых паролей, пока не пройдет определенный период времени. Один из параметров определяет, сколько дней должно пройти прежде, чем пароль можно будет использовать повторно, а другой определяет сколько раз нужно сменить пароль, прежде, чем его можно будет использовать повторно. СУБД запоминает все введенные пароли (точнее, их хеши) и сравнивает их.
С точки зрения СУБД Oracle это взаимоисключающие параметры, т.е. когда одному присваивается какое-либо числовое значение, то второй должен принимать значение UNLIMITED. Оба параметра не могут принимать числовые значения, но могут принимать значения UNLIMITED. Установка обоих параметров в UNLIMITED разрешает немедленное повторное использование паролей.
Один из способов управления паролями заключается в редактировании и выполнении скрипта, предназначенного для настройки политики парольной защиты - $ORACLE_HOME/rdbms/utlpwdmg.sql. Этот скрипт имеет ряд предварительно установленных параметров, поэтому в большинстве случаев администратор может просто выполнить его.
Скрипт utlpwdmg.sql присваивает параметру password_reuse_time=1800, а password_reuse_max=UNLIMITED. Методологически целесообразнее присваивать значение параметру password_reuse_time, а не password_reuse_max, потому что настойчивый пользователь может обойти ограничение password_reuse_max, поменяв пароль password_reuse_max+1 раз.
История паролей хранится в таблице sys.user_history$.
SYS @ orcl >select * from user_history$;
USER# PASSWORD PASSWORD_DATE ---------- ------------------------------ --------- 79 8006C2C56E61DB9D 24-APR-06 66 8F4F9102D7864F47 23-MAY-06 66 87A9B0BB9A8B9FCD 06-JUN-06 5 8D2FA9B19EBC52C4 06-JUN-06 66 992FD456594C1A6E 06-JUN-06 66 11F1EC5B54F7D35B 06-JUN-06 66 BD8F1C27CA78D7D1 06-JUN-06
При создании БД автоматически создается профиль DEFAULT. Он содержит в числе прочих настроек еще и политику устаревания паролей.
Вот параметры до изменения
| DEFAULT | FAILED_LOGIN_ATTEMPTS | PASSWORD | 10 |
| DEFAULT | PASSWORD_LIFE_TIME | PASSWORD | UNLIMITED |
| DEFAULT | PASSWORD_REUSE_TIME | PASSWORD | UNLIMITED |
| DEFAULT | PASSWORD_REUSE_MAX | PASSWORD | UNLIMITED |
| DEFAULT | PASSWORD_LOCK_TIME | PASSWORD | UNLIMITED |
| DEFAULT | PASSWORD_GRACE_TIME | PASSWORD | UNLIMITED |
| DEFAULT | PASSWORD_VERIFY_FUNCTION | PASSWORD | NULL |
| FAILED_LOGIN_ATTEMPTS | Допустимое количество неуспешных попыток регистрации до блокировки учетной записи |
| PASSWORD_LIFE_TIME | Время жизни пароля |
| PASSWORD_REUSE_TIME | Число дней, в течение которых пароль нельзя использовать повторно. |
| PASSWORD_REUSE_MAX | Необходимое число изменений пароля, прежде чем им можно будет воспользоваться повторно. |
| PASSWORD_VERIFY_FUNCTION | Скрипт проверки стойкости пароля. Допускается создавать собственные функции проверки пароля. |
| PASSWORD_LOCK_TIME | Длительность блокировки в днях. Сколько времени будет заблокирована учетная запись после блокировки |
| PASSWORD_GRACE_TIME | Продолжительность дополнительного периода в днях. В течение этого времени разрешается подключение к БД, но выводится предупреждение о смене пароля. |
| DEFAULT | FAILED_LOGIN_ATTEMPTS | PASSWORD | 3 |
| DEFAULT | PASSWORD_LIFE_TIME | PASSWORD | 60 |
| DEFAULT | PASSWORD_REUSE_TIME | PASSWORD | 1800 |
| DEFAULT | PASSWORD_REUSE_MAX | PASSWORD | UNLIMITED |
| DEFAULT | PASSWORD_LOCK_TIME | PASSWORD | .0006 |
| DEFAULT | PASSWORD_GRACE_TIME | PASSWORD | 10 |
| DEFAULT | PASSWORD_VERIFY_FUNCTION | PASSWORD | VERIFY_FUNCTION |
После применения скрипта utlpwdmg. sql поведение базы данных изменится. При вводе нового/изменении старого пароля СУБД будет выполнять следующие проверки:
Проверка, что пароль такой же, как логин Проверка, что пароль длиннее 4-х знаков Проверка, что пароль не 'welcome', 'database', 'account', 'user', 'password', 'oracle', 'computer', 'abcd' Проверка того, что пароль содержит не менее 1 буквы & 1 цифру & один знак пунктуации. Проверка, что пароль отличается от предыдущего пароля не менее чем в 3-х знаках в соответствующих позициях.
Администратор может самостоятельно изменить параметры профиля примерно так:
SQL >ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION null; Profile altered.
Полный синтаксис этой команды:
ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LIFE_TIME 60 PASSWORD_REUSE_TIME 1800 PASSWORD_REUSE_MAX UNLIMITED PASSWORD_LOCK_TIME 1/1440 PASSWORD_GRACE_TIME 10 PASSWORD_VERIFY_FUNCTION verify_function;
Руководствуясь параметром failed_login_attempts, сервер автоматически блокирует учетную запись после заданного числа неуспешных попыток регистрации в системе.
Поскольку эта особенность может быть использована злоумышленником для блокировки работающих учетных записей, то средства блокировки можно настроить так, чтобы учетная запись разблокировалась автоматически через время password_lock_time (в днях). Если password_lock_time устанавливается в UNLIMITED, то автоматической разблокировки не происходит. Разблокировать учетную запись может только член группы ДБА.
Параметр password_lock_time=0.0006 указывается в сутках, величина 1/1440 означает задержку в 51,84 секунды.
Если попытки подключения прекратились, не достигнув значения failed_login_attempts, то по истечении времени password_lock_time счетчик блокировки будет сброшен в 0.
Для отмены политики управления паролями можно несколько раз выполнить команду Alter profile default limit, установив изменяемый параметр в unlimited, чтобы сбросить настроенные параметры к их значению по умолчанию:
alter profile default limit FAILED_LOGIN_ATTEMPTS unlimited PASSWORD_LIFE_TIME unlimited PASSWORD_REUSE_TIME unlimited PASSWORD_REUSE_MAX unlimited PASSWORD_LOCK_TIME unlimited PASSWORD_GRACE_TIME unlimited PASSWORD_VERIFY_FUNCTION null;
Table1.shtml
| checkpwd 1.1 | Red-Database-Security | Windows, Linux | Dictionary | 150.000 | Free | can connect to the database and check multiple accounts in one step | no BF mode | |
| orabf 0.7.4 (new) | 0rm | Windows | Brute Force, Dictionary | 1.100.000 (BF) 330.000 (Dictionary) | Free | fastest tool for BF and BF | no database connection | |
| John the Ripper | Windows, Unix | Dictionary | N/A | Free | source available, generic password cracker, many platforms | no database connection | ||
| Bob the Butcher | Bartavelle | coming soon | Brute Force | N/A | Free | N/A | N/A | |
| AppDetective** | AppSecInc | Windows | Dictionary Brute Force | 5000 | Commercial | can connect to the database, BF and dictionary mode, check roles and default/easy to guess passwords | ||
| NGSSquirrel | NGS Software | Windows | Dictionary | 138.979 | Commercial | can connect to the database, BF and dictionary mode + smart dictionary mode (0 replaces o, 1 replaces i, ...) | ||
| bfora | dab | Perl | Dictionary, Brute Force | N/A | Free | connect to the database platform independent | slow, no BF mode | |
| Hashattack 0.2.0 | Josh Wright | PL/SQL | Dictionary | < 500 | Free | platform independent | slow, no BF mode | |
| Oracle PW Cracker 1.6 | Adam Martin | PL/SQL / Oracle Forms | Dictionary | < 500 | Free / Share (4$) | platform independent | slow, no BF mode | |
| Oracle PW Cracker | Bear Dang | PLSQL | Brute Force | < 500 | Free | platform independent | slow | |
| Cain & Abel | Massimiliano Montoro | Windows | Brute Force | N/A | Free | collection of many security tools | fast |
Сводная таблица скорости программных взломщиков (оригинал)
Варианты усовершенствования парольной защиты сервера Oracle
- От DES следует отказаться в силу малой длины ключа и малой длины блока. Малая длина ключа означает успешность силовой атаки за небольшое время, а малая длина блока означает повышенный уровень коллизий.
Если у разработчиков Oracle есть приверженность к алгоритмам шифрования, то можно взять новый, более совершенный алгоритм AES, пришедший в 2000 г. на смену DES'у. Этот алгоритм допускает вариацию длины блока (128, 192, 256 бит), длины ключа 128, 192, 256 бит и количества раундов (чем больше раундов, тем выше качество шифрования и меньше скорость). Алгоритм AES сертифицирован национальным институтом США по стандартизации NIST и АНБ (Агентство Национальной Безопасности США).
Либо можно выбрать сертифицированную криптографически стойкую хеш-функцию, которых к сегодняшнему дню разработано несколько десятков. В России таким стандартом является ГОСТ Р 34.11, в Европе - RIPEMD, в США - SHA, MD5. Они протестированы компетентными организациями (органами) и приняты в качестве государственных стандартов. Для предотвращения коллизий и сведения к минимуму эффекта от парадокса дней рождений современную длину блока можно установить в 256 бит. По современным оценкам этой длины хватит на сотню-другую лет, при сохранении современных темпов развитии вычислительной техники.
- Конкатенацию логина и пароля следует заменить другим преобразованием, например сложением. Дело в том, что конкатенация приводит к неожиданному эффекту:
SYS @ orcl >create user "o" identified by racle; SYS @ orcl >create user "or" identified by acle; SYS @ orcl >create user "ora" identified by cle; SYS @ orcl >create user "orac" identified by le; SYS @ orcl >create user "oracl" identified by e;
SYS @ orcl >select username,password from dba_users where username like 'o%' order by username; USERNAME PASSWORD ------------------------------ ------------------------------ o 8C05BDE49B713CC9 or 8C05BDE49B713CC9 ora 8C05BDE49B713CC9 orac 8C05BDE49B713CC9 oracl 8C05BDE49B713CC9
Этот пример показывает два факта:
Неожиданный способ порождения коллизий. Т.е. если в базе данных заведен пользователь "ora" с паролем "cle", то в процессе силовой атаки мы можем наткнуться на логин "o" с паролем "racle", в результате чего угадать реальную пару логинпароль будет совсем несложно, потому что для каждого пароля случайной добавкой (солью) является часть его логина. Таким образом, в целях минимизации числа коллизий следует от конкатенации отказаться. Зная имена стандартных пользователей sys, system, outln и т.д., противник имеет возможность заблаговременно сгенерировать словарь. Если не весь словарь целиком, то хотя бы из наиболее часто употребительных паролей. В этом случае задача расшифровывания сводится к задаче поиска в массиве заранее вычисленных значений. А в случае, например, побитового сложения логина и пароля, знание имен стандартных пользователей пользы противнику не принесет.
Есть еще одни вариант - по аналогии с ОС - использовать действительно случайное значения "соли". Однако, тогда эту соль пришлось бы где-то в базе данных хранить, а в данной конструкции разработчики Oracle проблему хранения соли элегантно обошли.
- «Двухэтажную» конструкцию Oracle полезно превратить в «трехэтажную», по аналогии со стандартом ANSI X9.17. Такая конструкция существенно усложнит для криптоаналитика атаку с накоплением, основанную на парадоксе дней рождений, а также атаку с анализом промежуточных ключей.
Кроме того, «трехэтажная» конструкция замедлит скорость вычисления хеша, что замедлит скорость силовой атаки, и тем самым повысит стойкость криптосистемы. Это стандартное требование к хеш-функциям, гласящее, что «хеш-функция должна вычисляться медленно». Если хеш-функция вычисляется быстро, то хакер тоже ее вычислит быстро, и быстро осуществит перебор паролей. Медленный однонаправленный алгоритм не сильно замедлит одноразовое вычисление пароля, при подключении к БД, но существенно затруднит противнику перебор всевозможных паролей. Наиболее популярное решение - это многократное итеративное использование хеш-функций. Например, в Unix-системах однонаправленная функция шифрования применяется итеративно несколько раз, чтобы обеспечить достаточно большое время отклика.
- Не игнорировать различие между заглавными и строчными символами. В этом пункте нет вообще никаких принципиальных сложностей.
В настоящий момент количество возможных паролей есть
Расширение множества допустимых паролей позволит скомпенсировать на десяток-другой лет возможные успехи в вычислительной технике и криптоанализе.
- После вышеописанных изменений криптосхему корпорации Oracle следует подвергнуть сертификации. Это повысит доверие к ПО Oracle. Для такого популярного продукта как СУБД Oracle официальное признание и подтверждение его надежности со стороны компетентных организаций является важным моментом, как при его эксплуатации, так и при продвижении на рынке. В худшем случае, слабое звено будет выявлено, и заменено более стойким.
- В качестве варианта по построению защищенной СУБД, интересно было бы генерировать уникальное значение ключа для каждой инсталляции СУБД. Дело в том, что для некоторых ИС с повышенными требованиями к безопасности очень желательно иметь возможность скомпилировать своего собственного клиента с зашитым в нем уникальным ключом, т.е. клиента, способного подключаться только к своей «родной» БД, оснащенной таким же ключом. Понятно, что обычный клиент со стандартным ключом никогда не подключится к такой БД. Не смотря на все возникающие сложности, предлагаемая конструкция дает сильную гарантию безопасности информации в БД.
Внедрение скрытого пользователя
SQL> Create user hacker identified by hacker; SQL> Grant DBA to hacker;
SQL> Select username from dba_users; SYS SYSTEM DBSNMP SYSMAN MGMT_VIEW HACKER
Затем добавляем в представление DBA_USERS (например, с помощью TOAD) одну строку "and u.name!='HACKER'", как показано на рисунке.
В результате в БД имеется скрытый пользователь, не обнаруживаемый обычными запросами.
Подводя итог, следует сказать, что
Подводя итог, следует сказать, что реальной уязвимости на сегодняшний день противники СУБД Oracle не продемонстрировали. Каких-либо уязвимостей в криптографической конструкции не предъявлено. Новых теоретических результатов по вопросу получения несанкционированного доступа к СУБД Oracle тоже нет. Результаты по подбору паролей в [,] получены за счет эффективного применения вычислительных средств и осуществляют банальную силовую атаку на хеш. При отсутствии специализированного ПО либо специализированных аппаратных средств, осуществить такую атаку за разумное время невозможно, точнее вероятность успеха ничтожно мала, а время атаки космически велико.
Это подтверждается самими авторами [], которые не нашли уязвимость в криптосхеме или ее реализации, а всего лишь продемонстрировали очередной вариант силовой. Надо отдать им должное, они честно признают этот факт: «…нельзя сразу указать криптографическую слабость конструкции хеш-функции в СУБД Oracle …» Фактически они подтвердили, что единственный способ на сегодняшний день узнать пароль - это силовая атака (полный перебор).
Стойкость парольной защиты Oracle также подтверждается и известным сайтом, посвященном уязвимостям в СУБД Oracle: «It is not possible to decrypt a hashstring … »
Тем не менее, стоит подчеркнуть, что в системах с повышенными требованиями к безопасности для обеспечения надежной аутентификации следует использовать более сильные средства, чем стандартная парольная защита СУБД Oracle. Интересный вариант - настроить внешнюю аутентификацию и тем самым перенести проблему из СУБД в другое место.
Пользователям можно порекомендовать выбирать пароли, состоящие из нестандартных символов, заключая их в двойные кавычки.
Сравнивая парольные защиты в Oracle и ОС Unix, следует отметить, что ОС защищены слабее. Я имею в виду то, что в основных промышленных ОС - Solaris 8,9, HPUX 10,11, AIX 4,5- в качестве пароля используются только первые 8 знаков. Вы можете произвести эксперимент, и окажется, что, например, для пользователя root, пароли rootroot, rootroot1, rootroot2 и т.д. являются с точки зрения ОС одинаковыми, т.е. одинаково проходными! Так что, если Вы набираете 10 знаков при подключении к серверу, то фактически Вы набираете только первые 8. Спрашивается, имеет ли смысл защищать СУБД, если защита самого сервера слабее? В ОС Линукс и Solaris 10 ситуация с паролями намного лучше.
