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

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

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

1. DoS атака з використанням іншого сайту в якості проксі.
2. DoS атака з використанням іншого сайту в якості нападника.
3. DDoS атака з використанням багатьох інших сайтів в якості серверів-зомбі.

Якщо з першим двума видами атак все відносно просто і їх відносно легко проводити (в першому випадку лише потрібно знайти DoS уразливість на сайті, а в другому - великий файл на сайті), то з третьою атакою з використанням серверів-зомбі все більш складніше. Бо потрібно знайти відповідні Abuse of Functionality уразливості на багатьох сайтах та створити ботнет з серверів-зомбі. І щоб продемонструвати реальність даних атак я розробив спеціальну програму, про яку розповім в даній статті.

DoS атака з використанням іншого сайту в якості проксі.

http://www.google.com/ig/add?feedurl=http://site/script?p=benchmark(100000,md5(now()))

В цьому випадку використовується DoS уразливість на сайті http://site (в даному випадку DoS через SQL Injection), для проведення атаки через сайт Гугла (через функціонал iGoogle).

DoS атака з використанням іншого сайту в якості нападника.

http://www.google.com/ig/add?feedurl=http://site/big_file

При наявності великого файлу на сайті http://site можна провести DoS атаку на нього через сайт Гугла, вказавши в iGoogle адресу цього файлу. І якщо зробити серію таких запитів до iGoogle, сервер Гугла перенавантажить своїми запитами сервер, що атакується.

DDoS атака з використанням багатьох інших сайтів в якості серверів-зомбі.

Для дослідження ефективності даних атак я розробив програму для проведення DDoS атак через використання інших сайтів. Яку я назвав DDoS attacks via other sites execution tool (DAVOSET). Це інструмент для проведення DDoS атак через Abuse of Functionality уразливості на сайтах.

Для атаки в DAVOSET потрібно вказати лише адресу сайта, що атакується (http://site), або великого файлу на цьому сайті (http://site/big_file) чи DoS уразливості на ньому. Після чого всі зомбі-сервери зі списку заданого в програмі атакують вказаний сайт і перенавантажать сервер.

Для дослідження я використав 20 зомбі-серверів - це 20 онлайн сервісів, що мають Abuse of Functionality уразливості, що розміщені на 10 фізичних серверах (деякі з цих сервісів розміщені на одному сервері, а також є випадки використання декількох різних уразливих скриптів чи різних уразливостей в одному скрипті одного сервіса). Для тестування були вибрані два невеликих сайти на двух не дуже потужних серверах (враховуючи невелику кількість зомбі-серверів в ботнеті).

Для першого сайта: в результаті атаки завантаження головної сторінки даного сайта зросло в середньому на 21,19% - з 4,72 с. до 5,72 с. Тобто сайт став тормозити на короткий час. І це лише при 20 зомбі-серверах.

При цьому результати роботи DAVOSET наступні (за один запуск): час 0:05, запитів 20, байт відправлено 3068. Тобто невеличкий об’єм трафіку використаного програмою призвів до значно більшого об’єму трафіку на сервер, що атакується. При циклічному запуску програми (наприклад, кожні 5 секунд) та при більшій кількості зомбі-серверів, можна повністю заблокувати роботу даного серверу.

Для другого сайта: в результаті атаки завантаження головної сторінки даного сайта зросло в середньому на 1677% - з 2,21 с. до 39,28 с. (і на 3465% - до 78,80 с. при повторному тестуванні через пів години). І це лише при 20 зомбі-серверах.

При цьому результати роботи DAVOSET наступні (за один запуск): час 0:03, запитів 20, байт відправлено 3368. Зазначу, що другий сервер після запуску декількох атак (для підрахунку середнього значення) починав не просто сильно тормозити, а взагалі підвисав майже на пів години. Так що навіть невелика DDoS атака з 20 зомбі-серверами може надовго підвисити сервер.

Враховуючи поширенність Abuse of Functionality уразливостей на сайтах, що дозволяють атакувати інші сайти, та ігнорування адмінами сайтів даної проблеми, вона є актуальною. А враховуючи те, що мережу з таких зомбі-серверів можна створити без зайвого витрачання ресурсів (в тому числі й фінансових), як це має місце в класичних ботнетах (де потрібно створювати трояни та експлоіти, що будуть їх завантажувати на ПК користувачів, а також потрібно поширювати дані експлоіти та пітримувати зомбі-мережу), то даний вид ботнетів є дуже вигідним з фінансової сторони. Тому даний метод атак може стати поширеним в найближчій перспективі.

Продовжуючи традицію, пропоную вашій увазі цікаві секюріті статті. Щоб ви поповнювали свої знання з веб безпеки.

Добірка цікавого чтива на тему безпеки, в тому числі web security (статті з Вікіпедії):

• Buffer overflow
• Buffer overflow protection
• Clear Channel Assessment attack
• Code injection
• Common Vulnerabilities and Exposures

Продовжу тему витоку інформації про версію системи. Як я зазначав, виведення версії системи - це поширена функція у веб додатках та веб системах. Багато різних движків виводять інформацію про версію системи і дана можливість движків є уразливістю. Це витік інформації (Information Leakage) про версію системи, що може бути використаний для атаки на сайти, що використовують даний движок.

Наведу нові приклади Information Leakage уразливостей в різних веб додатках (зокрема форумах), що приводять до витоку інформації про версію системи.

IPB

В IPB на кожній сторінці форуму виводиться версія системи (Powered by Invision Power Board v1.3).

phpBB

В phpBB версію системи можна дізнатися в файлах http://site/docs/CHANGELOG.html, http://site/docs/INSTALL.html та http://site/docs/README.html (phpBB 2.0.13).

vBulletin

В vBulletin на кожній сторінці форуму виводиться версія системи (Powered by vBulletin Version 3.8.2).

SMF

В SMF на кожній сторінці форуму виводиться версія системи (Powered by SMF 1.1.11).

YaBB

В YaBB на кожній сторінці форуму виводиться версія системи (Powered by YaBB 2.4).

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

SecureState SQL Injection Video

В даному відео ролику демонструється виконання коду через SQL Injection уразливість для отримання віддаленого доступу з адмінськими правами на Windows сервері. Атака відбувається через SQL Server запущений з правами адміністратора.

Після того, як була знайдена SQL Injection, через неї виконується спеціальний код (з Binary Payload), що виконує необхідні команди на сервері з правами сервера СУБД, в якості якого виступає SQL Server. Що відкриває реверс шел на сервері, який з’єднується з telnet-клієнтом на комп’ютері хакера і надає йому адміньский доступ до системи. Рекомендую подивитися дане відео для розуміння векторів атак з використанням SQL Injection.

В минулому році в статті DoS атаки через Abuse of Functionality уразливості я розповів про можливість проведення DoS атак через Abuse of Functionality уразливості на інших сайтах. Зокрема я навів приклади подібних уразливостей на сайтах regex.info та www.slideshare.net. Дані атаки можуть бути як однонаправлені (unidirectional DoS), так і двонаправлені (bidirectional DoS), в залежності від потужностей обох серверів.

Зараз розповім вам про можливість проведення CSRF атак на інші сайти через Abuse of Functionality уразливості. Дослідження даних атак я почав ще в 2007 році, коли виявив подібну уразливість на regex.info.

Використання Abuse of Functionality для атак на інших сайти.

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

Для даних атак можна використати як Abuse of Functionality уразливості (подібні до наведених в даній статті), так і Remote File Include уразливості (як у PHP додатках) - це Abuse of Functionality через RFI.

Даний метод атак може знадобитися, коли необхідно провести приховану CSRF атаку на інший сайт (щоб не засвітитися), для проведення DoS і DDoS атак та для проведення інших атак, зокрема для виконання різних дій, які потрібно зробити з різних IP. Наприклад, при онлайн голосуванні, для накручування показів лічильників та показів реклами на сайті, а також для накручення кліків (click fraud).

Abuse of Functionality:

Атака відбувається при звернені одного сайта (http://site) до іншого (http://another_site) при використані відповідної функції сайта (http://site/script).

http://site/script?url=http://another_site

Переваги даного методу атак.

У даного метода, що використовує зовнішні сайти для атак на інші сайти, є наступні переваги (порівняно з використанням власного комп’ютера):

• Використання ресурсів інших серверів.
• Приховання реферера (порівняно з CSRF атаками через користувачів сайтів).
• Приховання власного IP, що окрім приховання джерела атаки, також може використовуватися для обходу обмежень на IP.
• Проведення DoS атак на інші сайти, з використанням серверів зовнішніх сайтів.
• Проведення DDoS атак на інші сайти, з використанням серверів зовнішніх сайтів.

Зазначу, що дану DoS атаку можна використати для атак на редиректори, про які я писав в своїх статтях Пекло редиректорів та Пекельний вогонь для редиректорів.

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

Приклади уразливих веб сайтів та веб сервісів.

Для проведення CSRF атак на інші сайти можна використати різні сервіси:

1. Онлайн сервіси regex.info та www.slideshare.net.

2. Анонімайзери, такі як anonymouse.org.

3. Онлайн перекладачі на www.google.com, translate.google.com, babelfish.altavista.com та babelfish.yahoo.com.

4. Сервіси для викачки відео з відео-хостингів, такі як keepvid.com.

5. Веб додаток Firebook на всіх сайтах, що його використовують (але потрібно мати доступ в адмінку або проводити CSRF атаку на адміна сайта).

6. W3C валідатори - всього 11 вразливих валідаторів (12 скриптів).

7. Функціонал iGoogle:

http://www.google.com/ig/add?feedurl=http://google.com

Ще 24.07.2008 я звернув увагу, що через Abuse of Functionality та Insufficient Anti-automation уразливості на сайті Гугла, даний функціонал iGoogle може бути використаний для атак на інші сайти.

Продовжуючи розпочату традицію, після попереднього відео про атаку з використанням Jikto і Blindmap, пропоную новий відео секюріті мануал. Цього разу відео про отримання root на Linux. Рекомендую подивитися всім хто цікавиться цією темою.

linux rooting video

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

Після того, як шел розміщений на сервері, потрібно закачати експлоіт на сервер, відкомпілювати його та запустити. Для підняття своїх прав - з обмеженого акаунту до root. Рекомендую подивитися дане відео для розуміння векторів атак з використанням експлоітів для Linux для підняття прав (elevation of privilege) в системі.

Продовжуючи традицію, пропоную вашій увазі цікаві секюріті статті. Щоб ви поповнювали свої знання з веб безпеки.

Добірка цікавого чтива на тему безпеки, в тому числі web security (статті з Вікіпедії):

• Full disclosure
• Alphanumeric code
• Arbitrary code execution
• Blended threat
• Call gate

В статті Local XSS - Локальний XSS, я згадував про такий вид Cross-Site Scripting уразливостей, як Міжконтекстний XSS (Cross Context Scripting), також відомий як Cross-zone scripting. Розповім про нього більш детально.

Такий клас уразливостей як Cross-zone scripting - це відомий різновид XSS уразливостей. Дані уразливості мають місце у бразерах та в плагінах (розширеннях, тулбарах) для браузерів, а також додатках, що використовують браузерні движки (наприклад, в читачах фідів).

Зокрема дані уразливості мали місце в наступних бразерах та інших додатках:

• В Mozilla Firefox (та інших браузерах на движку Gecko): MFSA 2009-46 (Chrome privilege escalation due to incorrectly cached wrapper), MFSA 2009-51 (Chrome privilege escalation with FeedWriter), MFSA 2009-57 (Chrome privilege escalation in XPCVariant::VariantDataToJS()), MFSA 2009-70 (Privilege escalation via chrome window.opener), MFSA 2010-20 (Chrome privilege escalation via forced URL drag and drop) та інші випадки chrome privilege escalation.
• В Internet Explorer та браузерах на движку IE, таких як Sleipnir, Portable Sleipnir і unDonut.
• В Opera (декілька разів).
• А також в різних читачах фідів.

А також подібні уразливості знаходили в наступних плагінах для браузерів:

• Для IE - Darksky RSS bar.
• Для Firefox - Firebug, Sage (декілька разів), Fizzle, WizzRSS Reader, WizzRSS Reader Lite, ScribeFire, Feed Sidebar, Update Scanner, CoolPreviews, infoRSS.
• А також в QuickTime плагіні (для різних браузерів).

Cross-zone scripting - це інший вид XSS, ніж Local XSS. Тому що через ці уразливості в браузерах і плагінах до них можна виконати код на компьютері користувача (в локальному контексті), а не на веб сайті (в контексті даного сайту). Тобто через Cross-zone scripting атака відбувається на комп’ютер користувача (з його поточними правами), а через Local XSS - на веб сайт (з правами даного користувача). Але спільним для обох видів XSS є те, що дані уразливості проявляються в локальному ПЗ користувача.

Головною особливістю Міжконтекстного XSS є те, що дані уразливості використовується для доступу до компьютера користувача, зокрема для доступу до локальних файлів. Тобто через уразливості в браузері чи його плагіні JS (або VBS) код виконується не в зоні (контексті) Інтернет, а в локальній зоні (в термінології IE), або в chrome контексті (в термінології інших браузерів), що дозволяє отримати доступ до локальної файлової системи з правами даного користувача. Звідси й назва Cross-zone scripting або Cross Context Scripting.

Іноді я зустрічаю сайти, де одна і та сама уразливість має місце на всьому сайті, на кожній його сторінці. Це можуть бути як SQL Injection чи Cross-Site Scripting, так й інші уразливості. Тобто сайт представляє собою сито з дірок.

Подібні випадки можуть мати місце з наступних основних причин:

1. На сайті є уразливий код, що включений до багатьох або усіх сторінок сайта.

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

3. На сайті не зроблені видповіді налаштування (або на сайті вцілому, або в кожному скрипті зокрема), що призводить до появи дірок на багатьох або усіх сторінках сайта (наприклад, Full path disclosure уразливостей).

Розглянемо приклади подібних випадків.

Серед випадків, що відносяться до першої причини, є наступні. В 2006 році я виявив численні SQLi та XSS уразливості на www.daily.com.ua, що мали місце майже на кожній сторінці сайта.

В 2007 році я виявив численні XSS уразливості на www.moskva.com, що мали місце майже на всіх сторінках сайта. А в 2009 році я виявив численні XSS уразливості на www.yuniti.com, що мають місце на всіх сторінках сайта (і досі не виправлені).

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

Також в 2006 році я виявив уразливості в Яндекс-Директ - в JS-коді системи Яндекс-Директ. Які я виявив на одному сайті, що розміщував контекстну-рекламу даної системи (і кожна сторінка, що містила даний код, мала XSS уразливості). І відповідно всі сайти, що використовували Яндекс-Директ і самі не докладали зусиль по убезпеченню від XSS атак, можли бути атаковані (всі користувачі даних сайтів). А в 2007 році я виявив на одному сайті уразливість в коді Google Analytics.

Серед випадків, що відносяться до третьої причини, є наступні. В PHP додатках, якщо не відключене виведення повідомлень про помилки (на сайті чи в кожному скрипті), у випадках, коли має місце помилка, виводиться повідомлення про помилку, при цьому вказуючи повний шлях на сервері (тобто це Full path disclosure уразливість). І в тих випадках, коли проблема стосується всіх php-скриптів на сайті (наприклад, сталися проблеми з якимось важливим файлом, або змінилися права на сервері, або інші проблеми на сервері), то у всіх php-скриптах буде FPD уразливість.

Численні подібні випадки можна побачити з серії моїх статей про “Warning” Google хакінг. Або на взломаних сайтах, коли були внесені некоректні зміни в один файл (зокрема, файл конфігурації), що включається в усі скрипти на сайті, і тому на кожній сторінці сайта має місце FPD уразливість.

В презентації Cross Site Scripting Attacks: Xss Exploits And Defense, що була три роки тому розміщена на www.slideshare.net, розміщена однойменна книга, яка вийшла в 2007 році.

Книга Cross Site Scripting Attacks: Xss Exploits and Defense, про яку я вже писав - це перша книга про XSS уразливості. Що була написана групою авторів: Jeremiah Grossman, Robert Hansen, Petko D. Petkov, Anton Rager та Seth Fogie. І з якою ви можете ознайомитися в онлайні.