В своїй презентації Top Ten Web Hacking Techniques (2008), Jeremiah Grossman розповідає про найкращі 10 веб хаків 2008 року. Раніше я вже писав про Найкращі веб хаки 2008 року і в своїй презентації Джеремія детально розповідає про десятку найкращих веб хаків.
This is English version of my XSS vulnerabilities in 8 millions flash files article.
I’ll continue a topic, which I started in 2008 in my article XSS vulnerabilities in 215000 flash files. That time I found hundreds of thousands flash files vulnerable to Cross-Site Scripting attacks. After previous article, published at 12.11.2008, I continued researches and found, that much more flash files - millions flash files - were vulnerable to XSS attacks. As flash files in different global and local banner systems, as flash files at individual sites.
Vulnerable ActionScript code.
As I already wrote in previous article, vulnerability is in the next AS code. As with setting second parameter in function getURL (target), as without it.
getURL(_root.clickTAG, "_blank");
But, as my researches showed, in different flash files (at different sites and banner systems) different parameters are using for passing of a site’s address to flash file. Besides clickTAG there are also using url and other parameters.
getURL(_root.url, "_blank");
Attack occurs via passing of XSS code to flash file in clickTAG, url or other parameter:
http://site/flash.swf?clickTAG=javascript:alert('XSS')
http://site/flash.swf?url=javascript:alert('XSS')
There are also flash files which are using two parameters, particularly clickTAG and TargetAS, with the next AS code:
getURL(_root.clickTAG, _root.TargetAS);
Attack occurs with using of parameters clickTAG and TargetAS:
http://site/flash.swf?clickTAG=javascript:alert('XSS')&TargetAS=
After click on flash the transfer of string to function getURL occurs, which passed to flash via appropriate parameter. Thus can be executed JavaScript code, which was passed to flash. So it’s strictly social XSS.
Prevalence of the problem.
Vulnerability exists in ActionScript code for counting of clicks in flash banners. And taking into account that such code is using for many years in different banner systems of Internet (including widespread instructions for developing of flash banners with using of vulnerable AS code), so the problem is widespread enough. For example, I registered at banner.kiev.ua already in 2000, and, as far as I remember, already at that time they had recommendations at the site with using of vulnerable AS code.
So problem is concerned with faulty recommendations for developing of flash banners with possibility of counting of clicks. And it’s concerned millions flash banners in the Net.
Such vulnerabilities exist in many banner system, as global, as local ones. Particularly these vulnerabilities I found in systems phpAdsNew, OpenAds and OpenX (at many sites on these engines), and also in banner system www.banner.kiev.ua and in other banner systems of Uanet an Runet.
There are a lot of potentially vulnerable flash files in Internet (according to Google):
About 3960000 results. At 12.11.2008 there were about 215000. Growth in 18,42 times for this time.
About 4050000 results. At 12.11.2008 there were about 996000. Growth in 4,07 times for this time.
In total it’s about 8010000 (more than 8 millions) flash files which are potentially vulnerable to XSS attacks. Not all of these flashes are vulnerable, but many of them. And these are only those flash files, which were indexed by Google, and actually there can be much more of them.
Among them there are about 12400 + 275 gov-sites - the sites of state institutions of different countries.
Note, that some of these flashes are using method #1 for protection against XSS, which is mentioned bellow. But it’s small percent of flashes - mostly they are using vulnerable AS code.
Besides, similar Strictly social XSS vulnerability I found at 15.03.2009 in plugin WP-Cumulus for WordPress (in file tagcloud.swf).
filetype:swf inurl:tagcloud.swf
About 34000000 results. I.e. another 34 millions flashes which are potentially vulnerable to XSS attacks 
. Add 34 millions to 8 millions and result 42 millions of vulnerable flash files!
Nuances of work in different browsers.
In flashes with set target = “_blank” it’s not possible to get to cookies in Internet Explorer (particularly IE6), Mozilla and Google Chrome. But it’s possible to get to cookies in Firefox 3, Opera 9.52 and possibly in other browsers.
Also in case of set target = “_blank”, JS-code doesn’t work in browsers IE6 and Google Chrome.
If target is unspecified, or if target set to other than “_blank” (including via parameter TargetAS, if it’s using in flash), JS-code works in all browsers. And it’s possible to get to cookies in all browsers.
Examples of vulnerable flash files.
Among sites with flashes vulnerable to XSS there is server.cpmstar.com (attack via parameter clickTAG):
Among gov-sites as an example of flash at www.fatherhood.gov (attack via parameter clickTag):
Example of vulnerable flash at www.banner.kiev.ua (attack via parameter url):
Example of vulnerable flash at www.wie-man-sieht.net, which allows to get to cookies in all browsers (attack via parameter url):
Example of vulnerable flash at www.adspeed.com, which allows to get to cookies in all browsers (attack via parameters clickTAG and TargetAS):
Protection of flash files against XSS attacks.
To prevent such XSS attacks via flash files it’s needed to not use vulnerable AS code and it’s needed to use one of the next methods.
1. Instead of vulnerable AS code it’s possible to use more secure code. E.g. code which is mentioned at Adobe’s site - Designer’s Guide: Building Macromedia Flash Banners with Tracking Capabilities.
on (release) {
if (clickTAG.substr(0,5) == "http:") {
getURL(clickTAG);
}
}
It’s code on button. If using of code on frame, then for button “button” code will be the next:
_root.button.onRelease = function () {
if (clickTAG.substr(0,5) == "http:") {
getURL(clickTAG);
}
}
But this method isn’t protecting against URL spoofing, which allows to conduct of redirection attacks to arbitrary (including malicious) sites. So it’s better to use more secure AS code.
2. To use direct URL in flash (http://site), without using of parameter clickTAG.
3. If needed to count clicks, then it’s possible to use URL to banner system (http://banner/click?id=1), which will redirect to necessary site.
For example, in my system MustLive Banner System directly in the interface I’m recommending to use for flash banners above-mentioned methods #2 and #3, so there is no this problem with XSS via flash files in it. So attend to your flash files and don’t allow such vulnerabilities in them.
Після написання новини про те, що понад 100000 сайтів заражені шкідливими iframe, я провів дослідження і знайшов цікавий сервіс Safe Browsing від Google (який є частиною вбудованої в пошуковець антивірусної системи). Даний сервіс дозволяє дізнатися інформацію про будь-який сайт просканований Гуглом, чи він є інфікованим і чи він був інфікованим на протязі останніх 90 днів.
Google є один з небагатьох пошуковців, що вже багато років проводить власні дослідження зараженності веб сайтів, про що періодично публікує звіти, чи заяви стосовно найбільш гучних випадків, як у вищезгаданій новині. А також повідомляє користувачів власної пошукової системи про небезпечність інфікованих сайтів у результатах пошуку. І сервіс Safe Browsing дозволяє отримати доступ до даних Гугла стосовно зараженності сайтів в Інтернеті.
Щоб скористатися сервісом Safe Browsing, потрібно зайти на сторінку діагностики сайта (в URL потрібно вказати домен сайта, інформацію по якому ви хочете отримати):
http://google.com/safebrowsing/diagnostic?site=site.com
І ознайомившись з цим сервісом я розробив метод, за допомогою якого я зможу використовувати Safe Browsing для пошуку інфікованих сайтів (окрім безпосереднього пошуку в Гуглі та знаходженні повідомлень про зараженність сайтів).
Щоб виявити кількість сайтів занесених Гуглом в базу інфікованих, потрібно використати наступні запити:
Всього в індексі Гугла до 1570000 сайтів занесених в базу Safe Browsing. Раз вони туди були занесені, значить вони або зараз інфіковані, або були інфіковані раніше.
site:google.com/safebrowsing/ ua
В Уанеті за даними Гугла до 8970 сайтів занесених в базу Safe Browsing.
Скільки сайтів інфіковано за даними Гугла:
site:google.com/safebrowsing/ “suspicious activity”
Всього до 29900 сайтів. З них до 817 gov-сайтів.
Скільки сайтів інфіковано в Уанеті за даними Гугла:
site:google.com/safebrowsing/ ua “suspicious activity”
Всього до 555 сайтів. З них до 84 державних сайтів.
Продовжу тему, яку я підняв в 2008 році в своїй статті XSS уразливості в 215000 флеш файлах. Тоді я виявив сотні тисяч флешек уразливих до Cross-Site Scripting атак. Після попередньої статті, опублікованої 12.11.2008, я продовжив дослідження і виявив, що набагато більше флешек - мільйони флеш файлів - вразливі до XSS атак. Як флешек у різних глобальних і локальних банерних системах, так і флешек на окремих сайтах.
Уразливий ActionScript код.
Як я вже зазначав в попередній статті, уразливість в наступному AS коді. Причому як з вказанням другого параметра в фунції getURL (target), так і без нього:
getURL(_root.clickTAG, "_blank");
Але, як показали мої дослідження, в різніх флешках (на різних сайтах та банерних системах) використовується різні параметри для передачі адреси сайта у флешку. Окрім clickTAG також використовуються url та інші параметри.
getURL(_root.url, "_blank");
Атака відбувається через передачу XSS коду flash файлу в clickTAG, url чи іншому параметрі:
http://site/flash.swf?clickTAG=javascript:alert('XSS')
http://site/flash.swf?url=javascript:alert('XSS')
Також існують флешки, що використовують два параметри, зокрема clickTAG і TargetAS, з наступним AS кодом:
getURL(_root.clickTAG, _root.TargetAS);
Атака відбувається з використанням параметрів clickTAG і TargetAS:
http://site/flash.swf?clickTAG=javascript:alert('XSS')&TargetAS=
При кліку на флешку відбувається передача функції getURL рядку, що переданий флешці через відповідний параметр. Таким чином може виконатися JavaScript код, що був переданий флешці. Тобто це strictly social XSS.
Поширенність проблеми.
Уразливість наявна в ActionScript коді для підрахунку кліків у флеш банерах. І враховуючи, що подібний код використовується вже багато років в різних банерних системах Інтернету (в тому числі поширені інструкції по розробці флеш банерів з використанням вразливого AS коду), то проблема достатньо поширена. Наприклад, на banner.kiev.ua я зареєструвався ще в 2000 році, і, наскільки я пам’ятаю, вже тоді в них на сайті були дані рекомендації з використанням вразливого AS коду.
Тобто проблема пов’язана з неякісними рекомендаціями по розробці флеш банерів з можливістю підрахунку кліків. І вона стосується мільйонів флеш банерів у Мережі.
Подібні уразливості наявні в багатьох банерних системах, як глобальних, так і локальних. Зокрема дані уразливості я виявив в системах phpAdsNew, OpenAds та OpenX (на багатьох сайтах на даних движках), а також в банерній системі www.banner.kiev.ua та в інших банерних системах Уанета і Рунета.
Потенційно взразливих флешек в Інтернеті дуже багато (за даними Google):
Результатів приблизно 3960000. 12.11.2008 їх було приблизно 215000. Зростання в 18,42 рази за цей час.
Результатів приблизно 4050000. 12.11.2008 їх було приблизно 996000. Зростання в 4,07 рази за цей час.
В сумі виходить, що приблизно 8010000 (понад 8 мільйонів) флешек потенційно вразливі до XSS атак. Не всі з цих флешек вразливі, але чимало з них. І це лише флеш файли проіндексовані Гуглом, а реально їх може бути набагато більше.
Середи них приблизно 12400 + 275 gov-сайтів - сайтів державних установ різних країн.
Зазначу, що деякі з цих флешек використовують методику №1 для захисту від XSS, що наведена нижче. Але це невеликий відсоток флешек - в основному вони використовують вразливий AS код.
До речі, подібну Strictly social XSS уразливість я виявив 15.03.2009 в плагіні WP-Cumulus для WordPress (в файлі tagcloud.swf).
filetype:swf inurl:tagcloud.swf
Результатів приблизно 34000000. Тобто ще 34 мільйони флешек потенційно вразливих до XSS атак . Додайте 34 млн. до 8 млн. і вийде 42 мільйони вразливих флешек!
Особливості роботи в різних браузерах.
При вказаному у флешці target = “_blank” до кукісів не можна дістатися в Internet Explorer (зокрема IE6), Mozilla та Google Chrome. Зате можна дістатися до кукісів в Firefox 3, Opera 9.52 і можливо в інших браузерах.
Також у випадку, якщо вказаний target = “_blank”, JS-код не спрацьовує у браузерах IE6 та Google Chrome.
При невказаному target, або при вказаному target іншому ніж “_blank” (в тому числі через параметр TargetAS, при його використанні у флешці), JS-код спрацьовує в усіх браузерах. І в усіх браузерах можна дістатися до кукісів.
Приклади уразливих флешек.
Серед сайтів з уразливими до XSS флешками є server.cpmstar.com (атака через параметр clickTAG):
Серед gov-сайтів приведу приклад флешки на www.fatherhood.gov (атака через параметр clickTag):
Приклад уразливої флешки на www.banner.kiev.ua (атака через параметр url):
Приклад уразливої флешки на www.wie-man-sieht.net, що дозволяє дістатися до кукісів в усіх браузерах (атака через параметр url):
Приклад уразливої флешки на www.adspeed.com, що дозволяє дістатися до кукісів в усіх браузерах (атака через параметри clickTAG і TargetAS):
Захист флешек від XSS атак.
Щоб не допустити даних XSS атак через флешки потрібно не використовувати вразливий AS код і потрібно використати один з наступних методів.
1. Замість вразливого AS коду можна використати більш надійний код. Наприклад код, що наводиться на сайті Adobe - Designer’s Guide: Building Macromedia Flash Banners with Tracking Capabilities.
on (release) {
if (clickTAG.substr(0,5) == "http:") {
getURL(clickTAG);
}
}
Це код на кнопку. При використанні кода на кадр, то для кнопки button код буде наступним:
_root.button.onRelease = function () {
if (clickTAG.substr(0,5) == "http:") {
getURL(clickTAG);
}
}
Але цей метод не захищає від підміни URL, що дозволить провести атаки редирекції на довільні (в тому числі зловмисні) сайти. Тому краще використати більш надійний AS код.
2. Використати прямий URL у флешці (http://site), без використання параметру clickTAG.
3. Якщо потрібно підраховувати кліки, то можна використати URL на банерну систему (http://banner/click?id=1), що редиректне на потрібний сайт.
Наприклад, в своїй системі MustLive Banner System безпосередьно в інтерфейсі я рекомендую використовувати для флеш банерів вищеназвані методи №2 і №3, тому й даної проблеми з XSS через флеш файли в ній немає. Так що слідкуйте за своїми флешками і не допускайте в них подібних уразливостей.
Продовжуючи розпочату традицію, після попереднього відео про створення експоіта в Metasploit, пропоную новий відео секюріті мануал. Цього разу відео про створення ActiveX експоіта в Metasploit. Рекомендую подивитися всім хто цікавиться цією темою.
milw0rm exploit 2 metasploit (activex)
В даному відео ролику демонструється використання Metasploit Framework для створення експлоіта для вразливого ActiveX-компонента (використовуючи дані з іншого експлоіта). Зокрема, як і в попередньому відео, демонструється процес використання MSF-eXploit Builder, що є складовою Metasploit Framework. Рекомендую подивитися дане відео для розуміння інструментарія середовища MSF.
В статті Правила пентеста - аудит по стандарту PCI DSS розповідається про методології пентестингу і про стандарт PCI DSS. А також про методику проведення аудиту безпеки по стандарту PCI DSS (Payment Card Industry Data Security Standard).
В статті наводяться наступні аспекти PCI DSS аудиту:
Проведення аудиту безпеки по стандарту PCI DSS необхідно для тих сайтів банків та e-commerce сервісів, що працюють з кредитними картами.
Продовжуючи розпочату традицію, після попереднього відео про хак голосового VLAN, пропоную новий відео секюріті мануал. Цього разу відео про створення експоіта в Metasploit. Рекомендую подивитися всім хто цікавиться цією темою.
В даному відео ролику демонструється використання Metasploit Framework для створення експлоіта (використовуючи дані з іншого експлоіта). Зокрема демонструється процес використання MSF-eXploit Builder, що є складовою Metasploit Framework. Рекомендую подивитися дане відео для розуміння інструментарія середовища MSF.
This is English version of my Fingerprinting of Apache web server article.
Already at 10.09.2006 I created method of fingerprinting of Apache web server. This method based on feature of Apache, which I found at that time during security researches at my localhost (on Apache 1.3.23).
Feature of Apache.
There is interesting feature of Apache web server, which lie in that for accessing to file it’s possible to not set its extension. As I found recently, this future concerned with MultiViews option (if it’s turned on, which is by default).
I.e. for accessing to file robots.txt at the site, request can be made to file robots.txt:
http://site/robots.txt
Or request can be made to file robots (without extension):
http://site/robots
I.e. with making of request to file without setting of its extension, Apache will show file (which can have arbitrary extension at the server) after making of auto-addition of extension.
At that it concerns only those extensions, which is known by Apache. I.e. those ones, MIME type of which is known by Apache (which sets in settings of web server, particularly in mime.types). Order of auto-addition of extensions also sets in settings of web server.
For example, according to settings of my Apache, if to place test.html, test.txt and test.xml at the server, then at request to file test:
http://site/test
Content of test.xml will be shown, i.e. xml extension is going first. Html extension is going next and after that is txt extension.
Fingerprinting of Apache.
This feature can be used for identification of Apache.
For this it’s needed to find any working file at the server, which name and extension is known. For example, page.html. And after that to send two requests: http://site/page.html and http://site/page.
If in both cases there will be shown content of the same file and, which is the most important, there will be no error 404, then this web server is Apache.
Searching for hidden information.
Also this feature can be used for searching for hidden information at the sites. On which this feature of Apache will lead to information leakage.
For example, if there is a file secret.ext at the site, which extension (ext) can be complex (non-standard), or can be standard. To find this file there is no need to guess its full name (with extension), and it’ll be enough to guess only name without extension. Which allows to find this hidden file much faster.
http://site/secret
I have happened to use this feature of Apache on own experience during security audit to find hidden information at the site, admin of which didn’t expect that somebody would find this information.
Affected versions.
This feature works in Apache 1.x - tested in Apache 1.3.23 and Apache 1.3.37. Also it works in Apache 2.x, but I haven’t happened to meet such sites on Apache 2.x. So all versions of Apache with turned on MultiViews have this feature.
For example, Google also isn’t using extensions in some scripts at their sites - http://www.google.com/search - but they are using server GWS and it’s there such name set for web application. Besides Apache I haven’t happened to meet other web servers with such feature.
Ще 10.09.2006 я розробив методику визначення веб сервера Apache (fingerprinting). Дана методика базується на особливості Apache, яку я тоді, під час секюріті досліджень, виявив в себе на localhost (на Apache 1.3.23).
Особливість Apache.
Цікава особливість веб сервера Apache полягає в тому, що для доступу до файла, можна не вказувати його розширення. Як я нещодавно вияснив, ця особливість пов’язана з опцією MultiViews (якщо вона ввімкнена, що є по замовчуванню).
Тобто для доступу до файла robots.txt на сайті, можна зробити запит до файла robots.txt:
http://site/robots.txt
Або можна зробити запит до файла robots (без розширення):
http://site/robots
Тобто зробивши запит до файла без вказання його розширення, Апач виведе файл (який може мати довільне розширення на сервері) зробивши автодоповнення розширення.
При цьому це стосується лише тих розширень, які знає Апач. Тобто тих, MIME type яких відомий Апачу (що задається в налаштуваннях веб сервера, зокрема в mime.types). Порядок підстановки розширень також задається налаштуваннями веб сервера.
Наприклад, відповідно до налаштуваннь мого Apache, якщо на сервері розмістити test.html, test.txt і test.xml, то при запиті до файла test:
http://site/test
Виведеться зміст test.xml, тобто першим йде розширення xml. Наступним йде розширення html і потім вже розширення txt.
Визначення Apache.
Дану особливість можна використати для ідентифікації Apache.
Для цього потрібно виявити будь-який робочий файл на сервері, ім’я і розширення якого відомі. Наприклад, page.html. І потім послати два запити: http://site/page.html і http://site/page.
Якщо в обох випадках буде виведений зміст того ж самого файлу і, що є найбільш важливим, не буде помилки 404, значить цей веб сервер є Apache.
Пошук прихованої інформації.
Також дану особливість можна використати для пошуку прихованої інформації на сайтах. На яких дана особливість Apache призведе до витоку інформації.
Наприклад, якщо на сайті є файл secret.ext, розширення якого (ext) може бути складним (нестандартним), а може бути й стандартним. Для виявлення цього файлу не потібно вгадувати його повне ім’я (з розширенням), а достатньо буде вгадати лише ім’я без розширення. Що дозволить значно швидше виявити цей прихований файл.
http://site/secret
На власному досвіді під час секюріті аудиту доводилося використовувати дану особливість Апача для виявлення секретної інформації на сайті, адмін якого не сподівався, що хтось знайде цю інформацію.
Вразливі версії.
Дана особливість працює в Apache 1.x - перевірено в Apache 1.3.23 і Apache 1.3.37. Також вона працює в Apache 2.x, але мені не доводилося зустрічати подібні сайти на Apache 2.x. Так що всі версії Apache з ввімкненим MultiViews мають дану особливість.
Наприклад, Гугл також не використовує розширення у деяких скриптів на своїх сайтах - http://www.google.com/search - але в них сервер GWS і це в них таке ім’я задане для веб додатка. Окрім Apache мені не доводилося зустрічати інших веб серверів з подібною особливістю.
Продовжуючи розпочату традицію, після попереднього відео про те, як зробити файл таким, що не виявляється антивірусами, пропоную новий відео секюріті мануал. Цього разу відео про хак голосового VLAN. Рекомендую подивитися всім хто цікавиться цією темою.
В даному відео ролику демонструється методика проведення хака анонімного голосового VLAN. Методика показана на прикладі обладнання Cisco. Рекомендую подивитися дане відео для розуміння методів атаки на VLAN.
* 
You are currently browsing the archives for the Статті category.
Copyright © 2006-2025 MustLive. Усі права захищені.
Партнер проекту Websecurity.com.ua - веб проект mlfun.org.ua.