Рівень забезпечення інформаційної безпеки корпоративних систем сьогодні помітно зріс, і типові помилки зустрічаються все рідше - адміністратори регулярно встановлюють поновлення і реалізують вимоги пральний політики на серверах Windows, виконують вимоги контролю доступу на мережевому обладнанні, сегментируют мережі. Однак існує ряд проблем, яким до цих пір не приділяється належної уваги, і одна з них - захищеність корпоративних систем управління базами даних. У даній статті я хочу проаналізовані найбільш критичні вразливі місця на прикладі систем, побудованих на базі даних Oracle.
Отримати доступ до сервера з встановленими на ньому останніми оновленнями для системи безпеки і стійкими паролями стає досить складно, тому вектори атак зміщуються сьогодні в сторону додатків, найбільш важливими з яких є бази даних, тим більше що саме інформація в базах даних часто є кінцевою метою зловмисника . База даних Oracle - одна з поширених в корпоративному середовищі систем, тому вона і була обрана в якості прикладу, а точніше, версії Oracle Database 9i і 10g. Розглянемо ряд критичних вразливих місць, якими можна скористатися, не маючи логічних прав доступу до бази даних Oracle.
Віддалений доступ до бази даних надає служба Oracle TNS Listener, що працює за замовчуванням на TCP-порту 1521, і більшість атак направлено саме на цю службу. Listener - компонент мережевого доступу до систем Oracle, приймає клієнтські запити на з'єднання і направляє їх для обробки відповідного серверного процесу. Зазвичай Listener розглядається як перший етап на шляху вторгнення в бази даних і інші служби, тому погано сконфігурованих і незахищений Listener надає порушнику різні можливості атак, включаючи віддалене виконання команд і відмова в обслуговуванні.
Лазівки зовнішнього периметра
- отримати детальну інформацію про атакується системі - імені бази даних (SID), її версії, шляхи до файлів журналів, версії операційної системи і т. д .;
- провести атаку класу "відмова в обслуговуванні";
- виконувати SQL-команди від імені адміністратора бази;
- отримати віддалений доступ до системи.
Всі ці дії можна зробити, використовуючи стандартні утиліти, що поставляються з базою даних (див. Екран 1), і лише в деяких випадках можуть знадобитися додаткові сценарії, доступні в Internet.
lsnrctl stop 192.168.55.16
Все це говорить про незахищеність системи при використанні налаштувань за замовчуванням, причому зловмисник не повинен володіти ніякими додатковими програмними засобами, крім стандартних утиліт.
Захист зовнішнього периметра
Для захисту служби 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, що відразу позначається на безпеці бази даних.
Приклад запуску утиліти на Oracle 10g з настройками за замовчуванням можна побачити на екрані 2. Як ми бачимо, стандартні параметри в Oracle 10g більш безпечні в порівнянні з Oracle 9, але все ж мають ряд недоліків.
Підключення до бази даних
У разі використання парольного захисту 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 11 g. в ній знову присутні облікові записи з паролями за замовчуванням, що не блокуються: DIP, MGMT_VIEW, SYS, SYSMAN, SYSTEM.
Крім наведених стандартних облікових записів, є безліч додатків для Oracle і систем типу SAP, які інтегруються з базою даних; вони мають свої стандартні системні облікові записи, які також можна використовувати для проникнення в систему. Список стандартних призначених для користувача облікових записів налічує близько 600 імен і доступний в Мережі (www.petefinnigan.com/default/default_password_list.htm). Для перевірки бази даних на наявність облікових записів з паролями, встановленими за замовчуванням, можна скористатися утилітою oscanner, яка може здійснювати перевірку по заданому списку стандартних облікових записів. Приклад запуску утиліти oscanner для перевірки встановленої версії Oracle 9 R2 показаний на екрані 3. Тут ми бачимо, що у користувачів DBSNMP, SCOTT, SYS і SYSTEM встановлені паролі за замовчуванням, тому будь-який зловмисник може отримати віддалений доступ до бази даних.
Навіть якщо все невикористовувані системні облікові записи видалені або заблоковані, а стандартні паролі змінені, ніщо не заважає зловмисникові використовувати перебір паролів до облікових записів. Існує кілька моментів, завдяки яким перебір паролів до бази даних Oracle в деяких випадках приносить успіх:
- багато системні імена користувачів відомі, що дозволяє підбирати тільки паролі;
- за замовчуванням не встановлено обмежень на довжину і складність пароля;
- перебір паролів до облікових записів за замовчуванням не блокується.
Проблема пральний політики також стосується і інших баз даних, це до сих пір є основною проблемою будь-якої системи. Практика показує, що в 80% випадків перебір паролів завершується успіхом і рідко займає більше 10-15 хвилин.
Внутрішня безпека бази даних Oracle
На відміну від операційних систем, де процес оновлення вже не викликає труднощів і здійснюється майже в автоматичному режимі, з Oracle справи йдуть набагато гірше. По-перше, оновлення виходять рідко, по-друге, до цих пір їх установка нетривіальна і часто загрожує серйозними збоями в тих випадках, коли Oracle використовується в сукупності з будь-якої сторонньої системою, що працює з певною версією Oracle. Нарешті, навіть якщо поновлення справно встановлюються, це все одно не дає повної гарантії безпеки, так як за статистикою більше половини вразливих місць так і залишаються незакритими.
Основні атаки, що здійснюються користувачами бази даних Oracle, спрямовані на підвищення своїх привілеїв. Скориставшись уразливими місцями у вбудованих функціях, зловмисник може виконати наступні дії:
- підвищити привілеї до ролі адміністратора;
- провести атаку типу "відмова в обслуговуванні" або запустити довільний код на сервері;
- прочитати хеші паролів користувачів і спробувати надалі розшифрувати їх;
- змінити паролі до облікових записів користувачів, в тому числі адміністраторів;
- отримати доступ до системних файлів;
- отримати доступ до командного рядка сервера.
Всі ці можливості вимагають тих чи інших додаткових знань і програмних засобів, але тим не менше вони дуже популярні і мали місце практично у всіх системах на базі Oracle. А, враховуючи, що в Windows база даних Oracle за замовчуванням працює від імені облікового запису адміністратора, отримання доступу до командного рядка сервера через внутрішні процедури Oracle загрожує отриманням адміністративного доступу до операційної системи з усіма витікаючими наслідками. Наявність внутрішніх вразливих місць високого ступеня критичності укупі з помилками конфігурації і слабкими паролями представляє реальну загрозу безпеці компанії.
Рекомендації щодо захисту
Наведемо деякі рекомендації, необхідні для підвищення рівня захищеності Oracle, багато з яких можна застосувати й до інших баз даних.
1. При установці системи в робоче середовище:
- встановлюйте тільки необхідні для бізнес-процесу компоненти. Не встановлюйте тестові приклади схем;
- змініть паролі до адміністративних облікових записів SYS і SYTEM на задовольняють вимогам безпеки;
- при виборі імен баз даних (SID) використовуйте назви, що складаються не менше ніж з восьми символів, включаючи літери і спеціальні символи, але не збігаються з ім'ям хоста в DNS або Netbios;
- встановіть останні критичні оновлення перед введенням системи в експлуатацію.
2. Під час налаштування системи після установки:
- щоб створити обліковий запис користувача в операційній системі, від імені якого буде запускатися база даних Oracle, встановіть для неї надійний пароль і позбавите її адміністративних привілеїв;
- встановіть пароль на доступ до служби Listener. Використання установки LOCAL_OS_AUTHENT не рекомендується, так як не захищає локальний доступ до служби та ускладнює віддалене адміністрування (див. Лістинг 1);
- включите протоколювання всіх спроб підключення до Listener для виявлення спроб перебору паролів (див. лістинг 2);
- максимально обмежте доступ до локальних конфігураційним файлів tnsnames.ora, залишивши права на читання лише користувачу, від імені якого запускається база даних, так як пароль на підключення до Listener зберігається в файлі конфігурації;
- обмежте доступ до додатків, через які можна дізнатися SID, або змінюйте інформацію, виведену цими додатками;
- відключіть невикористовувані облікові записи та змініть паролі облікових записів, встановлених за замовчуванням;
- введіть як адміністративні, так і програмні обмеження на довжину і складність пароля. Програмно це можна реалізувати налаштуванням профілів користувачів в базі даних Oracle. Основні параметри профілю, що впливають на безпеку, можуть бути налаштовані шляхом зміни таких параметрів, як FAILED_LOGIN_ATTEMPTS (число невдалих спроб реєстрації), PASSWORD_LIFE_TIME (час дії пароля, рекомендується міняти раз в два місяці), PASSWORD_VERIFY_FUNCTION (ім'я функції для перевірки довжини і складності пароля) .
Приклад установки числа невдалих спроб входу, рівного п'яти:
alter profile DEFAULT
limit FAILED_LOGIN_ATTEMPTS 5;
alter user SCOTT
profile DEFAULT;
3. Періодичні перевірки: