Рівень забезпечення інформаційної безпеки корпоративних систем сьогодні помітно зріс, та типові помилки зустрічаються все рідше адміністратори регулярно встановлюють оновлення і реалізують вимоги парольної політики на серверах 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. Утиліта розповсюджується безкоштовно і доступна для завантаження за адресою 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 11g, в ній знову присутні облікові записи з паролями за замовчуванням, які не блокуються: 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 DEFAULT profile
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, яка передбачає знання аутентифікаційних даних адміністраторів. При запуску вона підключається до бази даних з аутентифікаційними даними заданого користувача, робить вибірку з таблиці з хешами паролів користувачів і звіряє ці хеші зі стандартними. Також утиліта здійснює підбір пароля за словником і перевіряє, заблокована обліковий запис;
*
періодично вимикайте неактивні облікові записи, наприклад облікові записи звільнених працівників;
*
періодично аналізуйте привілеї та ролі користувачів та залишайте тільки найнеобхідніші;
*
слідкуйте за документацією.

Ці основні рекомендації допоможуть найбільш повно захистити базу даних без застосування додаткових програмно-апаратних засобів. Детальну інформацію про захист Oracle можна знайти в офіційному документі Oracle Database Security Checklist, остання версія якого доступна за адресою

www.oracle.com/technology/deploy/security/ pdf/twp_security_checklist_db_database.pdf.