Сьогодні, в День багів в WordPress 2, я оприлюднюю багато цікавих уразливостей в WP. Першими я оприлюдню Information Leakage та Full path disclosure уразливості в WordPress, що я знайшов 05.06.2007, під час проведення проекту MOSEB.
Information Leakage:
В плагіні WordPress Database Backup (WP-DB-Backup) можливий доступ до бекапів БД сайта на WordPress через вгадування повного шляху до них. Бекапи можуть створюватися вручну адміном, або автоматично. Для атаки потрібно, щоб бекапи зберігалися на сайті (хоча б деякий час). WP-DB-Backup - це популярний плагін (що постачався з WordPress 2.0.x), що лише з сайту wordpress.org був викачаний 546218 разів (за станом на сьогодні).
Уразливі WordPress 2.0.11 та попередню версії, в поставку яких входив плагін WordPress Database Backup, а також всі версії WordPress (2.9.2 та попередні версії), при використанні даного плагіна (офіційно він сумісний з WP 2.9.2 та попередніми версіями і потенційно може працювати з WP 3.0 та 3.0.1).
Повний шлях до файлу з бекапами наступний:
http://site/wp-content/backup-xxxxx/database_wp_20070605_704.sql.gz
Щоб дістатися до бекапу, потрібно виявити ім’я папки та ім’я файла. Причому їх виявляти можна окремо - спочатку виявити папку, а вже потім файл.
1. Ім’я папки (backup-xxxxx) - це “backup-” + 5 символів md5-алфавіту і це 1048576 комбінацій.
2. Ім’я файла - це ім’я бази сайта в MySQL (database) + “_” + префікс (wp) + “_” + дата створення бекапу в форматі YYYYMMDD (20070605) + “_” + число від 000 до 999 (704) + “.sql.gz”.
Ім’я бази може співпадати з доменом або папкою на сервері, де розміщений сайт (так часто роблять провайдери), тому для визначення імені бази можна використати Full path disclosure уразливість (яких велика кількість в WP).
Префікс за замовчуванням дорівнює “wp”. Якщо префікс нестандартний, то його можна дізнатися за допомогою інших уразливостей в WP, зокрема SQL DB Structure Extraction (про які я писав раніше).
Дане число від 000 до 999 - це Swatch Internet time і це 1000 комбінацій. Якщо знати точний час створення файлу бекапу, наприклад, при CSRF-атаці (про яку я ще розповім), то можна визначити дане число. Наприклад, якщо файл був створенний в 12:00:00 на сервері, то це число буде дорівнювати 500.
Так що в звичайному випадку, коли ім’я бази, префікс та дата відомі, доведеться зробити до 1048576 комбінацій (папка) + до 1000 комбінацій (файл) = до 1049576 комбінацій (повний шлях до файлу). В середньому це 524788 комбінацій, що можна достатньо швидко підібрати при швидкому Інтернет-з’єднані.
Захист від даної уразливості.
Для захисту треба зробити відповідний файл .htaccess. І розмістити, наприклад, в папці wp-content, для заборони викачування бекапів з папки з бекапами. Що я використовую відтоді як знайшов дану уразливість.
Це можна обійти за допомогою Arbitrary file deletion уразливості, про яку я писав в грудні 2007 року. Для її використання потрібно провести CSRF-атаку на адміна. Дана атака спрацює в WP-DB-Backup <= 2.0.
http://site/wp-admin/edit.php?page=wp-db-backup.php&backup=.htaccess
Якщо .htaccess розмістити в папці з бекапами, то він може бути видалений. Причому навіть з виправленою Directory Traversal - в папці з бекапами файли все рівно можна витерти. Тому .htaccess потрібно розміщувати не в папці с бекапами, а в папках вищого рівня, наприклад, в папці wp-content.
Враховуючи, що WordPress Database Backup плагін створює пусті index.php в папці з бекапами для захисту від витоку інформації про бекапи, то за допомогою Arbitrary file deletion уразливості (при CSRF-атаці на адміна) це можна обійти:
http://site/wp-admin/edit.php?page=wp-db-backup.php&backup=index.php
Тоді не доведеться вгадувати ім’я файла. Це спрацює на всіх версіях WordPress з даним плагіном (WP-DB-Backup <= 2.0).
А якщо Directory Traversal дірка не виправлена, то можна пришвидшити процес знаходження папки з бекапами (backup-xxxxx) за допомогою Arbitrary file deletion уразливості (при CSRF-атаці на адміна), та витерти index.php в папці wp-content:
Для WordPress <= 2.0.3 (WP-DB-Backup <= 1.7):
http://site/wp-admin/edit.php?page=wp-db-backup.php&backup=../index.php
Якщо бекапи створюються регулярно (щоденно), або напевно відома дата створення бекапа, то тоді можна легко його отримати. Інакше, можна вгадувати імена файлів бекапів. Або можна провести CSRF-атаку на адміна та створити бекап, про що я розповім в наступному записі.
Даний витік інформації в бекапі БД найбільш небезпечний в зв’язку з тим, що в бекапі знаходиться логін та хеш адміна. Що можуть бути використані для отримання доступу до сайта. Це було дуже актуально до виходу WordPress 2.5, в якому переробили систему авторизації, після того як Steven Murdoch звернув увагу розробників WP на Cookie Authentication уразливість в WordPress. І з версії 2.5 в WP використовується новий метод авторизації через кукіси, але навіть в нових версіях движка витік бекапів все рівно є небезпечним і його не варто допускати.
Full path disclosure:
В WP-DB-Backup мають місце дві Full path disclosure уразливості, які виникають при відповідних POST запитах. Вони працюють лише при наявності відповідних прав у користувача (зокрема у адміна).
WordPress Database Backup Full path disclosure.html
WordPress Database Backup Full path disclosure2.html
Дані уразливості працюють в плагіні WordPress Database Backup 2.0 та попередніх версіях в будь-яких версіях WordPress.
Захист від даних уразливостей.
Для захисту можна або самому виправити дані Full path disclosure уразливості (як й інші FPD в WordPress), або ж оновити плагін до останної версії WP-DB-Backup 2.2.2.
З WordPress 2.0.11 постачається версія 1.8 плагіна. Як я нещодавно перевірив, в версії 2.1 плагіна виправили Full path disclosure та інші уразливості. Тому остання версія плагіна WordPress Database Backup 2.2.2 невразлива до CSRF та до Full path disclosure (а також невразлива до раніше згаданих Directory Traversal, Arbitrary file deletion, DoS та XSS). Але остання версія плагіна все ще вразлива до Information Leakage.
