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

В презентації Malware Defense-in-Depth 2.0, Aaed Alqarta розповідає про захист від шкідливого коду. Він описує концепіцію багаторівневого захисту від malware, причому її другу версію, призначену протидіяти шкідливому програмному забезпеченню, що розповсюджується у Веб 2.0.

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

Hacking [ Windows Vista ] By Private Exploit In Browser Google Chrome

В даному відео ролику демонструється процес використання експлоіта для браузера Google Chrome. Причому це приватний експлоіт. Дана уразливість в Chrome призводить до пошкодження пам’яті в браузері й виконання довільного коду.

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

В статті Бэкдор в БД: протроянивания MySQL с помощью хранимых функций, процедур и триггеров розповідається про створення бекдору в СУБД MySQL. Для цього використовуються збережені функції, процедури і трігери.

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

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

• Збережені процедури і тригери.
• Необхідність логування.
• Троянимо WordPress.
• Трігер для vBulletin.
• Кришимо “Булку”.
• Доступ є. Що далі.
• Старі трюки з UDF.

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

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

BEAST vs HTTPS

В даному відео ролику розповідається про використання BEAST-атаки. BEAST (Browser Exploit Against SSL/TLS) - це інструментарій для атаки на SSL/TLS, що дозволяє організувати перехоплення переданого в рамках зашифрованого з’єднання Cookie з параметрами аутентифікації користувацької сесії.

У відео показане використання BEAST для отримання кукіса від аккаунта PayPal. Даний інструментарій дешифрує переданий в рамках https-з’єдння сесійний кукіс. Рекомендую подивитися дане відео для розуміння векторів атак через уразливість в SSL/TLS.

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

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

• Hacking
• Penetration test
• Physical security
• Ring (computer security)
• Security engineering

В цьому місяці в журналі “PenTest Extra” була опублікована моя стаття. В січневому номері журналу PenTest Extra 01/2012, що вийшов 15.01.2012, опублікована стаття “Business Logic vulnerabilities via CSRF” (на англійській мові).

В ній розповідається про Business Logic уразливості, атака на які проводиться через CSRF. Дані уразливості дозволяють викрадати гроші з рахунків користувачів на сайтах банків, електронних платіжних систем та інших е-комерс сайтів. Такі уразливості я неодноразово знаходив та писав про них в новинах.

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

А також в даній статті я вперше анонсував свій новий інструмент Генератор CSRF, що призначений для створення CSRF експлотів. На якому були зроблені всі приклади експлоітів для статті.

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

Як я вже неодноразово розповідав, окрім виконання коду на сервері при завантаженні скриптів з відповідними розширеннями (як то php-скрипта у вигляді файла з розширенням php), існують альтеранативні методи. Відомі три методи виконання коду, коли розширення файла відмінне від того, яке повинно виконуватися на сервері відповідно до його налаштувань. Які дозволяють обходити захисні механізми веб додатків і проводити Code Execution атаки.

Обхідні методи виконання коду:

1. Через “1.asp;.txt” в імені файла. Працює в IIS.

Дана атака була названа semicolon attack. Ця уразливість була знайдена в 2009 році.

2. Через “1.asp” в імені папці. Працює в IIS.

Дана можливість виконання коду в Microsoft IIS була знайдена в 2011 році.

3. Через подвійне розширення (1.php.txt). Працює в Apache (з спеціальною конфігурацією). Цей метод відомий вже багато років, але все ще є дуже багато веб додатків вразливих до нього.

Про два перших методи (для IIS) я вже розповідав у вищезгаданих записах, а зараз я розповім детально про третій метод (для Apache). Ще в травні 2010 я запланував написати цю статтю і ось нарешті знайшов час.

Code Execution в Apache:

Атака відбувається при завантаженні через аплоадер файла, наприклад, з PHP кодом (або іншого скрипта), з подвійним розширенням. Це може знадобитися, коли завантаження php-файлів заборонене.

http://site/1.php.txt

Цей метод я виявив ще 04.11.2007 в себе на http://websecurity.com.ua коли зробив екслоіт для reCaptcha. Спочатку я зробив файл reCaptcha.pl.txt, але файл виконувався на сервері (як Perl скрипт, хоча і мав останнє розширення txt), тому я його перейменував на reCaptcha.txt і з тих пір в себе на сайті розміщую експлоіти як txt-файли (без подвійних розширень).

Спочатку я вирішив, що це некоректе налаштування на моєму сервері. Але потім я почав знаходити випадки такої misconfiguration на інших сайтах. З тих пір я ще неодноразово зустрічав подібні випадки на багатьох сайтах, тобто це поширене явище. Яке використовується для атаки на веб сайти.

Дана атака можлива через специфічні налаштування Apache. Вона пов’язана з модулем mod_mime. Тому атака можлива тільки на серверах Apache з модулем mod_mime.

В презентації General Principles of Web Security, Justin Emond розповідає про загальні принципи веб безпеки. Про SQL iн’єкції, міжсайтовий скриптінг та загальні погляди на безпеку при розробці веб додатків.

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

How To Find The Admin Control Panel Page

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

У відео показане використання програми (Perl-скрипта) для пошуку адмінки. Сама програма Admin Control Panel Finder представляє собою сканер ресурсів зі стандартними шляхами, але заточена саме на пошук адмінок. Рекомендую подивитися дане відео для розуміння векторів атак через Predictable Resource Location уразливості.

В Internet Explorer 9, що вийшов у березні цього року, було додано ряд покращень, що стосуються безпеки. Про які я розповів у вищезгаданому записі.

І окрім технології “Tracking Protection”, про яку я писав раніше, що підсилює захист конфіденційної інформації - на додаток до функцій InPrivate Browsing та InPrivate Filtering, доступним ще в Internet Explorer 8 - також були додані технології захисту від шкідливого коду. Сукупність цих технологій називається Malware protection.

Багаторівневий захист від malware в IE9 забезпечується наступними технологіями:

1. Використовуються такі засоби для захисту пам’яті як DEP/NX, Safe Exception handlers (SafeSEH) та ASLR, що використовувалися і в Internet Explorer 8.

2. Окрім вищегаданих функцій для захисту пам’яті, браузер також підтримує SEHOP (Structured Exception Handler Overwrite Protection). Це дозволяє забезпечити, що structured exception handling не можуть бути використані як вектор атаки, навіть якщо використовуються старі плагіні до браузера, що не були перекомпільовані для використання покращень SafeSEH.

3. Internet Explorer 9 скомпільований новим C++ компілятором з Visual Studio 2010. Який включає таку функуцію як Enhanced GS, також відому як Stack Buffer Overrun Detection.

4. Якщо IE8 використовував технологію SmartScreen, яка, за словами Microsoft, була успішною проти фішингових та інших шкідливих сайтів, так в блокуванні socially engineered malware. То в IE9 даний захист проти шкідливого коду був розширений за рахунок технології SmartScreen Application Reputation. Що попереджає користувача, якщо він викачує додаток без безпечної репутації з сайту без безпечної репутації. Але даний захисний маханізм має ряд недоліків.

Недоліки маханізму SmartScreen Application Reputation в IE9:

1. Цей захист від шкідливого коду в браузері недостатньо надійний. Тому що коли весь час, де треба і де не треба, питати користувача чи хоче він дозволити викачати файл, то це може надоїсти користувачу і він втратить пильність - почне просто вес час “дозволяти”. І таким чином захистний механізм перестане виконувати свою функцію.

2. З іншої сторони даний функціонал, коли запитується під час кожного скачування файлів, можна використати для DoS атаки. Подібно до тих численних DoS уразливостей в браузерах, про які я писав в 2008-2010 роках. Коли весь час показувати діалогові вікна, браузер буде заблокований і їм буде неможливо користуватися.