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

This is English version of my URL Hiding - new method of URL Spoofing attacks article.

In continue of my researches of vulnerabilities in search engines, I tell you about new interesting method of URL Spoofing attacks, which I called URL Hiding. It can be used for conducting of fishing attacks and for spreading of malware (particularly it can be used with previously described methods). This URL Hiding attack I found in Google, but other search engines also can be vulnerable.

This month, 19.05.2009, during searching in Google, I found interesting site, which not shows its URL in serp. I saw such sites earlier during using of Google (from 2000), but it’s first site which address I wrote down. This site is http://_-lilit-_.photosight.ru.

site:_-lilit-_.photosight.ru

In case when URL Hiding is using together with URL Spoofing methods, which I wrote about earlier (when long URL is made, e.g. with using of “_” char), then it improves the effectiveness of fishing and others attacks. Because long and suspicious URL will not be shown in serp of search engine, and when user will go by the link, then he can to not notice the URL (via using of URL Spoofing methods).

As I thought first, when using of underscore (like in case of http://_-lilit-_.photosight.ru), Google will not show address in serp at all. But there is no such effect in case of http://ane4ka-_.shalala.ru. Potentially it works only in case, if first char of domain is underscore.

I made a lot of researches when I was looking for sites with underscores, which hasn’t URL in serp, but didn’t find any such sites (but found one interesting bug in Google). So method of attack on Google for hiding of address of sites in serp can use this (with underscore at the beginning of domain), or other approach. But in any case URL Hiding attack is dangerous, because it allows to use search engines (Google in particular) for conducting of fishing and other attacks.

В даній статті я розповім вам про використання редиректорів в різних браузерах для проведення Cross-Site Scripting атак. Які можуть проводитися з метою викрадення кукісів, або доступу до сторінок веб сайта для проведення різноманітних просунутих атак (у випадку коли є зв’язок між кодом виконуємим через редиректор і сайтом), а також з метою проведення фішинг атак та виконання JavaScript коду (у випадку коли такого зв’язку немає).

Окрім того, що редиректори дозволяють редиректити на зловмисні та фішинг сайти (що є Redirector уразливістю), є також інші варіанти атак з їх використанням. Зокрема в своїх статтях Пекло редиректорів та Пекельний вогонь для редиректорів я писав про використання редиректорів для DoS атак. Ще в січні 2008 року я запланував написати статтю про різноманітні атаки з використанням редерикторів (планую зробити антологію атак через редиректори), що я обов’язково зроблю, але зараз розповів про одну з цих атак - про XSS атаки через редиректори.

Існують два типа редиректорів (серверних): location-header, що працюють через заголовок Location, та refresh-header, що працюють через заголовок Refresh.

В різних браузерах (через уразливості в них) можливі XSS атаки в різних редиректорах. Атаки відбуваються через редирекцію на javascript: URI та data: URI.

Атака №1

Як я писав про Cross-Site Scripting уразливості в Mozilla, Internet Explorer, Opera та Chrome, в браузерах Mozilla 1.7.x (та попередні версії), Mozilla Firefox 3.0.8 (та попередні версії), Internet Explorer 6 (та попередні версії, але не IE7 та IE8), Opera 9.52 (та попередні й наступні версії) та Google Chrome 1.0.154.48 (та попередні й наступні версії) можлива XSS атака через refresh-header редиректори. Атака відбувається при редирекції на javascript: URI.

Методика атаки:

При запиті до скрипта на сайті:
http://site/script.php?param=javascript:alert(document.cookie)
Що поверне у відповіді заголовок Refresh:
Refresh: 0; URL=javascript:alert(document.cookie)
Код спрацює в контексті даного сайту.

Дана уразливість в браузерах може використовуватися для проведення reflected XSS атак.

Атака №2

Як я писав про Cross-Site Scripting уразливості в Mozilla, Firefox та Chrome, в браузерах Mozilla 1.7.x (та попередні версії), Mozilla Firefox 3.0.12 (та попередні й наступні версії) та Google Chrome 1.0.154.48 (та попередні й наступні версії) можлива XSS атака через refresh-header редиректори. Атака відбувається при редирекції на data: URI (з або без використання base64).

Методика атаки:

При запиті до скрипта на сайті:
http://site/script.php?param=data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ%2b
Що поверне у відповіді заголовок refresh і код виконається у браузері:
refresh: 0; URL=data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ%2b

Так як в браузерах Firefox 3.0.12 і Google Chrome код спрацює не в контексті даного сайту, то таким чином до кукісів не дістатися, зате це можна зробити в старій Mozilla. Дана уразливість в браузерах (сучасних) може використовуватися для проведення фішинг атак та виконання JavaScript коду.

Атака №3

Як я писав про Cross-Site Scripting уразливості в Firefox та Opera, в браузерах Mozilla Firefox 3.0.12 (та попередні й наступні версії) та Opera 9.52 (та попередні й наступні версії) можлива XSS атака через location-header редиректори. Атака відбувається при редирекції на data: URI (з або без використання base64).

Методика атаки:

При запиті до скрипта на сайті:
http://site/script.php?param=data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ%2b
Що поверне у відповіді заголовок Location і код виконається у браузері:
Location: data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ+

Так як в браузерах Firefox і Opera код спрацює не в контексті даного сайту, то таким чином до кукісів не дістатися. Дана уразливість в браузерах може використовуватися для проведення фішинг атак та виконання JavaScript коду.

Обидва типи редиректорів, location-header та refresh-header, дуже поширені в Інтернеті, але найбільш поширеними є location-header редиректори. Тому наявність уразливостей, що працюють через location-header редиректори представляє найбільшу загрозу. Зокрема через дану уразливість в браузерах можливі атаки через сервіси редирекції, як я писав стосовно уразливості на tinyurl.com. Це дозволяє розповсюджувати malware через сервіси редирекції, коли замість адреси для редирекції буде вказаний код експлоіта.

Атака №4

Всі сучасні браузери не дозволяють виконання JavaScript коду при редирекції на javascript: URI в location-header редиректорах. Але як показали мої дослідження - це не завжди так. Як я писав про Cross-Site Scripting уразливості в Mozilla та Firefox, в браузерах Mozilla 1.7.x (та попередні версії) та Mozilla Firefox 3.0.12 (та попередні й наступні версії) можлива XSS атака через location-header редиректори, що використовують відповідь “302 Object moved”. Атака відбувається при редирекції на javascript: URI (а також можна провести атаку і на data: URI).

Методика атаки:

При запиті до скрипта на сайті:
http://site/script.php?param=javascript:alert(document.cookie)
Що поверне у відповіді заголовок Location:
HTTP/1.x 302 Object moved
Location: javascript:alert%28document.cookie%29
Браузер виводить сторінку “Object Moved”. При кліку по лінці “here” код спрацює в контексті даного сайту.

Дана уразливість в браузерах може використовуватися для проведення Strictly social XSS атак.

Атака №5

Після початкової публікацї статті, Aung Khant повідомив мені 24.08.2009 про уразливість в Maxthon 3 Alpha (3.0.0.145) з Ultramode. Яка дозволяє виконання JavaScript коду при редирекції на javascript: URI в location-header редиректорах. Це варіація атаки №4 (яку я перевіряв, але не знаходив в інших браузерах, але він знайшов її в Maxthon). Якщо в тому випадку XSS атака можлива через location-header редиректори, що використовують відповідь “302 Object moved”, то в даному випадку атака можлива при будь-яких 301 і 302 відповідях редиректорів. Атака відбувається при редирекції на javascript: URI.

Методика атаки:

При запиті до скрипта на сайті:
http://site/script.php?param=javascript:alert(document.cookie)
Що поверне у відповіді заголовок Location:
Location: javascript:alert%28document.cookie%29
Браузер виводить сторінку “Unable to connect to the site”. При кліку по лінці “Refresh the page” код спрацює. До речі, Maxthon 3 Alpha веде себе однаково у випадку атак №3,4,5 (код виконається не в контексті сайта).

Дана уразливість в Maxthon може використовуватися для проведення Strictly social XSS атак.

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

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

Атака №6

Як я писав про Cross-Site Scripting уразливість в Mozilla, Firefox та інших браузерах, в браузерах Mozilla 1.7.x (та попередні версії) та Mozilla Firefox 3.0.19 (та попередні й наступні версії) та потенційно в інших браузерах можлива XSS атака через location-header редиректори з відповіддю “302 Found”. Атака відбувається при редирекції на javascript: URI (а також можна провести атаку і на data: URI). Дана атака схожа на атаку №4.

Методика атаки:

При запиті до скрипта на сайті:
http://site/script.php?param=javascript:alert(document.cookie)
Що поверне у відповіді заголовок Location:
HTTP/1.x 302 Found
Location: javascript:alert(document.cookie)
Браузер виводить сторінку “Found”. При кліку по лінці “here” код спрацює в контексті даного сайту.

Дана уразливість в браузерах може використовуватися для проведення Strictly social XSS атак.

Атаки №7,8

В статті Cross-Site Scripting через редиректори 301 і 303 в різних браузерах я описав ще дві атаки через редиректори зі статусом 301 і 303. Це атаки через data: та javascript: URI.

[Оновлення: 05.08.2009]

Як я перевірив, Mozilla Firefox 3.0.13 також уразливий до атак №2,3,4.

У випадку всіх браузерів, що вразливі до атак №1,4, JS код виконується в контексті сайта.

[Оновлення: 22.08.2009]

Як я виявив з домопогою Aung Khant з YEHG Team, наступні браузери також уразливі:

Google Chrome 2.0.172.28, 2.0.172.37 та 3.0.193.2 Beta - уразливі до атак №1,2.

QtWeb 3.0 Build 001 та 3.0 Build 003 - уразливий до атак №1,2,3.

Safari 4.0.3 - уразливий до атак №1,2.

Opera 10.00 Beta 3 Build 1699 - уразливий до атак №1,3.

SeaMonkey 1.1.17 - уразливий до атак №1,2,4 і в №1,2,4 JS код виконується в контексті сайта.

[Оновлення: 25.08.2009]

Нова інформація від Aung Khant з YEHG Team:

Firefox 3.6 a1 pre - уразливий до атак №1,2,3,4 і в №1,2,4 JS код виконується в контексті сайта.

Firefox 3.7 a1 pre - уразливий до атак №2,3,4.

Orca Browser 1.2 build 5 - уразливий до атак №2,3,4.

Maxthon 3 Alpha (3.0.0.145 та 3.0.2.2) з Ultramode (емуляція Apple WebKit) - уразливий до атак №1,2. А також уразливий до атак №3,4,5 як Strictly social XSS.

[Оновлення: 05.08.2010]

Додав інформацію про атаку №6.

[Оновлення: 07.08.2010]

Нова інформація:

Mozilla Firefox 3.0.19 - уразливий до атак №2,3,4,6 і в №4,6 JS код виконується в контексті сайта.

Firefox 3.5.11 - уразливий до атак №2,3,4,6 і в №4,6 JS код виконується в контексті сайта.

Firefox 3.6.8 - уразливий до атак №2,3,4,6 і в №4,6 JS код виконується в контексті сайта.

Firefox 4.0b2 - уразливий до атак №2,3,4,6 і в №4,6 JS код виконується в контексті сайта.

Opera 10.53 - уразливий до атак №1,4,5,6.

[Оновлення: 16.09.2012]

Нова інформація:

Firefox 3.5.19, Firefox 3.6.28 - уразливі до атак №2,3,4,6 і в №4,6 JS код виконується в контексті сайта.

Firefox 10.0.7, Firefox 15.0.1 - уразливі до атак №2,3. В версіях Firefox 10.0.7 і 15.0.1 атаки №4,6 більше неможливі - дані уразливості були приховано виправлені Mozilla в Firefox 9.0.

Opera 10.62 - уразливий до атак №1,4,5,6.

[Оновлення: 25.09.2012]

Додав інформацію про атаки №7 і №8.

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

LSO: MSFweb 3.0 part 2

В даному відео ролику демонструється використання Metasploit Framework Web Console 3.0. Демонструються можливості MSF 3.0 та її Web Console по створенню експлотів, зокрема для IE. Рекомендую подивитися дане відео для розуміння середовища MSF.

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

Hacking SQL in Linux using the SecureState Swiss Army Knife

В даному відео ролику демонструється пошук SQL сервера та атака на нього за допомогою SecureState Swiss Army Knife. За допомогою даного додатку відбувається автоматизований пошук вразливого SQL сервера і створення на комп’ютері з ним нового акаунта адміністратора. Рекомендую подивитися дане відео для розуміння можливостей SecureState Swiss Army Knife.

Наскількі часто потрібно проводити перевірки веб додатків та веб сайтів? На це запитання спробував відповісти Binu Thomas в своїй статті How frequently should an Application be tested.

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

На думку Томаса, є наступні критерії вибору частоти проведення повторних перевірок веб додатків:

• Важливість даних
• Критичність додатку
• Частота змін у додатку

В своїй презентації Hacking Web 2.0 - Defending Ajax and Web Services, Shreeraj Shah розповідає про хакінг Веб 2.0. Про захист AJAX додатків та Веб Сервісів.

В цьому місяці я написав статтю про секюріті дослідження в Інтернеті, зокрема про знаходження уразливостей на веб сайтах та їх оприлюднення, а також про хакінг веб сайтів, та їх відповідність законодавству. Дана стаття була опублікована в The Web Security Mailing List в двох частинах 07.06.2009 та 14.06.2009.

Сьогодні я розмістив на сайті мою статтю на англійській мові (об’єднавши дві частини в одну статтю) та її переклад на українську мову. З якою ви можете ознайомитися.

Хакінг веб сайтів, секюріті дослідження, оприлюднення та законодавство

Зміст.

1. Передмова.
2. Знаходження уразливостей.
3. Хакінг веб сайтів.
4. Оприлюднення уразливості.
5. Приклади законів данної тематики.
6. Рекомендації по легальним секюріті дослідженням.
7. Інші цікаві аспекти веб безпеки та законодавства.

Hacking of web sites, security researches, disclosure and legislation

Table of contests.

1. Foreword.
2. Finding of vulnerabilities.
3. Hacking of web sites.
4. Vulnerability disclosure.
5. Examples of laws on this subject.
6. Guidelines for legal security researches.
7. Other interesting aspects of web security and legislation.

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

XSS injection in image formats

Якщо в попередньому відео ролику демонструвалася LFI атака через jpg файл, то в даному відео ролику демонструється XSS атака через файли зображень (зокрема через png файл). Тобто на сайт завантажується зображення в форматі png, в якому розміщений JavaScript (або VBScript) код.

І при перегляді даного файлу в Internet Explorer цей код виконається (що є давно відомою особливістю IE). Рекомендую подивитися дане відео для розуміння векторів Cross-Site Scripting атак, зокрема через файли зображень.

В своїй презентації Hacking and Securing .NET Apps, Shreeraj Shah розповідає про хакінг та захист веб додатків на платформі .NET. Про особливості атак на .NET додатки та їх захисту.

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

Local JPG shell Inclusion (LFI using php injected JPG)

В даному відео ролику демонструється LFI атака через локальний jpg файл. Тобто на сайт завантажується зображення в форматі jpg, в якому розміщений php код. І через Local File Inclusion уразливість цей код виконується. Рекомендую подивитися дане відео для розуміння векторів LFI атак, зокрема через jpg та інші файли.