Некоторые вопросы безопасности в Oracle

Источник: oracle

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

Получить доступ к серверу с установленными на нем последними обновлениями для системы безопасности и стойкими паролями становится довольно сложно, поэтому векторы атак смещаются сегодня в сторону приложений, наиболее важными из которых являются базы данных, тем более что именно информация в базах данных зачастую является конечной целью злоумышленника. База данных Oracle - одна из распространенных в корпоративной среде систем, поэтому она и была выбрана в качестве примера, а точнее, версии Oracle Database 9i и 10g. Рассмотрим ряд критичных уязвимых мест, которыми можно воспользоваться, не имея логических прав доступа к базе данных Oracle.

Внешний периметр

Удаленный доступ к базе данных предоставляет служба Oracle TNS Listener, работающая по умолчанию на TCP-порту 1521, и большинство атак направлено именно на эту службу. Listener - компонент сетевого доступа к системам Oracle, принимает клиентские запросы на соединение и направляет их для обработки соответствующему серверному процессу. Обычно Listener рассматривается как первый этап на пути вторжения в базы данных и другие службы, поэтому плохо сконфигурированный и незащищенный Listener предоставляет нарушителю различные возможности атак, включая удаленное выполнение команд и отказ в обслуживании.

Лазейки внешнего периметра

Для версий базы данных Oracle ниже 10g (8, 9i R1, 9i R2) в конфигурации по умолчанию можно осуществлять анонимное подключение и управление службой Listener. Эта проблема была впервые озвучена еще в 2001 году, но она до сих пор крайне актуальна. В конфигурации по умолчанию злоумышленник может:

получить детальную информацию об атакуемой системе - имени базы данных (SID), ее версии, пути к файлам журналов, версии операционной системы и т. д.;
произвести атаку класса "отказ в обслуживании";
выполнять SQL-команды от имени администратора базы;
получить удаленный доступ к системе.

Все эти действия можно совершить, используя стандартные утилиты, поставляемые с базой данных (см. экран 1), и лишь в некоторых случаях могут понадобиться дополнительные сценарии, доступные в Internet.

Рассмотрим атаку типа "отказ в обслуживании", исполняемую с помощью утилиты lsnrctl. С помощью команды stop любой удаленный неавторизированный пользователь может остановить службу Listener:

lsnrctl stop 192.168.55.16

Для получения удаленного доступа к системе используется утилита lsnrctl и сценарий tnscmd2.pl, позволяющий выполнять команды и посылать службе Listener произвольные пакеты. С помощью команды set log_file удаленный неавторизованный пользователь может изменить имя файла для хранения журналов, например, на имя исполняемого файла, лежащего в папке автозагрузки пользователя. Далее с помощью утилиты tnscmd2.pl злоумышленник может послать запрос, содержащий системные команды, которые в результате будут сохранены в файле журнала и выполнятся при следующей регистрации администратора в системе.

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

Защита внешнего периметра

Для защиты службы Listener существуют следующие параметры в файле LISTENER.ORA:

PASSWORDS_(listener name) = (listener_password) - параметр, который отвечает за установку пароля на подключение к Listener. После установки пароля пользователь не сможет остановить службу, а также проводить атаки, связанные со сменой имени файла журнала. Но тем не менее команды status и version выполняются и позволяют получить информацию о версии Listener, имени установочного каталога и версии операционной системы.
ADMIN_RESTRICTIONS_(listener name) - параметр, который во включенном состоянии ADMIN_RESTRICTIONS_(listener name) =ON (по умолчанию OFF) запрещает любые изменения файла конфигурации удаленно, т. е. смена имени и каталога файла журнала возможна только при наличии локального доступа к файлу listener.ora
LOCAL_OS_AUTHENTICATION_(listener name) - параметр, который во включенном состоянии (по умолчанию отключен) позволяет управлять службой Listener только локально - при любых попытках удаленного выполнения команд будет выдаваться сообщение об ошибке. Единственная команда, которую можно выполнить, - version, она выдаст версию установленной базы данных Oracle и версию операционной системы. В версии Oracle 10g R1 и выше Listener защищен путем установки параметра LOCAL_OS_AUTHENT в значение ON по умолчанию, что позволяет осуществлять управление только с локальной системы, что хоть и предотвращает ряд атак, но все равно позволяет получить доступ к управлению службой Listener при наличии любой непривилегированной учетной записи на сервере. С точки зрения администрирования крупной системы предпочтительнее все-таки иметь возможность удаленного администрирования Listener, поэтому многие администраторы отключают LOCAL_OS_AUTHENT, что сразу сказывается на безопасности базы данных.

Для проверки защищенности Listener можно воспользоваться удобной утилитой lsnrcheck.exe, работающей под Windows. Утилита распространяется бесплатно и доступна для загрузки по адресу http://www.integrigy.com/downloads/lsnrcheck.exe

Пример запуска утилиты на Oracle 10g с настройками по умолчанию можно увидеть на экране 2. Как мы видим, настройки по умолчанию в Oracle 10g более безопасны по сравнению с Oracle 9, но все же имеют ряд недостатков.

Подключение к базе данных

По умолчанию, чтобы подключиться к базе данных Oracle, необходимо знать пять параметров: IP-адрес сервера; порт Listener; имя базы данных (SID); имя пользователя; пароль. Относительно первых двух пунктов все ясно. Что касается имени базы данных (SID), то Listener для базы данных до версии 10g R1 по умолчанию выдает имена баз данных без аутентификации. Для этого достаточно воспользоваться утилитой lsntctl с ключом services. Если на Listener установлен пароль или включена настройка LOCAL_OS_AUTHENTICATION, что сделано в версии Oracle 10g по умолчанию, это значительно усложнит злоумышленнику доступ к базе.

Подбор SID

В случае использования парольной защиты Listener все же существует несколько способов получения имени базы данных (SID):

поиск информации в сторонних приложениях. База данных Oracle 10g R2 по умолчанию устанавливает Oracle Application Server, который работает на порту 1158. Этот сервер доступен для удаленного подключения и вместе с окном регистрации пользователя выдает SID базы данных. Также при установке Oracle в связке с системой SAP R/3 можно узнать SID базы данных через приложение SAP Web-Manegment, "слушающее" обычно TCP-порт 8001 и отвечающее за управление системой SAP;
имя базы данных является стандартным, устанавливаемым по умолчанию. Список стандартных SID опубликован в открытом доступе по адресу www.red-database-security.com/scripts/sid.txt, а перебор всех этих имен с помощью специализированных средств занимает несколько минут (www.red-database-security.com/whitepaper/oracle_guess_sid.html);
имя базы данных является словарным словом. Часто имена баз данных выражают их предназначение типа PAYMENT, CREDITS и т. п.;
имя базы данных состоит из небольшого количества символов. Все четырехсимвольные имена, например ORCL, перебираются в течение двух часов;
имя базы данных частично или полностью совпадает с именем хоста в службе DNS или NETBIOS;
имя базы данных можно узнать по ссылке из другой базы данных, из файла tnsnames.ora на одном из хостов в сети или, например, прослушивая сетевой трафик.

Таким образом, даже не имея доступа к Listener, можно узнать SID базы данных - практика показывает, что в 90% случаев тем или иным способом SID базы данных был получен.

Подбор паролей

Получив SID базы данных или обнаружив незащищенный порт Listener, злоумышленник может попытаться получить доступ к базе данных, подобрав учетные записи пользователей. Oracle при установке создает множество системных учетных записей со стандартными паролями. Обычно при установке по умолчанию с использованием Database Configuration Assistant после успешного завершения процесса большинство этих учетных записей автоматически блокируется. Однако если база данных конфигурируется вручную или по той или иной причине установка завершается некорректно, то учетные записи остаются открытыми, а администраторы обычно забывают их удалять, отключать или хотя бы менять пароли. Например, при установке базы данных Oracle 9 R2 программа установки запрашивает ввод новых паролей для учетных записей SYS и SYSTEM, но пароли учетных записей DBSNMP и SCOTT (в версии 9 R1 к ним добавляется OUTLN) при установке по умолчанию остаются неизменными, и эти учетные записи не блокируются после установки.

При установке версии Oracle 10g R1 программа установки запрашивает ввод новых паролей для учетных записей: SYS, SYSTEM, DBSNMP и SYSMAN. Остальные записи по умолчанию заблокированы, что обеспечивает безопасную конфигурацию.

Что касается последней версии Oracle 11 g , в ней опять присутствуют учетные записи с паролями по умолчанию, которые не блокируются: DIP, MGMT_VIEW, SYS, SYSMAN, SYSTEM.

Кроме приведенных стандартных учетных записей, имеется множество приложений для Oracle и систем типа SAP, которые интегрируются с базой данных; они имеют свои стандартные системные учетные записи, которые также можно использовать для проникновения в систему. Список стандартных пользовательских учетных записей насчитывает порядка 600 имен и доступен в Сети (www.petefinnigan.com/default/default_password_list.htm). Для проверки базы данных на наличие учетных записей с паролями, установленными по умолчанию, можно воспользоваться утилитой oscanner, которая может осуществлять проверку по заданному списку стандартных учетных записей. Пример запуска утилиты oscanner для проверки установленной версии Oracle 9 R2 показан на экране 3. Здесь мы видим, что у пользователей DBSNMP,SCOTT, SYS и SYSTEM установлены пароли по умолчанию, поэтому любой злоумышленник может получить удаленный доступ к базе данных.

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

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

Проблема парольной политики также касается и других баз данных, это до сих пор является основной проблемой любой системы. Практика показывает, что в 80% случаев перебор паролей завершается успехом и редко занимает более 10-15 минут.

Внутренняя безопасность базы данных Oracle

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

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

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

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

Рекомендации по защите

Приведем некоторые рекомендации, необходимые для повышения уровня защищенности Oracle, многие из которых применимы и к другим базам данных.

1. При установке системы в рабочую среду:

устанавливайте только необходимые для бизнес-процесса компоненты. Не устанавливайте тестовые примеры схем;
смените пароли к административным учетным записям SYS и SYTEM на удовлетворяющие требованиям безопасности;
при выборе имен баз данных (SID) используйте названия, состоящие не менее чем из восьми символов, включая буквы и специальные символы, но не совпадающие с именем хоста в DNS или Netbios;
установите последние критические обновления перед вводом системы в эксплуатацию.

2. При настройке системы после установки:

создайте учетную запись пользователя в операционной системе, от имени которого будет запускаться база данных Oracle, установите для нее надежный пароль и лишите ее административных привилегий;
установите пароль на доступ к службе Listener. Использование установки LOCAL_OS_AUTHENT не рекомендуется, так как не защищает локальный доступ к службе и усложняет удаленное администрирование (см. листинг 1);
включите протоколирование всех попыток подключения к Listener для обнаружения попыток перебора паролей (см. листинг 2);
максимально ограничьте доступ к локальным конфигурационным файлам tnsnames.ora, оставив права на чтение лишь пользователю, от имени которого запускается база данных, так как пароль на подключение к Listener хранится в конфигурационном файле;
ограничьте доступ к приложениям, через которые можно узнать SID, или модифицируйте информацию, выводимую этими приложениями;
отключите неиспользуемые учетные записи и смените пароли учетных записей, установленных по умолчанию;
введите как административные, так и программные ограничения на длину и сложность пароля. Программно это можно реализовать настройкой профилей пользователей в базе данных Oracle. Основные параметры профиля, влияющие на безопасность, могут быть настроены путем изменения таких параметров, как FAILED_LOGIN_ATTEMPTS (число неудачных попыток регистрации), PASSWORD_LIFE_TIME (время действия пароля, рекомендуется менять раз в два месяца), PASSWORD_VERIFY_FUNCTION (имя функции для проверки длины и сложности пароля).

Пример установки числа неудачных попыток входа, равного пяти:

alter profile DEFAULT
limit FAILED_LOGIN_ATTEMPTS 5;
alter user SCOTT
profile DEFAULT;

проанализируйте привилегии и роли пользователей и оставьте только самые необходимые, руководствуясь известным принципом наименьших привилегий. Как минимум, необходимо ограничить для роли PUBLIC доступ к таким пакетам, как UTL_SMTP, UTL_TCP, UTL_HTTP, UTL_FILE. Также максимально ограничьте доступ на выполнение JAVA-процедур;
ограничьте доступ к базе данных по IP-адресам, разрешив доступ только с Web-сервера, если база данных используется с ним в связке или только из подсети пользователей базы данных. Для этого можно воспользоваться межсетевым экраном или настройками конфигурационного файла protocol.ora. В конфигурационный файл необходимо внести строки:

tcp.validnode_checking = YES
tcp.excluded_nodes =
{Список запрещенных адресов}
tcp.invited_nodes =
{Список разрешенных адресов}

3. Периодические проверки:

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

Ссылки по теме