В презентації Encryption in the Public Cloud: 16 Bits of Advice for Security Techniques, Dave Asprey розповідає про шифрування в публічних хмарах. Про безпеку інформації при використанні публічних хмарних сервісів, зокрема про шифрування даних. Щоб у випадку взлому такого сервісу (а я неодноразово писав про такі інциденти), ваші дані були в безпеці.
В статті Включення бекдорів у веб додатки я розповів про основні шляхи потрапляння бекдору у веб додатки та навів приклади випадків впровадження бекдору у веб додатки та в відкриті операційні системи. Дана стаття є продовженням попередньої.
До раніше наведених веб додатків, в яких були виявленні бекдори, додам нові веб додатки, а також різні мережеві пристрої та серверні програми. В деяких випадках чорні ходи були додані розробниками, а в інших випадках бекдори були додані зловмисниками в код популярних веб додатків.
Випадки впровадження бекдору у веб додатках, мережевих пристроях та серверних програмах:
В попередній статті я писав про розміщення бекдору в WordPress (що мав місце в 2007 році), а також писав про забекдорені плагіни для Joomla. І з останнього прикладу з плагіном Social Media Widget для WP видно, що зловмисники шукають різні способи поширення шкідливого коду. Якщо забекдорити сам движок не вдається, то бекдорять плагіни для нього. З моєї статті випливало, що в будь-який веб додаток можуть потрапити бекдори, і цей випадок з плагіном наявне цьому підтвердження.
Розглянемо інструменти для пошуку чорних ходів. Окрім пошуку бекдорів вручну (як найбільш надійний метод), також можна використовувати спеціальні програми. Про багато з таких програм я писав раніше.
Наступні веб додатки мають функціонал пошуку бекдорів:
Також у грудні я розробив приклад простого веб додатку з вбудованим бекдором - Backdoored Web Application. Він призначений для перевірки систем пошуку бекдорів.
Продовжуючи розпочату традицію, після попереднього відео про ботнети: захоплення та керування, пропоную нове відео на веб секюріті тематику. Цього разу відео про захоплення мережі через руткіти для роутерів. Рекомендую подивитися всім хто цікавиться цією темою.
DEFCON 20: Owning the Network: Adventures in Router Rootkits
Торік на конференції DEFCON 20 відбувся виступ Michael Coppola. В своєму виступі він розповів про атаки на роутері, про створення руткітів для них та встановлення їх в роутери для контролю над пристроями. Що може використовуватися для створення ботнетів з мережевих пристроїв - про такі випадки я писав неодноразово.
Майкл розповів про різні аспекти теми руткітів для роутерів. Рекомендую подивитися дане відео для розуміння сучасних загроз в Інтернеті.
Продовжуючи розпочату традицію, після попереднього відео про сліпі XSS, пропоную нове відео на веб секюріті тематику. Цього разу відео про ботнети: захоплення та керування. Рекомендую подивитися всім хто цікавиться цією темою.
DEFCON 20: Botnets Die Hard - Owned and Operated
Торік на конференції DEFCON 20 відбувся виступ Aditya K. Sood та Richard J. Enbody. В своєму виступі вони розповіли про ботнети. Про існуючі ботнети і сучасні напрямки розвитку ботнетів, про те як відбувається контроль на ними, як перехопити цей контроль у зловмисників, з метою захоплення та керування ботнетом (щоб повністю відключити його, як це роблять секюріті фахівці, що борються з ботнетами).
Вони розповіли про багато різних аспектів ботнетів. Рекомендую подивитися дане відео для розуміння сучасних загроз в Інтернеті.
Продовжу тему “Error” Гугл хакінга (”Error” Google hacking). Котрий є різновидом Гугл хакінга - використання пошукових систем (зокрема Гугла) для пошуку уразливостей на сайтах.
Дана методика передбачає використання Гугла (чи інших пошукових систем) з метою пошуку повідомлень на сайтах про помилки, і дозволяє знайти важливу інформацію стосовно даних сайтів. За допомогою спеціальних пошукових запитів (дорків) можна знайти Full path disclosure та Information leakage уразливості на різноманітних сайтах в Інтернеті.
Новий перелік “еррор” пошукових запитів:
Продовжуючи тему технологій захисту від Cross-Site Scripting атак, після статей про HttpOnly та метод захисту з JavaScript, розповім про іншу технологію захисту від XSS атак. Яка передбачає використання заголовка X-XSS-Protection.
Заголовок X-XSS-Protection встановлюється на сервері до всіх веб сторінок, які треба захистити від XSS атак на стороні клієнта (тобто це клієнтська технологія, що вимагає підтримки браузером). Для цього веб додаток повинен у своїй відповіді вказати відповідний серверний заголовок:
X-XSS-Protection: 1; mode=block
Якщо вказати “1″, то браузер з підтримкою цього заголовка, включить захист від XSS на даній сторінці. Режим захисту може бути стандартний (фільтрація потенційного XSS коду), або блокування (що задається параметром mode=block).
Даний заголовок був розроблений Microsoft і вперше його підтримка була додана в Internet Explorer 8 в березні 2009. Пізніше Google додала його підтримку в свій браузер Chrome. В 2010 році була виявлена уразливість в XSS Filter в IE8, що дозволяла виконувати атаки на веб сторінки, що навіть не мали XSS уразливостей.
Особливості даної технології:
1. Використання заголовка захищає лише від reflected XSS.
2. Захист працює лише в браузерах, що підтримують заголовок. В цьому плані технологія схожа на HttpOnly (але HttpOnly підтримують набагато більше браузерів).
X-XSS-Protection підтримують наступні браузери:
Internet Explorer 8+
Google Chrome 8+ (спочатку в версії 4.0 була додана експериментальна функція “XSS Auditor”, але в версії 4.1 вона була відключена через виявлені уразливості й знову включена лише в версії 8.0).
Дана технологія захисту від XSS атак має свої достоїнства та недоліки. Як я вже казав, жодна з цих допоміжних технологій не може дати 100% гарантію захисту від XSS атак і вирішує лише частину проблеми, тільки виявлення та виправлення всіх XSS уразливостей дасть надійних захист. Але ці технології можна використати в парі з проведенням аудиту безпеки своїх сайтів, як додатковий елемент безпеки.
Продовжуючи розпочату традицію, після попереднього відео про взлом мережі за 60 секунд, пропоную нове відео на веб секюріті тематику. Цього разу відео про сліпі XSS. Рекомендую подивитися всім хто цікавиться цією темою.
Торік на конференції DEFCON 20 відбувся виступ Adam Baldwin. В своєму виступі він розповів про Cross-Site Scripting, про його підкласи і, зокрема, про такий різновид persistent XSS як сліпі XSS. Сам я не вживаю такого терміну і всі persistent XSS називаю persistent (хоча раніше і ввів термін per-user persistent XSS, для відокремлення від звичайних постійних XSS таких, що спрацьовують не для всіх користувачів, а лише для поточної сесії користувача, тобто близькі за природою до reflected XSS). Адам вирішив вжити термін “blind XSS” для виділення окремої категорії постійних XSS. І детально розповів про них у своїй доповіді.
Сліпі XSS - це ті уразливості, де одразу немає виконання коду (це в першу чергу стосується тих XSS, що знаходяться в адмінках або акаунтах, куди нападник немає доступу). Це дуже поширена частина постійних XSS. В своїй практиці серед persistent XSS я більше стикався саме зі сліпими, ніж звичайними (й першою Cross-Site Scripting, яку я дослідив, була саме сліпа постійна XSS).
Адам продемонстрував свою платформу xss.io призначену для експлуатації XSS уразливостей. Рекомендую подивитися дане відео для розуміння векторів атак через уразливості у веб додатках.
Продовжуючи розпочату традицію, після попереднього відео про RCE eксплоіт для Internet Explorer, пропоную нове відео на веб секюріті тематику. Цього разу відео про взлом мережі за 60 секунд. Рекомендую подивитися всім хто цікавиться цією темою.
DEFCON 20: Owned in 60 Seconds: From Network Guest to Windows Domain Admin
Торік на конференції DEFCON 20 відбувся виступ Zack Fasel. В своєму виступі він розповів про можливість швидкого захоплення акаунта адміністратора домена Windows. Він розповів про новий інструментарій та нові методи перехоплення мережевих запитів Windows Integrated Authentication.
Зак продемонстрував атаки для захоплення домена Windows (в тому числі через Інтернет) та надав поради для захисту від них. Рекомендую подивитися дане відео для розуміння векторів атак на локальну мережу.
Раніше я вже писав про Гугл хакінг - використання Гугла чи інших пошукових систем для пошуку уразливостей на веб сайтах. Зокрема в статтях Використання Гугл хакінга та Просунутий Гугл хакінг я детально розглянув цю тему та навів приклади вразливих веб додатків та запити для їх пошуку в Google.
А в циклі статтей “Warning” Google хакінг та “Error” Google хакінг я розповів про методики пошуку уразливостей типу Full path disclosure та Information Leakage в пошукових системах.
Одним з просунутих методів пошуку подібних уразливостей є пошук Information Leakage в локальний пошуковцях. На відміну від Гугл хакінга, в даному випадку уразливості шукаються не в зовнішніх (глобальних) пошуковцях, а саме в локальних.
Даний метод я розробив на початку січня 2008. Information Leakage уразливість я знайшов в движку RiSearch, про XSS уразливість в якому я вже писав. До цієї IL вразливі всі версії даного движка, тому що дірка пов’язана з некоректною конфігурацією пошукової системи. Саме тому ця IL проявиться не не всіх сайтах, а лише на тих, де адміни допустилися помилок при конфігурації RiSearch. Один такий сайт мені трапився у січні 2008 (зараз на цьому домені вже інший сайт, тому про нього не згадую), але можливі й інші сайти з подібною вразливою конфігурацію.
Information Leakage:
Суть уразливості полягає в тому, що якщо адмін не заборонив індексацію папки зі скриптами, то вихідні коди скриптів індексуються й їх можна побачити через локальний пошук (Source Code Disclosure). Що може призвести до витоків логінів і паролів (та іншої важливої інформації), які вказані в коді веб додатків.
http://site/cgi-bin/search.pl?query=password
Движок RiSearch PHP, що є PHP версією RiSearch, також вразливий до даної атаки:
http://site/risearch/search.php?query=password
Даним запитом знаходяться всі скрипти сайта, які містять слово password. Що дозволяє виявити паролі (до адмінки, до БД, тощо). RiSearch виводить проіндексовані дані сніпетами, тому видно лише фрагменти коду, але цього може бути достатньо для атаки.
Аналогічним чином можна виявити всю критичну інформацію, що була проіндексована RiSearch. Подібні уразливості можуть бути як в цьому, так і інших локальних пошуковцях.
Продовжуючи розпочату традицію, після попереднього відео про викрадення рухів курсору в Internet Explorer, пропоную нове відео на веб секюріті тематику. Цього разу відео про RCE eксплоіт для Internet Explorer. Рекомендую подивитися всім хто цікавиться цією темою.
Microsoft Internet Explorer JavaScript OnLoad Handler Remote Code Execution Vulnerability
В даному відео ролику демонструється використання Metasploit Framework для проведення атаки на уразливість в Internet Explorer. В Metasploit створюється і запускається експлоіт для IE, який призводить до віддаленого виконання коду в Internet Explorer при відкритті сторінки з кодом експлоіту. Даний експлоіт відкриває шел на атакованому комп’ютері, що дозволяє нападнику отримати контроль над ним.
Атака відбувається при відвідуванні в IE спеціально створеного веб сайта, що містить код експлоіту. Рекомендую подивитися дане відео для розуміння векторів атак на браузери.
* 
You are currently browsing the archives for the Статті category.
Copyright © 2006-2025 MustLive. Усі права захищені.
Партнер проекту Websecurity.com.ua - веб проект mlfun.org.ua.