У своєму пості Аспекты безопасности flash-приложений, Олександр Комлев навів презентацію Стефано Ді Паола стосовно безпеки flash додатків.
Stefano Di.Paola - Finding Vulnerabilities in Flash Applications
В своїй презентації “Знаходження уразливостей у флеш додатках”, Стефано розповідає про особливості безпеки технології Flash і додатків на її основі та пошук уразливостей у флешках.
Гугл хакінг (Google hacking) - це пошук уразливостей на сайтах за домогою Гугла (дану техніку можна використовувати і з іншими пошуковими системами). Про Гугл хакінг я вже розповідав раніше в проекті MOSEB, в статті Полювання на Капчі та в серії статей про “Warning” Google хакінг (про пошук Full path disclosure та Information disclosure уразливостей).
В даній статті я розповім про використання Гугл хакінга для пошуку Cross-Site Scripting уразливостей. Пошук вразливих сайтів буде проводитися на реальному прикладі - на XSS уразливості в RiSearch, що я оприлюднив учора.
Локальний пошуковий движок RiSearch поширений в Інтернеті і є чимало сайтів, що використовують старі вразливі версії движка. Декілька прикладів таких вразливих сайтів зі старими версіями RiSearch будуть наведені в статті.
Пошук сайтів з RiSearch.
Головний скрипт в даному пошуковці - search.pl. Тому необхідно знайти сайти, що містять даний скрипт.
inurl:search.pl - до 2700000 результатів.
Це дуже велика кількість результатів і серед них багато сайтів зі скриптом search.pl, що не відноситься до цього движка, тому знадобиться багато часу, щоб знайти необхідні сайти.
inurl:search.pl (по Україні) - до 18100 результатів.
Географічний фільтр дає можливість звузити результати пошуку. Це значно менша кількість результатів, тому можна більш швидше знайти необхідні сайти.
inurl:search.pl inurl:query - до 2830000 результатів.
Більш точний запит, але кількість результатів дуже велика, тому знадобиться багато часу, щоб знайти необхідні сайти.
inurl:search.pl inurl:query inurl:stpos - до 30800 результатів.
Доволі точний запит. Кількість результатів значно менша, тому можна більш швидше знайти необхідні сайти.
inurl:search.pl inurl:query inurl:stpos (по Україні) - до 704 результатів.
Точний запит разом з географічним фільтром дозволяють значно звузити результати пошуку. Кількість результатів невелика, тому можна швидко знайти необхідні сайти.
Також можливий пошук за іменем програми. В цьому випадку необхідно знайти сайти, що містять назву даного движка.
“Search powered by RiSearch” - до 8870 результатів.
“Powered by RiSearch” - до 56500 результатів.
“Powered by RiSearch PHP” - до 16500 результатів (це пошук іншої версії движка RiSearch PHP, старі версії якої також вразливі до XSS, як я вияснив сьогодні).
Це доволі точні запити. З невеликою кількістю результатів, що дозволяють швидко знайти необхідні сайти. А при використанні географічного фільтру, можна ще більш звузити діапазон і пришвидшити процес пошуку.
Результати пошуку вразливих сайтів.
За короткий час було знайдено 7 уразливостей в локальних пошуковцях на движку RiSearch на 6 сайтах.
XSS:
http://www.fishing.kiev.ua
http://www.agrobank.com.ua - сайт банку і це дуже несерйозно для банку мати уразливості на своєму сайті (з дірками на банківських сайтах я стикаюся часто).
http://shema.ru
http://parus.ua
http://www.radio.ru
http://www.tahlil.uz
Продовжуючи розпочату традицію, після попереднього відео про PHP Remote File Inclusion, пропоную новий відео секюріті мануал. Цього разу відео про Cross-Site Scripting через зображення. Рекомендую подивитися всім хто цікавиться цією темою.
WBB Portal Cross-Site Scripting Using Unsanitized jpg File
В даному відео ролику розповідається про використання зображення (jpg файла) для проведення XSS атаки на адміна веб сайта (на прикладі WBB Portal). Рекомендую подивитися дане відео для розуміння векторів атаки за допомогою Cross-Site Scripting та небезпеки подібних уразливостей.
Продовжу тему “Warning” Гугл хакінга (”Warning” Google hacking). Котрий є різновидом Гугл хакінга - використання пошукових систем (зокрема Гугла) для пошуку уразливостей на сайтах.
Дана методика передбачає використання Гугла (чи інших пошукових систем) з метою пошуку повідомлень на сайтах про помилки, і дозволяє знайти важливу інформацію стосовно даних сайтів. За допомогою спеціальних пошукових запитів (дорків) можна знайти Full path disclosure та Information disclosure уразливості на різноманітних сайтах в Інтернеті.
Новий перелік “варнінг” пошукових запитів (dorks):
Продовжуючи розпочату традицію, після попереднього відео про пошук уразливостей в веб додатках, пропоную новий відео секюріті мануал. Цього разу відео про PHP Remote File Inclusion атаку. Рекомендую подивитися всім хто цікавиться цією темою.
PHP Remote File Inclusion / Windows Backdoor
В даному відео ролику розповідається про використання PHP Remote File Inclusion уразливостей на прикладі одного веб сайта. Причому окрім використання RFI для створення PHP-шелу, хакер відкриває порт на сервері та створює на ньому бекдор. Рекомендую подивитися дане відео для розуміння векторів атаки за допомогою PHP Remote File Inclusion та небезпеки подібних уразливостей.
Let’s examine methods of searching for vulnerable captchas. Main tool it is Google hacking - searching for vulnerabilities at sites using Google (this approach can be used and with others search engines). When vulnerable captcha was discovered, than good guys (with purpose to inform about availability of vulnerabilities) and bad guys (with purpose to use these vulnerabilities) can find sites with vulnerable captcha using search engines. So let’s examine ways of using Google hacking for searching for sites with vulnerable captchas of different types: text, logical and image (graphic).
Searching for vulnerable text captchas.
In case of text captchas they can be searched by text, which is near with captchas (via Google Search).
“into the textbox below” - up to 71000 results.
Taking into account that different captchas can use the same or similar text phrases, it’ll be not simple to find specific vulnerable captсha. For more precise results it’s need to specify search phrase.
Resistance: for resistance to this method it’s better to change default captcha’s phrases, then your site will be harder to find by presence of vulnerable captcha. But it’s better to use reliable captchas.
Searching for vulnerable logical captchas.
In case of logical captchas they can be searched by text, which is near with captchas (via Google Search).
“Check this box if you are not a spammer” - up to 12500 results.
Taking into account that different captchas can use the same or similar text phrases, it’ll be not simple to find specific vulnerable captсha. For more precise results it’s need to specify search phrase.
Resistance: for resistance to this method it’s better to change default captcha’s phrases, then your site will be harder to find by presence of vulnerable captcha. But it’s better to use reliable captchas.
Searching for vulnerable graphic captchas.
In case of graphic captchas for searching for sites with vulerable captchas there are two approaches.
1. They can be searched by text, which is near with captchas (via Google Search).
“Please enter the numbers you see below” - up to 39500 results.
This variant is not too precise, because different captchas can use the same or similar text phrases. So it’ll be not simple to find specific vulnerable captсha (but it is possible to search for different ones to find captchas with similar vulnerabilities).
Resistance: for resistance to this method it’s better to change default captcha’s phrases, then your site will be harder to find by presence of vulnerable captcha. But it’s better to not use vulnerable captchas.
2. They can be searched by their image (via Google Image Search).
Let’s view on example of captcha mt-scode:
mt-scode.cgi - up to 3340 results.
inurl:mt-scode.cgi - up to 3270 results.
This variant is more precise, because it’s allow to search for specific vulnerable captсha.
Resistance: for resistance to this method it’s better to change captcha’s filenames, then your site will be harder to find by presence of vulnerable captcha. But it’s better to not use vulnerable captchas.
Розглянемо методи пошуку вразливих капч. Головним іструментом є Гугл хакінг - пошук уразливостей на сайтах за домогою Гугла (даний підхід можна використовувати і з іншими пошуковими системами). Коли виявлена вразлива капча, то хороші хлопці (з метою повідомлення про наявність уразливостей) та погані хлопці (з метою використання цих уразливостей) можуть за допомогою пошукових систем знайти сайти з даною вразливою капчою. Тому розглянемо шляхи використання Гугл хакінга для пошуку сайтів з уразливими капчами різних типів: текстових, логічних та графічних.
Пошук вразливих текстових капч.
У випадку текстових капч їх можна шукати по тексту, котрий є поряд з капчами (через Google Search).
“into the textbox below” - до 71000 результатів.
Враховуючи, що різні капчі можуть використовувати однакові або схожі текстові фрази, буде не просто знайти конкретну вразливу капчу. Для точніших результатів потрібно уточнювати пошукову фразу.
Протидія: для протидії даному методу варто змінювати стандартні фрази капч, тоді ваш сайт буде важче знайти через наявність вразливої капчи. Але краще використовувати надійні капчі.
Пошук вразливих логічних капч.
У випадку логічних капч їх можна шукати по тексту, котрий є поряд з капчами (через Google Search).
“Check this box if you are not a spammer” - до 12500 результатів.
Враховуючи, що різні капчі можуть використовувати однакові або схожі текстові фрази, буде не просто знайти конкретну вразливу капчу. Для точніших результатів потрібно уточнювати пошукову фразу.
Протидія: для протидії даному методу варто змінювати стандартні фрази капч, тоді ваш сайт буде важче знайти через наявність вразливої капчи. Але краще використовувати надійні капчі.
Пошук вразливих графічних капч.
У випадку графічних капч для пошуку сайтів з уразливими капчами існує два підходи.
1. Можна шукати по тексту, котрий є поряд з капчами (через Google Search).
“Please enter the numbers you see below” - до 39500 результатів.
Даний варіант є не дуже точним, тому що різні капчі можуть використовувати однакові або схожі текстові фрази. Тому буде не просто знайти конкретну вразливу капчу (але можна шукати різні, щоб знайти капчі зі схожими вразливостями).
Протидія: для протидії даному методу варто змінювати стандартні фрази капч, тоді ваш сайт буде важче знайти через наявність вразливої капчи. Але краще зовсім не використовувати вразливих капч.
2. Можна шукати по їх зображенню (через Google Image Search).
Розглянемо на прикладі капчі mt-scode:
mt-scode.cgi - до 3340 результатів.
inurl:mt-scode.cgi - до 3270 результатів.
Даний варіант є більш точним, тому що дозволяє шукати конкретну вразливу капчу.
Протидія: для протидії даному методу варто змінювати імена файлів капч, тоді ваш сайт буде важче знайти через наявність вразливої капчи. Але краще зовсім не використовувати вразливих капч.
На hostinfo була опублікована цікава стаття “Боротьба зі спамом в коментарях”. Дана тема є актуальною, зокрема враховуючи мій новий проект Місяць багів в Капчах, котрий відбудеться в листопаді.
В даній статті розповідається про методи боротьби зі спамом в коментарях, про плюси та мінуси різних методів захисту від спаму.
В статті наводяться наступні методи захисту:
Серед зазначених методів я б виділив як найбільш ефективні наступні: Використання служб аутентифікації, CAPTCHA (невразлива) та Akismet. Всі інші методи менш ефективні та їх можна так чи інакше обійти. А от служби аутентифікації та невразливі капчі (та в деякій мірі сервіс Akismet) можуть захистити від спам коментарів.
На hostinfo була опублікована цікава стаття “Чи так потрібна CAPTCHA”. Дана тема є актуальною, зокрема враховуючи мій новий проект Місяць багів в Капчах, котрий відбудеться в наступному місяці. Тому інформація на тему захисту від спаму є начасі.
В даній статті розповідається про системи CAPTCHA (Completely Automatic Public Turing Test to Tell Computers and Humans Apart). Та розповідається про те, що часто можна обійтись без CAPTCHA-систем, захищаючи свій сайт від спаму.
В статті наводяться наступні методи захисту:
Зазначу, що ці методи дають лише невеликий ефект і всі вони обходяться. Зі сторони безпеки вони всі не є дієвими (і відносно легко обходяться). Найбільш ефективним з наведених є метод обробки по токенам (квиткам), але й він обходиться.
Тому для захисту від автоматизованих повідомлень потрібно використовувати Капчі. Причому для більшого захисту можна використовувати їх разом з додатковими методами захисту, з числа наведених, зокрема з токенами). Головне, щоб сама капча була зроблена надійно. Про недоліки безпеки капч я і буду розповідати в Month of Bugs in Captchas.
This is English version of my Web 3.0 article.
In our time, in era of Web 2.0, people begin thinking about the future evolution of Net - begin thinking about Web 3.0. And so there were appeared publications of Internet figures about this topic lately. Particularly you can look at the article about Web 3.0 at Wikipedia. This article tells about different views at third web, but I have another views at it.
I begun thinking about third web already at the beginning of 2006 year. And not just thinking, but making real steps for appearing of Web 3.0. The first from them was my online Pascal interpreter. After its release I put this web application to Web 3.0 category and begun seeing in third web innovation component. After that I begun strenuously working on security of web sites (I worked on it in 2005 and in first part of 2006, but in second part of 2006 I started working on it more actively). And at the end of 2006 year I drew attention at another component of third web - at its security.
There are two components of Web 3.0: innovation and security.
Web 3.0 - innovation web.
I refer to innovation component my online interpreter - MustLive Perl Pascal Programs Interpreter. It’s first in the world online interpreter and first Web 3.0 application. If in case of Web 2.0 people started wide use web for content creation online (with help of software tools), than in case of Web 3.0 people would begin (and already begun) to use web for software creation online (with help of online interpreters). This is the next level of evolution of Internet.
Version 1.2 of interpreter in which was added online version released at 24.05.2006. This is the date of the beginning of Web 3.0 era’s innovation component.
Web 3.0 - secure web.
I refer to security component the security of sites and web applications. Working in web security field during 2005, 2006 and 2007 years I analyse current state of security of Net. And I can establish, that 90% of sites have security vulnerabilities (by my statistics). Since from opening of my security project in middle of 2006 year, I begun strenuously working on web security and social audit (finding vulnerabilities at sites and notifying their administrators about them).
And after I drew attention at security component of Web 3.0 I laid down next demand: third web must be more secure than second one. If now Web 2.0 has 90% vulnerable sites, than Web 3.0 must has 45-50% of them (i.e. two times less). Only then we can speak that era of third web already has come (in context of security). But I understand that it’s very hard task, and not many want to find vulnerabilities and fix them, so process of reaching of this indicators can be delayed, so with time it’s possible to adjust this demands and set for Web 3.0 limit in 60-70% of vulnerable sites, and set 40-50% already for Web 4.0. Main thing is to work in this direction.
I started my site websecurity.com.ua at 18.07.2006. This is the date of the beginning of Web 3.0 era’s security component.
The security of current Net is very low - Internet very dangerous environment. As considering its current problems for users (such as spam, fishing, viruses), and considering that 90% of sites have security vulnerabilities. So the level of security need to be strongly improved.
In this was consisted the essence of my Month of Search Engines Bugs project - improvement of security of Internet and bringing Web 3.0 era. And I’ll be working on this in the future.
* 
You are currently browsing the archives for the Статті category.
Copyright © 2006-2025 MustLive. Усі права захищені.
Партнер проекту Websecurity.com.ua - веб проект mlfun.org.ua.