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

Источник: Oracle Magazine RE
Пит Финнеган (Pete Finnigan)

Оглавление

Способы доступа

Существуют различные способы доступа к базам данных Oracle. Приведем некоторые из них:

· инструментальные средства сервера Oracle, такие, как sqlplus и svrmgrl ;
· Oracle Enterprise Manager;
· написанные пользователями программы на языках, поддерживаемых Oracle, включая:
                          · OCI;
                          · ODBC;
· JDBC;
· SQL*Net или NET 8.

В данном документе основной акцент делается на инсталляции Oracle под управлением ОС Unix, однако все рассматриваемые технические приемы и решения легко применимы и в других операционных системах.

Исследование Oracle

Oracle доброжелательно и безвозмездно предоставляет всем желающим пробные инсталляционные CD-диски с программным обеспечением СУРБД и новейшими инструментальными средствами разработки и приложениями. Доступны версии от Oracle 7.1 до Oracle 8i и 9i. В последнее время Oracle предлагает полные комплекты CD-дисков для всех операционных систем по очень низкой цене. Операционная система Solaris для Sparc и Intel поставляется с инсталлированным программным обеспечением Oracle. Издательство www.osborne.com совместно с книгой "Oracle8i for Linux Starter Kit" поставляет официальную версию Oracle 8i для Linux или Windows NT (в анонсе издательства о версии для Windows ничего не говорится, но это не существенно. - Прим. пер.).

Инсталляция Oracle под Linux или Windows очень полезна для получения представления о программном обеспечении и его использовании. Oracle регулярно изменяет функциональные характеристики программного обеспечения на нижних уровнях. Посмотрите на изменение от версии к версии структуры, объемов и количества X$-таблиц, в которых хранится вся служебная информация.

(Прим. пер.:)

Версия Oracle 

Количество X$-таблиц 

6

? (35)

7

126

8

200

8i

271

9i

352

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

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

Выяснение, какие базы данных инсталлированы и функционируют

Вы имеете доступ к Unix и намерены взломать базу данных Oracle. Как узнать, где инсталлировано программное обеспечение базы данных и как к нему обращаться? Базы данных Oracle могут быть распределенными, параллельными со многими экземплярами или автономными.

Во время инсталляции Oracle создается файл oratab, который содержит подробные данные о базах данных, инсталлированных на машине. Он может использоваться для запуска и остановки баз данных во время перезагрузки, а также для управления резервным копированием. Место нахождения этого файла не фиксировано, он может находиться в /etc или в /var/opt/oracle. Проще всего его можно найти следующей командой:

sputnik:pxf> find / -name oratab -print 2>/dev/null / more

/etc/oratab

Однако использование команды find не есть очень хорошая идея, если вы пытаетесь избежать обнаружения. Хорошо начать с просмотра /etc, /var/opt и /opt, а также их поддиректорий.

Файл oratab должен быть доступен для чтения, если только dba или администратор Unix не изменил права доступа к нему:

sputnik:pxf> ls -al oratab
-rw-rw-r-- 1 oracle root 676 Jul 16 14:47 oratab

Этот файл позволяет узнать список всех ORACLE_SID и ORACLE_HOME. Если используется соглашение об именовании OFA, то версия Oracle может быть "раскручена" по путям доступа к директориям. Важная часть здесь - ORACLE_SID, поскольку он может использоваться для определения, работает ли база данных.

Файлы конфигурирования SQL* NET и NET 8, как на сервере, так и на клиенте, могут использоваться для определения информации о базах данных, работающих как на сервере, так и во всей организации. Файлы конфигурирования SQL* NET и NET 8 будут рассмотрены ниже в разделе "Конфигурационные файлы SQL*NET и NET 8".

Проверка переменных окружения пользователя базы данных может также дать некоторую информацию. В системах Unix / Linux должен быть, по крайней мере, следующий набор переменных окружения:

  • ORACLE_HOME - место нахождения программного обеспечения Oracle.
  • ORACLE_SID - имя базы данных, доступ к которой вы хотите получить.
  • PATH - это стандартный путь доступа, но он должен включать в себя путь доступа к двоичным (binary) программам Oracle.
  • LD_LIBRARY_PATH - путь доступа к разделяемым библиотекам, и он должен включать в себя путь доступа к разделяемым библиотекам Oracle.

Еще один способ поиска доступных баз данных - с помощью команды Unix ps посмотреть, что работает на сервере. Здесь можно смотреть либо на реальные экземпляры баз данных, либо на процессы, работающие с этими экземплярами (пользователи легкомысленны и в командной строке соединения часто используют имя пользователя и пароль).

Пример определения, какие экземпляры базы данных работают:

sputnik:pxf> ps -ef / grep lgwr / grep -v grep / more
sputnik:pxf> oracle 654 1 0 10:37 ? 00:00:00 ora_lgwr_PENT

Здесь показано, что работает один экземпляр Oracle и SID базы данных - PENT. Поиск "lgwr" означает поиск идентификатора, используемого для обозначения фонового процесса Log Writer (процесс записи журнальных файлов). В СУРБД Oracle имеется несколько фоновых процессов, постоянной работающих и управляющих базой данных. Этот процесс один из них. Могут также работать и несколько дополнительных процессов. Все эти процессы используют для взаимодействия область разделяемой памяти, называемую SGA (Shared Global Area - разделяемая глобальная область).

Поиск информации в пользовательском окружении

Полезным упражнением для взламывания баз данных Oracle является проверка пользовательского окружения: не создали ли пользователи переменные окружения с именами пользователей и паролями в них.

Другая полезная проверка - запускает ли кто-нибудь какие-либо командные файлы, в которых командная строка соединения с базой данных содержит имена пользователей и пароли. Это можно увидеть с помощью следующей команды ps :

sputnik:pxf> ps -ef / grep ora

root

617

1

-

39

10:37

tty1

00:00:00

login -- oracle

root

618

1

-

39

10:37

tty2

00:00:00

login -- oracle

oracle

625

617

-

39

10:37

tty1

00:00:00

-bash

oracle

650

1

-

39

10:37

?

00:00:00

ora_pmon_PENT

oracle

652

1

-

39

10:37

?

00:00:00

ora_dbw0_PENT

oracle

654

1

-

39

10:37

?

00:00:00

ora_lgwr_PENT

oracle

656

1

-

39

10:37

?

00:00:00

ora_ckpt_PENT

oracle

658

1

-

39

10:37

?

00:00:00

ora_smon_PENT

oracle

660

1

-

39

10:37

?

00:00:00

ora_reco_PENT

oracle

662

1

-

39

10:37

?

00:00:00

ora_s000_PENT

oracle

664

1

-

39

10:37

?

00:00:00

ora_d000_PENT

oracle

690

625

-

39

10:41

tty1

00:00:00

sqlplus system/manager @doit.sql

oracle

691

690

-

39

10:41

?

00:00:00

oraclePENT (DESCRIPTION=(

oracle

692

618

-

29

10:41

tty2

00:00:00

-bash

oracle

740

692

-

29

10:45

tty2

00:00:00

ps -ef

oracle

741

692

-

29

10:45

tty2

00:00:00

grep ora


Можно увидеть, что кто-то запускает командные файлы SQL как пользователь SYSTEM , который по-прежнему имеет установленный по умолчанию пароль. Но этот пример слишком глупый, чаще можно увидеть выполнение командных файлов SQL с "зашитыми" в них именами пользователей и паролями. Обычно требуется написать командный файл shell или задание cron, которые проверяли бы каждую минуту список процессов, чтобы обнаружить запущенный командный файл SQL , или же сделать домашнюю работу и определить, когда должны запускаться пакетные задания.

Следующий очевидный шаг - найти целую машину или конкретные директории с командными файлами, содержащими имена пользователей Oracle и их пароли. Командные файлы могут быть любого типа: Bourne, KSH, Perl, SQL или двоичными. Не прогадаете, если поищите строки sqlplus или svrmgrl в каких-либо директориях или файлах.

Резервные копии баз данных и базы данных разработчиков

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

Здесь важно учитывать то, что данные и базы данных часто не размещаются в одной промышленной машине. Часто используются несколько баз данных для разработчиков, баз данных для компоновочного тестирования, системного тестирования и приемочных испытаний. Существуют также различные типы резервных копий.

Типы резервных копий Oracle

Существует три основных вида резервирования Oracle:

  • Экспорт: инструментальное средство Oracle exp используется для извлечения данных из базы данных в файл операционной системы. Формат файла нестандартный и будет обсуждаться в разделе "Журнальные, трассировочные, экспортные, сигнальные и управляющие файлы" (во второй части статьи - ред.). Инструментальное средство Oracle imp вставляет данные назад в ту же самую или другую базу данных. Можно выполнять частичный или полный экспорт всей базы данных. В полный экспорт включаются хешированные пароли. Если целью является кража данных, то достаточно выполнить экспорт схемы владельца приложения.
  • Холодное резервирование может выполняться различными способами и с помощью инструментальных средств.Он может выполняться также на диск или ленту. Во время холодного резервирования база данных должна быть полностью остановлена.
  • Горячее резервирование выполняется в базах данных с высокой доступностью, когда работа приложений не должны прерываться . Для горячего резервирования база данных должна находиться в режиме ARCHIVELOG (архивирование журнала). Если база данных находится в этом режиме, это еще не означает выполнение горячего резервирования. Узнать об этом гораздо сложнее.
    Для проверки, включен ли режим ARCHIVELOG , можно в sqlplus выдать следующий запрос:

    SQL> sho user
    USER is "DBSNMP"
    SQL> select log_mode
    2 from v$database;

    LOG_MODE
    ------------
    NOARCHIVELOG
    SQL>

Для проверки, выполняется ли в базе данных горячие или холодное резервирование, нужно провести небольшое исследование. Можно поискать в машине командные файлы резервирования, содержащие слова ALTER TABLESPACE [TABLESPACE NAME] BEGIN BACKUP . Проверьте задания cron, проверьте дневные листинги процессов: не запускалось ли программное обеспечение, которое могло выполнять резервирование. Проверьте протокольные файлы. Выясните, программное обеспечение для резервирования установлено на машине, используя для этого pkginfo -l . Можно проверить статус табличных пространств, не переключались ли они в режим "OFFLINE", что может быть хорошим признаком выполнения в данное время горячего резервирования.

SQL> select tablespace_name,status
2 from dba_tablespaces;

TABLESPACE_NAME
STATUS
SYSTEM
ONLINE
USERS
ONLINE
RBS
ONLINE
TEMP
ONLINE
OEM_REPOSITORY
ONLINE
INDX
ONLINE
APP_IND_1
ONLINE
APP_DATA_1
ONLINE

6 rows selected.

SQL>

Проверка холодного резервирования проще, так как вы можете снова проверить задания cron, листинги процессов и посмотреть, есть ли регулярные остановки, а затем поискать какое-нибудь работающее программное обеспечение резервирования. Если доступен сигнальный файл Oracle (alert log), то в нем просто найти все остановки и запуски базы данных. Попробуйте определить, где и когда записываются файлы и, что более важно, попытайтесь узнать, можно ли эти фалы взять и прочитать.

Резервные копии на ленте

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

[Прим. пер.: "социальная инженерия" - тактика злонамеренного проникновения, при которой взломщик путем "уговоров" обманывает пользователей или администратора (например, представляясь новым сотрудником) и добивается значимой информации о компании и/или её компьютерных системах, чтобы получить несанкционированный доступ к сети.
http://www.kolbi.ru/cgi/dict/show-dict.pl?_query=social+engineering&_submit=Search]

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

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

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

Базы данных разработчиков и тестовые базы данных

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

Во многих случаях базы данных разработчиков и тестовые базы данных имеют копии всех промышленных данных, поскольку они требуются для системного тестирования и настройки производительности. Так что, если вам требуются эти данные, очень часто достаточно одного дня для их извлечения из этих баз данных. Как найти базу данных разработчиков или тестовую базу данных? Их не загружают в ту же машину, в которой работает промышленная база данных. Выясните в файлах tnsnames.ora и l istener.ora SID базы данных, который похож на SID промышленной базы данных. Посмотрите в директории admin инсталляции Oracle файлы init.ora . Они имеют имена init[ORACLE_SID].ora .

Иногда остаются другие дырки - разработчики часто имеют гораздо больше прав доступа, чем это нужно. Когда тестовая среда переносится в промышленную базу данных, часто копируются также пользователи, и права доступа разработчиков также оказываются в промышленной базе данных. Ели вы заполучили имя пользователя (разработчика), который имеет хорошие привилегии, испытайте его и в промышленной базе данных.

Базы данных для работы в непредвиденных обстоятельствах

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

Конфигурационные файлы SQL*NET и NET 8

Конфигурационные файлы SQL*NET и NET 8 существуют как на сервере, так и на клиенте. Listener , работающий на сервере, ждет запросов для доступа к СУРБД. Эти конфигурационные файлы говорят листнеру, какая база данных и какой процесс Oracle будет принимать запрос.

В конфигурационных файлах SQL*NET и NET 8 будет также искаться информация. Они имеются как на сервере, так и на каждом клиенте, который получает доступ к базам данных Oracle. Конфигурационные файлы tnsnames.ora, listener.ora и sqlnet.ora обычно размещаются в ORACLE_HOME/network/admin в системах Unix и в /network/admin в системах Windows.

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

Пример входа в файле tnsnames.ora :

PENT =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)
(HOST = EUROPA)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = PENT)
)
)

EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
)
(CONNECT_DATA =

(SID = PLSExtProc)
(PRESENTATION = RO)
)
)

Здесь можно увидеть, что данный файл поддерживает процедуру EXTPROC и только одну базу данных Oracle. Протокол - TCP, а хост - EUROPA, но может быть и IP -адрес и различные протоколы. Стандартный порт прослушивания для листнера Oracle TNS - 1521, но можно использовать и 1526, если 1521 уже используется на этой машине другими инсталляциями Oracle. SERVICE_NAME - SID базы данных. Это имя совместно с именем пользователя и паролем требуется для установления соединения с конкретной базой данных.

Процесс EXTPROC принимает запросы процедур PL/SQL для вызова внешних 'C'-функций, написанных и инсталлированных разработчиками. Хорошее руководство по разработке таких функций и процессов можно найти в "PL/SQL Oracle PL/SQL programming. 2nd Edition" написанного Steve Feuerstein и изданного www.oreilly.com. СУРБД Oracle вызывает эти 'C'-функции через протокол TNS, и не использует прямые методы, применяемые самой Oracle во встроенных пакетах. Oracle вызывает 'C'-функции, которые делают большинство встроенного в пакеты с помощью ключевого слова PL/SQL pragma interface . Можно создавать пользовательские пакеты, использующие такой же синтаксис, и вызывать 'C'-функции Oracle и успешно компилировать их. Если это будет сделано, то при попытке выполнения функции или процедуры в пакете произойдет сбой с ошибкой "ORA-6509 ICD vector missing error". Это похоже на то, что Oracle имеет "зашитую" таблицу указателей функций. Это можно посмотреть в X$-таблицах. X$-таблицы не могут модифицироваться, поскольку они фактически являются окном в списки 'C'-структур (structs) в SGA. Если данная таблица находится в числе X$-таблиц, то к ней можно добавить новые входы с помощью отладочной (poke) команды oradebug, следите за пространством!

Файл tnsnames.ora - необходимый файл сервера базы данных. Он же может потребоваться на клиенте, в зависимости от того, используется ли сервер имен.

Ниже следует пример файла listener.ora:

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)
(HOST = EUROPA)(PORT = 1521))
)
)
(DESCRIPTION =
(PROTOCOL_STACK =

Этот файл управляет TNS -листнером на сервере. Он также содержит информацию об IP -адресах, имени хоста, протоколе и порте, который прослушивает листнер. Второй раздел детализирует имена баз данных и ORACLE_HOME этих баз данных. Файл listener.ora имеет важное значение для сервера баз данных. Если в одном узле используется несколько баз данных, все они могут разделять один файл listener.ora .

(PRESENTATION = GIOP)
(SESSION = RAW)
)
(ADDRESS = (PROTOCOL = TCP)
(HOST = EUROPA)(PORT = 2481))
)
)

SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = C:\Oracle\Ora81)
(PROGRAM = extproc)
)
(SID_DESC =
(GLOBAL_DBNAME = PENT)
(ORACLE_HOME = C:\Oracle\Ora81)
(SID_NAME = PENT)
)
)

Вторжение из других баз данных

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

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

SQL> select db_link,username,host
2 from all_db_links;

DB_LINK USERNAME HOST
------------- -------- ---------
VOSTOK VXD vostok@europa.world

1 rows selected.

SQL>

Для доступа к другим базам данных связям базы данных требуется использовать TNS , поэтому в файле tnsnames.ora должен быть соответствующий вход. В примере, приведенном выше, VOSTOK - это другая база данных в хосте europa. Очень часто связи баз данных создаются тогда, когда пользователи, создаваемые в базе данных, выполняют запросы от имени исходной базы данных как dba. Очень важно проверить такой путь доступа, чтобы увидеть, что высшие привилегии могут быть получены в промышленной базе данных.

Подтверждение версии Oracle

В самом начале очень полезно определить версию базы данных сервера Oracle, к которой вы хотите получить доступ. Это можно сделать очень легко без соединения с базой данных, а только запуском утилиты Oracle svrmgrl . Она расположена в директории ORACLE_HOME/bin инсталляции Oracle. Запуск выглядит следующим образом:

sputnik:pxf> svrmgrl

Oracle Server Manager Release 3.1.5.0.0 - Production

(c) Copyright 1997, Oracle Corporation. All Rights Reserved.

Oracle8i Enterprise Edition Release 8.1.5.0.0 - Production
With Partitioning and Java Options
PL/SQL Release 8.1.5.0.0 - Production

SVRMGR>

Совершенно ясно, что у нас работает версия 8.1.5 СУРБД.

Так же возможен удаленный и локальный запуск листнера, которые дадут аналогичную информацию. Формат команды: lsnrctl status.

Часть 2


Страница сайта http://test.interface.ru
Оригинал находится по адресу http://test.interface.ru/home.asp?artId=3499