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

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

Лінку на дану книгу люб’язно надав Роман в своєму книжному огляді. До речі, в своєму пості Роман згадує про цікавий випадок, який з ним стався коли він вирішив придбати собі в онлайні книги. В результаті замовлення книг на сайті магазину аудиокниг, він на додачу до самого зомовлення, ще й виявив серйозну 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. Так що дана уразливість повернулася . І тому адміністраторам варто не забувати оновлювати свої Апачі.

В листопаді минулого року була виявлена Cookie Authentication уразливість в WordPress (про наявність даної особливості роботи з кукісами було відомо й раніше). При наявності доступу до БД можна відтворити кукіс будь-якого користувача системи.

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

Вразливі версії WordPress від 1.5 по 2.3.3. Новий підхід до роботи з кукісами був запроваджений в WordPress 2.5. В якому була виявлена уразливість (причому тим же секюріті дослідником Steven Murdoch) в роботі нового механізму управління кукісами.

• Wordpress Cookie Authentication Vulnerability (деталі)

Три дні тому, 25.04.2008, вийшла нова версія WordPress 2.5.1 - оновлення для гілки WP 2.5.x.

WordPress 2.5.1 це багфікс та секюріті випуск для 2.5 серії. В даній версії була виправлена Insufficient Authorization уразливість (Cookie Integrity Protection Vulnerability), про яку я писав. Що дозволяла отримати доступ до акаунта адміністратора. Також була виправлена XSS уразливість.

На доданок до секюріті виправлень в версії 2.5.1 також виправлено 70 багів. Зокрема, були зроблені наступні виправлення:

• Покращення швидкодії для сторінок Dashboard, Write Post та Edit Comments.
• Краща швидкодія для тих, хто має багато категорій.
• Виправлення в Media Uploader.
• Апгрейд до TinyMCE 3.0.7.
• Виправлення в Widget Administration.
• Різноманітні покращення юзабіліті.
• Виправлена розмітка для IE.

Учора, 25.04.2008, була оприлюднена Insufficient Authorization уразливість в WordPress 2.5. Деталі уразливості поки не повідомляються, але вона доволі серйозна, тому що дозволяє отримати доступ в адмінський акаунт. Тому розробники WP випустили нову версію системи.

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

Вразлива версія WordPress 2.5. Дана уразливість виправлена в WordPress 2.5.1.

P.S.

Опублікував лінку на детальну інформацію про Cookie Integrity Protection Vulnerability в Wordpress 2.5.