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

Раніше я вже писав про небезпеки 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.

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

SQL Injection уразливості бувають наступних типів:

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

Reflected SQL Injection - це звичайні SQL ін’єкції, що часто зустрічаються у веб додатках які працюють з БД. Для проведення атаки у випадку даного типу SQL ін’єкцій, потрібно відправити запит до вразливого веб додатку, що містить SQL команди для виконання. Для нового виконання команд потрібно посилати новий запит.

Приклад запиту (для виведення інформації з БД):

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

Приклад запиту (для проведення DoS атаки):

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

Persistent SQL Injection, про які я писав раніше - це новий тип SQL ін’єкції, що я виявив в грудні 2008 року. Даний тип SQL ін’єкцій менш поширений ніж reflected, але також трапляється в веб додатках. Для проведення атаки у випадку даного типу SQL ін’єкцій, потрібно відправити до вразливого веб додатку запит з SQL командами для виконання, які зберіжуться в БД. Після чого вони будуть взяті з БД і виконані (тобто не одразу при запиті, а в процесі роботи веб додатку).

Відправити потрібно лише один запит, після чого SQL команди будуть весь час виконуватися (доки вони будуть в БД) в процесі роботи системи. Подібні SQL ін’єкції зручно використовувати для проведення атак, де потрібне постійне виконання деякого коду, наприклад, для DoS атак.

Приклад запиту (для проведення DoS атаки):

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

P.S.

В 2010 році я опублікував статтю Encoded SQL Injection уразливості, в якій описав новий, третій, клас SQL Injection уразливостей, що я виявив в 2009 році.

Окрім звичайних SQL ін’єкцій, які ви могли неодноразово зустрічати в багатьох веб додатках, які я назову Reflected SQL Injection, є також інший тип даного класу уразливостей, який я назвав Persistent SQL Injection. Назви цим двом типам SQL ін’єкцій я вибрав враховуючи особливості їх роботи та особливості проведення атак, що використовують дані уразливості.

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

Визначальною особливістю Persistent SQL Injection уразливостей є те, що після проведення одного запиту до сайту, атакуючий код заноситься в БД і в подальшому береться з БД для виконання SQL запитів. В процесі чого і виконується атакуючий код. І це відбувається постійно, тому я й назвав даний тип уразливостей Persistent SQL Injection.

Тобто, потрібно відправити лише один запит, після чого SQL команди будуть весь час виконуватися (доки вони будуть в БД) в процесі роботи системи.

Подібні SQL ін’єкції зручно використовувати для проведення атак, де потрібне постійне виконання деякого коду, наприклад, для DoS атак. Що я продемонстрував у випадку уразливості в CapCC. Використання даного типу уразливостей відбувається через CSRF атаку, за допомогою якої в БД заноситься атакуючий код, який в подальшому автоматично спрацьовує в процесі роботи системи.

Протидіяти подібним SQL Injection атакам важче, тому що потрібно переверяти не тільки вхідні дані від користувача, але й дані, що беруться з БД, чого програмісти за звичай не роблять, довіряючи даним з БД. До того ж, жоден WAF не виявить подібної уразливості. Тому потрібно проводити перевірку всіх даних перед виконанням SQL запитів.

В цьому місяці я писав в новинах, що МВС вилучило сервери Infostore (причому зробила це не найкращим чином) та СБУ закрила сайт Daily-UA. В першому випадку причиною закриття сайта стала порнографія на сайті, як заявило МВС, а в другому випадку - секретні матеріали, що були розміщені на сайті, як заявило СБУ.

Тому власники українських сайтів повинні пам’ятати про ці випадки і розуміти, що у випадку якщо на їх сайтах будуть розміщені порнографічні матеріали або секретні матеріали, то сервери з їхніми сайтами будуть вилучені (МВС та СБУ відповідно), а сайти будуть закриті, бо перестануть працювати. До того ж проти власників таких сайтів можуть бути порушені кримінальні справи.

У випадках з Infostore і Daily-UA мало місце навмисне (як заявляють правоохоронці) розміщення відповідних метеріалів на сайтах. А я хочу привернути вашу увагу до можливості навмисного використання (зловмисниками) даного державного механізму для закриття сайтів (кібер-рейдерство).

Це може бути зроблено як для політичної боротьби між партіями та закриття неугодних владі сайтів, так і для боротьби з конкурентами. Це новий варіант DDoS атаки, призначений для виведення сайту (причому переважно довоготривалого), в якому в якості інструмента використовуються не зомбі-машини, а правоохоронні органи.

Атака буде відбуватися наступним чином. На сайті знаходиться уразливість, що дозволяє на сайті розміщувати інформацію. Це може бути як повне, так і часткове захоплення сайту - доступу до адмінського акаунту чи акаунту користувача з необхідними правами, або інші уразливості, зокрема persistent XSS. В результаті використання уразливості на сайті буде розміщений необхідний “заборонений” контент: порнографія чи секретні матеріали. Порнографію легко знайти в Мережі, секретні документи дещо важче - тому атака з використанням порно більш імовірна.

Далі нападники тихенько повідомляють нашим правоохоронним органам, що на такому-то сайті є відповідний “заборонений” контент. Бо не варто очікувати, що наші правоохоронці самі його знайдуть. І після попереднього аналізу змісту сайта, правоохоронці підтвердять, що на зазначеному сайті наявний “заборонений” контент. Після чого сервери вилучаються і сайт припиняє свою роботу. Ось так, просто і ефективно, до того ж набагато дешевше ніж при довготривалій DDoS атаці, можна вивести сайт з Інтернету. І для цього лише потрібна маленька дірочка на сайті.

Враховуючи, що більшість веб сайтів в Уанеті та в цілому в Інтернеті мають уразливості (про що я неодноразово наголошував), то власникам сайтів варто приділяти увагу їхній безпеці та проводити аудит безпеки своїх сайтів. Щоб унеможливити подібні атаки конкурентів і не мати таких проблем з сайтами.

Компанія Google випустила свою онлайнову книгу на тему безпеки браузерів - Browser Security Handbook, про що я дізнався минулого тижня. Дана книга буде цікава розробникам браузерів, веб розробникам та секюріті дослідникам.

В книзі Гугла розповідається про характеристики, що відносяться до безпеки, таких браузерів як Microsoft Internet Explorer (6 і 7), Mozilla Firefox (2 і 3), Apple Safari, Opera, Google Chrome та вбудований браузер Android.

Це добре, що Гугл вирішив написати дану книгу, та ще й зробив її онлайновою. Але не мій погляд, він поспішив з цим. Тому що для компанії з численними дірками у власному браузері, варто було спочатку набратися досвіду і виправити всі дірки у власному браузері (не ігноруючи їх, я це іноді траплялося), а вже потім писати секюріті книгу.

А про дірки в Chrome я писав чимало, зокрема в своїх проектах День багів в Google Chrome, День багів в браузерах і День багів в браузерах 2. І перед написанням книги, Гуглу варто було спочатку виправити всі уразливості, про які я їм повідомив - як дірки в Chrome, так і на їхніх сайтах. Але в будь-якому разі я бажаю успіху Гуглу з їхньою книгою.

В своїй презентації Web Application Kung-Fu, Art of Defense, Shreeraj Shah розповідає про мистецтво захисту веб додатків. Статистика атак на веб додатки, методи атак та методи захисту веб додатків.

В своїй класифікації DoS уразливостей у веб додатках я привів такий вид Denial of Service уразливостей, як Зациклений DoS (Looped DoS). Цей вид DoS уразливостей я виявив на початку 2008 року.

Зациклений DoS (Looped DoS) - це уразливості в редиректорах, що призводять до зацикленої редирекції. Це відбувається коли редиректор перенаправляє клієнта (браузер користувача або іншу програму) на самого себе, що призводить до нескінченної редирекції.

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

Вперше я виявив подібну уразливість в Power Phlogger - популярній системі для ведення статистики відвідувань (що використовується на багатьох сайтах, на одному з яких я і виявив даний Зациклений DoS). Показовими прикладами Looped DoS також є уразливість на www.odesk.com та уразливість на www.google.com.

А також я розробив DoS атаку, яку назвав Пекло редиректорів (Redirectors’ hell). Дана атака являє собою другий варіант Зацикленого DoS, коли не редиректор сам на себе редиректить, а два редиректори нескінченно редиректять один на одного.

Серед браузерів тільки Mozilla, Firefox та інші браузери на движку Gecko автоматично зупиняють зациклений редирект (видаючи Redirect Loop Error). Інші браузери не мають такого захисту.

Denial of Service уразливості являють небезпеку для веб сайтів. І зокрема такий їх вид, як Looped DoS уразливості.