Архів для категорії 'Статті'

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

22:40 19.09.2009

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

Відкриті редиректори - це редиректори, що задають адресу для редирекції в 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 атак. Детально про дану атаку ви можете прочитати в моїй статті Використання сервісів редирекції для обходу фільтрів.

Введення в хакінг

22:42 18.09.2009

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

Проклята анімація з WWW

21:06 15.09.2009

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

Cursed Animations from the Wi1d W3st

В даному відео ролику демонструється процес атаки через e-mail з використанням ANI уразливості в Windows. Для розробки експлоіта використовується Metasploit Framework. Рекомендую подивитися дане відео для розуміння векторів атак з використанням ANI уразливості.

Redirectors: the phantom menace

22:47 12.09.2009

This is English version of my Redirectors: the phantom menace article.

There is such security problem in Internet as redirectors. Already at beginning of January 2008 I planned to write the article about different variants of attacks with using of redirectors. And now I present for you the article “Redirectors: the phantom menace”. It’s anthology of attacks with using of redirectors.

Attacks via redirectors.

Besides redirection to malicious and phishing sites, redirectors can be used for other attacks. Here is a list of all attacks via redirectors which I know:

  • Redirection.
  • HTTP Response Splitting and XSS (via HTTP Response Splitting) attacks.
  • Full path disclosure attacks.
  • Bypass of spam-filters.
  • Bypass of flash restrictions.
  • XSS attack via jar: URI in Firefox.
  • Attack on Google Toolbar.
  • CSRF attacks on a site.
  • Hidden attacks on other sites.
  • Image leakage in Firefox.
  • Denial of Service attacks.
  • Cross-Site Scripting attacks.

Redirection.

Standard attack with using of redirectors - it’s redirection to other sites for the purpose of infecting with viruses, conducting of phishing attacks, or just entice to the site of advertiser.

For these purposes numerous redirectors in Internet can be used, particularly in search engines (which I wrote about in MOSEB project), at popular sites (and other sites), in CMS and other web applications.

HTTP Response Splitting and XSS (via HTTP Response Splitting) attacks.

There can be HTTP Response Splitting vulnerabilities in web applications redirectors. Which can be used for conducting of HTTP Response Splitting and XSS (via HTTP Response Splitting) attacks. The protection from these attacks was made in last 4.x versions and 5.x versions of PHP. But PHP is using not at all sites, and there are not always last versions where it’s using, besides after fixing of this hole, developers of PHP added Full path disclosure hole.

Full path disclosure attacks.

If using at the site of last 4.x versions or 5.x versions of PHP, there is Full path disclosure vulnerability in PHP-redirectors.

Set “%0A1″ as URL of the site for this redirector and you’ll get the message “Warning: Header may not contain more than a single header, new line detected.” together with full path at the site.

http://site/redirector.php?url=%0A1

Bypass of spam-filters.

Redirectors can be used for bypass of spam-filters in e-mail. When spam-filters is set on appropriate URL of sites, then using of redirectors allows to bypass it. If filter is looking not on full URL, but on entering of string in site’s address, then it can be bypassed with help of redirection services (such as TinyURL and others).

Bypass of flash restrictions.

Bypass of flash restrictions on crossdomain access is possible via substitution of crossdomain policies (crossdomain.xml) with using of redirectors (which Stefan Esser wrote about). It can be used for conducting of Cross-Site Request Forgery attacks. These attacks (crossdomain) are possible in old versions of flash plugin.

XSS attack via jar: URI in Firefox.

In Mozilla Firefox the Cross-Site Scripting attacks are possible via jar: URI. Petko D. Petkov aka PDP found this vulnerability, and Beford found, that in Firefox it’s possible to use it together with redirectors for conducting of XSS attacks via jar: URI, without need to upload files on these sites. Vulnerability was fixed in Firefox 2.0.0.10 and SeaMonkey 1.1.7.

Attack on Google Toolbar.

As showed Aviv Raff, who found this vulnerability, in Google Toolbar it’s possible to spoof content of dialog window at adding of the button (with using of redirector). Vulnerable to Google Toolbar Dialog Spoofing Vulnerability are Google Toolbar 5 beta and previous versions.

CSRF attacks on a site.

Redirectors can be used for the purpose of conducting of CSRF attacks, when it’s needed to bypass checking of the referrer (as protection against CSRF), in order to make referrer from the same site.

Hidden attacks on other sites.

Redirectors can be used for conducting of attacks (particularly CSRF attacks) on other sites, for the purpose of hiding real attacking site, so as to mention quite another site in the logs.

Image leakage in Firefox.

Using of getImageData() together with redirection it’s possible to get cross-site access to images. Chris Evans found this vulnerability in Firefox. It was fixed in Firefox 2.0.0.18.

Denial of Service attacks.

Redirectors can be used for conducting of DoS attacks. There are possible two variants: redirector looped on itself (Looped DoS) and redirector looped on redirector (looped redirection attack).

About first variant of attack I wrote concerning vulnerabilities in Power Phlogger (and also I found these vulnerabilities on different sites), and about second variant of attack I wrote in detail in my articles Redirectors’ hell and Hellfire for redirectors.

Cross-Site Scripting attacks.

It’s possible to conduct XSS attacks via redirectors. For these purposes as refresh-header, as location-header redirectors can be used. Which I wrote about in detail in article Cross-Site Scripting attacks via redirectors.

There are next vulnerable browsers: Mozilla 1.7.x, Mozilla Firefox 3.0.x and 3.5.x (and Firefox 3.6 Alpha and 3.7 Alpha), Internet Explorer 6, Opera 9.x and 10.x, Google Chrome 1.x, 2.x and 3.x, QtWeb 3.0, Safari 4.0.x, SeaMonkey 1.1.x, Orca Browser 1.2 and Maxthon 3 Alpha (and in most cases previous versions of all mentioned browsers).

Conclusions.

Redirectors represent a danger to security of users of Internet. So owners of web sites, which have redirectors (open) on them, and also developers of browsers (when attack occurs because of a problem in browser), must not allow such vulnerabilities, and hard fixing already existent ones.

Редиректори: прихована загроза

22:44 11.09.2009

Існує така проблема безпеки в Інтернеті як редиректори. Ще на початку січня 2008 року я запланував написати статтю про різноманітні варіанти атак з використанням редиректорів. І зараз пропоную вашій увазі статтю “Редиректори: прихована загроза” (Redirectors: the phantom menace). Це антологія атак з використанням редиректорів.

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

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

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

Редирекція.

Стандартна атака з використанням редиректорів - це редирекція на інші сайти з метою зараження вірусами, проведення фішинг атак, або просто заманювання на сайт рекламодавця.

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

HTTP Response Splitting та XSS (через HTTP Response Splitting) атаки.

В веб додатках редиректорах можуть бути HTTP Response Splitting уразливості. Які можуть бути використанні для проведення HTTP Response Splitting та XSS (через HTTP Response Splitting) атак. В PHP в останніх 4.x версіях та в 5.x версіях зроблений захист від даних атак. Але не на всіх сайтах використовується PHP, а там де використовується, не завжди останні версії, до того ж виправивши дану дірку, розробники PHP додали Full path disclosure дірку.

Full path disclosure атаки.

При використанні на сайті PHP останніх 4.x версій або 5.x версій, в PHP-редиректорах наявна Full path disclosure уразливість.

Задайте “%0A1″ в якості URL сайта для даного редиректора і отримаєте повідомлення “Warning: Header may not contain more than a single header, new line detected.” разом з full path на сайті.

http://site/redirector.php?url=%0A1

Обхід спам-фільтрів.

Редиректори можуть використовуватися для обходу спам-фільтрів в пошті. Коли спам-фільтри налаштовані на відповідні URL сайтів, то використання редиректорів дозволить обійти їх. Якщо фільтр шукає не по повному URL, а по входженню рядка в адресу сайта, то його можна обійти за допомогою сервісів редирекції (таких як TinyURL та інших).

Обхід обмежень флеша.

Можливий обхід обмежень флеша на міжсайтовий доступ через підстановку міждоменних політик (crossdomain.xml) за допомогою використання редиректорів (про що писав Stefan Esser). Це може використовуватися для проведення Cross-Site Request Forgery атак. Дані атаки (міждоменні) можливі в старих версіях флеш плагіна.

XSS атака через jar: URI в Firefox.

В Mozilla Firefox можливі атаки міжсайтового скриптінга через jar: URI. Дану уразливість виявив Petko D. Petkov aka PDP, а Beford виявив, що в Firefox можна використати її разом з редиректорами для проведення XSS атак через jar: URI без необхідності завантаження файлів на дані сайти. Уразливість виправлена в Firefox 2.0.0.10 та SeaMonkey 1.1.7.

Атака на Google Toolbar.

Як продемонстрував Aviv Raff, який знайшов дану уразливість, в Google Toolbar можна підмінити зміст діалогового вікна при додаванні кнопки (з використанням редиректора). До Google Toolbar Dialog Spoofing Vulnerability вразливі Google Toolbar 5 beta та попередні версії.

CSRF атаки на сайт.

Редиректори можуть використовуватися з метою проведення CSRF атак, коли потрібно обійти перевірку на реферер (як захист проти CSRF), щоб реферер був з цього самого сайта.

Приховані атаки на інші сайти.

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

Витік умісту зображень в Firefox.

Використовуючи getImageData() разом з редирекцією можливо одержати міжсайтовий доступ до зображень. Дану уразливість в Firefox знайшов Chris Evans. Вона виправлена в Firefox 2.0.0.18.

Denial of Service атаки.

Можна використовувати редиректори для проведення DoS атак. Можливі два варіанти: редиректор зациклений на собі (Looped DoS) та редиректор зациклений на редиректорі (атаки зацикленою редирекцією - looped redirection attack).

Про перший варіант атаки я писав стосовно уразливостей в Power Phlogger (а також я знаходив дані уразливості на різних сайтах), а про других варіант атаки я детально писав в своїх статтях Пекло редиректорів та Пекельний вогонь для редиректорів.

Cross-Site Scripting атаки.

Через редиректори можна проводити XSS атаки. Для цього можуть бути використані як refresh-header, так і location-header редиректори. Про що я детально написав в статті Cross-Site Scripting атаки через редиректори.

До уразливих браузерів відносяться: Mozilla 1.7.x, Mozilla Firefox 3.0.x та 3.5.x (та Firefox 3.6 Alpha і 3.7 Alpha), Internet Explorer 6, Opera 9.x та 10.x, Google Chrome 1.x, 2.x та 3.x, QtWeb 3.0, Safari 4.0.x, SeaMonkey 1.1.x, Orca Browser 1.2 та Maxthon 3 Alpha (та в більшості випадків попередні версії усіх зазначених браузерів).

Висновки.

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

XSS уразливості на 404 сторінках

22:47 05.09.2009

Cross-Site Scripting (XSS) уразливості дуже поширені в Інтернеті, що добре видно з моїх новин. Я регулярно знаходжу подібні уразливості на веб сайтах, про що пишу в себе на сайті, а також згадую про знайдені іншими секюріті дослідниками XSS дірки на відомих сайтах. Також я не раз писав про XSS хробаків.

XSS уразливості мені доводилося знаходити у різних веб додатках, а також у браузерах та веб серверах. Після уразливостей в пошуковцях, про що я вже писав детально в своєму проекті MOSEB, одними з найбільш поширених є XSS на Error 404 сторінках, про що я розповім детально.

Стандартний вектор атаки у випадку XSS на 404 сторінках - це вказання XSS-коду в якості адреси сторінки на сайті, що призведе до виведення 404-ї сторінки і до виконання JavaScript коду.

XSS:

http://site/%3Cscript%3Ealert(document.cookie)%3C/script%3E

Подібні XSS бувають reflected, persistent, DOM based та strictly social.

Прикладом persistent XSS на 404 сторінці є уразливість в Power Phlogger (код спрацює при перегляді логів відвідувань). DOM based XSS мені також траплялися, зокрема в компоненті ProofReader для Joomla. А reflected XSS на 404 сторінках - це найбільш поширений випадок. Прикладами даних XSS є уразливості на mts.com.ua, в Apache Tomcat та в Joomla.

А також уразливості в браузерах, що проявляються на 404 сторінках: Cross-Site Scripting з використанням UTF-7 в IE (reflected) та Cross-Site Scripting з UTF-7 в Mozilla та Firefox (strictly social XSS).

Так що розробникам веб серверів, браузерів та веб сайтів варто завжди перевіряти свої розробки на наявність XSS уразливостей на 404 сторінках (як і на усіх інших сторінках про помилки). Щоб не допускати уразливостей на даних сторінках.

Опис Cross-Site Scripting від CERT

22:47 03.09.2009

В своій статті CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests CERT розповідає про Cross-Site Scripting (XSS). Стаття датована 02.02.2000 - це перша документована згадка про такий вид уразливостей, як XSS. В тому числі в тексті використаний термін “Cross-Site Scripting” для позначення атак з включенням html-тегів в сторінки сайтів.

В статті йдеться про reflected XSS. Зазначу, що про persistent XSS було відомо ще в 1998, про що в Мережі є публікації за той час. Просто лише з появою reflected XSS (на початку 2000 року), почали вживати сам термін XSS, а до цього persistent XSS уразливості просто називали “ін’єкціями скриптів”.

В даній статті подається опис Cross-Site Scripting уразливостей, їх вплив та рекомендації по їх усуненню.

Знаходження, експлуатація та лікування XSS хробаків

19:27 29.08.2009

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

Find, Exploit & Cure XSS w0rms

В даному відео ролику демонструється процес знаходження та експлуатації XSS уразливостей для разповсюдження XSS хробаків (на прикладі meebo.com), а також даються поради по їх лікуванню. Рекомендую подивитися дане відео для розуміння векторів Cross-Site Scripting атак.

Захоплення SQL сервера через SQL ін’єкцію

22:48 22.08.2009

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

Rooting SQL Server via SQL Injection

В даному відео ролику демонструється взлом SQL сервера. Через уразливий веб сайт, що має SQL ін’єкцію, на якому SQL Server запущений з адмінськими правами, створюється новий акаунт адміністратора. Рекомендую подивитися дане відео для розуміння векторів SQL Injection атак.

Закриття сайтів через їх взлом

22:42 15.08.2009

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

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

Тобто вже сам взлом може призвести до закриття сайта (це може бути дефейс і/або розміщення вірусів). Закриття може бути тимчасове - коли провайдер закрив сайт, доки його власник не почистить свій сайт, або повне - коли власник сайта закрив свій проект (бо не міг впоратися з проблемою дірявості власного сайта). В своїх дослідженнях безпеки Уанету (за 2006-2009 роки) я наводив безліч таких випадків. Як останній випадок з www.virtlibrary.dp.ua, так і минулорічні випадки з dn.kiev.ua та wmast.com.ua.

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