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

В своїй презентації 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. В подальшому виявлені логіни можуть бути використані для визначення паролів користувачів сайта.

Раніше я вже писав про небезпеки DoS атак на браузери. В даній статті я зосереджу увагу на DoS атаках через споживання ресурсів.

Згідно з класифікацією DoS уразливостей в браузерах існує три види Denial of Service уразливостей в браузерах: Вибиваючі DoS, Блокуючі DoS і DoS через споживання ресурсів.

DoS через споживання ресурсів (resources consumption DoS) бувають двох типів:

• Споживання ресурсів CPU (CPU overload).
• Споживання ресурсів RAM (memory consumption).

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

Особливості CPU overload DoS атак:

1. Іноді бувають разом з підвисанням браузера, але частіше без підвисання.

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

3. При наявності декількох вкладок користувач не зможе визначити, яка з них приводить до приторможень (зможе лише в рідких випадках), за винятком браузера Chrome, де є вбудований Task Manager. Тому користувач може закрити всі чи багато вкладок, щоб вирішити проблему завантаження CPU.

4. Недосвідчені користувачі, у тому числі користувачі Chrome (які не знають про Task Manager) можуть зовсім закрити браузер, щоб вирішити проблему завантаження CPU.

5. Більш досвідчені користувачі, що помітять приторможення ПК, можуть запустити Task Manager ОС і побачити, що браузер завантажує CPU, і якщо не захочуть чи не зможуть розібратися який сайт винуватий, можуть закрити весь браузер.

6. Що у випадку табів, що у випадку окремих вікон - ситуація однакова. При наявності більш одного вікна чи таба в більшості випадків важко визначити причину підвисання. Що призведе до закриття усіх вікон чи табів, або всього браузера.

7. У результаті буде дискомфорт (і можлива втрата даних користувача), як і при перших двох видах DoS атак.

8. Даний вид DoS атак дуже підходить для проведення Reverse DDoS атак.

Розповім вам історію про дірку, що може врятувати світ. Ця історія відноситься до жанру хайтек фантастики, як я назвав цей жанр. Хайтек фантастика (hi-tech fiction) - це різновид фантастики, де йдеться про передові технології та ІТ, а також є частка фантастики. Дана історія базується на реальних подіях.

Спочатку про один факт, на якому базується дана історія.

Це XSS уразливість яку я вчора виявив на sourceforge.net на високопіарістій сторінці (PR9). Подібна дірка - це мрія для SEO-шника і я перетворив цю мрію на реальність.

Та сама уразливість: Save the world.

А ось й історія про дірку, що може врятувати світ.

XSS дірка на sourceforge.net може бути використана для html включень. Зокрема для розміщення лінок, як я показав вище. А її PR9 може зробити багатьох людей щасливими. Навіть більше, в наш час коли існує чимало фінансових проблем в світі в зв’язку з фінансовим і економічним кризисом, ця дірка може принести додаткові доходи багатьом людям. Що дуже важливо в наш час, коли багатьох людей звільняють і зростає безробіття.

Знаєте ви чи ні, що зі сторінками з високим PR ви можете заробити кошти. Чим більший PR тим краще. А PR9 є доволі великим значенням і тому він може принести доходи (безпосередньо чи опосередковано). Лише уявіть собі світ без кризису, світ миру і щастя. Щоб досягнути цього нам потрібно лише дві речі: 1. Google повинен підтримувати лінки від XSS (а не як він ігнорує їх зараз), всі чи тільки на sourceforge.net. 2. Адміни sourceforge.net повинні не фіксити дірку (як мінімум доки кризис не мине). Таким чином одна маленька XSS дірка може врятувати світ.

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

В своїй презентації The Web Is Broken, Bipin Upadhyay розповідає про сучасний стан веба. Про стан безпеки в Інтернеті, поширені уразливості на веб сайтах і атаки на них, та методи захисту сайтів.

This is English version of my Classification of SQL Injection vulnerabilities article.

SQL Injection are serious vulnerabilities, which are widespread in modern web applications. And they can lead to full compromise of web sites.

There are next types of SQL Injection vulnerabilities:

1. Reflected SQL Injection.
2. Persistent SQL Injection.

Reflected SQL Injection - these are regular SQL Injections, which often happen in web applications which are working with DB. To make an attack in case of this type of SQL Injection, it’s needed to send request to vulnerable web application, which contains SQL commands for execution. For new execution of commands it’s needed to send new request.

Example of request (for retrieving information from DB):

http://site/script?id=-1+or+1=1

Example of request (for conducting DoS attack):

http://site/script?id=1+and+benchmark(10000000,benchmark(10000000,md5(now())))

Persistent SQL Injection, which I wrote about earlier - this is new type of SQL Injection, which I found in December 2008. This type of SQL Injection less widespread than reflected, but also happens in web applications. To make an attack in case of this type of SQL Injection, it’s needed to send to vulnerable web application a request with SQL commands for execution, which will save in DB. After that they will be taken from DB and executed (i.e. not right away during request, but during work process of web application).

It’s needed to send just one request, after that SQL commands will be executed all the time (while they will be in DB) during work process of the system. Such SQL Injections are convenient to use for conducting attacks, when constant execution of some code is needed, e.g. for DoS attacks.

Example of request (for conducting DoS attack):

http://site/script?param=1+and+benchmark(10000000,benchmark(10000000,md5(now())))

P.S.

In 2010 I’ve published the article Encoded SQL Injection vulnerabilities, in which I’ve discribed new, the third, class of SQL Injection vulnerabilities, which I’ve found in 2009.