Современные информационные технологии /4. Информационная безопасность

Шмир М. А.

Національний авіаційний університет, Україна

Аналіз NoSQL ін’єкцій на прикладі MongoDB

Завдяки новим вимогам сучасних великомасштабних компаній, таких як: Facebook, Google, Amazon та Twitter, виникла необхідність розподілити дані по величезній кількості серверів. Традиційні реляційні бази даних (БД) не відповідають таким потребам масштабованості; оскільки потребують одного вузла для виконання всіх операцій транзакції. Завдяки цьому фактору набули широкого розповсюдження нереляційні(NoSQL) БД. Однією з найпоширеніших NoSQL БД є MongoDB, що є 4-ю з 10-и найбільш популярних БД.

Напрямки NoSQL атак

Web-додатки і сервіси зазвичай використовують NoSQL БД для зберігання даних про клієнтів. Рисунок 1 показує типову архітектуру web-додатків, в яких NoSQL БД використовуються для зберігання даних. Доступ до бази даних здійснюється через драйвер - протоколу доступу, який на декількох мовах програмування надає бібліотеки для доступу клієнтів до БД. Хоча драйвери самі по собі не можуть бути вразливими, іноді вони надають незахищені прикладні інтерфейси програмуванні(API), які, при неправильному використанні розробником програми, можуть додати уразливості додаткові, яке дозволяє довільні операції над базою даних. Як показано на рисунку 1, зловмисники можуть вставити запит з ін'єкцією, що, при обробці дозволить потрібну неприпустиму операцію над БД.

Рис. 1. «Архітектура web-додатків»

Основні механізми NoSQL атак можуть бути розподілені на 5 класів:

Тавтології. Ці атаки дозволяють обійти механізми аутентифікації або інші механізми доступу шляхом введення коду в умовні оператори, породжуючи вираження, які завжди є істиною(тавтології).

Операція об'єднання (Union). Запит Union є добре відомим методом SQL ін'єкції, в яких зловмисники використовують вразливий параметр, щоб змінити набір даних, що повертаються для даного запиту. Найбільш поширені види використання операції об‘єднання повинні обходити аутентифікації та отримувати дані.

JavaScript ін'єкції. Цей новий клас вразливостей, представлений в NoSQL, дозволяє виконання JavaScript в межах бази даних. JavaScript дозволяє складні операції і запити до ядра бази даних. Виконання такої вставки призводить до неконтрольованого доступу та модифікації даних.

Запити виду «Piggybacked». У цих запитах, зловмисники використовують припущення щодо використання спеціальних символів, щоб вставити додаткові запити, які повинні виконатись в базі даних, що може привести до виконання довільного коду з боку нападника.

Запити виду «Origin violation». HTTP REST API, є популярним модулем в NoSQL БД. На жадь, вони вводять новий клас вразливостей, який дозволяє зловмисникам отримати доступ до БД з іншого домену. При таких атаках зловмисники використовують справжніх користувачів і їх web-браузери, щоб виконати будь-яку дію.

Ін‘єкції-тавтології

Давайте розглянемо архітектуру, зображену на рисунку 1, де web -додаток реалізується використовуючи PHP, який використовує запити в форматі JSON для доступу до БД. На прикладі MongoDB симулюємо вразливість масиву даних до ін‘єкцій, що є аналогічною SQL ін'єкції.

PHP кодує масиви даних у форматі JSON за допомогою вбудованих механізмів, що дозволяють зловмисникові послати наступний зловмисний код: username[$ne]=1&password[$ne]=1. Цей код вноситься в базу даних механізмами MongoDB: db.logins.find({ username: {$ne:1 }, password {$ne: 1 })

Оскільки «$ne» в MongoDB означає не рівність певній умові. Формується запит, в якому всі записи в колекції з логінами, для яких ім'я користувача не дорівнює 1, та паролями, що не дорівнюють 1, повертаються базою.

SELECT * FROM logins WHERE username <> 1 AND password <> 1

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

Ін‘єкції з використанням операція об'єднання (Union)

SQL вразливості до ін‘єкцій є результатом того, що запити формуються з тексту, що вводить користувач, який не кодується. Структура запитів JSON робить атаки важчими в сучасних сховищах даних, так як MongoDB. Проте це все-таки можливо.

Розглянемо форму авторизації, що надсилає ім‘я користувача та пароль за допомогою POST методу HTTP на сервер, який формує запит використовуючи конкатенацію. Приклад запиту: string query = “{ username: ‘” + post_username + “’, password:‘” + post_passport + ‘ “ }”

Але зі шкідливою вставкою, цей запит може ігнорувати пароль і ввійти в обліковий запис користувача без пароля: { username: ‘tolkien’, $or: [{}, {‘a’: ‘a’, password ‘’}], $comment: ‘successful MongoDB injection’}

Пароль стає невід‘ємною частиною запиту, так як порожній запит {} завжди вірний, і кінцевий коментар не впливає на запит. Ця атака буде успішною в будь-якому випадку, якщо ім'я користувача правильне.

JavaScript ін'єкції

Особливість NoSQL - можливість запуску JavaScript-коду в ядрі бази даних для виконання складних запитів або транзакцій. Популярні бази даних, що виконують JavaScript: MongoDB, CouchDB, Cloudant і BigCouch.

Виконання JavaScript відкриває нові можливості для атаки зловмисника. Наприклад, розглянемо складну операцію, яка вимагає коду JavaScript і включає введення даних користувачем, в якості параметра в запиті. Візьмемо модель даних магазину, який має колекцію товарів,де кожен елемент має свою ціну і кількість. Для того, щоб отримати суму або середнє значення цих полів, розробник пише функцію MapReduce, яка отримує ім'я поля, яке має використовувати (кількість або ціну) в якості параметра користувача. У PHP, такий код може виглядати наступним чином (де $param вводить користувач):

$map = “function(){for (var i=0; i < this.items.length; i++){ emit(this.name, this.items[i].$param);} }”; $reduce = “function(name, sum) {return Array.sum(sum); }”;$opt=“{out:‘totals’}”;$db->execute(“db.stores.mapReduce($map,$reduce,opt);”);

Запит сумує поле, яке визначається по $param для кожного елемента за іменем. $param очікує отримати або суму або ціну, щоб виконати запит. Замість вхідних даних, оператору можна передати довільний JavaScript-код, що виконається в базі.

Ця ін'єкція дуже схожа на класичні ін'єкції SQL. Захист від такої атаки спрямовується на відмову від використання та виконання JavaScript в конфігурації бази даних.

Запити виду «Piggybacked»

Набір операцій додають ключ і його відповідне значення в БД. Після запуску РНР драйвера, він отримує два параметри: $memcached->set(‘key’, ‘value’);

Дослідження показали, що драйвер не може відфільтрувати ASCII символи і повертає «\r(0x0D)» та «\n(0x0A)», що створює можливість для вставки нового рядка в ключовий параметр, що врезультаті додасть шкідливу команду в кеш.

Розглянемо наступний код, в якому $param вводиться користувачем і використовується в якості ключа: $memcached=new Memcached(); $memcached ->addServer(‘localhost’,11211); $memcached->set($param, “some value”);

Зловмисники можуть вставити наступні дані, що призведе до ін'єкції: “key1 0 3600 4\r\nabcd\r\nset key2 0 3600 4\r\ninject\r\n”. У цьому прикладі перший ключ(key1) додається до БД з певним значенням. Зловмисники можуть додати ще один ключ(key2), вставивши у нього ін‘єкцію. Можна використати такі операції incr <Key> <Amount> - збільшити ключ, decr <Key> <Amount> - зменшити ключ, delete <Key> - видалити ключ. Зловмисники також можуть використовувати ці три функції з їх параметрами замість ключа(key2). Те ж можна виконати для множинних записів: deleteMulti, getMulti і setMulti, де ін'єкції відбуться в одному з ключових полів.

Ця вразливість драйвера була виправлена тільки PHP 5.5, але, на жаль, існує в усіх попередніх версіях. Більш ніж 86% PHP-сайтів використовують версію старше 5.5, тобто решта вразливі до ін'єкцій.

Запити виду «Origin violation»

Ще одна спільна риса NoSQL БД - вони часто мають відкритий HTTP REST API, який дозволяє виконувати запити до бази даних з клієнтських додатків. Відомі БД з відкритим REST API: MongoDB, CouchDB і HBase. Відкритий REST API призводить до незахищеності бази даних проти ін‘єкцій.

Поки БД знаходиться в захищеній мережі за допомогою мережних фільтрів, зловмисникам потрібно знайти уязвимість в мережі чи виконати ін‘єкцію, що в подальшому дасть змогу виконувати різні запити. Коли БД надає в користування REST API всередині захищеної мережі, будь-хто отримає доступ до захищеної мережі і зможе виконувати запити до БД використовуючи тільки HTTP, тобто запити будуть надходити з web-браузера. Якщо зловмисник зможе підставити HTML-форму на web-сайт чи переманити користувача на власний сайт, вони зможуть виконати будь-який POST-запит у БД після заповнення HTML-форми. POST-запити включають додавання документів.

Як приклад використаємо додаток «Sleepy Mongoose» - повнофункціональний HTTP інтерфейс для MongoDB. АРІ додатку знаходиться за URL-адресою http:// {ім‘я хоста}/{ім‘я БД}/{ім‘я колекції}/{дія}. Параметри для пошуку документа можуть бути включені в якості параметрів запиту, а також нові документи можуть бути додані в якості даних запиту. Наприклад, якщо ми хочемо додати новий документ { username: 'attacker' }до колекції ‘admins’ в БД під назвою ‘hr’ на хост ‘safe.internal.db’, то потрібно надіслати POST-запит http://safe.internal.db/hr/admins/_insert з параметрами ‘username=attacker’.

Використаємо цю функцію для проведення атаки, яка додає новий документ в колекцію ‘admins’, таким чином з‘явиться новий адміністратор в базі даних ‘hr’, який знаходиться в нібито безпечній внутрішній мережі. Для успішної атаки зловмисники повинні мати контроль над web-сайтом та розмістити на ньому HTML-форму, що буде включати JavaScript ін‘єкцію, яка буде автоматично надсилати форму.

<form action=” http://safe.internal. db/hr/admins/_insert” method=”POST” name=”csrf”> <input type=”text” name=”docs” value=” [{"username":attacker}]” /> </form> <script> document.forms[0].submit(); </script>

Використовуючи фішинг, зловмисникам потрібно обдурити користувачів за відвідати сайт чи вставити ін‘єкцію у звичний для них сайт. Також користувачі мають мати права доступу до інтерфейсу «Sleepy Mongoose».

Таким чином, використовуючи права користувачів, зловмисники зможуть атакувати БД, що знаходиться в захищеній мережі. Це доволі простий метод ін‘єкцій, але він потребу певних приготувань: визначення імен хоста, бази даних, і так далі.

Висновок

NoSQL БД страждають від одних і тих же ж небезпек , як і SQL БД. Не зважаючи на те, що деякі методи низького рівня і протоколи змінилися, ризик ін'єкції, неправильного управління контролем доступу і небезпечного впливу мережі залишається високим.

Найбільш розповсюдженими є такі 5 класів атак:

1) Тавтології.

2) Операція об'єднання (Union).

3) JavaScript ін'єкції.

4) Запити виду «Piggybacked».

5) Запити виду «Origin violation».

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

Література:

1. Lane A. No SQL and No Security,‖ blog [Електронний ресурс] / Lane. – 2011. – Режим доступу до ресурсу: www.securosis.com/blog/nosql-and-no-security.

2. L. Okman et al. ―Security Issues in NoSQL Databases,‖ Proc. IEEE 10th Int‘l Conf. Trust, Security and Privacy in Computing and Communications (TrustCom), 2011, pp. 541–547. 5.

3. MongoDB Secutiry Guide release 3.0.7 / [MongoDB Inc.] – 24.11.2015–136 p.

4. Dynamo: Amazon‘s Highly Available Key-Value Store,‖ in Proceedings of the 21st ACM Symposium on Operating Systems Principles / Decandia, Hastorun, Jampani та ін.]. // Stevenson. – 2007.