Цей документ не охоплює базовий SQL синтаксис або SQL ін'єкції. Передбачається, що читач вже має відмінне розуміння предмета. Цей документ буде сфокусований на просунутих техніках, які можуть бути використані в атаках на web-додатки використовують Microsoft SQL Server. Ці техніки демонструють як атакуючий може використовувати SQL ін'єкції для того щоб видаляти з бази даних минаючи брандмауер і проникати у внутрішню мережу. Цей документ покликаний навчити професіоналів інформаційної безпеки потенційно небезпечним ефектів SQL ін'єкцій, які можуть статися у вашій організації.
Вступ
Виявлення SQL ін'єкцій
Отримання результатів з SQL ін'єкцій
підвищення привілеїв
Завантаження файлів
Проникнення у внутрішню мережу
сканування портів
рекомендації
висновок
Цей документ не охоплює базовий SQL синтаксис або SQL ін'єкції. Передбачається, що читач вже має відмінне розуміння предмета. Цей документ буде сфокусований на просунутих техніках, які можуть бути використані в атаках на web-додатки використовують Microsoft SQL Server. Ці техніки демонструють як атакуючий може використовувати SQL ін'єкції для того щоб видаляти з бази даних минаючи брандмауер і проникати у внутрішню мережу. Цей документ покликаний навчити професіоналів інформаційної безпеки потенційно небезпечним ефектів SQL ін'єкцій, які можуть статися у вашій організації.
Web-додатки стають більш захищеними, оскільки зростає кількість повідомлень про атаки, таких як SQL ін'єкції. Проте, у великих і комплексних додатках, одна помилка може стати результатом компрометації всієї системи. Безліч розробників і адміністраторів web-додатків можуть мати помилкове відчуття безпеки, оскільки вони використовують процедури, або приховують повідомлення про помилки повертаються в вікно браузера. Це дає підставу вірити в те, що вразливістю неможливо скористатися.
Хоча в цьому документі ми обговорюємо Microsoft SQL Server, це не говорить про те, що цей продукт менш захищений, ніж інші платформи, такі як Oracle або IBM DB2. SQL ін'єкції це не конкретна уразливість Microsoft SQL Server це також проблема баз даних в цілому. Можливо, велика проблема Microsoft SQL Server це його гнучкість. Завдяки цій гнучкості відкриваються нові можливості для проведення атак класу SQL Injection. Мета цього документа показати, що кожен раз, коли адміністратор або розробник допускає виконання довільного SQL запиту, яку атакують система відкрита для повного захоплення. Це не є показником того, що продукт Microsoft SQL Server вразливим в цілому.
Виявлення SQL ін'єкцій
При спробі використання SQL ін'єкцій в додатках, атакуючий потребує методі визначення дійсно відбулося впровадження довільного SQL запиту. Так само існує необхідність в методі отримання результатів. Для цього можуть бути використані дві вбудовані функції SQL сервера. Функції OPENROWSET і OPENDATASOURCE призначені для відкриття віддаленого джерела даних. Цими параметрами, щоб відкриття з'єднання за допомогою провайдера OLEDB. Функція OPENROWSET буде використана в усіх прикладах, але з тими ж результатами може бути використана функція OPENDATASOURCE.
Цей вислів повертає всі рядки таблиці table1 з віддаленого джерела даних:
параметри:
(1) Ім'я провайдера OLEDB
(2) Рядок підключення (може бути в форматі необхідному OLEDB або ODBC)
(3) Вираз SQL
В процесі SQL ін'єкції атакуючий може визначити, виконався чи SQL запит. Якщо SQL запит успішно виконаний, атакований сервер спробує встановити вихідні повідомлення з комп'ютером атакуючого на вказаний порт. Це що виходить SQL з'єднання в більшості випадків не буде блоковано брандмауером, так як використовується 80-й порт.
Ця техніка дозволяє атакуючому дізнатися виконався чи SQL запит, навіть якщо повідомлення про помилки і результати запиту не були виведені у вікно браузера.
Отримання результатів з SQL ін'єкцій
Функції OPENROWSET і OPENDATASOURCE найбільш часто використовуються для вилучення необхідних даних. Вони можуть бути також використані для переміщення даних на віддалений SQL сервер. Функція OPENROWSET може бути використана не тільки для виконання запиту SELECT, але також для виконання INSERT і DELETE в зовнішніх джерелах даних. Обробка даних з віддаленого джерела не є загальним випадком і працює, тільки якщо OLEDB провайдер підтримує цю можливість. Провайдер SQLOLEDB володіє такими функціональними можливостями.
Нижче наведено приклад приміщення даних у зовнішній джерело даних:
У цьому прикладі всі рядки в таблиці table2 локального SQL сервера будуть додані в таблицю table1 знаходиться на віддаленому сервері. Для успішного виконання запиту необхідно щоб обидві таблиці мали схожу структуру.
Як ми дізналися в попередньому абзаці, віддалені джерела даних можуть бути перенаправлені на будь-який з вибору сервер атакуючого.
Атакуючий може змінити запит вище для з'єднання з віддаленим джерелом даних, таким як копія Microsoft SQL Server запущених на машині атакуючого.
Для того щоб успішно вставити дані, атакуючий повинен створити таблицю table1 з тими ж стовпцями і типами даних як в таблиці table2. Ця інформація може бути визначена, використовуючи цей же трюк для системних таблиць. Це спрацює, тому що структура системних таблиць заздалегідь відома. Атакуючий повинен почати з створення таблиць зі структурою ідентичною системних таблиць sysdatabases, sysobjects і syscolumns. Потім щоб витягти необхідну інформацію повинні бути виконані наступні SQL запити:
Після відтворення таблиць в базі даних, завантаження необхідних даних з SQL сервера тривіальна.
Використовуючи цей метод, атакуючий може видаляти з таблиць, навіть якщо додаток приховує повідомлення про помилки або результати невірних запитів.
Отримавши відповідні привілеї, атакуючий зможе завантажити список логінів і паролів:
Отримання хешей паролів дає можливість атакуючому використовувати brute-force атаку для підбору паролів.
Атакуючий також зможе виконувати команди на атакованому сервері і отримувати результати їх виконання:
Якщо брандмауер налаштований блокувати всі вихідні з'єднання SQL сервера, атакуючий може використовувати один з декількох методів для обходу брандмауера. Атакуючий може використовувати при передачі даних 80-й порт призначений для HTTP з'єднання. Нижче наведено приклад цієї техніки:
Якщо вихідні повідомлення на 80-й порт блокується брандмауером, то атакуючий може спробувати використовувати інші номери портів до тих пір, поки не знайде незаблокований.
підвищення привілеїв
Часто адміністратор, дотримуючись рекомендацій безпеки, налаштовує програми для запуску від імені непривилегированного користувача. Знайшовши вразливість в додаток, запущеному від непривилегированного користувача атакуючий намагається підвищити привілеї і отримати права адміністратора. Атакуючий може використовувати інші відомі і невідомі уразливості, що призводять до підвищення привілеїв. Існує кілька свіжих вразливостей виявлених в SQL сервері, якщо атакуючий може виконувати довільні SQL запити, то він порівняно легко зможе підняти привілеї.
Завантаження файлів
Як тільки атакуючий отримав необхідні привілеї SQL сервера, він можливо захоче завантажити на сервер бінарний файл. Оскільки це не може бути зроблено за допомогою протокол такий як SMB, порти 137-139 зазвичай заблоковані брандмауером, атакуючому потрібен інший метод для приміщення бінарного файлу в файлову систему жертви. Це може бути зроблено посредствам завантаження двійкового файлу в локальну таблицю на хості атакуючого і розміщення файлу на атакується хост використовуючи з'єднання SQL сервера.
Для реалізації цього атакуючий повинен створити таблицю на локальному сервері наступним чином.
Створивши таблицю для бінарного файлу, завантажуємо його туди наступним чином:
Бінарний файл може бути завантажений на сервер-жертву з сервера атакуючого за допомогою наступного SQL запиту виконаного на сервері-жертві:
Цей запит призведе до вихідного з'єднанню з сервером атакуючого і запише результат запиту в файл. В цьому випадку, з'єднання відбувається з використанням протоколу і порту використовується за умовчанням, таке з'єднання, ймовірно, буде блоковано брандмауером. Для обходу брандмауера, атакуючий може спробувати використовувати:
Перший SQL запит конфигурирует з'єднання з сервером хакера для використання 80-го порту, другий SQL запит з'єднується з сервером хакера, використовуючи 80-й порт, і закачує бінарний файл.
Використовуючи цю техніку, скрипт буде підключатися до якого-небудь сервера і завантажувати бінарний файл атакуючого або копіювати і запускати файл на сервері-жертві.
Проникнення у внутрішню мережу
Сполучені і віддалені сервери Microsoft SQL Server дозволяють одного сервера прозоро взаємодіяти з іншим віддаленим сервером баз даних. Сполучені сервери дозволяють виконувати розподілені запити і навіть дозволяють управляти віддаленими серверами баз даних. Атакуючий може скористатися цими можливостями для доступу до внутрішньої мережі.
Атакуючий повинен почати зі збору інформації, що зберігається в системній таблиці master.dbo.sysservers як продемонстровано тут:
Далі атакуючий може запросити інформацію з з'єднаного віддаленого сервера.
Якщо седіненние і віддалені сервери не сконфігуровані для доступу до даних (НЕ сконфігуровані для виконання довільних запитів, дозволено виконання тільки збережених процедур) атакуючий може спробувати:
Використовуючи цю техніку атакуючий може «стрибати» від одного сервера до іншого проникаючи глибше у внутрішню мережу через пов'язані і віддалені сервери:
Як тільки атакуючий отримав необхідний доступ до сполученого чи віддаленим сервером він або вона могла б завантажити файл на сервер, використовуючи методи згадувані раніше.
сканування портів
Після знаходження уразливого (web) додатки, атакуючий може використовувати наступний SQL запит:
Якщо порт відкритий, час відповіді може бути менше встановленого в параметрі timeout (залежить від програми використовує цей порт) і буде повернуто наступне повідомлення про помилку:
Інший можливий ефект такого сканера портів це DOS-атака. Розглянемо наступний приклад:
рекомендації
Головна рекомендація - переконатися в відсутність вразливостей SQL Injection. Це найбільш важлива рекомендація, тому що навіть якщо не вдасться виконати трюки, описані в цій статті, можливо, з'явиться інший спосіб використовувати уразливості. Для запобігання від SQL ін'єкцій рекомендується використовувати параметричні запити і фільтрувати введення користувача на наявність не букв і цифр.
Найбільш правильний метод - дотримуватися стандартів безпечного програмування при написанні додатків. Якщо код програми вже написаний, необхідно провести аудит для виявлення вразливостей. Так само рекомендується звернутися до деяких засобів автоматизації, які призначені для виявлення таких типів проблем.
Навіть якщо Ви відчуваєте, що закрили всі відомі уразливості, хорошим рішенням буде відключення невикористовуваних функціональних можливостей SQL сервера. Але тільки в тому випадку якщо ця функціональність дійсно вам не потрібна. На щастя, функції, які ми хочемо заблокувати використовуються не часто.
Ви повинні заборонити спеціальні запити через OLEDB від SQL сервера. Можливість здійснення цих запитів контролюються установкою значення DisallowAdhocAccess в системному реєстрі.
Якщо ви використовуєте примірник за замовчуванням, встановіть значення DisallowAdhocAccess = 1 в кожній подветкой ключа:
Виконайте наступні кроки, для того щоб встановити це значення:
Якщо ви параноїк, ви можете встановити ключі реєстру в режим тільки для читання, для того щоб їх не можна було редагувати.
Так само дуже важливим є накладення патчів усувають помилки в безпеці, необхідно робити це вчасно.
Остання обережність, налаштуйте і протестуйте брандмауер так, щоб він блокував весь зайвий вихідний трафік. Це допоможе не тільки зберегти базу даних, але і поліпшить безпеку мережі в цілому.
Те, що ми продемонстрували в цьому документі це невеликі можливості доступу, які можуть бути використані для отримання повного контролю над безліччю серверів. SQL це універсальна мова. Не один розсудлива людина не дозволить запускати довільний код Сі ++ або Visual Basic на сервері. Теж стосується SQL. Жодна розсудлива людина не дозволить сліпо виконати те, що ввів користувач. Цей документ показує чому це не повинно траплятися.
Microsoft SQL Server це потужний, гнучкий і доступний сервер баз даних є основою для безлічі додатків. Виходячи з цього факту, важливо розуміти, як SQL сервер може бути скомпрометований, і тим більше важливо розуміти, як цього можна уникнути. SQL сервер це інструмент і якщо його використовувати неправильно або недбало в результаті можна наразити на небезпеку не тільки дані, але і інші додатки в мережі. Це означає, що ми повинні серйозно підходити до забезпечення безпеки Microsoft SQL Server.
