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

Раніше я вже розповідав про різні класи Сross-Site Scripting уразливостей, в тому числі про багато класів XSS створених мною. В останнє я розповідав про Міжмовний XSS (Cross-Language Scripting) та Міжконтекстний XSS (Cross Context Scripting). А зараз розповім вам про ще один тип XSS уразливостей.

Це Міжпрограмний XSS - Cross-Application Scripting (CAS, XAS). Про який я згадув раніше в добірці статей і зараз розповім докладніше. Цей різновид XSS уразливостей трапляється в локальних додатках. Причому в зазначеній статті на Вікіпедії згадується не тільки про Cross-Application Scripting, але й про Cross-Application Request Forgery (CARF).

Різновиди Cross-Application Scripting.

Бувають наступні види Міжпрограмного XSS:

• Постійний XAS - persistent XAS.
• Відбитий XAS - reflected XAS.

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

Особливості Міжпрограмного XSS.

Дані уразливості трапляються в локальних додатках, що використовують браузерні движки. Такі як движок браузера Internet Explorer (Trident) чи інших браузерів. Тому виконання JavaScript/VBScript коду в таких додатках призводить до виконання коду в браузері в локальному контексті. З відповідними наслідками (зокрема можливий доступ до файлової системи, що може призвести до витоку інформації з локальних файлів).

Як і у випадку Local XSS, дані уразливості мають місце в локальних додатках - в цьому схожість цих класів XSS. Але XAS уразливості направлені на локальний комп’ютер, а не на веб сайти - в цьому цей клас схожий з Cross Context Scripting. Але якщо у випадку Cross Context Scripting атака відбувається в рамках одного додатку (чи в самому браузері, чи через плагін/доповнення/тулбар до браузеру), то у випадку XAS атака відбувається між різними додатками. Так само як це має місце в Міжпрограмних DoS (Cross-Application DoS), про які я писав в 2008 році.

Окрім виконання JS/VBS коду в локальному контексті подібно до Cross Context Scripting (Cross-zone scripting), XAS може використовуватися для виконання коду в локальному додатку (вразливому до переповнення буферу).

Детально про Cross-Applications Scripting ще в 2005 році розповів QQLan в статті XSS – WEB = Cross-Applications Scripting. В якій автор навів цікаві приклади XAS дірок в сканері безпеки WebInspect та в утілітах Windows.

Приклади Cross-Application Scripting уразливостей.

Прикладами Міжпрограмного XSS є наступні уразливості в декстопних програмах, зокрема таких як антивіруси, IM-клієнти, словники, сканери безпеки та утіліти Windows:

Cross-Application Scripting в Sophos Anti-Virus

Cross-Application Scripting та Cross-Application DoS в ICQ 6

Cross-Application Scripting в Babylon

XAS уразливості в SPIDynamics WebInspect, що описані в вищезгаданій статті.

XAS в Gpedit та RSoP в Microsoft Windows, що описані в вищезгаданій статті.

Використання движків браузерів, зокрема IE, в інших додатках, розробники яких не слідкують достатньо за безпекою, створює умови для появи Cross-Application Scripting уразливостей.

В статті Безопасность расширений Opera - новые векторы атак через аддоны браузеров розповідається про безпеку розширень до браузерів, зокрема до Opera. Про вектори атак через доповнення до браузера.

В даній статті розглянуті наступні аспекти безпеки розширень Opera:

• Розширення зсередини.
• XSS.
• Потенційні цілі.
• Як передавати дані.
• Взаємодія розширень і безпека.
• Користувацькі скрипти в Opera.

Використання стандартних веб технологій (таких як HTML, CSS і JavaScript) для розробки доповнень, призводить до появи уразливостей в аддонах до браузерів, аналогічних тим, які ми зустрічаємо у веб додатах. Тому розробникам доповнень до браузерів (так само як і плагінів, таких як Flash та інші) слід краще слідкувати за безпекою власних програм.

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

Metasploit MYSQL Brute force

В даному відео ролику демонструється використання Metasploit Framework для проведення Brute Force атак на MySQL. Розглядається брутфорсінг функціонал Metasploit.

Після вказання файлів з переліком логінів і паролів проводиться атака по словнику. Рекомендую подивитися дане відео для розуміння векторів атак на СУБД, зокрема на MySQL.

Розповім вам про атаки через буфер обміну (attacks via clipboard). Концепція яких в мене виникла вже багато років тому, після того як я стикнувся з XSS, що вимагала вставки даних з буферу. І наведу вам методику проведення таких атак через JS і Flash.

Раніше я вже писав про Cross-Site Scripting уразливості в формах, де я розповідав про XSS атаки на форми, як reflected XSS, так і persistent XSS. Подібні уразливості я знаходив на багатьох сайтах і в багатьох веб додатках в 2007-2011 роках. Але окрім них, ще бувають strictly social XSS в формах, коли потрібно змусити жертву скопіювати в буфер обміну спеціальний код і вставити його з буфера для проведення атаки - такі уразливості я знаходив ще в 2006 році. Про що я писав в статті Міжмовний XSS - Cross-Language Scripting. І використання даної методики дозволить вирішити першу частину задачі - копіювання коду в буфер, а далі залишиться лише змусити жертву вставити з буфера для проведення атаки.

Існує можливість в браузері заносити дані в буфер обміну. Зокрема, це можна зробити через JavaScript та Flash. Зчитувати з буфера обміну не можна (це зроблено з метою безпеки), зате можна заносити дані в буфер (бо в цьому розробники не вбачають небезпеки). Що може бути використано для атаки.

Використовуючи функцію копіювання в буфер обміну можна проводити різні атаки, зокрема Cross-Site Scripting і Cross-Application Scripting, а також спам, фішинг і malware атаки. Наприклад, для проведення XSS атаки коли треба вставити код з буфера обміну в текстове поле. Або CAS коли якийсь додаток має переповнення буфера в якомусь полі (при вставці даних в це поле), і можна занести в браузері в буфер необхідний код, після вставки якого з буферу в поле відбудеться DoS чи Code Execution атака. Або можна заносити шкідливі програми (зокрема exe-файли) для викачування в качалки, що моніторять буфер обміну. І якщо в них задане автоматичне викачування файлів, то дане шкідливе ПЗ буде викачане автоматично (Automatic File Download).

Також можна занести в буфер обміну URL довільного сайта - з метою спаму, фішинга чи розповсюдження malware. Наприклад, деякі сайти автоматично копіюють адресу поточної сторінки сайта - для зручності відвідувачів. Щоб людина вставляючи з буфера адресу в браузер, випадково вставила не ту адресу, яку вона раніше скопіювала, а ту, яку їй підсунули, щоб вона перейшла на вказаний сайт. Який може бути як рекламним, так і фішинг ресурсом, або сайтом зі шкідливим кодом. Це кліпбоардний фішинг / кліпбоардний спам (clipboard phishing / clipboard spamming) і дані атаки можуть бути більш ефективними ніж атаки через закладки та стартову сторінку (про які я писав в статтях Темна сторона закладок та Темний дім в 2009 році).

При використанні JavaScript можна копіювати лише в IE. При використанні Flash - в будь-якому браузері з флеш-плагіном. Можливість працювати з буфером обміну з’явилася в Flash 7 (ActionScript 1) і була оновлена в Flash 10 (ActionScript 3), тому для атаки потрібно, щоб у користувача була відповідна версія флеш-плагіна (в залежності від використаного коду).

Для надійності варто використовувати AS1 (при копіюванні текстових даних), щоб код спрацював в користувачів як нових, так і старих версій флеш-плагіна (а також тих, хто буде запускати swf-файл в стаціонарному флеш-плеєрі). А також атака через флеш спрацює, коли у користувача вимкнутий JavaScript (що дозволить обійти відповідний захист, наприклад, NoScript чи тимчасове вимкнення JS). З іншої сторони, враховуючи, що після появи в 2008 році заяв про можливість підсовувати шкідливі лінки користувачам та виявлення флеш-банерів, що проводили подібні атаки, Adobe внесла зміни в флеш плеєр починаючи з версії 10.0, тому для атаки в браузері потрібна взаємодія з користувачем (при цьому при запуску флешки в стаціонарному флеш плеєрі атака автоматично спрацює в усіх флеш плеєрах версії 7.0 і вище).

Але в деяких користувачів може бути відсутній чи тимчасово вимкнутий флеш плагін, тому для більш надійної атаки варто використовувати комбінований метод JS + Flash (тобто поєднати обидва методи атаки). Флеш дозволяє провести атаку кросбраузерно і в різних ОС, зате JS дозволяє провести атаку на користувачів, хоча й тільки Internet Explorer, в яких немає флеш плагіна (або використовується стара версія), а також він не має обмежень на запис до буферу (які з’явилися в Flash 10.0). Тому варто об’єднати сильні сторони обох методів.

Приклад JS коду для IE:

<script>window.clipboardData.setData('text','XSS');</script>

Приклад AS1 коду:

System.setClipboard("XSS");

Приклад AS3 коду:

import flash.desktop.ClipboardFormats;
Clipboard.generalClipboard.setData(ClipboardFormats.TEXT_FORMAT, "XSS");

Також можна в JS і AS зробити циклічне копіювання в буфер (наприклад, кожної хвилини). Що дозволить провести постійну (persistent) атаку через буфер обміну, коли користувачу увесь час, доки відкрита сторінка з атакуючим кодом, буде підсовуватися в буфер необхідний код.

При цьому слід зазначити, що починаючи з Flash 10.0 Адоб обмежила функціонал роботи з буфером обміну, що існував до цього (для покращення безпеки після появи в 2008 році вірусних флешек, що проводили атаки через буфер). І тепер необхідна взаємодія з користувачем, тобто необхідно, щоб користувач зробив дії мишею чи клавіатурою. Але при атаці на користувачів нових версій флеш плеєра (флеш плагіна) це можна обійти за допомогою Clickjacking, зокрема можна використати флешку ZeroClipboard (або зробити аналогічний алгоритм, без використання JS, а лише AS) в парі з Clickjacking. Або з MouseOverJacking. Наявність цієї можливості демонструє, що виправлення Adobe для роботи з буфером у Флеш 10 обходиться і дана атака все ще можлива.

В тіло даної сторінки включений JS-код (з вищенаведеним кодом для IE), що заніс в ваш буфер рядок “XSS”. А також була включена флешка, що призначена для флеш плеєра 9 та попередніх версій (але в 2023 році я прибрав swf файл). Що ви самі можете перевірити .

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

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

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

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

Зокрема те, що з 22.09.2011 не працює дірявий сайт www.foxtrot.com.ua - це цілком може бути пов’язано з обшуками, що з недавніх пір проводить МВС в офісах Фокстрота. І в подібній ситуації може опинитися будь-який власних дірявого сайта.

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

В статті Безопасность расширений Google Chrome - привычные векторы атак в контексте аддонов для браузера розповідається про безпеку розширень до браузерів, зокрема до Google Chrome. Про вектори атак через доповнення до браузера.

В даній статті розглянуті наступні аспекти безпеки розширень Google Chrome:

• XSS.
• Кукіси.
• Дані веб браузера як ціль для атаки.
• Фішинг.
• Ризики, пов’язані з використання JSON.
• Впроваджуємі скрипти.

Використання стандартних веб технологій (таких як HTML, CSS і JavaScript) для розробки доповнень, призводить до появи уразливостей в аддонах до браузерів, аналогічних тим, які ми зустрічаємо у веб додатах. Тому розробникам доповнень до браузерів (так само як і плагінів, таких як Flash та інші) слід краще слідкувати за безпекою власних програм.

В презентації Mc Graw Hill Hacking Exposed Web 2.0, наводиться повний текст книги “Hacking Exposed Web 2.0″. В якій розповідається про вразливий до хакінгу Web 2.0. Про те, які ризики безпеки існують в Веб 2.0 додатках та як від них захиститися.

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

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

• Privacy-invasive software
• Keystroke logging
• Cross-application scripting
• Evasion (network security)
• Uncontrolled format string

Продовжуючи розпочату традицію, після попереднього відео про eксплоіт для Apache mod_isapi, пропоную нове відео на веб секюріті тематику. Цього разу відео про іконкового ніндзя. Рекомендую подивитися всім хто цікавиться цією темою.

“Icon Ninjas” Internet Security PSA

В даному відео ролику, розробленного на замовлення Гугла та інших компаній для Internet Security PSA, демонструється типовий процес атаки через Інтернет (така собі соціальна реклама). І закликається Інтернет-користувачів слідкувати за безпекою власного комп’ютера виконуючи стандартні і давно відомі кроки для захисту ПК.

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

В статті Silverlight: защита и нападение розповідається про методи захисту та атаки на Silverlight додатки. Про безпеку при розміщенні Silverlight-додатків на веб сайтах.

В даній статті розглянуті наступні аспекти пов’язані з безпекою Silverlight:

• Модель безпеки Silverlight.
• Sandbox.
• Мережева взаємодія.
• Десктопні додатки Silverlight.
• Експлуатація уразливостей Silverlight-контролів.
• Як зробити Silverlight-контроли більш безпечними.

Флеш не єдина RIA платформа в Інтернеті, тому варто також звертати увагу на безпеку платформи Silverlight.