|
|
|
Ваши замечания и предложения отправляйте редактору По техническим вопросам обращайтесь к вебмастеру Дата публикации: 10.11.02 | |
| СТАТЬЯ |
10.11.02
|
© Пит Финнеган (Pete
Finnigan)
Статья была опубликована в журнале
Oracle Magazine RE
Часть 2. Оглавление
Инъекция 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 7 и более ранних версиях тела пакетов поставлялись с РСУБД в исходном коде. Также можно читать “свернутые” пакеты и видеть в них некоторые части SQL, используемого в пакетах. Мы искали в пакетах SQL-код, часть которого задается параметрами, затем вызывали функцию или процедуру, в которую передавали дополнительный SQL. Мы пытались, кроме всего прочего, обнаружить функцию или процедуру, которая изменяет пароль пользователя SYS. Это удалось в одном случае, но только при соединении как DBA. При попытках из других учетных записей возникала ошибка ORA-1031. Так что следите за информацией, может быть, это препятствие будет устранено.
Выполнение произвольного SQL в данном случае, возможно, не имеет смысла – если мы можем выполнять встроенные пакеты, то мы, естественно, имеем привилегии для выполнения произвольного SQL. Ключевой момент инъекции SQL – эскалация привилегий или выполнение SQL, выполнение которого запрещено.
Использование инъекции 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. Некоторые хорошие примеры:
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$
|
Name
|
Null?
|
Type
|
| USER# | NOT NULL | NUMBER |
| NAME | NOT NULL | |
| TYPE# | NOT NULL | NUMBER |
| PASSWORD | ||
| DATATS# | NOT NULL | NUMBER |
| TEMPTS# | NOT NULL | NUMBER |
| CTIME | NOT NULL | DATE |
| PTIME | DATE |
|
| EXPTIME | DATE |
|
| LTIME | DATE |
|
| RESOURCE$ | NOT NULL | NUMBER |
| AUDIT$ | VARCHAR2(38) |
|
| DEFROLENOT | NULL | NUMBER |
| DEFGRP# | NUMBER |
|
| DEFGRP_SEQ# | NUMBER |
|
| ASTATUS | NOT NULL | NUMBER |
| LCOUNT | NOT NULL | NUMBER |
| DEFSCHCLASS | VARCHAR2(30) | |
| EXT_USERNAME | NVARCHAR2(4000) |
|
| SPARE1 | NUMBER |
|
| SPARE2 | NUMBER |
|
| SPARE3 | NUMBER |
|
| SPARE4 | VARCHAR2(1000) |
|
| SPARE5 | VARCHAR2(1000) |
|
| SPARE6 | DATE |
недокументированные параметры инициализации – параметры инициализации Oracle (параметры файла INIT.ORA), имена которых начинаются со знака подчеркивания, являются неподдерживаемыми параметрами. Полный список этих параметров можно получить из x$-таблиц. Эти таблицы будут рассмотрены ниже. Oracle не рекомендует устанавливать эти параметры без специального разрешения корпорации. Пример запроса списка всех скрытых параметров:
select *
from sys.x$ksppi
where substr(ksppinm,1,1)='_';
(Прим. пер.: интересна динамика увеличения количества параметров инициализации в разных версиях Oracle:
|
Версия
|
Документированных
|
Недокументированных
|
Всего
|
|
6
|
111
|
19
|
130
|
|
7
|
117
|
68
|
185
|
|
8
|
193
|
119
|
312
|
|
8i
|
203
|
301
|
504
|
|
9i
|
251
|
436
|
687
|
)
Некоторые из интересных параметров – это те, которые позволяют открывать базу данных, даже если она испорчена. Они могут быть использованы для открытия базы данных, созданной из неполных резервных копий, чтобы попытаться извлечь из нее данные. Такой параметр называется _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.
Дополнительная информация
За дополнительной информацией обращайтесь в компанию Interface Ltd.
| INTERFACE Ltd. |
| ||||