Поламаний Веб
20:15 10.01.2009В своїй презентації The Web Is Broken, Bipin Upadhyay розповідає про сучасний стан веба. Про стан безпеки в Інтернеті, поширені уразливості на веб сайтах і атаки на них, та методи захисту сайтів.
В своїй презентації 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:
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 уразливості бувають наступних типів:
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 уразливості.
This is English version of my Classification of DoS vulnerabilities in web applications article.
In my Security manual, I told about DoS vulnerabilities in detail, which often happen in modern web applications (and also in browsers). Using of Denial of Service vulnerabilities in web applications can lead to server overload, up to its complete denial of service.
There are next types of Denial of Service vulnerabilities:
1. Classic DoS.
2. Recursive File Include.
3. Looped DoS.
Classic DoS.
These classic DoS vulnerabilities in web application divide on full denial DoS and overload DoS.
In case full denial DoS, vulnerability leads to freezing of web server, when its restart is needed. Or leads to crashing of process, web server (e.g. Apache) or database (e.g. MySQL), when server itself continue to work, but part of its functions become inaccessible (till restart of appropriate process). Also there are attacks on web applications which belong to this type of DoS, which lead to change of settings of web applications (i.e. via access to file system and changing of configuration files), which completely stop their work.
In case of overload DoS, vulnerability leads to heavy overload of web server. Such happens during execution of resource-capacious operations (e.g. request to DB and data output), when there is no restrictions on capacity of executable operations, or this restrictions are setting by user and they are not checking (i.e. they can be arbitrarily manipulated). Which leads to that user knowingly or unintentionally can send to execution heavy request, which overloads server.
Recursive File Include.
Vulnerabilities Recursive File Include, which I wrote about earlier - it’s one of new types of Denial of Service.
Recursive File Include - it’s Local file include vulnerability, which is using for making DoS attack. I.e. it is local inclusion of the files (scripts), which leads to DoS attack due to recursion, when files are infinitely including (which overloads server).
Looped DoS.
Looped DoS - it’s vulnerabilities in redirectors, which lead to looped redirect. It happens when redirector send client (user browser) to itself, which leads to infinite redirection.
In case if client, which has visited this redirector at site, has no restrictions on redirection, then it can goes to this web application for a long period of time (which will be sending it to itself all the time), which leads to server overload.
В своєму Посібнику з безпеки, я детально розповів про DoS уразливості, що часто трапляються в сучасних веб додатках (а також браузерах). Використання Denial of Service уразливостей у веб додатках може призвести до перенавантаження сервера, аж до його повної відмови в обслуговуванні.
Denial of Service уразливості бувають наступних видів:
1. Класичні DoS.
2. Recursive File Include.
3. Зациклений DoS (Looped DoS).
Класичні DoS.
Дані класичні DoS уразливості у веб додатках діляться на DoS повної відмови та DoS перенавантаження.
У випадку DoS повної відмови, уразливість призводить до підвисання веб сервера, коли потрібне його перезавантаження. Або вибивання процесу, веб сервера (наприклад, Apache) чи СУБД (наприклад, MySQL), коли сам сервер продовжує працювати, але частина його функцій стає недоступною (до перезапуску відповідного процесу). А також до даного типу DoS відносяться атаки на веб додатки, що призводять до зміни налаштувань веб додатів (наприклад, через доступ до файлової системи і зміни файлів конфігурації), які повністю зупиняють їх роботу.
У випадку DoS перенавантаження, уразливість призводить до сильного перенавантаження веб сервера. Подібне трапляється при виконанні ресурсоємних операцій (наприклад, запит до БД і виведення інформації), коли відсутні обмеження на об’єми виконуємих операцій, або дані обмеження задаються користувачем і вони не перевіряються (тобто ними можна буде довільно маніпулювати). Що призводить до того, що користувач навмисно чи ненавмисно може послати на виконання тяжкий запит, який перенавантажить сервер.
Recursive File Include.
Уразливості Recursive File Include, про які я писав раніше - це один з нових видів Denial of Service.
Recursive File Include - це Local file include уразливість, що використовується для проведення DoS атаки. Тобто це локальне включення файлів (скриптів), що призводить до DoS атаки за рахунок рекурсії, коли файли інклюдяться нескінченно (що перенавантажує сервер).
Зациклений DoS (Looped DoS).
Зациклений DoS (Looped DoS) - це уразливості в редиректорах, що призводять до зацикленої редирекції. Це відбувається коли редиректор перенаправляє клієнта (браузер користувача) на самого себе, що призводить до нескінченної редирекції.
У випадку якщо клієнт, який відвідав даний редиректор на сайті, не має обмежень на редирекцію, то він може тривалий час звертатися до даного веб додатку (який буде весь час перенаправляти його на себе), що призведе до перенавантаження серверу.