Уразливість Drupal чи некомпетентність програмістів?

18.02.2015
Drupal vulnerability or developers' carelessness?
Автор:

В жовтні 2014-го року компанія Sektion Eins виявила уразливість, якій піддаються всі версії 7 гілки Drupal. Вона дозволяє виконати довільний SQL-запит в БД, не маючи ніяких прав в системі. Рівень небезпеки визначено як найвищий. 15 жовтня вийшло оновлення ядра до версії 7.32, яке усуває цю вразливість. Але сьогодні ми поговоримо про іншого роду “вразливості”.

Уразливість, знайдена компанією Sektion Eins, була у функції обробки значень для SQL-запиту. При обробці масиву для SQL-функції IN передбачається, що це не асоціативний масив, ключі беруть участь у формуванні імені placeholder-а. Якщо в функцію передати асоціативний масив із спеціально сформованими ключами, то можна втрутитися в SQL-запит і змінити пароль для суперадміна системи (користувача Drupal з ID = 1), або переробити паролі під будь-якого користувача і систему…

Для користувачів питання безпеки стоїть на першому місці. І тому багато сайтів у мережі працюють на Drupal, адже це одна з найбільш захищених CMS: багато іменитих компаній і важливих урядових організацій використовують Drupal для своїх сайтів. А тому ми поговоримо про інші проблеми безпеки.

Займаючись тестуванням сайтів у InternetDevels, ми намагаємося знайти якомога більшу кількість “багів” (помилок), які впливатимуть на сприйняття сайту користувачем (наприклад, проблеми з версткою), чи впливатимуть на роботу із сайтом в цілому (проблеми функціоналу). На досліджуваних нами сайтах ми шукали “дірки в коді”, за допомогою яких можна було б нашкодити сайту: шукали сторінки, відкриті для анонімного користувача… І таки знаходили. Це, звичайно, серйозна помилка програмістів, але не критична.

А як на рахунок інших сайтів на Друпалі? Сайтів тисячі і подібних відкритих сторінок мабуть також. А якщо…? Ні, такого не може бути! Хоча… А що, якщо є сторінки, відкриті для доступу анонімних користувачів з можливістю редагування? І не просто редагування, а з можливістю вносити серйозні зміни, наприклад, вводити PHP-код. Нагадуємо, що сторінки редагування нод в Друпалі мають вигляд виду site.com/node/id/edit, де id — це числовий ідентифікатор ноди.

Алгоритм нашого пошуку:

  • URL (адреса) сторінки повинен містити “node” і “edit”;
  • Hа сторінці в тексті повинна згадуватися фраза «Вы можете размещать PHP-код» (для російської) або «You may post PHP code» (для англійської) (мова може бути будь-яка з доступних на drupal.org).

Вводимо в стрічку пошуку: inurl:node inurl:edit "Вы можете размещать PHP-код", натискаємо “Enter”.

Або вводимо: inurl:node inurl:edit "You may post PHP code", натискаємо “Enter”

Як бачимо, для російської мови виводить декілька сторінок із живих сайтів, які вже були “поламані” раніше. Для Англійської — кілька десятків сторінок (які теж були поламані, але не так давно і виключно в наукових цілях).

То що ми маємо? Сторінку на сайті, відкриту для індексації пошукових систем і з можливістю введення PHP-коду. Чому не закрили сторінку для індексації для пошукових ботів, можна здогадатися, але чому є можливість вводу PHP коду для незареєстрованих юзерів, відверто не зрозуміло... Нагадаємо. В Drupal є спеціальний модуль для вставлення коду на сторінку, наприклад Code Filter. При розробці сайту необхідно встановлювати обмеження для даного типу вводу: лише суперадмін повинен мати таку можливість. Але пошук показав, що в мережі є сайти, над якими працювали “недобросовісні” програмісти. Що ж робити? Все дуже просто, заходимо на такі сторінки, вибираємо формат вводу PHP код і вводимо наприклад:

<?php db_query("drop table {system}");?>

Зберігаємо зміни і вуаля...ми “вбили” таблицю System. Вона ключова, без неї сайт не буде працювати. Якщо у розробників не було бекапу, це дуже сумно (для них звісно ж). Основна задача зловмисників — підключитися до бази даних і внести якісь зміни: створити нового користувача із наданням йому прав адміна, або виведення паролів для користувачів і т.п.

Неуважність або безвідповідальність програмістів може дуже нашкодити вашому сайту. Зауважимо, що навіть якщо нода відкрита для редагування, індексується пошуковиком, але не має можливості вводити PHP, то це також небезпечно. Адже є ще формат вводу тексту “Full HTML”, користуючись яким можна вводити теги типу:

<script>

var iframe = window.getElementsByTagName( "iframe" )[ 0 ];

alert( "Frame title: " + iframe.contentWindow.title );

</script>

<iframe src="http://www.fsb.ru" width="600" height="1000">

<p>Your browser does not support iframes.</p>

</iframe>

Результат не змусить себе чекати

Але зловмисникам можна легко зашкодити:

1) Забороняємо використовувати PHP-код всім, крім Адміна;

2) Закриваємо доступ до всіх сторінок. Навіть якщо є можливість редагування, забираємо всі формати тексту, крім “Plain text” i “Filtered HTML”, або створюємо власний формат із певним набором тегів, наприклад:

<a> <p> <span> <div> <h1> <h2> <h3> <h4> <h5> <h6> <img> <map> <area> <hr> <br>  <ul> <ol> <li> <dl> <dt> <dd> <table> <tr><td> <em> <b> <u> <i> <strong> <del> <ins> <sub> <sup> <quote> <blockquote> <pre> <address> <code> <cite> <param> <strike> <caption> <tbody>;

3) Дозволяємо доступ пошуковим роботам лише на основні сторінки ресурсу.

Коротше, попередити всі можливі проблеми такого типу можна, зробивши одну річ: при розробці сайтів ніколи не слід забувати про безпеку. Адже якщо самостійно відкривати для зловмисників усі можливості для їхньої діяльності, то навіщо тоді писати код взагалі? Пишіть грамотний код і буде вам спокій.

P. S. На всіх “поламаних” сторінках на англомовних ресурсах було вилучено можливість вводити PHP-код, таблицю “system” поремонтували (хоча індексація відкритих для редагування сторінок пошуковиками не припинилася). Російськомовні ресурси, на жаль “ушли в закат”...

В багтрекері Drupal інформація про уразливість з'явилася більш 11 місяців тому, але до Security team інформація не дійшла. І тепер розробникам доведеться роз'яснювати, чому так вийшло і що вони зробили для того, щоб зменшити ймовірність повторення такої ситуації. А якщо врахувати що на Drupal працює 1,1 млн сайтів у всьому світі, та понад 932 тис. з них використовують версію 7.х., то є велика імовірність, що ще не всі встигли оновили ядро...

 

Голосів: 1 Рейтинг: 5

Також по темі

1

Модуль Migrate дозволяє імпортувати вміст сайту в Drupal із інших джерел. Читайте в нашому блозі, як встановити та налаштувати цей інструмент для коректної роботи.

2

Бути членом Drupal спільноти дуже відповідально. Саме тому компанія InternetDevels організувала 3-місячний код-спринт присвячений вдосконаленню CMF. Результати багатообіцяючі....

3

Іноді власники сайтів стикаються з різними проблемами, пов'язаними з їх Drupal-проектами. Тому ми запустили сервіс, який пропонує швидку технічну підтримку вашого сайту.

4

На даний час сервіси з готовими html-темами набирають стають дедалі популярнішими. Однак, чи так вже легко верстати на їх основі Drupal-сайти?...

5

Часто на адресу Drupal можна побачити заяву в стилі: «На цьому фреймворці не створити high-load веб-сайту». Ми спростуємо цей міф не...

Subscribe to our blog updates