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

В минулому році в статті 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. І з якою ви можете ознайомитися в онлайні.

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

Jikto & Blindmap - Demonstration of Attack

В даному відео ролику демонструється використання таких інструментів як Jikto (його модифікованої версії Jikto+) та Blindmap, для пошуку уразливостей на сайтах. Причому сам пошук відбувається через браузер іншої особи, яка навіть і не підозрює, що її браузер використовується для пошуку вірусів (в цьому особливість Jikto).

Для даної атаки необхідні Jikto+ (контрольна панель та сам JS-скрипт, розміщені в Інтернеті), цільовий сайт, сайт з persistent XSS (де буде розміщений JS-скрипт Jikto) та Blindmap. Рекомендую подивитися дане відео для розуміння векторів атак з використанням Jikto і Blindmap.

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

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

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

Warning: Permission denied

Warning: date

Warning: Access denied for user (при роботі з СУБД, зокрема MySQL)

Warning: db2 function.db2

Warning: dba function.dba

Warning: dbase function.dbase

Warning: dbmexists

Warning: dbmfetch

Warning: dbminsert

Warning: dbmopen

Раніше я вже писав про можливості закриття сайтів через їх уразливості, а в останнє я розповідав про закриття сайтів через їх взлом. Зараз разповім вам про нову можливість впливу на власників дірявих сайтів через законодавство.

Можливе закриття сайтів (а також висенення обвинувачення) через порушення закону про захист персональних даних. Як я писав учора, Верховна Рада України прийняла закон про захист персональних даних, який набирає чинність з 01.01.2011. І з того часу дія даного закону може торкнутися кожного власника дірявого сайта в Україні.

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

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

Так що всім адмінам і власникам сайтів варто слідкувати за безпекою власних сайтів, щоб не потрапити під дію даного закону.

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

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

• SiteKey
• Snarfing
• Trojan horse (computing)
• XSS Worm
• Exploit (computer security)