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

Два дні тому я виявив DoS уразливість в Internet Explorer 6. DoS я виявив, як раз коли перевіряв DoS уразливість в Microsoft Internet Explorer 7 (тому вона має місце в IE6 та IE7). І на основі даного PoC я розробив свій експлоіт, який ви можете використати в якості теста для вашого браузера.

В результаті роботи експлоіта браузер вилітає. Даний експлоіт працює на Internet Explorer 6 під Windows XP SP2 і повинен працювати під Internet Explorer 7 (виходячи з інформації автора PoC, з якого я зробив свій експлоіт).

Протестувати:

Internet Explorer 6 & 7 DoS.html

Останній тест для IE був DoS в Internet Explorer, з яким ви також можете ознайомитися.

В лютому, 26.02.2008, я знявся для телепередачі телеканалу Інтер. І спеціально для мого виступу на Інтері я розробив презентацію про фішинг-атаки через Інтернет.

Презентація доступна на українській та російській мові:

Фішинг-атаки через Інтернет на користувачів банків

Фишинг-атаки через Интернет на пользователей банков

В презентації наводяться приклади фішерських атак через підставний сайт пошукової системи, підроблений сайт банку та через уразливість на сайті банку.

В своєму пості The Danger of Pre-canned RFI Exploits, RSnake підняв цікаву тему. Готові RFI експлоіти можуть бути небезпечними (тим чи іншим чином). І якщо бути не дуже уважним, і особливо якщо той, хто запускає експлоіт не сильно розбирається в RFI уразливостях та експлоітах для них, то можна зіштовхнутися з деякими проблемами.

Аналізуючи коди різних експлоітів, як для RFI, так й інших уразливостей, мені доводилося зіштовхуватися з деякими “бонусами”, що залишили їх розробники . В своєму пості RSnake зупинився саме на Remote File Include експлоітах. Він наводить три приклади, розглядаючи потенційні проблеми, котрі можуть виникнути при необережному використанні експлотів.

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

Пропоную вам ознайомитися з цікавою книгою Кевіна Мітника “Искусство обмана“. В своїй книзі “Мистецтво обману”, Кевін розповідає про соціальну інженерію, про те як він опанував дану професію (наводить деякі деталі своєї біографії) і про можливості її використання.

Лінку на дану книгу люб’язно надав Роман в своєму книжному огляді. До речі, в своєму пості Роман згадує про цікавий випадок, який з ним стався коли він вирішив придбати собі в онлайні книги. В результаті замовлення книг на сайті магазину аудиокниг, він на додачу до самого зомовлення, ще й виявив серйозну Information Leakage дірку (що приводила до витоку конфеденційних даних покупців магазину).

Як він зазначив, після того як він повідомив власникам сайта, дірку залатали швидко, а ось про спасибі забули. На жаль, це звичайна ситуація (для власників будь-яких сайтів). Про те, що власникі сайтів забувають казати спасибі за повідомлення про уразливості на їх сайтах, я знаю дуже добре: за 2006, 2007 та 2008 роки, що я займаюсь соціальним секюріті аудитом, з подібнім видношенням зіткався і зіткаюся дуже часто (я почав зіткатися з несерйозним відношенням починаючи ще з 2005 року, як почав займатися напрямком веб безпеки, і по сьогодні).

P.S.

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

В травні минулого року була виявлена Cross-Site Scripting уразливість в stats плагіні для WordPress.

Це persistent XSS уразливість, яка мала місце в плагіні stats, що дозволяє мати статистику відвідувань від wordpress.com. Уразливим було поле referer в статистиці, що накопичує плагін. Дана уразливість вже виправлена.

• Persistent cross-site scripting in wordpress.com dashboard (деталі)

01.05.2008

Продовжу тему безпеки секюріті сайтів, яку я піднімав в попередніх записах Безпека сайтів про безпеку, 2, 3, 4, 5, 6, 7 та 8.

Ось нова добірка уразливих секюріті сайтів:

• www.cisco.com
• www.shram.kiev.ua (хакерський сайт)
• www.ibm.com

Всім security проектам та компаніям слід приділяти більше уваги власній безпеці.

10.06.2008

Ще одна добірка уразливих секюріті сайтів:

• www.spidynamics.com та hp.com
• www.nstalker.com
• shiflett.org

Секюріті компаніям, особливо тим, що випускають сканери безпеки, варто більше слідкувати за безпекою власних сайтів.

Сьогодні вийшла нова версія програми Perl Pas Interpreter v.1.4.2. В новій версії:

• Додана константа e (з 16-бітною точністю).
• Оптимізована робота з константами.
• Покращена робота write та writeln з пробілами.
• Покращена робота вбудованих функцій з пробілами.

Деталі на сайті інтерпретатора. Тема для обговорення програми на форумі.

Додаткова інформація про Perl Pas Interpreter в розділі Онлайн інструменти.

Темою зараженості веб сайтів я цікавлюся вже деякий час і в цьому році я почав активно проводити дослідження цього питання. Зокрема, в своїй статті про стан зараженості Уанета, я приводив дані про стан зараженості Уанета в попередні роки та зпрогнозував стан на 2008 рік (і я прогнозував подальше збільшення зараженості Уанета).

І зараз я приведу один з прикладів, що підтверджує мої прогнози. В січні я вже писав про небезпечний сайт Партії регіонів.

Нещодавно, 25.05.2008, шукаючи в Гуглі деяку інформацію, я виявив, що сайт dn.kiev.ua інфікований. Тому що Google заявив, що “Ця сторінка може заподіяти шкоду вашому комп’ютерові”. Гугл може й помилятися з такими ярликами, але частіше все ж таки вони вірно відмічають інфіковані сайти.

Після того, як я сам перевірив сайт онлайн ЗМІ “Деловая неделя” http://dn.kiev.ua, я впевнився, що він інфікований. На даному сайті розміщений шкідливий script, причому в зашифрованому вигляді, що створює iframe на скрипт на зовнішньому сайті (що в свою чергу редиректить на інший шкідливий сайт).

Адмінам dn.kiev.ua варто витерти шкідливий код зі свого сайта і почати серйозно слідкувати за безпекою власного сайта. Бо уразливостей на ньому вистачає (як я глянув лише на одній головній сторінці), про що красномовно засвідчив цей випадок з розміщенням на сайті шкідливого коду.

При необхідності відправити CSRF запит (при CSRF атаці) через POST, потрібно використовувати форму. Це класичний метод. Для автоматичної відправки запиту з форми використовується ява-скрипт. Подібні форми (для POST атак при XSS, CSRF та Insufficient Anti-automation уразливостях) я багато разів приводив в себе на сайті, зокрема в проекті MoBiC.

Також існує інша можливість відправки POST CSRF запитів - використання CSRF редиректорів.

Chris Shiflett розробив такий CSRF Redirector. Це GET в POST редиректор, що автоматично переводить GET запит в POST.

Формат запиту наступний:

http://shiflett.org/csrf.php?csrf=http://site/script&parameter=value

Можливість використання даного CSRF редиректора я приводив раніше на прикладі уразливості на www.itmg.com.ua.

XSS через GET:

• alert(document.cookie)

Одною з проблем даного сервісу, якщо зробити такий публічний CSRF редиректор, є те, що на сайті з’явиться redirector уразливість. Котру всі бажаючі зможуть використовувати як для хороших (як в моєму випадку), так і поганих цілей. Тому подібні уразливості також не варто допускати на своїх сайтах.

Як написав RSnake в своєму записі More Expect Exploitation In Flash, використання флеша для проведення XSS атак через заголовок Expect знову можливе. Раніше у флеші можна було відправляти заголовки Expect і деякий час тому Adobe виправила це (заборонивши цю можливість). Але як вияснилося, є можливість обійти цю заборону і відправляти заголовки Expect.

Для проведення у флеші XSS атак через заголовок Expect на старі версії Apache раніше використовувався наступний синтаксис:

req.addRequestHeader("Expect","<script>alert('XSS')</script>");

Що було виправлено в нових версіях флеш плагіна. Але, як виявив Titon, зараз можна відправляти Expect заголовки наступним чином:

req.addRequestHeader("Expect:FooBar","<script>alert('XSS')</script>");

Тобто додавши деякий текст після двокрапки можна обійти дану заборону і виконати у флеші XSS атаку через заголовок Expect. Так що дана уразливість повернулася . І тому адміністраторам варто не забувати оновлювати свої Апачі.