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

Атака через браузер. Аналіз шкідливих Flash та PDF файлів

22:43 08.12.2011

В статті Атака через браузер. Анализ вредоносных Flash-объектов и документов в формате PDF розповідається про сучасні атаки через браузери (сайт журнала в даний момент не працює із-за технічних робіт, тому статтю слід шукати на інших сайтах в Мережі). Зокрема через плагіни до браузерів, такі як Adobe Acrobat та Adobe Flash.

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

  • Введення.
  • Аналіз шкідливих файлів.
  • Приклад 1. PDF + JavaScript.
  • Приклад 2. SWF.
  • Приклад 3. PDF + SWF.
  • Висновки.

Використання уразливостей в популярних плагінах до браузерів, таких як Acrobat і Flash, в останні роки стало одним з найбільш популярних напрямків атак на користувачів Інтернету. Окрім шкідливих pdf і swf файлів, також використовуються комбіновані експлоіти, такі як флеш-контент у pdf-файлі.

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

22:40 06.12.2011

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

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

Гугл-фішинг (Google-phishing)

20:12 03.12.2011

Розповім вам про Гугл-фішинг (Google-phishing). Це метод проведення фішинг атак Гуглом, з яким я стикнувся сьогодні.

Все почалося з того, що сьогодні моя подруга повідомила про один інцидент, який в неї трапився з поштою Gmail. Який призвів до того, що її акаунт був заблокований Гуглом і вона не може потрапити до свого поштового акаунту. Коли вона згадала про те, що з неї вимагали кошти (оплата кредиткою), в мене одразу з’явилася думка, що це фішинг атака. Але вислухавши всю її розповідь стало зрозуміло, що це саме Гугл її заблокував і почав з неї вимагати гроші або документи. Що я підтвердив, коли на власні очі побачив відповідні повідомлення Гугла, зайшовши в її акаунт. Враховуючи те, як Гугл поводить себе в рамках цієї “верифікації”, я назвав це Гугл-фішингом (Google-phishing).

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

Будь-якому користувачу сервісів компанії Google може вивестися повідомлення про необхідність пройти верифікацію віку. І якщо вказати невірні дані (або вірні дані, але людина має недостатній вік), коли вік буде менше 13 років, то акаунт буде заблокований. При блокуванні Гугл виводить “The Google Account for …@gmail.com has been disabled” (для інших сервісів повідомлення відповідне). Більш того, Гугл дає 30 днів на розблокування, після чого акаунт видаляється. І якщо ви цим акаунтом користовулися для пошти, то ваша поштова скринька (з усіма листами) буде видалена, те саме стосується блогів на блог-хостінгу Blogger та інших сервісів Гугла.

Детально про верифікацію віку (age verification) можна прочитати на сайті Гугла. Всього Гугл пропонує три методи розблокування:

  • Оплатити кредиткою - зробити оплату на $0,30 (при цьому банк ще може зняти $1 за проведення транзакції). При цьому компанія обіцяє, що ця сума буде повернута (але це не стосується плати, що може зняти банк).
  • Відправка скана документа, що засвідчує особу та її вік, через сайт.
  • Відправка скана документа через пошту або факс.

Всі ці вимоги Гугла я вважаю перебільшеними. І подібний підхід, щоб заблокувати акаунт, а потім вимагати гроші з кредитки або скан паспорта, я можу назвати тільки як фішинг. В даному випадку Гугл-фішинг, який ще можна назвати Age verification phishing.

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

Окрім Age verification phishing, також може бути проведена атака - Age verification attack. Коли зловмисники атакують (через CSRF або при тимчасовому доступі до акаунту) будь якого користувача сервісів Гугла і заблокують йому акаунт. Після чого йому доведеться витратити час (і потенційно й кошти) для його розблокування. А якщо людина відсутня деякий час (наприклад, поїхала у відпуску), коли сталася дана атака, і термін в 30 днів пройшов, коли вона виявила, що таке трапилося, то людина залишиться без свого акаунта. І без усіх даних, що в ньому знаходилися.

Методи захисту від ClickJacking

22:42 02.12.2011

Раніше я розповідав про методи захисту від ClickJacking в статті Заголовок X-Frame-Options, де розповів про один з таких методів. А зараз розповім про всі основні методи захисту від ClickJacking. Зазначу, що дані методи (з різною ефективністью) можуть також використовуватися для захисту від MouseOverJacking.

Існують наступні методи захисту від ClickJacking:

  • На стороні клієнта:
    • Ghostery
    • NoScript
    • GuardedID
    • Gazelle
  • На стороні сервера:
    • Framekiller (працює у всіх браузерах)
    • Заголовок X-Frame-Options (вимагає підтримки зі сторони браузера)

Якщо client-side методи вимагають наявності у користувача спеціального плагіна (Ghostery, NoScript чи GuardedID) або спеціального браузера (Gazelle) для захисту від ClickJacking, то server-side методи, зокрема Framekiller, цього не вимагають.

За виключенням заголовка X-Frame-Options. Який вимагає як наявності відповідного браузера (останні версії основних п’яти браузерів), так і необхідності веб розробникам і адмінам сайтів додавати його підтримку на сайтах (щоб сайти виводили даний заголовок), щоб захист спрацював у браузері користувача.

Низькорівневий пошук уразливостей у веб-додатках

22:43 01.12.2011

В статті PHP-дайвинг: низкоуровневый поиск уязвимостей в веб-приложениях розповідається про низькорівневий пошук уразливостей у веб-додатках, зокрема у PHP-додатках. Який автор статті назвав PHP-дайвінгом.

В даній статті розглянуті наступні аспекти пошуку уразливостей у PHP-додатках на низькому рівні:

  • Ціль дайвінгу.
  • Процес обробки веб-додатку PHP інтерпретатором.
  • Інструменти: Vulcan Logic Dumper (vld), bytekit та evalhook.
  • Приклади дайвінгу.
  • Додаткові техніки.

Пошук уразливостей у PHP-додатках на низькому рівні має свої переваги. Зокрема він може застосовуватися там, де не можна використати аналіз вихідних кодів (whitebox підхід) - при пошуку уразливостей в закритому коді PHP-програм.

Забезпечення безпеки веб сервісів через політики

20:16 25.11.2011

В презентації Seamlessly Securing Web Services Using Policies, Mifla Mashood та Gihan Wikramanayake розповідають про забезпечення безпеки веб сервісів. Що пропонується роботи за допомогою політик, зокрема політик стандарту WS-Policy.

Заголовок X-Frame-Options

22:43 19.11.2011

Після появи такої техніки атаки як Clickjacking, розробленої Джеремією Гроссманом та Робертом Хенсеном в 2008 році, виробники браузерів почали замислюватися над методом протидії даній атаці. Щоб не чекати доки кожен окремий веб розробник почне додавати захист від Clickjacking (а також від MouseOverJacking, розробленої мною), а зробити захист на рівні браузера. Як це зробив розробник NoScript плагіна для Firefox, додавши подібний захист ще в 2008 році.

І на початку 2009 року, з виходом Internet Explorer 8, було розроблене рішення для протидії Clickjacking та MouseOverJacking атакам. Це http-заголовок X-Frame-Options. Це було одне з найкращих покращень безпеки в 2009 році (але в своєму записі я вже описав можливості обходу цього захисного методу). Детально про цей заголовок, його формат та значення заголовка, що підтримуються браузерами, ви можете прочитати на сайті Mozilla в статті The X-Frame-Options response header.

На даний час підтримуються наступні значення заголовка X-Frame-Options:

  • DENY - сторінка (з будь-якого сайта) не може бути показа у фреймі.
  • SAMEORIGIN - сторінка може бути показана у фреймі, якщо вона знаходиться на тому самому сайті (домені).

Спочатку Microsoft реалізувала його в своєму браузері IE8, а потім інші виробники браузерів додали його підтримку. На даний момент, за даними Мозіли, наступні браузери підтримують заголовок X-Frame-Options (починаючи з вказаних версій):

  • Internet Explorer 8.0.
  • Firefox 3.6.9 (Gecko 1.9.2.9).
  • Opera 10.50.
  • Safari 4.0.
  • Chrome 4.1.249.1042.

Метод захисту від Clickjacking та MouseOverJacking атак за допомогою заголовка X-Frame-Options має свої переваги та недоліки.

Переваги методу:

  1. Захист від атак через приховані frame та iframe.
  2. Легкість реалізації на сайті - потрібно лише додати на необхідну сторінку (або на весь сайт) даний заголовок.
  3. Два режима блокування: DENY і SAMEORIGIN.
  4. Всі основні п’ять браузерів (їх останні версії) підтримують даний заголовок.

Недоліки методу:

  1. Веб розробникам і адмінам потрібно додавати його підтримку на сайті, щоб захист спрацював у браузері. Тобто по замовчуванню всі сайти є уразливими до даних атак (навіть у версіях браузерів, що підтримують цей заголовок), доки на них не буде налаштоване виведення цього заголовка.
  2. Методика атак через CSS, що я описав в статті про MouseOverJacking, дозволяє обходити даний захист та може застосовуватися для проведення Clickjacking та MouseOverJacking атак.
  3. Не всі браузери підтримують цей заголовок, в тому числі старі версії основних п’яти браузерів. Тому мільйони користувачів цих браузерів будут незахищені перед атаками, навіть на сайтах, що використовують цей заголовок.

Обхід аутентифікації через SQL Injection

22:44 17.11.2011

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

sql injection

В даному відео ролику демонструється одна з найбільш простих і відомих SQL ін’єкцій. Але в даному випадку має місце не просто SQL Injection атака, а обхід аутентифікації через SQL Injection. Тому що SQL ін’єкція має місце в формі аутентифікації. Причому автор відео знайшов дану уразливість на сайті університету (web.arizona.edu) в старій версії phpMyAdmin (версія 2.5.6).

Подібні SQL ін’єкції в формах аутентифікації достатньо поширені. Я сам багато разів знаходив такі уразливості на різних сайтах та в різних веб додатках, про що я вже писав, зокрема в CMS WebManager-Pro. Рекомендую подивитися дане відео для розуміння векторів атак через SQL Injection.

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

20:19 04.11.2011

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

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

Зміна адмінського пароля в Joomla

20:01 03.11.2011

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

Reset Admin Password for Joomla

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

При наявності доступа до БД сайта (при наявності доступа до менеджерів СУБД на сайті, таких як phpMyAdmin та MySQL Perl/CGI Client, або розміщені на сайті шела з таким функціоналом, або навіть менеджера СУБД), можна змінити пароль адміна. Рекомендую подивитися дане відео для розуміння векторів атак через доступ до БД.