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

В своїй презентації HDIV (HTTP Data Integrity Validator), Bisan розповідає про HTTP Data Integrity Validator. Даний фреймворк являє собою опенсорсний Java Web Application Security Framework.

В статті Слепая быстрота: новейшие методы Blind SQL Injection розповідається про новітні методи проведення Blind SQL Injection атак. Враховуючи, що при сліпій SQL ін’єкції потрібно діставати інформацію з БД посимвольно, то дана атака є більш повільною ніж звичайна SQL ін’єкція, тому й розробляються методи для її пришвидшення.

В статті наводяться наступні методи Blind SQL Injection атак:

• Повний перебір,
• Бінарний (двійковий) пошук,
• Використання find_in_set() і подібних функцій,
• Використання find_in_set() + more1row.

Якщо методи повного перебору і бінарного пошуку вже давно відомі, то методи з використанням find_in_set() є новими, і вони дозволяють ще більше пришвидшити сліпі SQL ін’єкції.

Зазначу, що методи з використанням find_in_set() мають ряд обмежень порівняно з методом бінарного пошуку. Тому на власній практиці я вже багато років використовую саме бінарний пошук для Blind SQL Injection і буду використовувати й надалі. Але сучасні розробки в галузі Blind SQL Injection потрібні, щоб ще більше пришвидшити дані атаки.

Продовжуючи розпочату традицію, після попереднього відео про просунутий SQL Injection в Joomla, пропоную новий відео секюріті мануал. Цього разу відео про XSS та HTML Injection атаки в ICQ. Рекомендую подивитися всім хто цікавиться цією темою.

ICQ 6 HTML EXECUTION AND CRASH

В даному відео ролику демонструється проведення HTML Injection атаки в ICQ 6. Враховуючи, що ICQ 6 використовує движок Internet Explorer, можна проводити XSS та HTML Injection атаки, в тому числі використовуючі уразливості в IE для виконання коду та DoS атак.

Використання движків браузерів, зокрема IE, в інших додатках, створює умови для проводення Cross-Application Code Execution (тобто Cross-Application Scripting) та Cross-Application DoS атак. Рекомендую подивитися дане відео для розуміння векторів міжпрограмних атак та небезпеки подібних уразливостей.

В статті Защита сайта с помощью .htaccess и .htpasswd розповідається про захист сайта за допомогою .htaccess і .htpasswd на веб сервері Apache.

Використання вбудованих механізмів захисту інформації веб сервера Apache дозволяє просто і достатньо надійно захистити необхідні ресурси веб сайта. Дані механізми можуть застосовуватися для обмеження доступу до файлів або директорій.

В даній статті розповідається про файли .htaccess і .htpasswd та процес їх створення. Всі приклади використовують базову (basic) аутентифікацію.

Продовжуючи розпочату традицію, після попереднього відео про експлуатацію уразливостей в ПЗ, пропоную новий відео секюріті мануал. Цього разу відео про просунутий SQL Injection в Joomla. Рекомендую подивитися всім хто цікавиться цією темою.

Advanced Mysql Injection in Joomla

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

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

Раніше я писав про можливість закриття сайтів через їх взлом, коли через дефейс і/або розміщення вірусів сайт може бути закритим. Окрім цього можлива атака на сайт з іншою ціллю. Можлива атака на сайт з метою його блокування в пошукових системах.

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

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

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

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

Exploiting SW Vulnerabilities

В даному відео ролику демонструється процес знаходження уразливості в Windows-бібліотеці з використанням дебагера OllyDbg. Та створення для неї експлоіта (на Perl) для атаки на сервер через Інтернет. Рекомендую подивитися дане відео для розуміння процесу створення експлоітів та векторів атак через Інтернет.

This is English version of my Attacks via closed redirectors article.

In my article Redirectors: the phantom menace I wrote about attacks with using of open redirectors. Besides using of open redirectors for various attacks, closed redirectors also can be used.

Open redirectors - are redirectors which set address for redirection in URL (http://site/redirector.php?url=http://site2). Closed redirectors don’t set address for redirection in URL and have necessary addresses in DB, from which they take them by id (http://site/closed_redirector.php?id=1).

Closed redirectors considered more secure in comparison with open ones, but, as it’s clear from my article, they also can be used for many attacks (when there is possibility to set in them necessary URLs, or if they already were set). To closed redirectors belong as redirection services (such as TinyURL and others), as different counters, ratings and banner systems, where necessary URL is set in DB and is accessible by id. I.e. if you have access, for example, to banner system at the site, and can set arbitrary value of URL for banner (to which user will go at click on it), then you can conduct various attacks.

I meet many times in Internet cases of using of closed redirectors for different attacks. And also used them by myself during finding of vulnerabilities at the sites (for bypassing of filters and WAF). And I wrote about some of these attacks at my site.

Attacks via closed redirectors.

There are possible next attacks via closed redirectors:

• Redirection.
• Bypass of spam-filters.
• Bypass of flash restrictions.
• XSS attack via jar: URI in Firefox.
• CSRF attacks on a site.
• Hidden attacks on other sites.
• Image leakage in Firefox.
• Denial of Service attacks.
• Cross-Site Scripting attacks.
• Bypass of protection filters.

If there were 12 attacks via open redirectors, then there are possible 10 attacks via closed redirectors (one new attack from them). You can read in detail about these attacks in my article.

In case of such attacks as Redirection, Bypass of spam-filters, Bypass of flash restrictions, XSS attack via jar: URI in Firefox, CSRF attacks on a site, Hidden attacks on other sites, Image leakage in Firefox, the attack itself occurs almost equally for open and closed redirectors. In case of Denial of Service attacks it’s necessarily needed to use of closed redirector, i.e. there are possible two variants of an attack: using of open and closed redirector, using of two closed redirectors.

In case of Cross-Site Scripting attacks there are such attacks, which are possible with closed redirectors, particularly at redirection services such as TinyURL. These are attacks #3 and #5, which are described in my article Cross-Site Scripting attacks via redirectors. And I’ll tell more in detail about tenth attack.

Bypass of protection filters.

Redirection services (which are closed redirectors) allow to create new addresses for already existent addresses of the sites. Which allows to use them for bypass of the filters (including WAF) at the sites. It can be used in case of need to place a link or at conducting of XSS attacks. You can read in detail about this attack in my article Using of redirection services for bypass of the filters.

В своїй статті Редиректори: прихована загроза я писав про атаки з використанням відкритих редиректорів. Окрім використання відкритих редиректорів для різних атак, також можуть використовуватися і закриті редиректори. Це антологія атак з використанням закритих редиректорів.

Відкриті редиректори - це редиректори, що задають адресу для редирекції в URL (http://site/redirector.php?url=http://site2). Закриті редиректори не задають адресу для редирекції в URL і мають необхідні адреси в БД, з якої беруть їх по id (http://site/closed_redirector.php?id=1).

Закриті редиректори вважаються більш безпечними порівняно з відкритими, але, як видно з моєї статті, і вони можуть використовуватися для багатьох атак (коли є можливість задавати в них потрібні URL, або якщо вони вже були задані). До закритих редиректорів відносяться як сервіси редирекції (такі як TinyURL та інші), так і різні рахівники, рейтинги та банерні системи, де потрібний URL заданий в БД і доступний по id. Тобто якщо ви маєте доступ, наприклад, до банерної системи на сайті, і можете задати довільне значення URL для баннера (на яке перейде відвідувач при кліку по ньому), то ви можете провести різноманітні атаки.

Я неодноразово зустрічав в Інтернеті випадки використання закритих редиректорів для різних атак. А також сам використовував їх під час знаходження уразливостей на сайтах (для обходу фільтрів та WAF). І про деякі з даних атак я писав в себе на сайті.

Атаки через закриті редиректори.

Можливі наступні атаки через закриті редиректори:

• Редирекція.
• Обхід спам-фільтрів.
• Обхід обмежень флеша.
• XSS атака через jar: URI в Firefox.
• CSRF атаки на сайт.
• Приховані атаки на інші сайти.
• Витік умісту зображень в Firefox.
• Denial of Service атаки.
• Cross-Site Scripting атаки.
• Обхід захисних фільтрів.

Якщо атак через відкриті редиректори було 12, то через закриті редиректори можливі 10 атак (з них одна нова атака). Детально про дані атаки ви можете прочитати в моїй статті.

У випадку таких атак як Редирекція, Обхід спам-фільтрів, Обхід обмежень флеша, XSS атака через jar: URI в Firefox, CSRF атаки на сайт, Приховані атаки на інші сайти, Витік умісту зображень в Firefox, сама атака відбудеться майже однаково для відкритих і закритих редиректорів. У випадку Denial of Service атак обов’язково необхідне використання закритого редиректору, тобто можливі два варіанта атаки: використання відкритого і закритого редиректора, використання двох закритих редиректорів.

У випадку Cross-Site Scripting атак є такі атаки, що можливі з закритими редиректорами, зокрема на сервісах редирекції, таких як TinyURL. Це атаки №3 та №5, що описані в моїй статті Cross-Site Scripting атаки через редиректори. А про десяту атаку я розповім більш детально.

Обхід захисних фільтрів.

Сервіси редирекції (що є закритими редиректорами) дозволяють створювати нові адреси для вже існуючих адрес сайтів. Що дозволяє використовувати їх для обходу фільтрів (в тому числі WAF) на сайтах. Це може бути використано при необхідності розмістити лінку та при проведенні XSS атак. Детально про дану атаку ви можете прочитати в моїй статті Використання сервісів редирекції для обходу фільтрів.

В своїй презентації Introduction to Hacking for University Hack Day, Christian Heilmann розповідає про хакерів та пояснює сучасне значення хакінга.