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

Local XSS

22:46 21.05.2010

This is English version of my Local XSS article.

I’ll tell you about new type of Cross-Site Scripting vulnerabilities, Local XSS, which I created in June 2006 for better classification of XSS vulnerabilities, when found vulnerability in Ad Muncher.

Local XSS - it’s Cross-Site Scripting vulnerabilities in local software (at computer of the user, or in local network), which leads to appearance of XSS vulnerabilities. I.e. it’s such XSS vulnerabilities, which take place not directly at the site, but in local software of the user. And which allow to attack even those sites, which can even not have XSS vulnerabilities.

Particularly this type of vulnerabilities leads to appearance of so-called universal XSS, which allow to conduct attacks on multiple sites, in case when user is using vulnerable software. Examples of universal XSS are UXSS in PDF, vulnerability in Ad Muncher and vulnerability in XSS Filter in IE8.

Nuances of Local XSS.

Local XSS vulnerabilities can take place in browsers and in other programs, which concerned with work in Internet. Such as plugins for browsers, proxy servers, ad blockers (which perform function of proxy server) and others.

These vulnerabilities take place not at the site, but at user’s local computer (at using of vulnerable software), so admins of the sites and web developers often ignore such vulnerabilities. In some cases owners of the sites can do nothing concerning to these vulnerabilities (only to advice users to update vulnerable software), in other cases owners of the sites can use different protecting methods (as in case of UXSS in PDF and vulnerability in XSS Filter in IE8).

One of nuances of Local XSS is that, that they can bypass WAF at the site (due to that vulnerabilities take place on local software of the user, but not at the site). So to resist at web site to these attacks with using these vulnerabilities, it’s needed to use not WAF, but special methods (as in case of vulnerabilities in PDF and IE8).

There is such class of vulnerabilities as Cross-zone scripting. These vulnerabilities take place in browsers, particularly in Mozilla Firefox (and other browsers on Gecko engine) and in Internet Explorer (and browsers at IE engine, such as Sleipnir, Portable Sleipnir, unDonut) and in plugins (extensions, toolbars) for browsers.

Cross-zone scripting - it’s other type of XSS, then Local XSS. So these vulnerabilities don’t belong to Local XSS. Because via these vulnerabilities in browsers and plugins for them it’s possible to execute code at user’s computer (in local context), but not at web site (in context of this site). I.e. via Cross-zone scripting the attack is going to user’s computer (with his current rights), and via Local XSS - at web site (with rights of this user). But common for both types of XSS is that, that these vulnerabilities appear in local software of the user.

Types of Local XSS.

There are next types of Local XSS:

  • Reflected local XSS - the most widespread type of Local XSS.
  • Persistent local XSS - it’s Post Persistent XSS (Saved XSS), i.e. this type of XSS belongs at the same time to Persistent XSS and to Local XSS.
  • Strictly social local XSS - this type of XSS belongs at the same time to Strictly social XSS and to Local XSS.

About Post Persistent XSS (Saved XSS) sub-class of Cross-Site Scripting vulnerabilities I wrote already, and about Strictly social XSS sub-class I’ll write separate article with time.

Let’s look at examples of different types of Local XSS vulnerabilities.

Reflected local XSS.

Reflected local XSS - it’s Reflected XSS in local applications.

Examples of Reflected local XSS are the next vulnerabilities:

1. Universal XSS in PDF, which I wrote about in 2007. This vulnerability in Adobe Reader and Acrobat, and also their plugins for browsers, was found and disclosed by Stefano Di Paola at the end of 2006. For the attack it was needed to use pdf-file at any site which has pdf-file (with the exception of those ones, which made a protection against this attack on server-side).
2. Vulnerabilities in different plugins for browsers, particularly vulnerabilities in Adobe Flash Player and Adobe Acrobat. If under-mentioned persistent XSS via Flash and strictly social XSS in millions of flash files are considered by Adobe as feature of flash, then Adobe fixed above-mentioned reflected XSS.
3. Cross-Site Scripting via jar: URI in Firefox, which was found by PDP and Beford in 2007.
4. Universal XSS vulnerability in Ad Muncher, which I wrote about in 2010. The attack was going at visiting of special crafted URL, with using of which it was possible to conduct XSS attack at any site (with the exception of those cases, which I wrote about in this post).
5. Vulnerabilities in Sidki and Proxomitron, which Charles Reis, Steven D. Gribble, Tadayoshi Kohno and Nicholas C. Weaver wrote about in 2008. As they found the year after me, in 2007, to this XSS besides Ad Muncher are also vulnerable Sidki and filter sets Grypen for Proxomitron.
6. Vulnerability in Internet Explorer 8 - Eduardo Vela Nava and David Lindsay at the beginning of this year found vulnerability in XSS Filter in IE8, which allows to conduct XSS attacks on users of IE8 at any sites (with the exception of those ones, which made a protection against this attack on server-side).
7. New vulnerability in Ad Muncher, which I wrote about in 2010. The attack is similar to previous vulnerabilitiy in Ad Muncher.

Persistent local XSS.

Persistent local XSS - it’s Persistent XSS in local applications, particularly it’s Post Persistent XSS (Saved XSS) vulnerabilities.

Examples of Persistent local XSS are the next vulnerabilities:

1. Vulnerabilities in Flash plugin for browsers. At uploading of swf-files with XSS-code at the server, it’s possible to conduct an attack on users, which have flash plugin (which have more than 99% of Internet users). As I noted, Adobe isn’t considered this as security issue, because it’s feature of Flash technology, so owners of the sites and web developers need to work on security by themselves, if including of flashes is allowed (as in case of vulnerability in Invision Power Board) or if uploading of flashes is allowed (as in case of vulnerability in FCKeditor).
2. Vulnerability in QuickTime plugin for browsers. Particularly via Media Link in QuickTime at uploading of files (in xml-format) with extension mp3 at the server, it was possible to conduct the attack at users which have QT plugin (one of the popular plugins).
3. Cross-Site Scripting vulnerability in Internet Explorer, which I wrote about in 2007. Attack is going at saving of a page with specially crafted URL and next opening of this page in the browser.
4. Cross-Site Scripting vulnerability in Google Chrome, which I wrote about in 2008. Attack is similar to attack on IE.
5. Cross-Site Scripting vulnerability in Opera, which I wrote about in 2008. Attack is similar to attack on IE and Chrome.
6. Universal XSS vulnerability in Ad Muncher, which I wrote about in 2010. In this application it was possible to conduct as Reflected local XSS attack, as Persistent local XSS attack.
7. New vulnerability in Ad Muncher, which I wrote about in 2010. The attack is similar to previous vulnerabilitiy in Ad Muncher.

Strictly social local XSS.

Strictly social local XSS - it’s Strictly social XSS in local applications.

Examples of Strictly social local XSS are the next vulnerabilities:

1. Cross-Site Scripting in Mozilla and Firefox, which I wrote about in 2007. Attack is going via gopher protocol. For conducting of XSS attack is needed that user of browser Mozilla, Firefox or SeaMonkey (or other browsers on Gecko engine) go to specially crafted page and change codepage to UTF-7.
2. Cross-Site Scripting with UTF-7 in Mozilla and Firefox, which I wrote about in 2009. Attack is going via http, https and ftp protocols (this vulnerability is a continuation of previous one, in which new protocols are used).
3. Cross-Site Scripting vulnerabilities in Mozilla and Firefox, which I wrote about in 2009. Attack is going at request to location-header redirector with setting of JavaScript code. At request the browser shows page “Object Moved”, where in the link “here” shows this code, at click on which the code will execute.
4. The strictly social XSS vulnerabilities in 8 millions and 34 millions of flash files are possible via flash plugin for browsers.

Example of Local XSS.

The most bright example of Local XSS vulnerability is universal XSS in Ad Muncher. Essence of this vulnerability was in the next.

Vulnerability was possible due to that program set current URL in body of current page (without filtering of tags). So with special crafted URL it was possible to execute code at any site.

Conducting of reflected XSS attack:

http://www.google.com/webhp?%3C/script%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

With using of this vulnerability it was possible to conduct XSS attack at any site (with the exception of above-mentioned cases). The attack can be conducted e.g. via hidden iframe. At that the attack worked in any browser.

Local XSS - Локальний XSS

22:45 18.05.2010

Розповім вам про новий вид Cross-Site Scripting уразливостей, Local XSS, який я створив у червні 2006 року для кращої класифікації XSS уразливостей, коли знайшов уразливість в Ad Muncher.

Local XSS (Локальний XSS) - це Cross-Site Scripting уразливості в локальному програмному забезпеченні (на компьютері користувача, або в локальній мережі), які приводять до появи XSS уразливостей. Тобто, це такі XSS уразливості, що мають місце не безпосередньо на сайті, а в локальному ПЗ користувача. І які дозволяють атакувати навіть сайти, що можуть і не мати XSS уразливостей.

Зокрема такий вид уразливостей призводить до появи так званих універсальних XSS, що дозволяють проводити атаки на численні сайті, у випадку коли користувач використовує уразливу програму. Прикладами універсальних XSS є UXSS в PDF, уразливість в Ad Muncher та уразливість в XSS Filter в IE8.

Особливості Local XSS.

Local XSS уразливості можуть мати місце в браузерах та в інших програмах, що пов’язані з роботою в Інтернеті. Таких як плагіни для браузерів, проксі сервери, банерорізки (що виконують функцію проксі сервера) та інших.

Дані уразливості мають місце не на сайті, а у користувача на локальному комп’ютері (при використанні уразливої програми), тому адміни сайтів і веб розробники часто ігнорують подібні уразливості. В деяких випадках власники сайтів нічого зробити не можуть по відношенню до даних уразливостей (лише порадити користувачам оновити уразливу програму), в інших випадках власники сайтів можуть використовувати різні захисні методи (як у випадку UXSS в PDF та уразливості в XSS Filter в IE8).

Однією з особливостей Локальних XSS є те, що вони можуть обходити WAF на сайтах (із-за того, що уразливості мають місце в локальному ПЗ користувача, а не на сайті). Тому щоб на веб сайті протидіяти атакам з використанням даних уразливостей, потрібно використовувати не WAF, а спеціальні методи (як у випадку уразливостей в PDF та IE8).

Існує такий клас уразливостей як Cross-zone scripting. Дані уразливості мають місце у бразерах, зокрема в Mozilla Firefox (та інших браузерах на движку Gecko) та в Internet Explorer (та браузерах на движку IE, таких як Sleipnir, Portable Sleipnir, unDonut) та в плагінах (розширеннях, тулбарах) для браузерів.

Cross-zone scripting - це інший вид XSS, ніж Local XSS. Тому дані уразливості не відносяться до Local XSS. Тому що через ці уразливості в браузерах і плагінах до них можна виконати код на компьютері користувача (в локальному контексті), а не на веб сайті (в контексті даного сайту). Тобто через Cross-zone scripting атака відбувається на компьютер користувача (з його поточними правами), а через Local XSS - на веб сайт (з правами даного користувача). Але спільним для обох видів XSS є те, що дані уразливості проявляються в локальному ПЗ користувача.

Різновиди Local XSS.

Бувають наступні види Local XSS:

  • Reflected local XSS - найбільш поширений різновид Local XSS.
  • Persistent local XSS - це Post Persistent XSS (Saved XSS), тобто даний різновид XSS відноситься одночасно і до Persistent XSS і до Local XSS.
  • Strictly social local XSS - даний різновид XSS відноситься одночасно і до Strictly social XSS і до Local XSS.

Про Post Persistent XSS (Saved XSS) підклас Cross-Site Scripting уразливостей я вже писав, а про Strictly social XSS підклас я з часом напишу окрему статтю.

Розглянемо приклади різних видів Local XSS уразливостей.

Reflected local XSS.

Reflected local XSS - це Reflected XSS в локальних додатках.

Прикладами Reflected local XSS є наступні уразливості:

1. Універсальна XSS в PDF, про що я писав в 2007 році. Дану уразливість в Adobe Reader та Acrobat, а також їхніх плагінах до браузерів, виявив і оприлюднив Stefano Di Paola наприкінці 2006 року. Для атаки необхідно було використати pdf-файл на будь-якому сайті, що містить pdf-файл (за виключенням тих, що на стороні сервера подбали про захист від даної атаки).
2. Уразливості в різних плагінах для браузерів, зокрема уразливості в Adobe Flash Player та Adobe Acrobat. Якщо нижчезгадані persistent XSS через Flash та strictly social XSS в мільйонах флеш файлах вважаються Адобом фічою флеша, то вищезгадані reflected XSS Адоб виправив.
3. Cross-Site Scripting через jar: URI в Firefox, яку виявили в 2007 році PDP та Beford.
4. Універсальна XSS уразливість в Ad Muncher, про що я писав в 2010 році. Атака відбувалася при відвідуванні спеціально створених URL, за допомогою чого можна було провести XSS атаку на будь-якому сайті (за виключенням тих випадків, про які розповідається в данному записі).
5. Уразливості в Sidki та Proxomitron, про що Charles Reis, Steven D. Gribble, Tadayoshi Kohno та Nicholas C. Weaver написали в 2008 році. Як вони виявили через рік після мене, в 2007 році, окрім Ad Muncher, також до подібної XSS вразливі Sidki та набір фільтрів Grypen для Proxomitron.
6. Уразливість в Internet Explorer 8 - Eduardo Vela Nava та David Lindsay на початку цього року виявили уразливість в XSS Filter в IE8, що дозволяє проводити XSS атаки на користувачів IE8 на будь-яких сайтах (за виключенням тих, що на стороні сервера подбали про захист від даної атаки).
7. Нова уразливість в Ad Muncher, про що я писав в 2010 році. Атака аналогічна попередній уразливості в Ad Muncher.

Persistent local XSS.

Persistent local XSS - це Persistent XSS в локальних додатках, зокрема це Post Persistent XSS (Saved XSS) уразливості.

Прикладами Persistent local XSS є наступні уразливості:

1. Уразливості в Flash плагіні для браузерів. При завантаженні swf-файлів на сервер з XSS-кодом, можна провести атаку на користувачів, що мають флеш плагін (який мають більше 99% користувачів Інтернет). Як я вже зазначав, Адоб не важає це проблемою безпеки, бо це фіча технології Flash, тому власникам сайтів та веб розробникам потрібно самим займатися безпекою, при дозволі включення флешек (як у випадку уразливості в Invision Power Board) чи дозволі завантаження флешек (як у випадку уразливості в FCKeditor).
2. Уразливості в QuickTime плагіні для браузерів. Зокрема через Media Link в QuickTime при завантаженні файлів (в xml-форматі) з розширенням mp3 на сервер, можна було провести атаку на користувачів, що мають QT плагін (один з популярних плагінів).
3. Cross-Site Scripting уразливість в Internet Explorer, про що я писав в 2007 році. Атака відбувається при збереженні сторінки зі спеціально створеним URL та подальшому відкритті даної сторінки в браузері.
4. Cross-Site Scripting уразливість в Google Chrome, про що я писав в 2008 році. Атака аналогічна до атаки на IE.
5. Cross-Site Scripting уразливість в Opera, про що я писав в 2008 році. Атака аналогічна до атаки на IE та Chrome.
6. Універсальна XSS уразливість в Ad Muncher, про що я писав в 2010 році. В даному додатку можна було провести як Reflected local XSS атаку, так і Persistent local XSS атаку.
7. Нова уразливість в Ad Muncher, про що я писав в 2010 році. Атака аналогічна попередній уразливості в Ad Muncher.

Strictly social local XSS.

Strictly social local XSS - це Strictly social XSS в локальних додатках.

Прикладами Strictly social local XSS є наступні уразливості:

1. Cross-Site Scripting в Mozilla та Firefox, про що я писав в 2007 році. Атака відбувається через gopher протокол. Для проведення XSS атаки необхідно, щоб користувач браузера Mozilla, Firefox або SeaMonkey (чи інших браузерів на движку Gecko) перейшов не спецільно створену сторінку і змінів кодування на UTF-7.
2. Cross-Site Scripting з UTF-7 в Mozilla та Firefox, про що я писав в 2009 році. Атака відбувається через http, https і ftp протоколи (дана уразливість є продовждення попередньої, в якій використовуються нові протоколи).
3. Cross-Site Scripting уразливості в Mozilla та Firefox, про що я писав в 2009 році. Атака відбувається при запиті до location-header редиректора з вказанням JavaScript коду. При запиті браузер виводить сторінку “Object Moved”, де в лінці “here” виводить даний код, при натисканні на яку код спрацює.
4. Через flash плагін для браузерів можливі strictly social XSS уразливості в 8 мільйонах та 34 мільйонах флеш файлах.

Приклад Local XSS.

Найбільш яскравим прикладом Local XSS уразливості є універсальна XSS в Ad Muncher. Суть даної уразливості полягала в наступному.

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

Проведення reflected XSS атаки:

http://www.google.com/webhp?%3C/script%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

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

Цікаве чтиво на тему web security

22:46 17.05.2010

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

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

Використання SQLPwnage для атак на MSSQL

21:05 14.05.2010

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

Fast-Track: SQLPwnage; breaking the 64kb debug barrier

В даному відео ролику розповідається про атаку на Microsoft SQL Sever з використанням інструмента SQLPwnage. Причому атакуючий код розбивається на 9 частин, щоб обійти обмеження в 64 КБ.

Як і в відео про захоплення SQL сервера через SQL ін’єкцію, в даному відео ролику демонструється взлом SQL сервера. Через уразливість в SQL Sever проводиться атака на даний сервер, на якому під системним акаунтом запускаєть шел сервер і в який хакер залогінюється через TightVNC. Рекомендую подивитися дане відео для розуміння векторів атак на SQL Sever.

Цікаве чтиво на тему web security

22:48 11.05.2010

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

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

DNS Rebinding атаки

22:42 30.04.2010

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

DNS Rebinding with Robert RSnake Hansen

В даному відео ролику RSnake розповіє про DNS Rebinding атаки. Про те як працює DNS, як відбувається DNS Rebinding в браузерах, яким чином на це можна вплинути і для яких атак це може бути використано. Рекомендую подивитися дане відео для розуміння DNS Rebinding атак.

Обхід систем для пошуку вірусів на веб сайтах

22:44 29.04.2010

В продовження мого дослідження систем для пошуку вірусів на веб сайтах та статті Безпечний пошук, розповів вам про обхід даних систем. Даний метод обходу систем для пошуку вірусів на веб сайтах я придумав декілька днів тому.

Обмірковуючи тему захисту від вірусів на сайтах я виявив, що можливий обхід систем для пошуку вірусів на веб сайтах, зокрема тих, що вбудовані в пошукові системи. Це можливо через використання клоакінга, коли аналізується User Agent, і якщо це пошукова системи, то шкідливий код не виводиться, якщо ж браузер - то виводиться. Подібне можна реалізувати в шкідливих скриптах (Perl, PHP та інших), розміщенних на інфікованих сайтах, або на сайтах зловмисників, на які посилаються інші сайти, зокрема в тегах script та iframe.

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

Даний метод може бути використанний проти більшості зі згаданих систем, якщо вони мають власний User Agent, відмінний від User Agent браузера. Особливо проти систем для пошуку вірусів, що вбудовані в пошуковці, бо боти пошуковців мають відповідні User Agent. Але цей метод не спрацює проти моєї системи WebVDS, тому що вона використовує User Agent браузера і тому виглядає як звичайний браузер користувача.

Основна безпека PHP

19:10 24.04.2010

В своїй презентації Essential PHP Security, Arne Blankerts розповів про основну безпеку PHP. Це доповідь з конференці ZendCon 2009.

Цікаве чтиво на тему web security

22:43 23.04.2010

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

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

SEO при дірявому сайті, як допомога зловмисникам

22:49 22.04.2010

Раніше я вже писав про атаки на веб сайти та їх наслідки, які пов’язані з SEO - це атака для блокування сайта в пошукових системах та вплив на ранжування сайта через його уразливості. А зараз розповім про інший аспект також пов’язаний з SEO.

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

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

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

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