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

Проводячи сьогодні дослідження уразливості на cpmstar.com, що я знайшов 19.01.2008, я виявив, що в Інтернеті дуже багато флешек з цією ж самою уразливістю. Всього в Інтернеті біля 215000 флеш файлів вразливих до Cross-Site Scripting (на більше 200000 сайтів).

Це видно з даних Google:

filetype:swf inurl:clickTAG

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

XSS:

Уразливість в наступному AS коді:

getURL(_root.clickTAG, "_blank");

Атака відбувається через передачу XSS коду flash файлу в параметрі clickTAG:

http://site/flash.swf?clickTAG=javascript:alert('XSS')

При кліку на флешку відбувається передача функції getURL рядку, що переданий флешці через параметр clickTAG. Таким чином може виконатися JS код, що був переданий флешці.

На http://server.cpmstar.com:

• alert(’XSS’)

Зазначу, що флешки з target = “_blank” (в getURL) не дозволяють дістатися до cookies. А також вони не працють в IE6. Якщо target заданий не “_blank” (або зовсім не вказаний), то тоді флешки дають можливість дістатися до кукісів в усіх браузерах (та працють в IE6).

Ось ще приклади вразливих флешек на трьох сайтах:

На http://www.banjohangout.org:

• alert(’XSS’)

На http://ad1.emediate.dk:

• alert(’XSS’)

На http://www.open4smart.eu:

• alert(’XSS’)

Існують подібні флешки, що використовують змінну clickTAG, з наступним AS кодом:

getURL(_root.clickTAG, _root.TargetAS);

Атака відбувається з використанням змінних clickTAG і TargetAS:

http://site/flash.swf?clickTAG=javascript:alert('XSS')&TargetAS=

На http://www.adspeed.com:

• alert(’XSS’)
• alert(document.cookie)
• цікавий

Це дозволяє дістатися до кукісів в усіх браузерах та атака нормально працює в IE.

Дані XSS - це strictly social XSS, про які я вже згадував стосовно уразливості на craigslist.org. Про даний клас уразливостей я ще розповім детально.

P.S.

Як я вияснив під час додаткових досліджень, при target = “_blank” (в getURL) можна дістатися до кукісів в Firefox 3. Тому при вказаному в флешці target = “_blank” до кукісів не можна дістатися в IE6 та Mozilla, зате можна дістатися до кукісів в Firefox 3 і можливо в інших браузерах.

Існує такий вид Denial of Service уразливостей як Міжпрограмні DoS (Cross-Application DoS). Подібні уразливості я неодноразово знаходив і вони є достатньо поширеними в наш час, коли різні додатки використовують зовнішні компоненти (бібліотеки).

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

Серед наочних прикладів варто згадати DoS дірки в Internet Explorer, що впливають на всі браузери на движку IE (а іноді й на Windows в цілому), DoS в движку Mozilla (Gecko), що впливають на Firefox, Seamonkey та інші браузери на даному движку, а також PCRE, в якому періодично знаходять переповнення буфера, і дані уразливості проявляються в PHP, Adobe Flash та інших додатках.

Іншим прикладом є поштові клієнти, що використовуєть браузерні движки, і тому можуть мати DoS дірки, що були знайдені в даних браузерах. Зокрема Outlook Express і Outlook використовують движок IE, а Thunderbird і поштовий клієнт Seamonkey використовують движок Mozilla - й тому вони можуть бути вразливими до подібних атак. Більшість атак на браузери вимагає підтримки яваскрипту, що за звичай відключений в поштових клієнтах. Але існують DoS уразливості, що не потребують JS - як наприклад знайдені мною DoS в Outlook Express та DoS в Outlook.

Також через дірки в зовнішніх бібліотеках можуть бути вразливими файлові менеджери. Такі як Windows Explorer та Total Commander. У всіх зазначених випадках, і в Outlook Express та Outlook, і Windows Explorer та Total Commander, атака відбувається через дірки в Internet Explorer.

Такі уразливості можуть існувати як в клієнтських додатках (таких як Outlook Express, Windows Explorer, та інших додатках, що використовуєть компоненти IE) і в серверних додатках (наприклад, модулях веб сервіра), так і в веб додатках (коли вразливий деякий зовнішній компонент).

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

В своїй презентації DDoS Attacks, Jignesh Patel розповідає про DDoS атаки. Основи DoS, опис та таксономія DDoS, захисні механізми та сучасні техніки захисту від даних атак.

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");

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