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

Продовжуючи розпочату традицію, після попереднього відео про 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):

Warning: preg_replace

Warning: preg_grep

Warning: preg_match_all

Warning: preg_match

Warning: preg_quote

Warning: preg_replace_callback

Warning: preg_split

Warning: mysql_data_seek

Warning: require

Warning: require_once

Warning: fwrite

Warning: flock

Warning: unlink

Warning: file

Warning: readfile

Продовжуючи розпочату традицію, після попереднього відео про пошук уразливостей в веб додатках, пропоную новий відео секюріті мануал. Цього разу відео про 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

Серед зазначених методів я б виділив як найбільш ефективні наступні: Використання служб аутентифікації, CAPTCHA (невразлива) та Akismet. Всі інші методи менш ефективні та їх можна так чи інакше обійти. А от служби аутентифікації та невразливі капчі (та в деякій мірі сервіс Akismet) можуть захистити від спам коментарів.

• Борьба со спамом в комментариях (деталі)

На hostinfo була опублікована цікава стаття “Чи так потрібна CAPTCHA”. Дана тема є актуальною, зокрема враховуючи мій новий проект Місяць багів в Капчах, котрий відбудеться в наступному місяці. Тому інформація на тему захисту від спаму є начасі.

В даній статті розповідається про системи CAPTCHA (Completely Automatic Public Turing Test to Tell Computers and Humans Apart). Та розповідається про те, що часто можна обійтись без CAPTCHA-систем, захищаючи свій сайт від спаму.

В статті наводяться наступні методи захисту:

• Обмеження по частоті повідомлень
• Блокування повідомлень по ключовим словам
• Заміна символів двійниками
• Зміна імен полів уведення
• Заміна написів картинками з текстом
• Вбудовування полів-принад
• Побудова форми за допомогою JavaScript
• Генерування випадкових імен полів уведення
• Генерування приймаючого скрипта
• Обробка по квитках

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

Тому для захисту від автоматизованих повідомлень потрібно використовувати Капчі. Причому для більшого захисту можна використовувати їх разом з додатковими методами захисту, з числа наведених, зокрема з токенами). Головне, щоб сама капча була зроблена надійно. Про недоліки безпеки капч я і буду розповідати в Month of Bugs in Captchas.

• Так ли нужен CAPTCHA (деталі)

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.

В наш час, в епоху Web 2.0, люди починають замислюватися над майбутнім розвитком Мережі - починають замислюватися над Web 3.0. І тому останнім часом з цього приводу з’являтися публікації Інтернет діячів. Зокрема можете ознайомитися зі статтею про Web 3.0 на Wikipedia. В ній розповідається про різні погляди на третій веб, в мене ж погляди на це зовсім інші.

Сам я почав замислюватися над третім вебом ще на початку 2006 року. І не просто замислюватися - а робити реальні кроки для появи Веб 3.0. Першим з яким був мій онлайновий інтерпретатор Паскаля. Після його випуску я відніс цей веб додаток до категорії Веб 3.0 і почав бачити в третьому вебі інноваційну складову. Потім я почав посилено займатися питаннями безпеки веб сайтів (чим я займався і в 2005 і в першій половині 2006, але в другій половині 2006 я почав займатися цим більш активно). І наприкінці 2006 року я звернув увагу на іншу складову третього веба - на його безпеку.

Є дві складові Web 3.0: інновації та безпека.

Web 3.0 - інноваційний веб (Web 3.0 - innovation web).

До складової інновацій я відношу свій онлайн інтерпретатор - MustLive Perl Pascal Programs Interpreter. Це перший в світі онлайн інтерпретатор та перший Веб 3.0 додаток. Якщо у Веб 2.0 люди стали широко використовувати веб для розробки контенту в онлайні (за допомогою програмних засобів), то в Веб 3.0 люди почнуть (і вже почали) використовувати веб для розробки програм в онлайні (за допомогою онлайнових інтерпретаторів). Це наступний рівень розвитку Інтернет.

Версія 1.2 інтерпретатору в якій була додана онлайн версія вийшла 24.05.2006. Це дата початку інноваційної складової ери Web 3.0.

Web 3.0 - безпечний веб (Web 3.0 - security web).

До складової безпеки я відношу безпеку сайтів і веб додатків. Займаючись веб безпекою на протязі 2005, 2006 та 2007 років я проаналізував сучасний стан безпеки Мережі. І можу констатувати, що 90% сайтів мають уразливості безпеки (за моєю статистикою). Починаючи з відкриття мого секюріті проекту в середині 2006 року, я почав посилено займатися питаннями веб безпеки і соціальним аудитом (знаходячи уразливості на сайтах і повідомляючи про них їх адміністраторам).

І звернувши увагу на складову безпеки Веб 3.0 я виставив наступну умову: третій веб має бути більш безпечним ніж другий. Якщо зараз Веб 2.0 має 90% уразливих сайтів, то Веб 3.0 повинен мати їх 45-50% (тобто в 2 рази менше). Лише тоді можна говорити, що епоха третього вебу вже настала (в контексті безпеки). Але я розумію, що це дуже складна задача, і знаходити уразливості та їх виправляти мало хто хоче, тому процес досягнення цих показників може затягнутися, тому з часом можна підкорегувати ці вимоги і для Веб 3.0 встановити межу в 60-70% уразливих сайтів, а 40-50% вже для Веб 4.0. Головне працювати в цьому напрямку.

Свій сайт websecurity.com.ua я запустив 18.07.2006. Це дата початку складової безпеки ери Web 3.0.

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

В цьому і полягала суть мого проекту Місяць багів в Пошукових Системах - покращення безпеки Інтернету і наближення епохи Веб 3.0. І над цим я буду працювати в подальшому.

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

Локальні пошукові системи бувають декількох типів:

• власні скрипти (зроблені під сайт, в тому числі й безкоштовні скрипти),
• вбудовані пошукові движки в CMS,
• пошукові системи сторонніх виробників (як відомих пошукових систем, так і менш відомих вендорів).

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

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

Серед уразливих популярних локальних пошуковців я писав про наступні: PicoSearch, Яndex.Server (Free Edition та Enterprise), AltaVista local search engine, Google Custom Search Engine (що я оприлюднив в рамках MOSEB) та Google Search Appliance (а рік тому я писав про іншу XSS в Google Search Appliance).

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