Архів для категорії 'Статті'

Підбір паролей до MySQL

19:15 06.10.2011

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

Metasploit MYSQL Brute force

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

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

Атаки через буфер обміну

22:43 30.09.2011

Розповім вам про атаки через буфер обміну (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 файл). Що ви самі можете перевірити ;-) .

Закриття сайтів по політичним мотивам

22:47 27.09.2011

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

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

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

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

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

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

Безпека розширень Google Chrome

15:07 24.09.2011

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

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

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

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

Вразливий до хакінгу Web 2.0

19:21 23.09.2011

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

Цікаве чтиво на тему web security

19:25 22.09.2011

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

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

Іконковий ніндзя

20:28 10.09.2011

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

“Icon Ninjas” Internet Security PSA

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

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

Silverlight: захист і напад

22:45 09.09.2011

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

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

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

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

Обхід захисту на images.google.com

16:08 08.09.2011

В 2007 я виявив уразливості на images.google.com (в пошуці по зображенням), про які розповів під час проекту MOSEB, та www.google.com та translate.google.com (в онлайн перекладачі). І тоді Гугл проігнорував дані уразливості, а в 2009 році я виявив, що вони частково (втихаря) виправили дірку в пошуці по зображенням - шляхом обмеження адрес, на які можна зайти через даний функціонал. І я тоді одразу ж розробив метод обходу даного обмеження, про що зараз вам розповім.

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

Але це обмеження обходиться наступним чином. Можна взяти вже готову сторінку (з зображенням в даному випадку), яка проіндексована Гуглом - це може бути як сторінка на сайті нападника, яку він підготував для атаки і дав пошуковцю її проіндексувати, або це може бути сторінка взломаного сайта. Після чого, на цю сторінку розміщується malware чи інший контент (наприклад, для фішинга), і використовується робочий URL на images.google.com для проведення атаки.

Що цікаво, якщо розмістити на сторінці html-код для проведення фішинг атаки на користувачів Google, то бот скоріше за все цього не виявить. Тому можна буде не після індексації розміщувати цей код на сайт, а навіть до індексації - бот пошуковця спокійно проіндексує такі сторінки.

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

Експлоіт для Apache mod_isapi

19:13 03.09.2011

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

Apache 2.2.14 mod_isapi Dangling Pointer

В даному відео ролику демонструється процес використання експлоіта для веб сервера Apache, зокрема для уразливості Apache 2.2.14 mod_isapi Dangling Pointer. Дана уразливість в Апачі дозволяє виконати довільний код на сервері з правами системи (SYSTEM на ОС Windows).

Атака відбувається при локальному запуску експлоіта, який створює шел на 4444 порту сервера. Рекомендую подивитися дане відео для розуміння векторів атак на веб сервери.