ВСКРЫТИЕ ПАРОЛЕЙ В СУБД ORACLE

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

Злоумышленник может попробовать получить доступ к хэшам паролей пользователей, которые обладают ролью DBA, и попытаться их расшифровать. Рассмотрим ситуации, в которых мы можем получить эти заветные хэши [1, c. 187]:

• Один из самых распространенных вариантов – удаленное получение доступа к консоли СУБД под учетной записью, у которой по умолчанию есть доступ на чтение таблицы с хэшами паролей (права SELECT ANY DICTIONARY или SELECT ANY TABLE), но нет роли DBA, к примеру, это может быть учетная запись пользователя DBSNMP. Расшифровав пароль, мы получим доступ к базе данных с правами DBA, а также, что немаловажно, сможем попытаться использовать подобранный пароль для доступа к другим сервисам или к ОС.
• Доступ к хэшам паролей также можно получить, найдя уязвимость класса PL/SQL Injection в функции или процедуре, которая исполняется от имени пользователя с правами SELECT ANY DICTIONARY, позволяющими читать системные таблицы.
• Еще один возможный вариант – получение доступа к базе данных через SQL инъекцию в веб-приложении, которое работает с СУБД. В этом случае есть вероятность, что пользователь, от имени учетной записи которого совершаются запросы к СУБД, имеет доступ на чтение системной таблицы с хэшами паролей.

1. Хранение паролей

Начнем с главного – где и как хранятся пароли пользователей в СУБД Oracle. Все описанное ниже касается СУБД Oracle версии ниже 11g – в ней был реализован новый механизм хранения паролей.

Пароли хранятся в базе данных в зашифрованном виде в системной таблице SYS.USER$. В этой таблице хранится такая информация об учетных записях, как имя пользователя, зашифрованный пароль, время создания пользователя, и другие данные. Чтобы получить удобочитаемые данные о зашифрованных паролях, можно воспользоваться представлением dba_users, которое позволяет получать доступ к аутентификационным данным в понятном виде. Таблица dba_users является представлением (view) системной таблицы SYS.USER$.

Рисунок 1. Выборка паролей из таблицы dba_users

Как видно из рисунка, хэш пароля состоит из 8 байт и составлен по определен ному алгоритму, который мы сейчас изучим.

2. Подбор паролей

2.1 Подбор паролей с использованием словаря

Подбор паролей обычно начинается с проверки на словарные слова (часто используемые - qwerty, 123456). Велика вероятность того, что пользователи используют словарные пароли. Для перебора паролей к СУБД Oracle по словарю создано множество утилит, ссылки на большую их часть представлены на сайте http://www.red-database-security.com/.

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

Часто, в качестве пароля используется словарное слово с добавлением в конце одного-двух символов. Тогда затраты времени увеличатся в 39*39 раз для перебора всех вариантов, то есть весь перебор займет около 4 часов, что тоже приемлемо.

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

2.2 Подбор пароля методом грубого перебора (bruteforce)

Рассмотрим подбор методом грубого перебора. В общем случае он занимает огромное количество времени, но если проанализировать алгоритм шифрования пароля, а также накладываемые правила на пользовательский пароль ( минимальная длина, допустимые символы, допустимый регистр и т.д.), то можно существенно сократить время перебора.

Для вскрытия паролей методом полного перебора также существует множество утилит. Часть из них представлены на сайте http://www.red-database-security.com/. Ниже приведена сравнительная таблица скорости подбора паролей для различных утилит взятая с упомянутого выше сайта 

Рисунок 3. Сравнение скорости работы утилит, осуществляющих подбор паролей методом полного перебора

2.3 Перебор с использованием Rainbow Tables

При генерации хэша пароля в СУБД Oracle используется дополнительный параметр – соль (англ. salt), которая в теории создана для того, чтобы предотвратить атаку посредством создания заранее сгенерированных таблиц для быстрого перебора паролей “Rainbow Tables” (специальный вариант таблиц поиска, использующий механизм уменьшения времени поиска за счет увеличения занимаемой памяти, или time-memory, tradeoff. Радужные таблицы используются для вскрытия паролей, преобразованных при помощи необратимой хэш-функции). Но, учитывая то, что соль в СУБД Oracle версии ниже 11g нам известна заранее, так как она представляет собой имя пользователя (исключения составляют случаи, когда нам известен только хэш, но на практике это бывает довольно редко), мы можем сгенерировать Rainbow Tables для распространенных имен пользователей, чтобы потом подбирать пароли в разы быстрее.

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

3. Вывод

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

Список литературы:

1. Поляков А.М. Безопасность Oracle глазами аудитора: нападение и защита, 2010 - С. 187-195
2. Joshua Wright. An Assessment of the Oracle Password Hashing Algorithm, 2005 - P. 2-6
3. Benchmark Oracle Password Cracker // Red Database Security. URL: http://www.red-database-security.com/whitepaper/oracle_password_benchmark.html (дата обращения 01.06.2018)