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

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

Injecting a Backdoor via PhpMyAdmin

В даному відео ролику демонструється використання phpMyAdmin, доступ до його отриманий через різноманітні уразливості (в тому числі й через відсутність обмежень на доступ до веб додатку), для виконання SQL команд для розміщення бекдору на сервері. А через бекдор відбувається захоплення сервера. Раніше я вже наводив відео про захоплення сервера з СУБД SQL Server та MySQL через SQL Injection.

Для цього на сервер через phpMyAdmin заливається шел (простий шел, подібний до мого MustLive Remote Shell). Після чого додається новий акаунт адміністратора в систему. Рекомендую подивитися дане відео для розуміння SQL Injection атак та ризиків розміщення на сайті додактів для роботи з БД (таких як phpMyAdmin та інших).

Наприкінці грудня 2009 року - початку січня 2010 року відбулася хакерська атака, що отримала назву Операція Аврора (Operation Aurora). Дана атака проводилася проти Google та ряду інших американських компаній.

Ось декілька відео про Операцію Аврора:

McAfee Operation Aurora Overview

The Operation Aurora Internet Explorer exploit - live!

The «Aurora» IE Exploit in Action

В даних відео роликах розповідається про саму Операцію Аврора та демонструється використання експлоіта для Internet Explorer, що використовувався під час даної атаки.

Кеш пошукових систем може бути корисним інструментом в умілих руках. Існує чимало можливостей використання кешу для хакерів.

Можливості кешу пошуковців:

1. Пошук уразливостей сайта в кеші.
2. Пошук уразливостей сайта в сніпеті.
3. Немає записів в логах сайта.
4. Обхід обмежень на доступ до сайта.
5. Наявність уразливостей в кеші.
6. Завжди можна отримати інформацію з сайта.
7. Визначення часу, коли сайт працював востаннє.
8. Визначення часу, коли сайт був взломаний.
9. Розповсюдження шкідливого коду.

Пошук уразливостей сайта в кеші.

В кеші пошуковців можна знайти уразливості сайта, наприклад Full path disclosure та інші Information Leakage уразливості, що вже були виправлені на сайті. Зокрема подібну уразливість я виявив на www.stat24.com.ua.

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

Пошук уразливостей сайта в сніпеті.

В сніпетах пошуковців (дані з кеша, що виводяться в результах пошуку) можна знайти уразливості сайта, наприклад Full path disclosure та інші Information Leakage уразливості, що вже були виправлені на сайті.

Немає записів в логах сайта.

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

Обхід обмежень на доступ до сайта.

Якщо для вас обмежений доступ до сайта (по IP), але дозволений доступ для ботів пошуковців, то можна дістати інформацію з кеша пошуковця.

Наявність уразливостей в кеші.

В самому кеші пошукових систем також можуть бути уразливості. Зокрема я знаходив XSS уразливість в Яндексі, що мала місце в кеші пошуковця.

Завжди можна отримати інформацію з сайта.

Можна отримати інформацію з сайта навіть якщо він в даний момент не працює (зовсім перестав працювати чи тимчасово, наприклад в результаті атаки).

Визначення часу, коли сайт працював востаннє.

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

Визначення часу, коли сайт був взломаний.

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

Розповсюдження шкідливого коду.

Якщо пошукова система занесе в свій кеш сторінку сайта зі шкідливим кодом, то всі хто відвідає цей кеш будуть атаковані, так само як при відвіданні даного сайта. І можна буде, наприклад, по емайлу посилати лінки на кеш пошуковця, щоб використати його ім’я для збільшення кількості людей, що перейдуть по цим лінкам.

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

Rooting a box via MySQL Injection

В даному відео ролику демонструється використання SQL Injection уразливості на сайті, що використовує MySQL, для захоплення сервера (на Windows XP). Раніше я вже наводив відео про захоплення сервера через SQL ін’єкцію де використовувався Microsoft SQL Server.

Для цього на сервер через SQL ін’єкцію заливається шел (простий шел, подібний до мого MustLive Remote Shell). Після чого додається новий акаунт адміністратора в систему та через Remote Desktop Connection під’єднується до сервера. Рекомендую подивитися дане відео для розуміння SQL Injection атак.

У випадку Content Spoofing уразливостей можливі як HTML включення, так й інші варіанти атак. Зокрема коли можливе обмежене включення контенту для проведення Content Spoofing атаки. До таких атак відносяться Link Injection та Text Injection.

Хорошим прикладом HTML Injection є уразливість в WP-Cumulus для WordPress. При наявності HTML включення, можна проводити Link Injection та Text Injection атаки (які є його підвидом), але коли повноцінне HTML включенне неможливе (наприклад при фільтрації на сервері чи WAF), то тоді дані атаки можуть стати у нагоді. Зазначу, що дані атаки можливі як при включенні до html сторінок, так і до флеш файлів і капч.

Link Injection.

Хорошим прикладом Link Injection є уразливість на www.ibm.com. Подібні уразливості можуть використовуватися для проведення атак редирекції.

Можливі два варіанта атаки:

1. Коли можна лише вказати лінку на зовнішній сайт:

http://site/page?url=http://badsite

2. Коли можна вказати лінку на зовнішній сайт та її текст:

http://site/page?text=Click%20here!&url=http://badsite

У випадку Link Injection, іноді можливе не тільки включення лінки, а й коду скриптів (JS чи VBS) для проведення Strictly social XSS атак. Як у випадку forum.banner.kiev.ua та WP-Cumulus.

HTML Injection уразливість в WP-Cumulus може зокрема використовуватися для Link Injection атаки, причому можна задавати довільну кількість лінок.

http://site/wp-content/plugins/wp-cumulus/tagcloud.swf?mode=tags&tagcloud=%3Ctags%3E%3Ca+href='http://badsite'+style='font-size:40pt'%3EHacked%3C/a%3E%3C/tags%3E

Text Injection.

Хорошим прикладом Text Injection є уразливість на seal.godaddy.com - в логотипі Secure web site від GoDaddy.

HTML Injection (Text Injection):

• включення тексту

Про подібну уразливість я вже писав раніше на allmebel.com.ua та forum.banner.kiev.ua.

Можлива наступна атака (з вказанням довільного тексту):

http://site/page?text=Hacked

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

Подібні атаки відбуваються через html-сторінку (як на www.ibm.com), флешку (як на WP-Cumulus, seal.godaddy.com і forum.banner.kiev.ua) або капчу (як на allmebel.com.ua).

В своїй презентації Get Rich or Die Trying, що Jeremiah Grossman представив на конференції Black Hat в 2008 році, він розповів про сучасні методи атак в Інтернеті. Які можуть використовуватися для заробітку коштів.

This is English version of my The future of XSS attacks article.

In case if for Cross-Site Scripting attack it’s not possible to use any tags and angle brackets at the site, it’s possible to conduct XSS attack with using of tags’ properties. It can be style property, or different even handlers (or sometimes it’s possible to conduct attack via src property). For the attack it’s needed to use quotes (single or double ones, or sometimes even quotes isn’t required), to add new property to the tag, in which we managed to include the code.

At attack via style property the next methods are used (in which the code executes automatically at page opening):

1. Via expression(), which works only in browsers IE (before IE8).
2. Via background:url() or background-image:url(), which works only in browsers IE.
3. Via -moz-binding:url(), which works only in Mozilla Firefox and other browsers on Gecko engine (before Firefox 3).

Examples of attacks with expression() and -moz-binding you can see in case of vulnerabilities at www.ibm.com.

At attack via event handlers the next methods are used:

1. Via onMouseOver, onfocus, onblur, onselect, onchange, onclick and other events (in which the code executes at appropriate event).
2. Via onerror, onload, onunload (in which the code executes automatically at page opening, or its closing in case of onunload event).

A possibility of using of onerror, onload and onunload happens not very often, and other handlers trigger not automatically, so they are less popular at conducting of XSS attacks. The most often the attacks via style property are used.

But already in 2008 in Firefox 3 possibility of attack via -moz-binding was removed (it was partly removed - it’s possible to attack only with using of xml-files at the same site). Which I wrote about in article XSS attacks in Mozilla Firefox via styles. And in Internet Explorer 8, which released at beginning of 2009, support of expression() was removed. Support of javascript and vbscript URI in background-image and background-image also can be removed with time.

So in light of these events it became harder to conduct automated XSS attacks in new browsers in such conditions (when it’s not possible to use any tags and angle brackets). And as more widespread these versions of browsers become, the harder it’ll be to conduct XSS attacks in such conditions (so that they will be automated, without need for user to do some actions). From other side, such browsers as Opera, Chrome and other browsers completely resist to attacks via style property.

For solving of this task the technique MouseOverJacking can be used, which I already wrote about. This technique allows to conduct automated XSS attack. At that it’s cross-browser solution, which works in all browsers. Including in IE8 - at using of CSS (as in my PoCs) it allows to bypass IE8’s built-in protection against Clickjacking.

I.e. MouseOverJacking can be used not only for specific attacks, which were about in the article about this technique, but for wide variety of XSS attacks (instead of expression() and -moz-binding). At that the attack is fully automated, so the effectiveness of the attack is the same as in expression() and -moz-binding (and due to cross-browser it’s possible to attack even more users).

It’s possible to conduct such attacks as via MouseOverJacking, as via Clickjacking. But MouseOverJacking has higher effectiveness, because at Clickjacking attack the victim must to do a click (which can not always happen), but at MouseOverJacking it’s not needed to do any actions, only one move of the mouse (which will always happen).

Examples of PoC for Cross-Site Scripting vulnerabilities.

For reflected XSS:

http://site/script?param=%22%20style=%22width:100%;height:100%;display:block;position:absolute;top:0px;left:0px%22%20onMouseOver=%22alert(document.cookie)%22

For persistent XSS:

<a href="#" style="width:100%;height:100%;display:block;position:absolute;top:0px;left:0px" onMouseOver="alert(document.cookie)">&nbsp;</a>

So I propose to use MouseOverJacking technique for wide variety of XSS attacks (in case of impossibility of using of the tags and angle brackets). And security professionals and attackers can use this technique for creating of PoC for XSS vulnerabilities or for conducting of XSS attacks.

У випадку коли для Cross-Site Scripting атаки на сайті не можна використати жодні теги і кутові дужки, можна провести XSS атаку з використанням властивостей тегів. Це може бути властивість style, або різні обробники подій (або іноді можна провести атаку через властивість src). Для атаки потрібно використати лапки (одинарні чи подвійні, або іноді навіть лапки не потрібні), щоб додати нову властивість тегу, в який вдалося включити код.

При атаці через властивість style використуються наступні методи (при яких код виконується автоматично при завантаженні сторінки):

1. Через expression(), що працює лише в браузерах IE (до IE8).
2. Через background:url() чи background-image:url(), що працює лише в браузерах IE.
3. Через -moz-binding:url(), що працює лише в Mozilla Firefox та інших браузерах на движку Gecko (до Firefox 3).

Приклади атак з expression() і -moz-binding ви можете побачити у випадку уразливостей на www.ibm.com.

При атаці через обробники подій використуються наступні методи:

1. Через onMouseOver, onfocus, onblur, onselect, onchange, onclick та інші події (при яких код виконується при відповідній події).
2. Через onerror, onload, onunload (при яких код виконується автоматично при відкритті сторінки, або її закритті у випадку події onunload).

Можливість використовувати onerror, onload і onunload трапляється не дуже часто, а інші обробники спрацьовують не автоматично, тому менш популярні при проведенні XSS атак. Найбільш часто використовуються саме атаки через властивість style.

Але ще в 2008 році в Firefox 3 була прибрана можливість атаки через -moz-binding (прибрана частково - можна атакувати лише з використанням xml-файлів на тому ж сайті). Про що я писав в статті XSS атаки в Mozilla Firefox через стилі. А в Internet Explorer 8, що вийшов на початку 2009, прибрана підтримка expression(). Підтримка javascript та vbscript URI в background та background-image також може бути з часом прибрана.

Тому в світлі даних подій в нових браузерах стало важче проводити автоматизовані XSS атаки у таких випадках (коли не можна використати жодні теги і кутові дужки). І чим більш поширеними стануть дані версії браузерів, тим важче буде проводити XSS атаки в даних умовах (щоб вини були автоматизовані, без необхідності користувачу виконувати деякі дії). З іншої сторони, такі браузери як Opera, Chrome та інші браузери зовсім не піддаються атакам через властивість style.

Для вирішення цієї задачі може використовуватися техніка MouseOverJacking, про яку я вже писав. Дана техніка дозволяє провести автоматизовану XSS атаку. Причому це кросбраузерне рішення, що працює в усіх браузерах. В тому числі в IE8 - при використанні CSS (як у моїх PoC) вона дозволяє обійти вбудований захист IE8 від Clickjacking.

Тобто MouseOverJacking може використовуватися не тільки для специфічних атак, про які йшлося в статті про дану техніку, а для широкого кола XSS атак (замість expression() і -moz-binding). Причому атака повністю автоматизована, тобто ефективність атаки така сама як і у expression() і -moz-binding (а за рахунок кросбраузерності можна атакувати навіть більше користувачів).

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

Приклади PoC для Cross-Site Scripting уразливостей.

Для reflected XSS:

http://site/script?param=%22%20style=%22width:100%;height:100%;display:block;position:absolute;top:0px;left:0px%22%20onMouseOver=%22alert(document.cookie)%22

Для persistent XSS:

<a href="#" style="width:100%;height:100%;display:block;position:absolute;top:0px;left:0px" onMouseOver="alert(document.cookie)">&nbsp;</a>

Так що я пропоную використовувати техніку MouseOverJacking для широкого кола XSS атак (у випадку неможливості використання тегів і кутових дужок). І секюріті професіонали і нападники можуть використовувати дану техніку для створення PoC для XSS уразливостей чи для проведення XSS атак.

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

A Post-mortem of Yahoo! Account Security

В даному відео ролику демонструється використання уразливості в створенні кукісів в акаунті Yahoo. За допомогою спеціальної програми генеруються кукіси для необхідного логіна, після чого можна отримати Yahoo ID даного користувача (без знання паролю) і відповідно доступ до усіх сервісів Yahoo! (під даним логіном), включаючи веб версію Yahoo! IM та Yahoo! Mail. Рекомендую подивитися дане відео для розуміння подібних атак.

В грудні в своїй статті XSS уразливості в 8 мільйонах флеш файлах я писав, що в Інтернеті є до 34000000 флешек tagcloud.swf потенційно вразливих до XSS атак. Враховучи, що мало хто звернув увагу в попередній статті на мою згадку про ще 34 мільйони вразливих флешек, то я вирішив написати про це окрему статтю.

Файл tagcloud.swf розроблений автором плагіна WP-Cumulus для WordPress і постачається з даним плагіном для WordPress, а також з іншими плагінами, зокрема Joomulus і JVClouds3D для Joomla та Blogumus для Blogger. Враховуючи поширеність даного флеш файла, зазначу, що це найбільш поширена флешка в Інтернеті з XSS уразливістю.

Поширенність проблеми.

Взразливих файлів tagcloud.swf в Інтернеті дуже багато (за даними Google):

filetype:swf inurl:tagcloud.swf

Якщо 18.12.2009 результатів було приблизно 34000000, то зараз результатів приблизно 32500000. І це лише флеш файли проіндексовані Гуглом, а реально їх може бути набагато більше.

Тобто є приблизно 32,5 мільйони сайтів з файлом tagcloud.swf вразливих до XSS та HTML Injection атак.

З них приблизно 273000 gov-сайтів вразливих до XSS та HTML Injection атак.

Уразливості в swf-файлі.

Файл tagcloud.swf вразливий до XSS та HTML Injection атак через параметр tagcloud.

XSS:

http://site/tagcloud.swf?mode=tags&tagcloud=%3Ctags%3E%3Ca+href='javascript:alert(document.cookie)'+style='font-size:+40pt'%3EClick%20me%3C/a%3E%3C/tags%3E

Код виконається при кліку. Це Strictly social XSS.

HTML Injection:

http://site/tagcloud.swf?mode=tags&tagcloud=%3Ctags%3E%3Ca+href='http://websecurity.com.ua'+style='font-size:+40pt'%3EClick%20me%3C/a%3E%3C/tags%3E

HTML Injection атаку можна провести зокрема на ті флешки, де заборонені (у флешках чи через WAF) javascript та vbscript URI в параметрі tagcloud.

Приклади уразливих сайтів.

Приклади уразливих сайтів з даним swf-файлом я наводив в записі XSS уразливості в tagcloud.swf на gov та gov.ua.

Так що флеш девелоперам варто слідкувати за безпекою своїх флешек. А власникам сайтів з уразливими флешками (зокрема tagcloud.swf) потрібно або самим їх виправити, або звернутися за цим до їх розробників.