Как взломать или обойти парольную защиту Oracle

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

Основным принятым средством аутентификации (проверки подлинности) пользователя Oracle и включаемой/выключаемой роли является указание пароля. Так, пароль указывается при выполнении соединения с СУБД (например, в SQL*Plus в команде CONNECT), в предложении SQL создании пользователя или в полном определении связи с посторонней БД (database link).

Хранение пароля

Заданный для пользователя Oracle командой CREATE/ALTER USER пароль подвергается преобразованию и попадает в словарь-справочник в виде свертки (password hash). При указании пароля в момент установления соединения с СУБД Oracle заново вычислит свертку и сравнит ее с хранимой в БД. В открытом виде пароли в БД не хранятся.

Основное место хранения свертки пароля - таблица словаря-справочника SYS.USER$. Над этой таблицей как базовой построена производная, SYS.DBA_USERS. Если в профиле (profile) пользователя включен параметр PASSWORD_REUSE_TIME, свертки пароля также хранятся в SYS.USER_HISTORY$.

Увидеть свертки логически можно, выдав например:

SQL> CONNECT / AS SYSDBA

Connected.

SQL> SELECT username, password FROM dba_users;

USERNAME PASSWORD

------------------------------ ----------------------------------------------------

MGMT_VIEW 34D8B04B40368661

SYS 8A8F025737A9097A

SYSTEM 2D594E86F93B17A1

DBSNMP FFF45BB2C0C327EC

SYSMAN 2CA614501F09FCCC

XDB FD6C945857807E3C

SCOTT F894844C34402B67

ADAM DC8670031DD24E45

PROF 3D2DEE6D12BD13D2

FORD 0805304F10B59B54

XTEST 5E3A5B0B1B1B4755

STREAMADMIN 77079477FD902BB1

OUTLN 4A3BA55E08595C81

EXFSYS 66F4EF5650C20355

WMSYS 7C9BA362F8314299

DIP CE4A36B8E06CA59C

TSMSYS 3DF26A8B17D0F29F

ANONYMOUS anonymous

18 rows selected.
Последняя строка в приведенной выдаче является иллюстрацией применения недокументированной, но широко известной возможности Oracle занести в БД на место свертки в БД непосредственное значение:

SQL> ALTER USER scott IDENTIFIED BY VALUES 'Это не свертка никакого пароля';

User altered.

SQL> SELECT username, password FROM dba_users WHERE username = 'SCOTT';

USERNAME PASSWORD

------------------------------ ------------------------------

SCOTT Это не свертка никакого пароля
Фактически это обесценивает привилегию CREATE SESSION, если таковая имеется (соединение все равно невозможно). Возможность занести в БД непосредственно свертку позволяет обладателю привилегии ALTER USER подменить на время пароль, чтобы за законных основаниях войти в систему под чужим именем. Однако если это пользователь SYS, замененный таким образом ему «пароль» не фиксируется в файле PWD .ORA , так что особой проблемы с доступностью это свойство не создает.

Если параметр СУБД O7_DICTIONARY_ACCESSIBILITY имеет значение TRUE (умолчание в версии 8), к трем указанным таблицам может обратиться любой обладатель системной привилегии SELECT ANY DICTIONARY; в противном случае - только владелец SYS.

Физически свертки можно наблюдать в файлах ОС: «парольном» PWD .ORA ; табличного пространства SYSTEM, где хранятся SYS.USER$ и SYS.USER_HISTORY$ (часто это SYSTEM 01.DBF ); полного экспорта; архивированных журналов.