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

Як я писав раніше, в 2011 році в ЄС прийняли закон стосовно cookies, а в деяких країнах ЄС, зокрема в Великобританії, вступ в дію закону відсрочили на рік. І даний закон може призвести до штрафів власникам сайтів, що його не дотримуються, в тому числі це може призвести до закриття сайтів (якщо сума штрафу буде занадто велика для власника сайту, щоб продовжувати його роботу).

Розглянемо цей закон ЄС в контексті штрафів та закриття сайтів. Подібно до всіх тих випадків в законодавсті України, про які я неодноразово писав з 2008, що призводили до закриття сайтів. В останнє я писав про закриття сайтів через обшук податкової.

Цей закон називається EU Cookie Law. Ви можете ознайомитися з детальним поясненням всіх особливостей даного закону в статті Definitive guide to the Cookie Law, в тому числі методів, які власники сайтів можуть використати для дотримання чи не дотримання даного закону. На даний час сайти в Євросоюзі переважно не дотримуються даного закону, але враховуючи, що це діючий закон ЄС, всім сайтам, які підпадають під дію цього закону, бажано його дотримуватися.

З травня 2011 цей закон вніс такі зміни в законодавство про онлайн приватність в ЄС, що у відвідувачів сайтів повинні запитувати дозволу перед використанням кукісів (окрім визначених випадків, таких як форми логіна). Один рік був наданий (як мінімум в UK) для веб сайтів, щоб вони змінили методи своєї роботи відповідно до нового закону і з 26.05.2012 цей закон почав діяти в повну силу (в даному випадку в UK).

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

Що це означає для веб сайтів.

Вони повинні змінити звичайний метод роботи з кукісами (який використовується з часу створення HTTP cookies), тобто “прихований метод”, і почати використовувати “голосний метод” - запитувати кожного користувача і відвідувача перед встанновлення кукісів.

Поточна ситуація.

Я бачив деякі сайти ЄС, включаючи вищезгадані сайти, які запитували перед встановленням кукісів, але небагато сайтів. Більшість сайтів ЄС, які я відвідав за останній рік, не робили цього, тому вони є не сумісними з EU Cookie Law.

Як я перевірив декілька популярних сайтів в ЄС напередодні 26.05.2012, ситуація з сумісністю до нового закону була наступна:

http://www.google.fr - не сумісний (приховано встановив два кукіси)

http://www.google.de - не сумісний (приховано встановив два кукіси)

http://fr.yahoo.com (редирект з yahoo.fr) - не сумісний (приховано встановив сім кукісів)

http://www.bing.com/?cc=fr (редирект з bing.fr) - не сумісний (приховано встановив одинадцять кукісів)

http://ec.europa.eu - на головній сторінці не встановлює кукіси, але після того, як я відвідав наступну сторінку, він встановив один кукі.

Аспект безпеки в даному законі.

Існує зв’язок між законом ЄС стосовно cookies та безпекою веб сайтів. Якщо сайт буде взломаний і кукіси будуть встановлені відвідувачам приховано (автоматично), то цей сайт може бути оштрафований - навіть якщо по замовчуванню цей сайт сумісний закону ЄС (запитує перед встанновленням кукісів).

Так що уразливості на будь-якому сайті (що підпадає під законодавство ЄС) можуть наразити його на штрафи в ЄС в зв’язу з цим законом. І це можуть бути як серйозні уразливості, що призводять до повної компрометаці сайта, так і Cross-Site Scripting (persistent XSS чи навіть reflected XSS) або HTTP Response Splitting уразливості. Тому що за допомогою XSS і HTTPRS уразливостей можна встановлювати кукіси - що робить ці сайти не відповідними до нового закону. Тому даний закон є гарною нагодою для власників веб сайтів для покращення їхньої безпеки.

В цьому місяці в журналі “Web App Pentesting” була опублікована моя стаття. В травневому номері журналу Web App Pentesting 05/2012, що вийшов 22.05.2012, опублікована стаття “Обхід веб антивірусів” (Bypassing web antiviruses).

В ній розповідається про такий метод обходу веб антивірусів, як клоакінг (який відомий ще з 90-х і використовувався для SEO цілей). Просунуте використання клоакінгу передбачає аналіз таких параметрів відвідувачів сайтів як User-Agent, IP та DNS, для виявлення веб антивірусів та приховання від них. Тому всі розробники систем пошуку вірусів на веб сайтах повинні враховувати це для протистояння malware.

Дана стаття базується на двох моїх попередніх статтях: Обхід систем для пошуку вірусів на веб сайтах та Ефективне використання клоакінгу проти веб антивірусів. Вона вміщує як матеріали цих статей, так і нову інформацію. Й детально описує методи, які malware може використати для приховання від веб антивірусів.

P.S.

Виклав на сайті повну версію статті Bypassing Web Antiviruses.

Продовжуючи розпочату традицію, після попереднього відео про експлоіт для Firefox та IE, пропоную нове відео на веб секюріті тематику. Цього разу відео про URL Bar Spoofing в Google Chrome. Рекомендую подивитися всім хто цікавиться цією темою.

Google Chrome Webkit URL Bar Spoof

В ролику демонструється URL Bar Spoofing уразливість в браузері Google Chrome (та інших браузерах на Webkit, таких як Safari). Дана уразливість дозволяє підробити URL в адресному рядку браузера (що може бути використано для проведення фішинг атак). Спочатку в адресному рядку відображається одна адреса, а потім, після короткотривалого повідомлення про помилку, у вікні відображується інша адреса (при збереженні сторінки попереднього сайта).

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

Як я вже писав минулого місяця, через перевірку податкової призупинили свою роботу інтернет-магазини Rozetka.ua і Sokol.ua. Окрім сайтів, також на час перевірки були закриті й офлайнові магазини цих компаній. Закриття сайтів цих інтернет-магазинів було тимчасовим, пов’язане з перевірками податкової адміністрації та обшуком УБОЗом офіса Sokol.ua.

Подібна переспектива може стосуватися будь-яких е-комерс сайтів, в першу чергу онлайн магазинів, аптек та аукціонів. Тобто тих, хто заробляє великі суми коштів при торгівлі в Інтернеті.

З даних інцидентів цілком очевидно, що не тільки СБУ і МВС можуть закривати сайти через порушення законодавства (про такі випадки я писав неодноразово), а також і ДПС. Щоб унеможливити подібні закриття сайтів у майбутньому обидва магазини перевели хостінги своїх сайтів закордон.

Головною особливістю цих інцидентів було те, що самі правоохоронці сайти спеціально не закривали (як вони заявляють), а лише проводили перевірки. Зокрема в тих приміщеннях цих компаній, де знаходилися сервери, на яких розміщувалися сайти. І відповідно під час обшуків всі комп’ютери вимикалися, як це завжди у нас буває, в тому числі й сервери. Але це стосується Sokol.ua, а сайт Rozetka.ua знаходився у хостер провайдера Mirohost і незважаючи на заяви податкової, що вони не закривали даний сайт, але саме вони вилучили сервер з сайтом у хостінг провайдера.

Подібна ситуація була торік з сайтом Фокстрота, про що я писав в статті Закриття сайтів по політичним мотивам. Вони також тримали сервер з сайтом в своєму офісі й під час обшуків МВС він перестав працювати. Але тоді сайт не працював довший час, вірогідно тому, що сервер було вилучено. Тому варто тримати сайти на серверах хостінг провайдерів, щоб уникнути подібних ситуацій. А щоб повністю їх унеможливити - у закордонних хостінг провайдерів.

Стосовно різних причин закриття сайтів правоохоронними органами, то можна сказати, що закриття сайтів через обшук податкової можна зініціювати й через взлом сайта. Наприклад, взломати сайт і вказати дані про доходи в декілька разів вищі, а потім скинути інформацію про це у податкову. Коли вони ознайомляться з “офіційними даними” на сайті, які будуть відрізнятися від задекларованих доходів і сплачених податків, ДПС проведе перевірку в офісі, яка можна призвести до переривання роботи сайта. Або просто можуть дати “наводку” податківцям. Наприклад, на Sokol.ua подав жалобу колишній клієнт магазину.

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

В презентації Web Service Security Method To SOA Development, Nafise Fareghzadeh розповідає про безпеку веб сервісів (Web Service). Для усунення ризиків безпеки при розробці веб додатків, що відносяться до категорії Service-Oriented Architecture (SOA).

В своєму звіти Top 50 Bad Hosts & Networks 2011 Q4, організація HostExploit в співпраці з Group-IB розповідають про ситуацію з шкідливим програмним забезпеченням в четвертому кварталі 2011 року. І наводять перелік 50 найбільших шкідливих хостів та мереж в Інтернеті.

Аналогічно StopBadware, організація HostExploit випускає власний звіт про інфікованість сайтів. Але окрім загальної статистики та опису поточного стану речей, вони також проводять дослідження найбільших поширювачів шкідливого ПЗ серед хостів та мереж.

Даний звіт складається за наступних розділів:

• Introduction
• News Roundup
• Frequently Asked Questions
• The Top 50 - Q4 2011
• Q4 2011 to Q3 2011 Comparision
• Top 10 Visual Breakdown
• What’s New
• Country Analysis
• The Good Hosts
• Bad Hosts by Topic
• Conclusions

Продовжуючи розпочату традицію, після попереднього відео про Address Bar Spoofing в Google Chrome, пропоную нове відео на веб секюріті тематику. Цього разу відео про експлоіт для Firefox та IE. Рекомендую подивитися всім хто цікавиться цією темою.

Exploit firefox 4, ie and google chrome

В ролику демонструється приватний експлоіт для різних браузерів. Зокрема автор назвав серед уразливих браузери Firefox, Internet Explorer та Google Chrome. Але в самому відео показане віддалене виконання коду лише в Firefox 4 та IE8 (тому як мінімум ці два браузери уразливі до даної атаки). Після виконання коду експлоіту, комп’ютер стає учасником бот мережі й нападник може віддалено керувати ПК користувача - робити скріншоти екрана та виконувати інші команди. Інтерфейс центра керування ботами показаний у відео-ролику.

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

Розповім вам про атаку через пошкодження таблиць в базах даних в СУБД MySQL. Яку я представив в травні 2009 в записі Атака на Abuse of Functionality в WordPress. Тоді я детально описав цю атаку на прикладі WordPress, а потім ще на прикладі Invision Power Board (про можливість такої атаки на IPB я знаю ще з 2007 року), але вирішив зробити про це детальну статтю.

Пошкодження таблиць в MySQL.

MySQL підтримує різні типи таблиць, які ще називають движками (storage engines). І різна кількість движків таблиць підтримується в різних версіях СУБД, зокрема MySQL 5.0 підтримує 10 движків. В MySQL існує такий тип таблиць як MyISAM. Вони є більш швидкими в роботі ніж інши типи таблиць і на протязі багатьох версій MySQL по замовчуванню використовує саме MyISAM движок при створенні нових таблиць (до версії MySQL 5.5.5). І в цього движка є важлива проблема - таблиці можуть псуватися (за звичай це індекси таблиць, тобто самі таблиці з даними залишаються цілими). Це стосується MyISAM та ISAM движків.

І відповідно їх потрібно рементовувати, для чого існує функція REPAIR для MyISAM таблиць. Функціонал ремонту може бути доданий у веб додаток - наприклад, IPB 2 і вище мають таку функцію в адмінці, а також такий функціонал додали в WordPress 2.9, але, як я писав, в ньому є DoS уразливість. Якщо такого функціоналу немає, що типово для більшості веб додатків, то потрібно використовувати будь-яки додатки для роботи з MySQL, в тому числі веб додатки, такі як MySQL Perl/CGI Client та phpMyAdmin.

Приклади вразливих додатків.

В 2009 році я розповів про можливість проведення даної атаки на WordPress (для DoS та повного захоплення сайта), а в 2011 році я розповів про атаки на IPB 1, IPB 2 та IPB 3 (для DoS). Інші веб додатки, що використовують MySQL і MyISAM таблиці, також вразливі до даної атаки.

Враховуючи, що пошкодженні таблиці є недоступними для веб додатку, то він перестає нормально проацювати. Проблема може торкнутися як якогось одного функціоналу сайту, так і усього сайту - коли веб додаток повністю перестане працювати і буде лише виводити повідомлення про помилку. Доки пошкодженні таблиці не відремонтують. Наприклад, коли пошкодити важливу таблицю в WordPress, то сайт перестає працювати і на всіх сторінках сайта виводиться повідомлення - в старих версіях движка виводиться “It doesn’t look like you’ve installed WP yet”, а в нових версіях виводиться “Error establishing a database connection”.

А враховуючи, що у веб додатках не використовуються автоматичний ремонт таблиць - я не знаю жодного такого веб додатку - то проблеми на сайті будуть доти, доки адмін сам не відремонтує таблиці (використовуючи будь-які програми для роботи з MySQL, щоб виконати REPAIR для цих таблиціь). Як я вже писав про WordPress, де в WP 2.9 розробники як би зробили автоматичне виправлення (після мого оприлюднення вищезгаданої атаки на WP), але, як я виявив, насправді вони збрехали і в движку не було зроблено автоматичного виправлення таблиць, і потрібно вручну запускати скрипт для ремонту таблиць.

Напрямки атаки.

Основними напрямками атаки через пошкодження таблиць в MySQL є наступні:

1. Проведення DoS атак. Створивши умови для пошкодження таблиць БД (через навантаження сайта), можна провести DoS атаку на сайт. Прикладами веб додатків уразливих до таких атак є WordPress та IPB.

2. Повне захоплення сайту. При наявності на сайті інсталятора та провевши DoS атаку (описану в п.1) на таблиці до яких чутливий інсталятор, можна змусити його вирішити, що движок не інстальований на сайті й провести переінсталяцію движка. Прикладами веб додатків уразливих до таких атак є WordPress.

Проведення атаки.

Для атаки потрібно знайти таблицю до якої чутливий веб додаток. Раніше я вже розповів до яких таблиць чутливі WordPress та Invision Power Board. WP чутливий до тиблиць wp_options та wp_users, а IPB чутливий до таблиць ibf_topics та ibf_session.

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

Висновки.

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

В документі Verifed by Visa and MasterCard SecureCode: or, How Not to Design Authentication розповідається про протокол 3-D Secure (3DS) і такі реалізації даного протоколу як Verifed by Visa та MasterCard SecureCode. Та про ризики безпеки, що існують при їх використанні власниками пластикових карток.

В своїй статті Справжня безпека сайтів із секюріті логотипами я вже писав при діряві сайти з логотипами VbV та MCSC, про підміну даними логотипами необхідності відповідати стандарту PCI DSS (та проводити відповідні аудити) та ігнорування проблем безпеки на цих сайтах. В даному ж документі, автори Steven J. Murdoch і Ross Anderson зосередилися на недоліках протоколу 3DS та шляхах його покращення.

В статті розглянуті наступні проблеми 3DS, зокрема таких систем як Verifed by Visa та MasterCard SecureCode:

1. Статистика шахрайства з платіжними картами.
2. Слабкості безпеки.
3. Шляхи покращення безпеки.

Системи, що базуються на протоколі 3DS мають багато недоліків (автори наводять сім основних проблем), що впливають на безпеку транзакцій, зокрема card-not-present (таких як транзакції через Інтернет). Тому для кращої продидії шахрайству з платіжними картами потрібно покращувати дані системи.

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

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

• Virtual machine escape
• DNS hijacking
• Email injection
• Frame injection
• Inter-protocol communication