Websecurity - Веб безпека

Нерідко Abuse of Functionality уразливості можуть призводти до появи Denial of Service уразливостей на веб сайтах. Що дозволить проводити DoS атаки на дані сайти.

Одним з прикладів DoS через Abuse of Functionality є уразливість в Power Phlogger. Серед скриптів даного веб додатку, що з ним постачаються, є скрипт extchange.php. При прямому запиті до даного скрипта, він змінює розширення php файлів системи на php3. І враховуючи, що в лінках на скрипти використовується розширення php, система перестає нормально працювати, що призводить до DoS атаки.

Іншим цікавим прикладом DoS через Abuse of Functionality, є використання ресурсів одних сайтів для проведення DoS атак на інші сайти. Дану уразливість я виявив на regex.info та www.slideshare.net.

На даних сайтах є сервіси, які звертаються до інших сайтів для віддаленого викачення файлів. На regex.info це скрипт, що викачує файл для аналіза exif інформації, а на www.slideshare.net це аплоадер. Причому на обох сайтах дані сервіси також вразливі до Insufficient Anti-automation атак.

Проведення DoS атаки можливе у випадку, якщо вказати на великий файл (big_file) для скачування. При викачуванні великого файлу сервер перенавантажиться, особливо якщо запустити на викачку декілька великих файлів (через Insufficient Anti-automation уразливість). Що призведе до DoS атаки на такий сервіс.

DoS через Abuse of Functionality:

http://regex.info/exif.cgi?url=http://site/big_file

http://www.slideshare.net/main/bulkweb?fromsource=webupload&url=http://site/big_file&title=test&dwnld_chk=on

Також цікаве й те, що таким чином можна проводити двонаправлені DoS атаки (bidirectional DoS attacks). Якщо задати викачку таким сервісом декількох великих файлів з одного сайта (це може бути один і той же файл, запущений для паралельної викачки), то це перенавантажить обидва сервери.

В своїй презентації CSRF: The Biggest Little Vulnerability on the Web, Shreeraj Shah розповідає про Cross-Site Request Forgery. Про те, що CSRF уразливості дуже поширені в Інтернеті й є достатньо небезпечними.

Розповім вам про використання сервісів редирекції з перспектив безпеки, про що я планував розповісти ще з квітня 2007, коли вперше стикнувся з даним підходом. І з тих пір неодноразово його використовував.

Сервіси редирекції дозволяють створювати нові адреси (URL) для вже існуючих адрес. Що дозволяє використовувати їх для обходу фільтрів.

Сервіси редирекції (такі як TinyURL) можна використовувати для:

1. Розміщення лінки на сайті, де фільтрується потрібна вам адреса. У випадку якщо почнуть фільтрувати й адреси сервісу редирекції, то можна використати інший сервіс.

2. Обходу фільтрації на адресу сайта при проведенні XSS атак. Даний підхід я багато разів використовував, зокрема у випадку уразливості на cool.a.ua.

3. Обходу обмежень на довжину рядка при проведенні XSS атак. Даний підхід я неодноразово використовував, зокрема у випадку уразливості на realmusic.ru.

Розглянемо на прикладі сервіса http://tinyurl.com.

Адреса http://websecurity.com.ua/webtools/xss_r.js стає http://tinyurl.com/2snoo7. Що дозволяє використовувати даний редиректор при наявності фільтрів на сайті. У випадку, якщо на сайті є фільтрація на адреси з домену websecurity.com.ua, то використання адреси з домену tinyurl.com дозволить обійти фільтр. У випадку, якщо на сайті є обмеження на довжину рядка, то використання редиректору (що має 25 символів, тоді як оригінальна адреса 43 символи) дозволить його обійти.

Для подібних задач можна використовувати як tinyurl.com, так і elfurl.com, hugeurl.com, shurl.net та інші сервіси редирекції. Зазначу, що на відміну від інших сервісів, hugeurl.com створює не короткі, а довгі адреси (що тим не менш дозволяє використовувати його для задач 1 і 2).

Як ви можете побачити, сервіси редирекції не тільки зручні для звичайних користувачів, але й можуть використовуватися для секюріті задач.

Продовжуючи розпочату традицію, після попереднього відео про експлуатацію MS-SQL, пропоную новий відео секюріті мануал. Цього разу відео про атаку на Windows через ActiveX уразливість. Рекомендую подивитися всім хто цікавиться цією темою.

Attack on Windows Systems based on the ActiveX Vulnerability

В даному відео ролику демонструється проведення атаки на Windows через ActiveX уразливість (через Internet Explorer). В результаті відвідання в IE сайту з експлоітом, на комп’ютері (в корні диска C) з’являється новий файл, що може бути шкідливим додатком. Рекомендую подивитися дане відео для розуміння векторів атаки через ActiveX уразливості та небезпеки подібних уразливостей.

В своїй презентації Automated Web Foo or FUD, David Kierznowski розповідає про хакінг з використанням Firefox Technika penetration testing framework від GNUCITIZEN.

При проведенні Directory Traversal атак, використовуються слеші (slash). Це також відноситься до атак з використанням Local File Include і SSI Injection уразливостей.

http://site/script?file=../secret.data

Атаки з використанням слеша працюють на будь-яких операційних системах (Windows, Linux, Unix). Про Directory Traversal та інші уразливості, де використовуються сиволи обходу директорій, веб розробники переважно обізнані, тому й часто фільтрують дані символи в своїх додатках.

Але як я продемонстрував в 2007 році на прикладі Local file include та Directory traversal уразливостей в WordPress, існує можливість проведення даних атак навіть при наявності захисту від них. Для цього потрібно використати зворотній слеш (back slash).

При використанні зворотнього слеша атака може бути проведена лише на ОС Windows. І за допомогою зворотнього слеша можна проводити всі атаки, де використовуються символи обходу директорій - Directory Traversal, Local File Include і SSI Injection.

http://site/script?file=..\secret.data

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

Продовжуючи розпочату традицію, після попереднього відео про Blind SQL Injection в MySQL, пропоную новий відео секюріті мануал. Цього разу відео про експлуатацію MS-SQL. Рекомендую подивитися всім хто цікавиться цією темою.

MS-SQL Exploitation Video

В даному відео ролику демонструється експлутація Microsoft SQL Server. Спочатку за допомогою nmap знаходяться машини з MS-SQL серверами, потім визначається версія сервера і через уразливість в ньому отримуються права адміна. Після чого в ОС на даному комп’ютері створюється новий адмінський акаунт. Рекомендую подивитися дане відео для розуміння векторів атаки через уразливості в MS-SQL та небезпеки подібних уразливостей.

В січні 2008 року Tavis Ormandy в своєму повідомленні в Bugtraq розповів про новий вид атак. Що він відніс до нового типу XSS уразливостей - Same Site Scripting. Дана атака можлива через некоректну конфігурацію DNS. І подібна некоректна конфігурація має місце на багатьох серверах, що призводить до можливості Same Site Scripting атак.

common dns misconfiguration can lead to “same site” scripting

Автор наводить три варіанти використання даної уразливості:

1. Атака на інших користувачів в shared UNIX системах.

2. Атака на локальний веб сервер користувача (що розміщений на його комп’ютері, або на тому, через який він має доступ до Мережі). Зокрема, атака може проводитися через XSS та інші уразливості, наявні на даних веб серверах. Про подібні атаки я вже розповідав в своїй статті Використання уразливостей на локальних машинах.

3. Атака через CUPS, що встановлений на комп’ютері користувача (а CUPS встановлений на більшості Unix, Linux і Mac OS систем).

Дана уразливість має місце на багатьох серверах, зокрема на fbi.gov, citibank.com і cisco.com.

В своїй статті Пекло редиректорів (Redirectors’ hell) я розповів про можливість створення нескінченної редирекції, для проведення DoS атаки. В статті я зосередив увагу на проведенні даної атаки між двома сервісами редирекції.

Але атака Пекло редиректорів може бути проведена не тільки між двома сервісами редирекції, а між сервісом редирекції (зокрема tinyurl.com) і будь-яким сайтом, що має відкритий редиректор. Що призведе до Зацикленого DoS.

Для демонстрації я використав сервіс tinyurl.com та один з редиректорів bigmir.net.

DoS (Looped DoS):

Атака двунаправлена: tinyurl.com <-> passport.bigmir.net. Вона навантажує обидва сайти.

http://tinyurl.com/hellfire-url
http://passport.bigmir.net/logout?url=http://tinyurl.com/hellfire-url

Таким чином будь-який редиректор на будь-якому сайті може бути використаний для проведення Looped DoS атаки.

Існують різні клієнти: Mozilla автоматично зупиняє зациклений редирект (видає Redirect Loop Error), а IE - не зупиняє. Якщо клієнт, що звертається до даних сайтів, сам не зупинить редирект, наприклад бот пошукових систем, то це спричинить велике навантаження на сервери.

Зазначу, що обмеження Mozilla спрацює лише для редиректорів, що видають відповідні серверні заголовки (Location або Refresh). Якщо ж редиректор використовує теги для перенаправлення (meta-refresh або JS), то це обмеження браузера не спрацює.

За останні декілька років я багато разів зтикався з функцією деяких сайтів (передусім поштових сервісів і крупних проектів), яка дозволяє перевіряти чи вільний даний логін. Щоб користувач міг створити унікальний логін при реєестрації на сайті. І ось у березні 2008 року, як я розробив свою програму Brute force login identifier (для виявлення логінів, з чим мені доводиться зтикатися під час секюріті аудиту), я вирішив провести детальне дослідження функції перевірки логінів.

Дана функція дозволяє нападнику виявляти робочі логіни в системі (login enumeration). Тобто наявність даної функції на сайті призводить до появи Abuse of Functionality уразливості. Приклади подібних уразливостей я наводив зокрема на hulu.com та на www.youtube.com.

Розглянемо алгоритм виявлення логіна на YouTube.

Якщо ввести в формі реєстрації (http://www.youtube.com/signup) в полі Username перевіряємий логін і натиснути Check Availability, система зробить перевірку і надасть відповідь (ця функція реалізована на AJAX). Якщо відповідь “Username unavailable” - значит такий логін існує в системі, якщо відповідь “Username available!” - значить такого логіна немає в системі.

Тобто потрібно буде перевірити перелік логінів за допомогою функції Check Availability й відібрати ті з них, для яких відповідь буде “Username unavailable”. І створити список робочих логінів.

У випадку якщо дана функція немає захисту від автоматизованих атак (тобто має місце Insufficient Anti-automation уразливість), як це є у більшості випадків, це дозволяє проводити автоматизоване виявлення логінів в системі. Що може бути зроблено за допомогою брутфорсерів логінів, наприклад, моєї програми Brute force login identifier. В подальшому виявлені логіни можуть бути використані для визначення паролів користувачів сайта.