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


Всі ці дії можна зробити, використовуючи стандартні утиліти, що поставляються з базою даних (див. екран 1), і лише в деяких випадках можуть знадобитися додаткові сценарії, доступні в Internet.

Екран 1. Приклад віддаленої установки Listener на СУБД Oracle 9 R2

Розглянемо атаку типу “відмова в обслуговуванні”, що виконується за допомогою утиліти lsnrctl. За допомогою команди stop будь віддалений неавторизований користувач може зупинити службу Listener:


lsnrctl stop 192.168.55.16

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

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

Захист зовнішнього периметра

Для захисту служби Listener існують наступні параметри у файлі LISTENER.ORA:


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

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

Екран 2. Приклад запуску утиліти lsnrcheck на СУБД Oracle 10G R1

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

За замовчуванням, щоб підключитися до бази даних Oracle, необхідно знати п’ять параметрів: IP-адресу сервера; порт Listener; ім’я бази даних (SID), а ім’я користувача; пароль. Щодо перших двох пунктів все ясно. Що стосується імені бази даних (SID), то Listener для бази даних до версії 10g R1 за замовчуванням видає імена баз даних без аутентифікації. Для цього достатньо скористатися утилітою lsntctl з ключем services. Якщо на Listener встановлений пароль або включена настройка LOCAL_OS_AUTHENTICATION, що зроблено у версії Oracle 10g за замовчуванням, це значно ускладнить зловмисникові доступ до бази.

Підбір SID

У разі використання парольного захисту Listener все ж існує кілька способів отримання імені бази даних (SID):


Таким чином, навіть не маючи доступу до 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 встановлені паролі за замовчуванням, тому будь-який зловмисник може отримати віддалений доступ до бази даних.

Екран 3. Приклад запуску утиліти oscanner на СУБД Oracle 9 R2

Навіть якщо всі невикористовувані системні облікові записи видалено або заблоковані, а стандартні паролі змінені, ніщо не заважає зловмисникові використовувати перебір паролів до облікових записів. Існує кілька моментів, завдяки яким перебір паролів до бази даних Oracle в деяких випадках приносить успіх:


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

Внутрішня безпека бази даних Oracle

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

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


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

Рекомендації по захисту

Наведемо деякі рекомендації, необхідні для підвищення рівня захищеності Oracle, багато з яких можна й до інших баз даних.

1. При установці системи в робоче середовище:


2. При налаштуванні системи після установки:


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


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



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

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


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

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

Лістинг 1. Установка пароля на доступ до Listener

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


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

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

Ваш отзыв

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

*

*