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

В наш час, в епоху 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).

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

Продовжу тему “Warning” Гугл хакінга (”Warning” Google hacking). Котрий є різновидом Гугл хакінга - використання пошукових систем (зокрема Гугла) для пошуку уразливостей на сайтах.

Дана методика передбачає використання Гугла (чи інших пошукових систем) з метою пошуку “Warning” повідомлень на сайтах про помилки, і дозволяє знайти важливу інформацію (про дані сайти). За допомогою спеціальних пошукових запитів (дорків) можна знайти Full path disclosure та Information disclosure уразливості на різноманітних сайтах в Інтернеті.

Новий перелік “варнінг” пошукових запитів (dorks):

Warning: public_html

Warning: Division by zero

Warning: failed to open stream

Warning: filemtime

Warning: implode

Warning: mysql_fetch_object

Warning: mysql_free_result

Warning: mysql_fetch_assoc

Warning: MySQL result

Warning: fsockopen

Warning: file_exists

Warning: function

Warning: DOMDocument::loadXML

Warning: DOMDocument::load

Warning: DOMDocument

Цікава стаття на тему флеш-безпеки була опублікована Стефаном Ессером (в минулому році) - Пошук нових дір з міждоменними файлами політик Флеша.

В статті розповідається про те, як зашити crossdomain.xml у gif-файл. З метою його використання для подальших атак (CSRF) через флешки, за допомогою уразливостей в політиці безпеки Flash Player, таких як альтернативні файли безпеки.

• Poking new holes with Flash Crossdomain Policy Files (деталі)

Для того щоб перевірити, чи не був ваш емайл акаунт (в даному випадку вебмайл) похаканий, можна скористатися одним цікавим методом. В своєму записі How to check if your WebMail account has been hacked Джеремія розповів про один метод перевірки емайл акаунта на предмет прихованої активності.

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

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

2. Відіслати собі на цей емайл ящик листа з прихованим зображенням. Причому тему листа потрібно зробити дуже інтригуючою (наприклад “Your new online Bank password” ). Даного листа потрібно залиши в ящику непрочитаним.

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

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

Find security bugs in your PHP applications in an instant

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

До речі, розробники Chorizo! (Next Generation Web Application Security Scanner, як вони його називають) в себе на сайті чесно заявляють, що автоматичного сканування може не вистачити. Тобто це недостатьно ефектиний засіб, якщо ви турбуєтеся про безпеку свого ресурсу (а я регулярно навожу приклади дірок на сайтах секюріті компаній, в тому числі тих, що випускають сканери). І вони радять замовляти секюріті аудит для кращих результатів . Що і я всім раджу робити, аудит безпеки - це найбільш ефективний засіб підвищення безпеки вашого веб проекту.

Існує такий термін “Гугл хакінг” (Google hacking) - це використання пошукових систем (в першу чергу Гугла, але можна й інших систем) для пошуку уразливостей на сайтах. Давно планую розповісти вам про дану методику пошуку дірок, і раніше я вже торкався цієї теми (зокрема в записі MOSEB-20 Bonus: Google dorks strikes back), і планую ще додатково розповісти про неї.

В цій статті я розповім про методику пошуку уразливостей типу Full path disclosure та Information disclosure.

Дану методику я назвав “Warning” Гугл хакінг (”Warning” Google hacking), тому що використовується слово “Warning” для пошуку повідомлень про помилки на сайті. Які Гугл заніс у свою базу. І за допомогою спеціальних пошукових запитів можна знайти Full path disclosure та Information disclosure уразливості на різноманітних сайтах в Інтернеті.

До “варнінг” пошукових запитів відносяться наступні дорки (dorks):

Warning: home

Warning: fetch_config

Warning: mysql_num_rows

Warning: mysql_query

Warning: mysql_select_db

Warning: mysql_fetch_row

Warning: mysql_connect

Warning: mysql_close

Warning: mysql_fetch_array

Warning: mysql_result

Warning: mysql

Warning: fopen

Warning: mkdir

Warning: Permission denied

Warning: include_once

Warning: include

Warning: main

Це об’ємний, але не вичерпний перелік “warning” запитів до пошукових систем (можливі й інші запити), котрі дозволяють шукати Full path disclosure та Information disclosure дірки на веб сайтах.

На bugtraq була опублікована цікава стаття “Віддалене керування ізольованими системами”. В ній розповідається про вирішення задачі віддаленого керуваннями комп’ютером.

Подібні задачі періодично виникають перед адміністраторами, наприклад, коли потрібно отримати можливість виконати деякі команди на робочому ПК, знаходячись при цьому дома. У випадку коли використання стандартних засобів ОС для віддаленого доступу неможливе, як і використання спеціалізованих програм (PC Anywhere, RAdmin та інших), можна розробити власний додаток.

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

• Удаленное управление изолированными системами (деталі)

В записі Підводне каміння в інтернет рекламі або чим небезпечний XSS я вже згадував про те, що опублікував статтю в лютневому номері журнала Хакер Спец. В статті “Шаманские дела / Реклама с подвохом” я розповів про недоліки безпеки рекламних брокерів (зокрема XSS уразливості).

Деякий час тому редакція журналу розмістила текст номера на сайті. Тому ви можете ознайомитися з моєю статтею на сайті журналу.

Шаманские дела / Реклама с подвохом

Також в цьому номері ви можете прочитати інтерв’ю зі мною .

Жестокая правда / Интервью с аудитором по безопасности

Представляю вам інформацію про одну з сучасних проблем в веб безпеці - редиректори. Раніше я вже торкався цієї теми в новинах. Даною темою я почав цікавитися з початку вересня 2006 року (після ознайомлення зі статтями RSnake за кінець серпня початок вересня про redirection). І з того часу я провів чимало досліджень в цьому напрямку.

Редиректори - це скрипти на веб сайтах, що переадресовують на інші сайти (редиректять). А Redirector уразливості - це уразливості в веб додатках, що відносяться до класу Abuse of Functionality. За звичай дані скрипти використовують для ведення статистики, куди ж (і в якій кількості) переходять користувачі сайту. Тому в більшості випадків в якості параметра для редиректорів використувують адресу сайта, на який має перейти користувач.

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

Наведу декілька прикладів редиректорів в популярних пошукових системах. Всі наведені лінки на редиректори ведуть на websecurity.com.ua.

Редиректори в пошукових системах:

• Редиректор Google (Гугл вже виправив цю уразливість, додавши захисний механізм, але він обходиться і про це я ще розповім)
• Редиректор Google Maps
• Редиректор Yahoo
• Редиректор Meta (на Меті є чимало інших редиректорів, про що я буду розповідати)
• Редиректор Rambler

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